To illustrate CoralMD, we launched a free server that provides aggregated and per exchange real-time Bitcoin market data. The exchanges we are currently connected to are: Coinbase and Okcoin. Below we explain the three choices of API and protocol you can use to receive live market data updates.

HTTP

Browsers and other http clients can make requests to the URLs below to get a full market data book snapshot in JSON format. The server caches the response for 2 seconds, so any successive requests less than 2 seconds apart will return the same data. This is enough for GUIs and other higher-latency applications. For low-latency real-time updates you should use the TCP or the FIX API.

{
    "success":			true,
    "last updated":		"20151022-03:28:18.676",
    "time zone":		"America/New_York",
    "symbol":			"BTC-USD",
    "exchange code":		"AGGR",
    "exchange name":		"Aggregated",
    "spread":			-2.06,
    "best bid size":		0.02000000,
    "best bid price":		270.60,
    "best ask size":		0.90000000,
    "best ask price":		268.54,

    "bids": [

        [ "BASE",		0.02000000,		270.60],
        [ "BASE",		0.02000000,		270.59],
        [ "BASE",		0.02000000,		270.58],
        ...
    ],

    "asks": [

        [ "OKCN",		0.90000000,		268.54],
        [ "OKCN",		0.86100000,		268.58],
        [ "OKCN",		2.34470000,		268.60],
        ...
    ]
}

FIX

We use FIX version 4.4. The standard FIX header (i.e. BeginString, MsgType, MsgSeqNum, SenderCompID and SendingTime) must be present in every message. The SenderCompID is your username. Click here to contact us and get the host, port, username and password to connect. Messages not specified below (i.e. Heartbeat, Test Request, etc.) follow the standard FIX format.

You use the Logon message to start a FIX session with the server. The server will reply with a Logon message to indicate that the logon was successful or with a Logout message to indicate that there was a problem with the logon.
          

The Logout message can be sent by the client to gracefully disconnect or it can be sent by the server to indicate that a logon attempt was not successful. In that case you should check the Text tag for clues.
          

The MarketDataRequest message can be sent by the client to subscribe to market data. The server supports subscription to all securities or individual subscriptions. The client can also use this message to unsubscribe. If the subscription is successful, the client will receive a MarketDataSnapshotFullRefresh with the book. When unsubscribing, the client will receive a MarketDataSnapshotFullRefresh with an empty book if successful.
          

The MarketDataRequestReject message is sent back by the server when it cannot process the MarketDataRequest sent by the client. It contains the reason why the request was rejected.
          

The MarketDataSnapshotFullRefresh message is sent by the server to provide the full market data book for a security. The server sends only one MarketDataSnapshotFullRefresh per symbol, never two symbols in the same message. This message is only sent as a response for a MarketDataRequest message. When processing this message, the client should clear his book before adding the orders.
          

The MarketDataIncrementalRefresh message is sent by the server to provide incremental updates for subscribed securities. Updates for more than one symbol can come on the same message. It is also used to indicate a live trade and to signal that a book for a security should be cleared.
          

TCP

For low-latency you should use our TCP API which is shorter and faster than FIX. It uses a byte-payload protocol where the first byte contains the size of the payload that follows. All binary numbers follow the big-endian network format. If you are using Java, you can use the ByteBuffer methods getShort (2 bytes), getInt (4 bytes) and getLong (8 bytes) to read binary numbers. The “Z” message (batch end) is always sent after previous update messages to denote that a full batch update has been sent by the server. That way the client might choose to take action only after a full batch has been received instead of taking action on individual updates. (Note: For FIX you can assume that each MarketDataIncrementalRefresh message contains a batch)

The Login message must be the first message sent by the client to the server upon connection. It provides username, password and the heartbeat interval the client wants to configure. The server will reply with an 'L' message back (without any fields) to indicate that the login was successful.
          

The server can send an error message to indicate any error condition like for example if the client can't be authenticated. It contains a text message with the details about the error. The text field does not have a fixed length. Its length will be the remaining of the message.
          

The client sends a SubscribeAll message to receive updates for all books. The server will reply with another 'A' message back if the subscription was successful. The client will receive all open orders from all books immediately after subscribing to all, so it should clear its books before sending this message. (Note: The subscription confirmation ('A' back) is sent by the server only after all orders are resent to the client)
          

The client sends an UnsubscribeAll message to stop receiving updates for all books. The server will reply with another 'X' message back if the unsubscribe request was successful. The client should clear all its books after receiving the unsubscribe confirmation back from the server.
          

The client sends a Subscribe message to subscribe for updates for a single symbol. The server will reply with another 'S' message back if the subscription was successful. The client will receive all open orders for the requested symbol immediately after sending the subscription, so it should clear its book before sending this message. (Note: The subscription confirmation ('S' back) is sent by the server only after all orders for the symbol are resent to the client)
          

The client sends an Unsubscribe message to stop receiving updates for the provided symbol. The server will reply with another 'U' message back if the unsubscribe request was successful. The client should clear the book for the symbol after receiving the unsubscribe confirmation back from the server.

The client should send a heartbeat message after a period of inactivity, in other words, after a period of silence when it hasn't sent any messages to the server. The heartbeat period is configured in the Login message. If the server does not receive any message after the heartbeat interval it disconnects the client due to a read timeout. The server also sends heartbeats to the client.

The server sends a NewOrder message to indicate that a new order was added to the book.

The server sends a OwnOrder message to indicate that this order should be marked as mine.

The server sends a ModifyOrder message to indicate that an order was modified and should be updated in the client book. This message has the same format as the NewOrder message, with a different type ('M' instead of 'N').

The server sends a RemoveOrder message to indicate that an order was deleted and should be removed from the client book.

The server sends a BatchEnd message to indicate that it has sent a full batch of book changes. The client might want to take action only after a full batch has been received instead of taking action on each individual book update. A client can assume that it will always receive a 'Z' message after one or more book update messages.

The server sends a LiveTrade message to indicate that a trade in one of the exchanges has occured.

The server sends a ClearBook message to indicate that the client should clear all orders belonging to this feed ID for the given symbol.

The server sends a ClearBookByExchange message to indicate that the client should clear all orders belonging to this feed ID and exchange ID for the given symbol.