Huobi Futures
Huobi Futures historical market data details - instruments, data coverage and data collection specifics
Huobi Futures historical data for all it's instruments is available since 2019-11-19.
https://api.tardis.dev/v1/exchanges/huobi-dm
api.tardis.dev
See Huobi Futures historical data coverage: available symbols, channels, date ranges and incidents
Historical CSV datasets for the first day of each month are available to download without API key.
See downloadable CSV files documentation.
Derivative ticker datasets are available since 2020-06-24.
data type | symbol | date | |
trades | BTC_CQ | 2020-02-01 | |
incremental_book_L2 | BTC_CQ | 2020-02-01 | |
book_snapshot_25 | BTC_CQ | 2020-02-01 | |
quotes | BTC_CQ | 2020-02-01 | |
derivative_ticker | BTC_CQ | 2020-07-01 | |
trades | FUTURES | 2020-03-01 | |
liquidations | FUTURES | 2021-09-01 |
Historical data format is the same as provided by real-time Huobi Futures WebSocket API with addition of local timestamps. If you'd like to work with normalized data format instead (same format for each exchange) see downloadable CSV files or official client libs that perform data normalization client-side.
Python
Node.js
cURL & HTTP API
cURL & tardis-machine
# pip install tardis-client
import asyncio
from tardis_client import TardisClient, Channel
tardis_client = TardisClient(api_key="YOUR_API_KEY")
async def replay():
# replay method returns Async Generator
messages = tardis_client.replay(
exchange="huobi-dm",
from_date="2020-02-01",
to_date="2020-02-02",
filters=[Channel(name="depth", symbols=["BTC_CW"])]
)
# messages as provided by Huobi Futures real-time stream
async for local_timestamp, message in messages:
print(message)
asyncio.run(replay())
// npm install tardis-dev
const { replay } = require('tardis-dev');
async function run() {
try {
const messages = replay({
exchange: 'huobi-dm',
from: '2020-02-01',
to: '2020-02-02',
filters: [{ channel: 'depth', symbols: ['BTC_CW'] }],
apiKey: 'YOUR_API_KEY'
});
// messages as provided by Huobi Futures real-time stream
for await (const { localTimestamp, message } of messages) {
console.log(localTimestamp, message);
}
} catch (e) {
console.error(e);
}
}
run();
curl -g 'https://api.tardis.dev/v1/data-feeds/huobi-dm?from=2020-02-01&filters=[{"channel":"depth","symbols":["BTC_CW"]}]&offset=0'
https://api.tardis.dev/v1/data-feeds/huobi-dm?from=2020-02-01&filters=[{%22channel%22:%22depth%22,%22symbols%22:[%22BTC_CW%22]}]&offset=0
api.tardis.dev
Example API response for Huobi Futures historical market data request
curl -g 'localhost:8000/replay?options={"exchange":"huobi-dm","filters":[{"channel":"depth","symbols":["BTC_CW"]}],"from":"2020-02-01","to":"2020-02-02"}'
Tardis-machine is a locally runnable server that exposes API allowing efficiently requesting historical market data for whole time periods in contrast to HTTP API that provides data only in minute by minute slices.
Huobi API Reference v1.0
See Huobi Futures WebSocket API docs providing documentation for each captured channel's format
- depth During data collection integrity of order book incremental updates is being validated using sequence numbers provided by Huobi Futures real-time feed (
versionfield) - in case of detecting missed message WebSocket connection is being restarted. See also details below regarding depth channel data collection details. - open_interest - generated channel, available since 2020-06-24 Since Huobi Futures does not offer currently real-time WebSocket open interest channel, we simulate it by fetching that info from REST API (https://huobiapi.github.io/docs/dm/v1/en/#get-contract-open-interest-information) every 4-6 seconds for each instrument. Such messages are marked with
"ch":"market.<symbol>.open_interest"and"generated":truefields anddatafield has the same format as REST API response data.
Up until 2020-01-31
depth channel was collected with step0 aggregation level (no aggregation) which produces full order book snapshots for each book change which is very inefficient to store. To circumvent this issue we stored only initial book snapshots and then incremental updates instead - incremental updates were calculated by diffing two subsequent book snapshots and provided in the same format as other depth messages, except having additional update: true flag set as in snippet below. Update with amount (second value in array) set to 0 means such level should be deleted, otherwise price level should be updated with new amount value.{
"ch": "market.ETC_CW.depth.step0",
"ts": 1572652860024,
"update": true,
"tick": {
"mrid": 24660973159,
"id": 1572652860,
"bids": [
[
4.869,
1175
]
],
"asks": [],
"ts": 1572652860013,
"version": 1572652860,
"ch": "market.ETC_CW.depth.step0"
}
}
On 2020-01-31 we've switched to
depth.size_150.high_freq channel instead when collecting data and which natively provides incremental order book updates without workarounds described above.Unfortunately it means that when requesting data for
depth channel it may return slightly different format depending for which time period request was made. It's only slightly different and boils down to the way order book update messages are marked vs order book snapshots. In depth.size_150.high_freq order book message has event field always present with value update or snapshot, for example:{
"ch": "market.LTC_CW.depth.size_150.high_freq",
"tick": {
...
"event": "update",
...
}
}
For messages before 2020-01-31 we've used
depth.step0 channel for collecting order book data which means order book update message has flag update set to true, if it's a snapshot it doesn't have that flag at all, for example:{
"ch": "market.ETC_CW.depth.step0",
"update": true,
"tick": {
...
}
}
All other fields are are the same (tick.bids and tick.asks etc).
We also provide normalization layer that handles those differences transparently via our client libs.
Market data collection infrastructure for Huobi Futures since 2020-06-19 is located in GCP asia-northeast1 (Tokyo, Japan), before that it was located in GCP europe-west2 region (London, UK).
Real-time market data is captured via multiple WebSocket connections.
Huobi servers are located in AWS ap-northeast-1 region (Tokyo, Japan).
Last modified 9d ago