Documents

• About
• Advertise on Bitcoincharts
• Information for exchanges
• Backlink Banners
• Markets API

Information for exchanges

In order to integrate with bitcoincharts your exchange is required to provide both complete trade history as well as the full orderbook. Both must conform to the format specified below and be available using HTTP(S).

As an example, your URLs could look like this:

Trade history: https//exchange.bitcoin/api/trades
Complete orderbook: https//exchange.bitcoin/api/orderbook

• The data must be JSON encoded.
• Both URLs must respond to HEAD and GET requests.
• Responses may be GZip'ed if the Accept-Encoding: gzip header is received.
• The orderbook URL may return an ETag header. In this case, a HEAD request will be sent to fetch the ETag and a GET will only be issued if it has changed. This will reduce bandwidth demands considerably.

If your markets supports multiple currencies it's best to provide data for each currency at separate URLs. E.g. /api/USD/trades, /api/EUR/trades

Once you have implemented this API send me an email at info@bitcoincharts.com and I'll add your exchange.

Error handling

Unparsable JSON responses will disable the crawler requring manual intervention. Don't let that happen.

The following HTTP error codes will disable the crawler, too: 401, 403, 404, 410

Trade history

The trade history must be an JSON array containing successive trades. Each trade must be represented by a JSON object having at least these properties:

• date - the unixtimestamp of the trade
• tid - a positive unique integer for referencing the trade
• price - the price in currency
• amount - the amount of bitcoins traded

The tid must be monotonically increasing. Gaps are allowed, however, you must not fill them in the future. If there a no trades to report, the response must be an empty array: []

Incremental updates

The URL must accept a parameter named since. since will be set to the last tid received, or 0 for bootstrapping. Your server must return trades newer than that tid. It may, however, return older trades. They will be ignored. This is mainly helps with reducing bandwidth as you'll often be returning empty arrays this way.

Timing

The crawler will hit this URL every 2 seconds. When an error (timeout, HTTP 5xx, ...) occurs, it'll slow down to 60 seconds eventually.

Example

GET https://exchange.bitcoin/api/trades?since=5

Response:
[
   {
      "tid" : 6,
      "price" : 3190.00,
      "amount" : 0.24843000,
      "date" : 1399210160
   },
   {
      "price" : 3195.00,
      "tid" : 7,
      "amount" : 0.08800000,
      "date" : 1399210708
   },
   {
      "price" : 3050.01,
      "tid" : 9,
      "amount" : 0.80000000,
      "date" : 1399213161
   },
   {
      "price" : 3195.00,
      "tid" : 10,
      "date" : 1399214944,
      "amount" : "0.05000000"
   },
   {
      "date" : 1399214983,
      "amount" : 0.00800000,
      "tid" : 17,
      "price" : "3195.00"
   }
]

Orderbook

The orderbook URL must return the full orderbook. It's an JSON object containing two properties: bids and asks Both properties consist of an array of arrays where the first element is the price and the second element is the amount.

Timing

The orderbook will be queried every 2 seconds (120 seconds with ETag). It must respond to a HEAD request. The HEAD response may contain an ETag that may be any string. If two successive HEAD requests yield the same ETag, no GET request to fetch the actual orderbook will be issued. This provides both low latency and low bandwidth consumption.

Example

{
   "bids" : [
      [ 3050.02, 0.06215041 ],
      [ 3050.01, 0.06215061 ],
      [ 3050.00, 0.07577000 ],
      [ 3010.47, 0.03280710 ],
      [ 3010.46, 1.50000000 ]
   ],
   "asks" : [
      [ 3195.00, 0.10400000 ],
      [ 3199.99, 0.25000000 ],
      [ 3200.00, 0.01879926 ],
      [ 3210.00, 0.25000000 ],
      [ 3279.98, 0.26560800 ]
   ]
}