Check one market before a job
The tables below give each market type’s first served time. A single market can start later, because markets list on their own dates. Four calls confirm the exact market, data type and window.1
Find the market
exchange and symbol match the requested market. Keep the exact spelling, pair separator, builder prefix, outcome identity, and slug when present. If no row matches, stop and keep the supplied identity rather than substituting another ticker.2
Read the data type's own start
Read the row’s
coverage_by_type for the data type you need. The row’s top-level coverage_from and the tables below do not set the start for every data type, and a data type missing from coverage_by_type cannot be inferred from a neighbouring one.3
Call the route for a bounded window
This example asks for the five minutes of BTC trades that ended one hour ago, a window every plan’s history reaches, including Free’s most recent 30 days:Keep the route, query, and
meta.request_id with the result. An empty response is a result to record, not a reason to try another symbol. To page through a longer window, follow Pull historical market data.4
Check quality for the same window
Check the same market, data type and window with
/v1/data-quality/coverage/{exchange}/{symbol} and the freshness route before using the response downstream. See Data quality./v1/status/coverage is a coarse public summary. For one market and data type, /v1/symbols coverage_by_type gives the start, and /v1/data-quality/coverage/{exchange}/{symbol} gives windows, gaps, and empirical cadence.
Data types by market type
Each row lists the market types with a REST endpoint for that data type, asGET /v1/capabilities reports them. Capabilities adds the routes, WebSocket channels, and live and replay availability. A listed market type does not guarantee every market, the same start for every symbol, or freshness.
Live streams and replay have their own availability, listed on WebSocket channels, and file exports list theirs on Exports.
TWAP order routes are served under each Hyperliquid namespace as
/twap/{symbol} and /twap/user/{user}. Lighter funding records are returnable on both deployments; retrieve current funding separately for each venue and keep each source’s units and timestamp. On Lighter on Robinhood Chain, funding, open interest, and liquidations exist for perpetual markets only.
Hyperliquid L4 resting-order depth is a separate data type from native L2. Its checkpoint, ordered diff, and history routes are separate from order-history and order-flow lifecycle routes. Lighter exposes tick-level L3 individual-order depth from March 5, 2026, capped at 250 orders per side per tick. Lighter has no L4 route, and Lighter on Robinhood Chain has no L3 route.
Native Hyperliquid core, HIP-3, and HIP-4 L2 routes return at most 20 levels per side. Spot native L2 and Lighter native L2 have their own depth parameters; check their operation pages rather than applying the 20-level rule.
Lighter mainnet markets span crypto, equities and indices, FX, commodities, and pre-IPO markets; public symbol discovery lists them, and the Data Catalog groups them by category.
Your plan does not change which data types or depths you can request. Plans set request rate, concurrency, standard replay speed, credits, export capacity, and Free’s rolling 30-day history window; see Rate limits. A capacity limit can delay or narrow a job; it does not mean the dataset is absent. Build and above keep the full retained archive.
History by data type
Each table gives the first instant a data type is served for that market type, asGET /v1/capabilities reports it. A request window that starts earlier and ends later is served from that instant. Read one symbol’s own start from /v1/symbols coverage_by_type, and use /v1/data-quality/coverage/{exchange}/{symbol} for its windows, gaps, and cadence.
The April 2023 start for core native L2 and trades is not a start for L4, L3, or order-lifecycle data: L4 coverage begins in 2026, and Lighter’s individual-order data is L3, not L4.
Hyperliquid core
Served under/v1/hyperliquid/*.
Hyperliquid Spot
Served under/v1/hyperliquid/spot/*.
HIP-3 builder perps
Served under/v1/hyperliquid/hip3/*.
HIP-4 outcome markets
Served under/v1/hyperliquid/hip4/*.
Lighter mainnet
Served under/v1/lighter/*.
Lighter on Robinhood Chain
Served under/v1/rh-lighter/*.
In
/v1/symbols coverage_by_type, orderbook is the native aggregated L2 data type. Full-depth aggregated L2 uses the /l2 endpoints and is listed only for Hyperliquid core and HIP-3. l3_orderbook is Lighter individual-order depth. l4_orderbook is Hyperliquid resting-book state, while l4_orders names order-level records. Neither L4 key stands in for order-history or order-flow lifecycle data.
Lighter L3 is individual-order depth, not an aggregated L2 shape. /v1/lighter/l3orderbook/{symbol} returns numeric order_index, owner_account_index, price, remaining_size, and original_size; the two index fields are Lighter indexes, not wallet addresses or raw order IDs.
Common mistakes
- Inferring coverage from a category name. An “RWA market”, “Spot pair” or “outcome market” still needs a market-type and symbol check.
- Treating a successful latest snapshot as evidence that every historical window exists.
- Reading a
403as a statement that a market is unavailable. It is a response about that endpoint, account or key. - Retrying a
404unchanged. Check the namespace and symbol format first. - Hiding a freshness or incident warning because the API returned a payload. If the state is outside tolerance, narrow, delay, mark, or stop the downstream job.