Coinbase Pro API Review
By XTRD CTO Serg Gulko
Like most people, my first impressions are based on visual appeal. Yes, I realize that it might be the wrong approach to judge a book by it’s cover, but it’s hard to beat human nature.
As part of the crypto exchange integration process at XTRD, we usually familiarize ourselves with the exchange’s provided user interface, support systems, communication channels, public documentation, and so on. I remember that the day we started working on Coinbase Pro, I posted a long and exciting speech in the internal employee group chat about my findings.
After dozens and dozens of clunky, sometimes even absurd GUIs I’ve witnessed, Coinbase Pro was like a breath of fresh air. Everything was so polished, so smooth (no, smooooooth), and worked so intuitively, that I said — “guys, that’s why Coinbase is one of most popular platforms to trade crypto. Yes, fees are high but you enjoy the process. It’s like a switchover from an old Soviet Union “Zhuguli” to Mercedes Benz. Look, they even have a FIX API!”.
But then we started working with Conbase’s API. First impressions can be deceiving. Below is the list of things that puzzled us (and which we solved).
Your order is not yours
The FIX protocol defines a special field called ClOrdId (Client Order ID) to carry client-assigned IDs of his/her orders. The client’s OME/EMS (order/execution management system) uses these unique IDs to track each order individually for many reasons. It could be execution, reporting, accounting, or of the above.
When the server receives and accepts the client’s order, it assigns its own ID to the order (transmitted using field OrderID). This is completely reasonable because you can’t rely on a counterparty to track orders. Your system, your rules, your order IDs.
Unfortunately, in Coinbase Pro, a client’s order IDs are not really clients’. In accordance with their rules, the field ClOrdId should contain a UUID string (something like this 58d1f436–6a53–11eb-9439–0242ac130002).
Any attempts to send something different — numbers (1,2,3…), strings (my_super_order_1, cool_order_132) or any other forms of IDs will be rejected. This means that your OMS/EMS should discard the existing methodology of client side ID generation (database IDs, timestamps, random strings, and so on) and start using Coinbase Pro rules. Time to rename ClOrdId to CoinbaseClOrdId!
Wait, UUID is not that bad for ID management, there are several other exchanges that use it. Why not adopt it and stop complaining?
Because there is another surprise with ClOrdIds on Coinbase Pro! Once an order is confirmed and you received the first ExecutionReport with OrderID, you’ll never see your IDs again. Any following update attempts to extract a list of open orders or trading history — everything will contain only the Coinbase-assigned ID.
So there are challenges to solve:
- adopt your OMS/EMS to use UUIDs or build a mapper between your native IDs and what you send to Coinbase
- build a matching mechanism that allows identifying orders using only OrderID and links it to ClOrdIds
Needless to say, our clients simply don’t know about the twists and turns of this plot. XTRD’s FIX API is designed in a way that doesn’t limit you or creates additional obstacles to solve. Your system, your orders, your rules.
XTRD allows the assignment of any type of IDs — numbers or strings. Each ExecutionReport (if successful) contains an OrderID (ID in our system, always a number), and an exchange-assigned ID (could be anything) that can be used for cross-checks between internal and exchange systems for a binary, synergistic execution verification and audit.
As a final word: Coinbase Pro is a fantastic product and a great exchange to trade on — it’s normal that some parts of a very complex offering have minor rough spots.
XTRD’s job is to ensure that our clients’ awareness of integration difficulties only exists from our complaints in articles!