Skip to main content
Data availability is about whether the requested data exists for a named venue family, symbol, data family, time window, and freshness tolerance. A venue family can have current order-book data and a shorter historical window for another data family. Capacity is separate: request rate, concurrency, standard replay speed, and credits determine how much work the account can run. Treat availability as a preflight step, not a marketing claim. If a window is missing, stale, or degraded once you pull it, Data gaps covers how to handle it.

​
Availability dimensions

​
Capacity is separate

After availability is confirmed, size the request against Rate limits: request rate, concurrency, standard replay speed, credits, and request-window limits. A capacity limit can delay or narrow a job; it does not mean the dataset is absent. Published market-data route access is not a higher-tier feature: plans gate capacity and Free’s rolling 30-day history window, not route families, schemas, or served depth, while actual availability remains route-, family-, symbol-, and schema-specific. Build and above keep the full retained archive.

​
Preflight pattern

1

Name the route family

Write the family in the job config before writing the endpoint. For example, hyperliquid_spot and hyperliquid_core should not collapse into one label.
2

Probe one exact market

Call one instrument, /v1/symbols, coverage, freshness, order-book, or trade route for the exact symbol before looping over symbols.
3

Check the data family

Confirm that the requested data family exists for the route. L4, L3, replay, funding, and open-interest coverage can have different constraints.
4

Attach the decision to output

Store the preflight result, route, symbol, window, and request IDs beside backtests, exports, dashboards, and model inputs.

​
Common mistakes

Do not infer availability from a category name. A phrase such as “RWA market”, “Spot pair”, or “outcome market” still needs a route-family and symbol check. Do not treat a successful latest snapshot as evidence that every historical window exists. Do not hide a freshness or incident warning from downstream systems just because the API returned a payload. If a route returns a valid response but the freshness or coverage state is outside tolerance, mark the output incomplete or stop the job. That is especially important for backtests, alerts, exports, and model features, where bad data can look like a real market signal.

​
Availability checklist

For every availability answer, capture the exact venue family, symbol, data family, UTC window, freshness tolerance, and first probe result. Record account capacity as a separate decision. If the answer cannot name those fields, it is only a category-level guess.

​
Next step

Open Data quality for the practical gate, then use Historical market data or Point-in-time backtesting if the job depends on historical windows.
Last modified on August 31, 2026