Hyperliquid runs its entire perpetuals order book on-chain, on its own purpose-built L1 — not an off-chain matching engine with on-chain settlement bolted on after the fact, the way most DEXs still work. That architecture is also why getting clean historical data out of it is its own small problem: the native API is built to serve a live trading UI first, and deep historical depth is a secondary concern.
Written for quants, researchers, and developers who want programmatic access, not a trading terminal.
What Hyperliquid historical data actually includes
Hyperliquid's own API serves historical data through a single POST /info endpoint, with a type field selecting the query — candleSnapshot for OHLCV, taking coin, interval, startTime, and endTime parameters in millisecond Unix timestamps. It works, but the native API doesn't retain full historical order-book depth or very old candles natively; large historical pulls return capped windows, so you iterate forward with later startTime values rather than pulling a full range in one call. Specific rate-limit numbers aren't published in a single definitive source — community guidance converges on pausing 200–500ms between looped requests and backing off on HTTP 429, which is a reasonable default, not an official guarantee.
Convex Lake's own data coverage, confirmed directly against its API docs: candles are a real, documented, billable data type — GET /candles?exchange=hyperliquid&timeframe=1h&slug=BTC, covering 234 Hyperliquid perpetuals across 7 timeframes (1m through 1d), delivered as daily gzip CSV downloads, gated to Research and Pro tier keys (not available on the free tier). Orderbook data is a different story right now: a perpetuals orderbook collector for Hyperliquid (alongside Bitfinex, Deribit, and Binance Futures) started running per an October 2026 changelog entry, covering BTC, ETH, SOL, XRP, DOGE, and HYPE — but as of this writing, Hyperliquid isn't yet in the public /orderbook endpoint's documented exchange list. The data is being collected; it isn't yet a documented, downloadable endpoint. Worth checking the docs directly before assuming it's live by the time you read this.
Hyperliquid historical data schema. Convex Lake fields; see /docs for the current reference.
| Data type | Key fields | Status | Typical use |
|---|---|---|---|
| Candles | timestamp, open, high, low, close, volume, trades | Live, documented | Price history, backtesting, cross-venue comparison |
| Orderbook | bids/asks, price, size | Collecting since Oct 2026, not yet in the public download endpoint | Future: liquidity and execution research |
| Trades | — | Not documented for Hyperliquid at time of writing | — |
Field names reflect Convex Lake's current schema at time of writing. Check convexlake.com/docs for the live reference before integrating.
Hyperliquid's official API vs. third-party providers
Hyperliquid's native API is a trading API that happens to expose history, not a historical-data product. candleSnapshot queries work and are free to call, but you're responsible for your own pagination, your own backoff logic, and your own storage if you want a real archive rather than a rolling window. There's no documented bulk export and no stated guarantee on how far back a given coin's candles actually go.
Comparing Hyperliquid historical data sources
| Source type | Access requirement | Depth | Setup effort | Best for |
|---|---|---|---|---|
| Hyperliquid official API | None — public POST /info | Candles only; capped historical windows, iterate manually | You build pagination, backoff, storage | Teams already building directly against Hyperliquid's trading API |
| Third-party aggregators/resellers | Account with the provider | Varies | Minimal, pre-built | Quick exploratory pulls |
| Convex Lake | API key, Research or Pro tier | 234 perpetuals, 7 timeframes, daily gzip CSV; orderbook collection in progress | REST API, documented endpoints | Research spanning Hyperliquid plus other crypto-derivatives and prediction-market venues under one schema |
Hyperliquid's on-chain architecture, and why it matters for the data
Hyperliquid isn't a DEX bolted onto a general-purpose chain — it's a custom L1 secured by its own consensus, HyperBFT, splitting work across two parallel environments: HyperCore, which runs the actual perpetuals order book and matching engine, and HyperEVM, which runs smart contracts. The order book itself is matched fully on-chain, not off-chain with later on-chain settlement — the same category of design as Limitless's on-chain CLOB on Base, applied here to perpetuals futures instead of binary prediction markets.
That matters for the data the same way it mattered for Limitless: a recorded fill reflects on-chain confirmation, not a separate trading-engine clock, so timing-sensitive research (execution latency, same-block ordering) needs to account for that directly rather than assuming a conventional centralized-exchange timestamp model.
Downloading and querying Hyperliquid historical data via API
A typical query flow through Convex Lake:
- Get an API key on the Research or Pro tier — Hyperliquid isn't available on the free tier.
- Discover available data. Call
/info?md_type=candles&exchange=hyperliquidto get the current list of tickers and timeframes. - Pull the file. Hyperliquid candles are rolling per-instrument files, not split by date — no
dateorticker-category parameter, justexchange,timeframe, andslug. - Store and join. Land files in your own storage and join on instrument across whatever other venues you're pulling.
A minimal example, straight from Convex Lake's own documented reference:
curl -O -J -H "x-api-key: do_YOUR_KEY" \
"https://api.convexlake.com/candles?exchange=hyperliquid&timeframe=1h&slug=BTC"
Field names and exact query parameters differ slightly by endpoint, and new data types (orderbook included) get added between when this is written and when you read it. Check the API docs for the current reference before building against it.
Common research and backtesting use cases
Cross-venue comparison sets Hyperliquid's on-chain perpetuals pricing against Deribit's and Binance's centralized options and futures markets on the same underlying — three structurally different venues (fully on-chain CLOB, centralized options exchange, centralized futures exchange) pricing the same asset. Backtesting strategies built around Hyperliquid's own HIP-3 builder-deployed markets or its broader asset coverage beyond crypto majors can use the same candle history to check strategy performance before committing capital. Once orderbook data clears into a public endpoint, execution and liquidity research becomes possible directly against real depth instead of candle-implied estimates.
Data quality pitfalls to watch for
Orderbook isn't available yet, despite being "covered." A changelog entry describing a new collector isn't the same as a documented, downloadable endpoint. Confirm current status in the docs rather than assuming coverage based on an older reference (including this one).
No date parameter on Hyperliquid candles. Unlike Kalshi or Polymarket's date-partitioned files, Hyperliquid (like Deribit) uses rolling per-instrument files. Pulling "yesterday's data" means re-downloading the current rolling file, not requesting a specific historical date directly.
On-chain confirmation timing, not a matching-engine timestamp. Fully on-chain matching means a fill's recorded time reflects block confirmation on Hyperliquid's own L1, which behaves differently from a centralized exchange's internal clock.
Native-API historical depth is capped, not complete. Hyperliquid's own candleSnapshot endpoint doesn't guarantee full history for every coin — treat "how far back does this go" as something to verify per-instrument, not assume uniformly.
Glossary: key terms in Hyperliquid historical data
HyperBFT is the custom consensus securing Hyperliquid's L1. HyperCore is the parallel environment running the actual on-chain perpetuals order book and matching engine; HyperEVM runs smart contracts alongside it. On-chain matching means each fill is itself a confirmed transaction on Hyperliquid's own chain, not an off-chain match settled later — the same category of design Limitless uses for prediction markets, applied here to perpetuals. HIP-3 refers to Hyperliquid's framework for builder-deployed perpetual markets beyond the core crypto-majors list.
FAQ
Does Hyperliquid's official API provide historical data?
Candles, yes, through POST /info with candleSnapshot. Full historical order-book depth and guaranteed deep history per coin, no — large pulls return capped windows you iterate through manually.
Does Convex Lake have Hyperliquid orderbook data?
Collection started in October 2026 per the changelog, but as of this writing it isn't yet in the documented, public /orderbook endpoint. Candles are live and documented today; check the docs for current orderbook status.
Is Hyperliquid data available on Convex Lake's free tier? No. Hyperliquid candles require a Research or Pro tier key.
How is Hyperliquid different from Deribit or Binance for historical data purposes? Deribit and Binance are centralized exchanges with off-chain matching; Hyperliquid matches its entire order book on-chain, on its own L1. All three expose candles in a similar rolling-file format on Convex Lake, but the underlying settlement model — and therefore what a trade timestamp actually represents — differs.
Getting started with Convex Lake's Hyperliquid historical data
Convex Lake covers Hyperliquid candles alongside Kalshi, Polymarket, Predict.fun, Limitless, Deribit, and Binance under one API, on the Research and Pro tiers. One schema instead of stitching together Hyperliquid's native API, a prediction-market provider, and a crypto-derivatives provider separately. See the API docs for the current endpoint reference, or get in touch for access.

