Blocks | 481823 |
Total BTC | 16.523M |
Difficulty | 923233068449 |
Estimated | 887736944047 in 1 blks |
Network total | 7983858.406 Thash/s |
Blocks/hour | 7.25 / 497 s |
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
Accept-Encoding: gzip
header is received.
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.
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
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:
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: []
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.
The crawler will hit this URL every 2 seconds. When an error (timeout, HTTP 5xx, ...) occurs, it'll slow down to 60 seconds eventually.
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" } ]
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.
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.
{ "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 ] ] }