Markets perform beautifully an essential function: provide the place where supply and demand meet.
A place where market participants can interact with each other. Every market has its own rules. Rules that vary from what is needed for an offer to be valid (quantity, price, etc.), to how supply and demand meet (auction-style, direct exchange-style, etc.).
Although the essence of the market has not changed since the ancient times, at least two elements have. First, most components of the market are now automated and machine-driven. Second, participants have evolved. Today, not only humans can interact, but also machines, leading to a new type of interactions: machine-to-machine.
In this context, most markets have their own Application Progamming Interface (API), a machine-to-machine cornerstone, providing the entry point for any machine-based operations.
Our algorithmic solution has been interacting, on a daily basis, with more than ten crypto exchanges for almost two years. We have spent time to understand the specificities of those rules for every market.
The objective is to help you navigate the crypto trading API ecosystem, on our scope, and potentially give you some directions on what can suit you best.
Here is our humble and wrapped overall feedback for the following APIs.
Binance
Wow!
>REST
- Great overall design / architecture
- Outstanding ecosystem, tons of libraries in many languages
- When an order is filled (even partially) instantly, the details of the order (price, volume, etc.) comes directly in the response of the request
Not wow!
>Websocket
- Orderbook data feed needs to be initialised with a REST call GET /api/v3/depth
>REST
- Fees are wrapped in a specific object called “trade”, not in the “order” object itself
Bitstamp
Wow!
>REST
- Very straightforward design / architecture
- Great for beginners
- Direct integration with the XRP Ledger / Allowing off and on-ledger deposits and withdrawals
Not wow!
- Documention is “just enough”, lacking, for example, a table of contents
>Websocket
- Orderbook data feed needs to be initialised with a REST call GET /api/v2/order_book
- Read-only mode (for sweet latency: use FIX interface)
Bittrex
Wow!
>REST
- Great overall design / architecture (v3 solved architecture issues the v1 had)
Not wow!
>Websocket
- Orderbook data feed needs to be initialised with a REST call GET /markets/{marketSymbol}/orderbook
- Specific workaround to get the sequence number from the header of the GET /markets/{marketSymbol}/orderbook
- Read-only mode
Coinbase Prime
Wow!
- Great documentation
>REST
- Best-in-class design / architecture (HTTP Verbs, endpoint naming, and format consistency)
- Libraries generally initiated / created by Coinbase
Not wow!
- Consistent downtimes during key trading events
>Websocket
- Read-only mode (for sweet latency: use FIX interface)
COINFLOOR
Wow!
>Websocket
- Trading features available
Not wow!
- No API key / secret key request signature, the account’s password is used to authentify the request in a standard base64 Authorization: basic header
>Websocket
- “Scale” system: numbers are not raw like in many APIs, but need to be converted (ex: £ has a scale of 100, so if £123.22 is needed, the API needs to receive 12322 in the request)
- No direction (buy or sell) option in the order, but a create order request where the volume should be positive (buy) or negative (sell)
- WARNING: when listening to the orderbook updates, a notification will be received for all orders that are created, INCLUDING THOSE THAT WILL HIT THE EXISTING BID(S) OR ASK(S). This flow creates a new transitional state between two orderbooks: 1 (initial orderbook) > 2 (orders that hit existing offers) > 3 (updated orderbook). Instead of 1>3 like in many major exchanges.
>REST
- A “BIST” API that emulates Bitstamp’s v1 API. In general, the endpoints are “just enough” but have some annoying specificities:
- A currency pair in the URL must be specified: as a result open orders for different pairs can’t be listed in one request
- No request to get the order details by providing its ID: workaround, list all open orders, and if the order is filled or cancelled, list all past transactions
- The documentation has some inconsistencies and errors (ex: HTTP verbs)
Deribit
Wow!
- Documentation is simple but still providing an example for every use case
- Using JSON-RPC: almost everything can be sent as a HTTP request or through Websocket request
Not wow!
>Websocket
- The connection needs (at first sight) to send at least one request every 10 min (heartbeat function can be used) or the connection will be closed by the server: be careful when using the feature “Enable Cancel On Disconnect” (all orders created by the connection will be removed when connection is closed)
Kraken
Wow!
>Websocket
- Trading features available: highly recommanded to avoid some Cloudflare errors on critical trades
>REST
- Place / cancel order calls can’t be overloaded
- Nonce system that forces all orders to be received sequencially by the plateform: can be usefull if a sequential order matters for your app
- Ability to request all the recent trades executed on a specific market on a public endpoint: very usefull for data analysis and order flow analysis
Not wow!
- Inconsistencies for the assets and pair names, especially between Websocket and REST API: XXBTZEUR becomes XBTEUR or XBT/EUR, etc.
>REST
- WARNING: the infamous 520 HTTP error! Not especially a Kraken problem but more a Cloudflare one, blocking HTTP calls at random moments. The situation is better now than 2 years ago. If reactivity is needed in crucial times (ex: high volatility), just use the Websocket
Okex
Wow!
- Great documentation overall, snippets of code, requests, responses
>Websocket
- Checksum of the orderbook directly inside the orderbook data feed
>REST
- High-level design / architecture (endpoint naming, format consistency)
- Overall great possibilities, like ammending an order, algo orders, etc.
Not wow!
>Websocket
- Read-only mode
>REST
- WARNING: sometimes when an order is sent, the server will respond with a trade ID “-1”. That means that the order was NOT placed in the matching engine, due to reasons only known by Okex itself. In this case, the order must be sent again
Poloniex
Wow!
>REST
- Very straightforward design / architecture
- Great for beginners
- Possibility to move a pending order in one endpoint
Not wow!
>Websocket
- Read-only mode
>REST
- Getting the details of an order may need two different endpoints, depending whether the order is closed or not
By Didier Pironi and Arthur Gallouin
About us
Suiteki develops and runs crypto algorithmic solutions.
Disclaimer
Suiteki does not endorse or promote any of the projects or cryptocurrencies mentioned in this blogpost. Any descriptions of functionality and services provided are for information only. Suiteki is not responsible for any loss of funds or other damages caused as a result of using the projects described above.
