HTX Futures

HTX Futures historical market data details - instruments, data coverage and data collection specifics

HTX Futures historical data for all its instruments is available since 2019-11-19.

https://api.tardis.dev/v1/exchanges/huobi-dmapi.tardis.dev

See HTX Futures historical data coverage: available symbols, channels, date ranges and incidents

Downloadable CSV files

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
incremental_book_L2	BTC_CQ	2020-02-01	Download sample
trades	BTC_CQ	2020-02-01	Download sample
derivative_ticker	BTC_CQ	2020-07-01	Download sample

API Access and data format

Historical data format is the same as provided by real-time HTX 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

# 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="2024-01-01",
    to_date="2024-01-02",
    filters=[Channel(name="depth", symbols=["BTC_CW"])]
  )

  # messages as provided by HTX Futures real-time stream
  async for local_timestamp, message in messages:
    print(message)


asyncio.run(replay())

See Python client docs.

Node.js

cURL & HTTP API

cURL & tardis-machine

Captured real-time channels

https://www.htx.com/en-us/opend/newApiPages/?id=447www.htx.com

See HTX Coin-M Futures WebSocket API docs providing documentation for each captured channel's format

Click any channel below to see HTTP API response with historical data recorded for it.

• trade Trade executions stream

• depth Order book snapshots and incremental updates stream. Order book integrity is validated using sequence numbers (version field) — on missed message the WebSocket connection is restarted. See also details below regarding depth channel data collection details.

• bbo — available since 2020-06-23 Best bid and ask quote updates stream

• liquidation_orders — available since 2020-06-23 Liquidation events stream

• contract_info — available since 2020-06-23 Contract definition and status updates stream

• basis — available since 2020-06-23 Basis and index price updates stream

• open_interest — generated channel, available since 2020-06-23 Generated open interest snapshots from REST endpoint every 4-6 seconds per instrument. Messages are marked with "ch":"market.<symbol>.open_interest" and "generated":true fields and data field has the same format as REST API response data.

• detail 24h contract statistics stream

• elite_account_ratio — generated channel, available since 2020-10-29 Generated elite account long/short ratio snapshots from REST endpoint using 5min period buckets.

• elite_position_ratio — generated channel, available since 2020-10-29 Generated elite position long/short ratio snapshots from REST endpoint using 5min period buckets.

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 used the depth.step0 channel for collecting order book data, which means an order book update message has the update flag 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 the same (tick.bids, tick.asks, etc.).

Please feel free to contact us if it's confusing in any way.

We also provide a normalization layer that handles those differences transparently via our client libs.

Market data collection details

Market data collection infrastructure for HTX Futures is located in GCP asia-northeast1 (Tokyo, Japan).

Real-time market data is captured via multiple WebSocket connections to wss://api.hbdm.vn/ws (proxied via Cloudflare).

HTX servers are located in AWS ap-northeast-1 region (Tokyo, Japan).