<p>I have worked through BTCChina's FIX APi (using their java example).  Creating a subscription request message such as:</p>

<pre><code>public static Message marketDataIncrementalRequest(String symbol) {
    quickfix.fix44.MarketDataRequest tickerRequest = new quickfix.fix44.MarketDataRequest();

    quickfix.fix44.MarketDataRequest.NoRelatedSym noRelatedSym = new quickfix.fix44.MarketDataRequest.NoRelatedSym();
    noRelatedSym.set(new Symbol(symbol));
    tickerRequest.addGroup(noRelatedSym);

    tickerRequest.set(new MDReqID("123"));      
    tickerRequest.set(new SubscriptionRequestType('1'));
    tickerRequest.set(new MarketDepth(0));

    addMDType(tickerRequest, '0');
    addMDType(tickerRequest, '1');
    addMDType(tickerRequest, '2');

    return tickerRequest;
}
</code></pre>

<p>The above message request is documented to provide full orderbook + trades snapshot + incremental refresh.  Unfortunately it just provides top-of-book with no sizes + trades with no size.   I suspect their FIX server implementation is not complete.  The same standard FIX message on OKCoin, works fine, providing full book.</p>

<p>The alternative API via websockets provides a call to get depth of book, however, according to documentation only provides 5 levels.</p>

<p>Various real-time OB viewers are showing deeper-than-5 depth, so assume there is an API for this.   Can anyone point me in the right direction?</p>

CC BY-SA 3.0
2015-02-18T18:39:11.027Z
Have you got this to work using FIX? I have the same problem.
James Moore
CC BY-SA 3.0
2015-02-18T22:19:39.520Z
No, unfortunately not.  BTC China seems to be ignoring it.  Their web socket API may provide a reasonable alternative.  I have not looked at it yet.
Jonathan Shore
CC BY-SA 3.0
2015-03-02T15:03:45.570Z
Ended up using their REST API and polling periodically (why do bitcoin exchanges use something so inefficient, very poor design).
Jonathan Shore
<exchanges><live-data><market-depth>
How to get BTCChina full Orderbook (FIX or alt API)
Jonathan Shore
# How to get BTCChina full Orderbook (FIX or alt API)

(Asked by: username_0 on 2015-02-08)

I have worked through BTCChina's FIX APi (using their java example).  Creating a subscription request message such as:
public static Message marketDataIncrementalRequest(String symbol) {
    quickfix.fix44.MarketDataRequest tickerRequest = new quickfix.fix44.MarketDataRequest();

    quickfix.fix44.MarketDataRequest.NoRelatedSym noRelatedSym = new quickfix.fix44.MarketDataRequest.NoRelatedSym();
    noRelatedSym.set(new Symbol(symbol));
    tickerRequest.addGroup(noRelatedSym);

    tickerRequest.set(new MDReqID("123"));      
    tickerRequest.set(new SubscriptionRequestType('1'));
    tickerRequest.set(new MarketDepth(0));

    addMDType(tickerRequest, '0');
    addMDType(tickerRequest, '1');
    addMDType(tickerRequest, '2');

    return tickerRequest;
}

The above message request is documented to provide full orderbook + trades snapshot + incremental refresh.  Unfortunately it just provides top-of-book with no sizes + trades with no size.   I suspect their FIX server implementation is not complete.  The same standard FIX message on OKCoin, works fine, providing full book.
The alternative API via websockets provides a call to get depth of book, however, according to documentation only provides 5 levels.
Various real-time OB viewers are showing deeper-than-5 depth, so assume there is an API for this.   Can anyone point me in the right direction?

**Tags:** exchanges, live-data, market-depth

> **Comments:**
> **username_1**: Have you got this to work using FIX? I have the same problem.  
> **username_0**: No, unfortunately not.  BTC China seems to be ignoring it.  Their web socket API may provide a reasonable alternative.  I have not looked at it yet.  
> **username_0**: Ended up using their REST API and polling periodically (why do bitcoin exchanges use something so inefficient, very poor design).  

---

## 0 answers

