| Version | Date | Comments |
|---|---|---|
| 1 | 25/11/2019 | First public version |
CryptoCompare offers industry standard FIX connectivity based on an unmodified FIX 4.4 for market data access. Low latency live streaming trade and orderbook data is available for a number of exchanges.
To gain access to CryptoCompare FIX connectivity, please contact us by email.
This document serves as a developer guide for integrating with the FIX streaming service.
Once access has been granted, connectivity can be established by connecting to fix.cryptocompare.com:8200.
A standard FIX4.4 dictionary is required for connectivity. In addition, for QuickFIX library users, we provide a sample connection configuration file.
Each client will have to modify the SenderCompID field within this config to match their uniquely provided ID. This will be provided by CryptoCompare when a client has been successfully provisioned for access.
Unlike traditional FIX venues which only provide data from one source, CryptoCompare offers market data from many different exchange venues. As such, when requesting market data subscriptions, the source venue should be supplied as part of the market identifier. A market identifier (refered to hereafter as Symbol) is comprised of an exchange or venue name with the instrument from and to parts.
Symbol format with both an Exchange and Market:
ExchangeName~FromSymbol~ToSymbol
A Symbol may also contain an exchange name without a market.
ExchangeName
When requesting data from the FIX endpoint, the client should send a MarketDataRequest (V) message. Three stream types will be available through this endpoint: trade and orderbook level 1 & 2. The type of data being requested should be indicated in the MDEntryType (269) field in line with the FIX documentation, with the addition of setting the MarketDepth (264) field to '1' for level 1 orderbook Data. In order to distinguish between level 1 & 2 orderbook data, we mark each level 1 message by writing "TOB" into the 'text' field.
FIX connectivity relies on an unmodified FIX 4.4 dictionary, an API key for authentication and IP whitelisting.
The idealised message flow on connection is as follows.
| Client | Message | Direction | Server |
|---|---|---|---|
| Logon | -> | ||
| Logon (Response) | <- | ||
| SecurityListRequest | -> | ||
| SecurityList | <- | ||
| MarketDataRequest | -> | ||
| MarketData | <- |
On establishing a TCP connection, the connecting FIX client is expected to send a Logon (A) message as the first message. It is expected that the password field of the Logon message will contain the API key.
The server will respond with a Logon should the connection be established successfully or a LogOut (5) otherwise.
Once the connection is established, to establish what Symbols are available, the client is expected to send a SecurityListRequest (x) message.
The server will respond with a SecurityList (y) message with status information in the SecurityRequestResult field.
SecurityList messages have 3 types:
- VALID_REQUEST (0) - The request was successful and the instrument list is attached to this message.
- INSTRUMENT_DATA_TEMPORARILY_UNAVAILABLE (4) - Backend components are currently initialising. The client should wait 2 seconds then re-send the request.
- NOT_AUTHORIZED_TO_RETRIEVE_INSTRUMENT_DATA (3) - The API key for the request was invalid. The client will need to logoff then logon with a valid API Key.
Please note, only a single concurrent connection is supported per API key.
Based on the Symbols returned in the SecurityList it is possible to subscribe using a Market Data Request (V) message with Symbols formatted as per Market representations defined above.
Once one or more valid subscriptions have been established to valid markets, the client will receive regular Market Data (W) messages whenever market updates occur.
Other message types are unsupported at this time.