Pulling structured data out of HTX without breaking when prices move

HTX (formerly Huobi, rebranded September 2023, per CoinDesk's coverage at the time) runs spot, margin and derivatives books that print fills around the clock. The app describes itself as "trusted industry leader with over 20 million users worldwide" listing "more than 1,000 types of cryptos" — a self-description from the Play Store listing, not an independently audited figure. A third party that needs to read account state out of it for tax, treasury, audit or risk is reading a moving target, not a daily statement. The integration question is which surface to pull from and how to keep that pull stable through HTX's own change-log cadence.

At a glance

What's inside HTX worth reading

The data domains a typical integrator actually wants out of HTX, mapped to where they live in the app and what they get used for:

Once those domains are flattened into a stable internal schema, they look the same shape no matter which HTX product they came from — which matters when the customer's downstream code already speaks a portfolio model:

{
  "account": { "asset": "USDT", "balance": "1234.5678", "frozen": "0.0", "type": "spot" },
  "order":   { "id": "1234567890", "symbol": "btcusdt", "side": "buy",
               "price": "67234.5", "amount": "0.01", "state": "filled",
               "filled_amount": "0.01", "filled_cash_amount": "672.345",
               "created_at": "2026-05-19T12:34:56Z" },
  "transfer":{ "asset": "ETH", "amount": "0.5", "direction": "deposit",
               "tx_hash": "0xabc...", "confirmations": 32, "credited_at": "..." }
}

Illustrative — field names confirmed against the wire during the build.

On the wire

A minimum-viable HTX read against the spot REST surface looks roughly like the snippet below. The shape is the same one the studio's deliverable wraps; the v2 WebSocket channel reuses the same key and signature method.

# Illustrative HTX REST: fetch spot account balances with a read-only key.
import hmac, hashlib, base64, urllib.parse, datetime, requests

ACCESS_KEY = "<KEY>"     # provisioned in the account holder's HTX dashboard
SECRET_KEY = "<SECRET>"  # read-only; withdraw scope OFF
HOST       = "api.huobi.pro"

def signed_get(path, params=None):
    params = params or {}
    params.update({
        "AccessKeyId":      ACCESS_KEY,
        "SignatureMethod":  "HmacSHA256",
        "SignatureVersion": "2",
        "Timestamp":        datetime.datetime.utcnow().strftime("%Y-%m-%dT%H:%M:%S"),
    })
    qs   = urllib.parse.urlencode(sorted(params.items()))
    base = "GET\n" + HOST + "\n" + path + "\n" + qs
    sig  = base64.b64encode(hmac.new(SECRET_KEY.encode(),
                                     base.encode(),
                                     hashlib.sha256).digest()).decode()
    url  = f"https://{HOST}{path}?{qs}&Signature={urllib.parse.quote(sig, safe='')}"
    return requests.get(url, timeout=10).json()

acct_id  = signed_get("/v1/account/accounts")["data"][0]["id"]
balances = signed_get(f"/v1/account/accounts/{acct_id}/balance")

# WebSocket /ws/v2 reuses the same key shape (signature method v2.1, per HTX's
# WebSocket announcement). The server pings every ~20s; the client MUST pong
# with the same timestamp or the connection drops mid-session.

How we pull it

Three routes carry the work, with one as the spine:

1. Authorized REST + WebSocket integration against HTX's spot and derivatives endpoints

The customer provisions a read-only key in their HTX dashboard, the studio wraps it. Reaches: balances, orders, fills, deposit and withdrawal history, public market data, derivatives positions. Effort is low for read-only and a working week typically covers the SDK wrapper, the WebSocket reconnect logic and the test rig. Durability is medium — HTX has shifted signature methods and rate-limit policy in the past per its own support announcements, so the maintenance line on the engagement carries a re-pin step for those events.

2. Authorized interface integration / protocol analysis of the HTX app

For surfaces the wire API does not cover — promo balances, on-app rewards, the in-app KYC-tier display, certain region-specific announcements — the studio captures the in-app calls under the account holder's consent, classifies them, and ships a typed wrapper in the same SDK. The output schema matches the live REST feed.

3. Native exports (CSV) for deep history

HTX's REST order-history endpoint is published as a 48-hour window. For one-shot historical pulls older than that, the studio scripts the in-app/web export-and-normalize so it lands in the same shape as the live feed, and the live feed is then responsible only for deltas from cut-over forward.

In practice the studio ships route 1 for everything that flows day to day, route 3 once at the start to seed historical state, and route 2 only when the customer's product team specifically needs a screen the API does not cover.

What lands in your repo

• An OpenAPI 3.1 specification covering the HTX surfaces the integration wraps — REST endpoints, the v2 WebSocket envelope, and the in-app calls (where used).
• Runnable Python and Node SDKs with HMAC-SHA256 signing, the WebSocket pong responder, exponential reconnect, and rate-limit back-off keyed to HTX's published per-endpoint limits.
• A normalization layer that flattens HTX's wire schema into a stable internal one — a HTX field rename in the future does not propagate into the customer's warehouse.
• A test suite that runs against a read-only key on a low-balance HTX account, plus a record/replay rig for the WebSocket so CI does not have to talk to the live exchange on every PR.
• An interface document mapping each in-app screen to the wire call behind it — handy when the customer's product team needs to ship the same data the app shows.
• A short compliance brief: key scope, token storage, audit log layout, retention defaults, NDA template if the engagement uses one.

Consent, keys, jurisdiction

HTX operates through multiple regional entities and its regulatory picture is genuinely mixed. The Seychelles Financial Services Authority published a public alert stating that Huobi Global Limited held no Seychelles VA/VASP licence and had been struck off the IBC register in October 2023. HTX itself has stated, in industry coverage and its own materials, that it operates licensed entities in Dubai under VARA and obtained a No-Objection Certificate from Pakistan's PVARA in 2025. We treat all of that as background, not as the basis for the integration.

The dependable basis the studio actually relies on is the account holder's own consent: the customer generates the API key inside their own HTX dashboard, scopes it read-only, can revoke it at any time, and we log every call the integration makes against that key. Data minimization is the default — the wrapper only retrieves the fields the customer's application actually consumes, and storage defaults to the customer's environment, not ours. Where the engagement involves the in-app surface (route 2) the studio works under the account holder's written authorization captured at onboarding, treating the integration as data extraction for interoperability rather than circumvention of any control.

Engineering details we plan for

• The 48-hour order-history window. HTX's GET /v1/order/history is documented as covering the recent 48 hours. We layer in /v1/order/orders with start-time / end-time slices, persist the result on the customer's side, and reconcile it against subsequent live deltas — so the integration does not silently truncate older trades.
• WebSocket signature drift. HTX moved signed connections onto /ws/v2 with the v2.1 HmacSHA256 signature method per its own support announcement, and the server pings every roughly 20 seconds — a missed pong drops the session. The deliverable includes the pong responder and the reconnect loop, and the maintenance line keeps the signer pinned to whatever HTX has currently published.
• Per-endpoint rate-limit policy. HTX has published rate-limit changes against parts of the REST surface (e.g. tightening on order endpoints). The SDK reads back-off from a config table rather than hard-coding, so the studio can roll a config change instead of a code change when HTX posts a new policy.
• Post-incident key hygiene. The September 2023 hot-wallet incident (~$7.9m ETH, per CoinDesk) and the November 2023 cluster reported by CNBC reshaped how HTX surfaces key permissions in the UI. We build with the post-incident permission model — withdrawal scope OFF on every key the integration provisions, even when the customer asks for trading scope, until trading is explicitly opted into on a separate key.
• Multi-product namespacing. Spot, USDT-margined and coin-margined derivatives use different REST paths and WebSocket topics. The SDK ships them as one client with three typed namespaces, so downstream code sees one connection rather than three loose ones with overlapping symbol names.

From $300 the customer has a runnable HTX integration in hand — billed only after delivery, only once they are satisfied with what they have. A build of this shape typically runs one to two weeks end to end. The same surfaces are also available as a pay-per-call hosted endpoint that the studio operates: no upfront fee, the customer pays only for calls actually made. Tell us what you need from HTX and we will scope it from there.

Interface evidence

The eight Play-Store screenshots the studio worked from. Click any to enlarge.

Sources and review notes

The mapping was cross-checked against the HTX official spot API documentation huobiapi.github.io/docs/spot/v1/en, HTX's own support note on the v2 WebSocket signature for spot and margin trading htx.com/support/94983224516200, the Seychelles FSA public alert on Huobi Global Limited fsaseychelles.sc, and CoinDesk's reporting on the September 2023 hot-wallet incident coindesk.com.

Other exchange apps clients pair with HTX

None of these are ranked or recommended over HTX — they are venues integrators routinely ask us to wire into the same unified schema, in our experience:

• Binance — global spot and derivatives venue with a REST + WebSocket model close in shape to HTX's; usually the first peer to be added.
• Coinbase — US-listed exchange with a separate institutional Prime API; relevant when the customer needs retail and HTX in one pipeline.
• Kraken — long-running venue with deep fiat support and a futures arm; the HMAC pattern from HTX slots in with little rework.
• OKX — spot, margin, perps and a copy-trading layer; the venue customers most often ask for next after HTX is delivered.
• Bybit — derivatives-led with a high-throughput WebSocket; commonly used as the hedge-leg venue against HTX positions.
• KuCoin — broad altcoin catalogue and a credentialed-key REST model close to HTX's; common in tax-export use cases.
• Bitget — futures and copy-trading focused; routinely paired with HTX in multi-venue dashboards.
• Gate.io — long tail of listings and an active REST + WS surface; the second venue many HTX integrators add for coverage.
• MEXC — wide altcoin coverage; comes up when the customer's portfolio tracker has to reconcile holdings HTX does not list.
• Bitfinex — long-running venue with sub-account structure useful in institutional flows; different auth shape, same integration shape.

Common questions before kickoff

Does this need our HTX trading API keys, or can it run on the read-only set?

For everything in the data-domains table, the read-only scope is enough. The key the customer provisions on HTX is scoped read-only with withdrawals off; if the same client later wants the integration to place orders, that is a separate, opt-in key with its own audit trail.

How do we get more than 48 hours of order history out of HTX?

The GET /v1/order/history endpoint is documented as a 48-hour window. The integration backfills longer history with /v1/order/orders time-sliced calls and persists the result on the customer's side, so the live feed and the historical record land in the same normalized schema.

Can spot and USDT-margined derivatives come through one feed, or do we need two?

They share an authentication shape but use different REST paths and WebSocket topics. The integration ships them through one client object with a typed namespace per product (spot, USDT-margined, coin-margined), so the customer's downstream code sees one connection rather than three.

What changes if HTX rotates the v2 WebSocket signature again?

HTX has rotated it before, most recently moving signed connections onto /ws/v2 with the v2.1 signature method. The maintenance line on the engagement covers re-pinning the signer and rerunning the regression rig within a working day of HTX's announcement, so the customer's pipeline does not drift.