Hyperliquid Historical Data: Bitquery vs Hyperliquid's free data

Where to get Hyperliquid historical data depends on what you need: trades, candles, the order book or full archive history. Hyperliquid publishes its own API and its own historical archive, both free. Any honest evaluation should start there, so this page does.

When you should just use Hyperliquid directly

Use the native Info API if:

• You are trading your own account and need your own orders, fills and positions. It is the canonical source, closest to the matching engine, with the lowest possible latency.
• You need the current aggregated book for one or two coins, and 5–20 levels is enough.
• You are building something small, single-venue, and free matters more than completeness.

It is a good API. For those jobs nothing else will be better, and you should not pay for a substitute.

Bitquery is for the jobs it is not built for: seeing the whole market, at order granularity, over time, alongside other chains.

What Hyperliquid's free archive actually contains

This is the part most evaluations get wrong. Hyperliquid publishes two public S3 buckets, and they are narrower than people assume:

Bucket / path	Contains
s3://hyperliquid-archive/market_data/	L2 book snapshots
s3://hyperliquid-archive/asset_ctxs/	Asset contexts
s3://hl-mainnet-node-data/node_fills_by_block (older data: node_fills, node_trades)	Fills, as written by a non-validating node
s3://hl-mainnet-node-data/misc_events_by_block	Non-trade events: transfers, staking, funding
s3://hl-mainnet-node-data/explorer_blocks, replica_cmds	Explorer blocks and L1 transactions
Not provided	Candles and spot asset data — "no other historical data sets", per Hyperliquid

Hyperliquid's own documentation states that hyperliquid-archive is uploaded roughly once a month, with no guarantee of timely updates, and that data may be missing. On hl-mainnet-node-data the requester pays the transfer costs.

So fills do exist for free — as raw node files you download, parse and index yourself. Candles, order statuses and per-order book changes are not in either bucket, and that is by design, not an oversight.

The core difference: L2 vs L3

Hyperliquid's public market-wide book data — both the l2Book websocket channel and the S3 snapshots — is L2: size aggregated per price level. Order-level detail (orderUpdates, userFills) exists in the native API, but only per address — one address you already know per subscription, at most 10 users per IP.

Bitquery serves the book market-wide at L3 (market-by-order).

	Hyperliquid native (market-wide)	Bitquery
Book grain	L2 — total size per price level	L3 — one event per individual order
Order identity	—	Oid, joins Orders ↔ BookUpdates ↔ Trades
Who placed the order	—	Trader { Address }
Depth	5–20 levels	Unlimited
Order-level data for other traders	Only per address you already know	Every order, every trader

Because Hyperliquid settles on a transparent L1, the wallet behind each order is public. That makes this L3 with named attribution — something that does not exist on centralised venues, where exchanges anonymise L3 feeds. It is what makes market-maker tracking, cancel-to-fill analysis and wallet-level order flow possible at all. See Track Order Flow by Wallet.

This data is on-chain

Hyperliquid is a transparent L1, so this information is derivable by anyone who indexes the chain — Bitquery's contribution is the indexing, normalisation and delivery, not exclusive access. The claim here is specifically that Hyperliquid's own API does not serve it market-wide, which is verifiable in their docs.

Account state: one address vs every account

The Info API answers for one address at a time: clearinghouseState for its margin and positions, spotClearinghouseState for its spot balances, openOrders for its orders. That is all you need for your own account. To rank the biggest positions on a market, map where the stops sit, or list who holds a token, you would have to know every address first and query each one within the rate limits.

Bitquery takes a snapshot of the full exchange state about every 12.5 minutes and serves it for every account at once: every open position with entry price, margin and unrealized PnL, margin per dex, spot balances, the order book with owners, waiting trigger orders, vaults and their depositors, Earn. The snapshots of the last 7 days are kept, so the state at a past moment is one query too. See the Snapshots API.

	HL Info API	Bitquery snapshots
Scope	One address per request	Every account on the exchange
Freshness	Now	The latest snapshot, up to ~12.5 minutes old
History	Current state only	Every snapshot of the last 7 days, or the one at a given moment
Filter and rank	Client-side, after fetching each address	Any field: market, size, entry price, leverage, trigger price, token
Delivery	REST, per-IP weight limits	GraphQL query; no subscription

Full comparison

Capability	HL Info API	HL S3 archive	Bitquery
Cost	Free	Free	Paid
Book granularity	L2 aggregated (order-level only per known address)	L2 snapshots	L3 market-by-order, market-wide
Trades / fills market-wide	Price, size, side and both addresses (trades)	Raw node fills (requester pays)	Full: direction, fees, leverage, position size before and after, realized PnL, execution order in the block
Candles	Via REST, pagination-limited	Not provided	Candles cube: 1m, 5m, 15m and 1h bars
Spot markets	Yes	No spot asset data	Yes
Liquidations market-wide	Per-address only	Inside raw node fills	Exchange-wide, with method, mark price, leverage
Funding per trader	Per-address only	Raw node events (misc_events_by_block)	PerpFundings, market-wide
Open positions	Per-address snapshot	Not provided	CurrentPositions, whole market, sortable; SnapshotPositions with entry price, margin and unrealized PnL, 7 days of snapshots
Margin, spot balances, open orders, vaults	Per address (clearinghouseState, spotClearinghouseState, openOrders), current only	Not provided	Snapshot* cubes: every account, every ~12.5 minutes, 7 days
Prediction market names	outcomeMeta, current markets	Not provided	On every trade, order and snapshot row (Market { Outcome })
Order statuses and per-order book changes	Per-address only (orderUpdates)	Not provided	Orders (rejects included) and BookUpdates, market-wide
Raw L1 actions	Not exposed	Raw L1 transactions (replica_cmds)	SignedActions: rejects and non-order actions, with signer
Update cadence	Real time	hyperliquid-archive: ~monthly, no guarantee	Real time
Completeness guarantee	—	Stated for hyperliquid-archive: data may be missing	SLA available
History depth	Snapshot + limited REST	Longer than Bitquery's window, as raw files	Rolling ~30 days via API (~7 days for orders, book updates and signed actions); older history as Parquet exports from the Data Store
Delivery	WebSocket / REST	S3 files	GraphQL, WebSocket, Kafka (protobuf), Parquet exports
Rate limits	Yes, per IP: connections, subscriptions, 10 users, REST weight	S3 transfer (requester pays on node data)	Plan-based, no per-coin fan-out
Other chains	Hyperliquid only	Hyperliquid only	Solana, EVM, Base, BNB, Tron, Bitcoin — same schema, same key

Same question, both ways

"Give me 1-hour OHLCV for BTC-PERP."

Natively, candles are not in the archive, so you either page through the REST candleSnapshot endpoint within its limits, or collect trades live and aggregate them yourself, then persist them.

With Bitquery it is one query:

query {
  Hyperliquid {
    Candles(
      limit: {count: 100}
      orderBy: {descending: Interval_Time_Start}
      where: {
        Market: {CoinRaw: {is: "BTC"}}
        Interval: {Time: {Duration: {eq: 3600}}}
      }
    ) {
      Interval { Time { Start Duration } }
      Market { Symbol Kind }
      Ohlc { Open High Low Close Volume }
    }
  }
}

CoinRaw: "BTC" is the native BTC perp (Symbol: "BTC" would also match HIP-3 BTC markets). Open and Close are the first and last taker fill of the bar in execution order. The same query becomes a live stream by changing query to subscription.

Where Bitquery is genuinely weaker

Worth saying plainly:

• Latency to the matching engine. For your own order placement and fills, the native API is closer to the source. Bitquery indexes blocks; there is a step in between.
• Cost. Free is free. If your use case fits inside the native API, use it.
• Freshness of account state. For one address, clearinghouseState answers with the state now. Bitquery's snapshots of every account are up to ~12.5 minutes old, are kept 7 days and cannot be subscribed to; between snapshots, the event cubes (Trades, Orders, PerpLiquidations) carry what changed.
• API history depth. The GraphQL cubes serve a rolling ~30-day window (~7 days for orders, book updates and signed actions). Hyperliquid's free buckets go back further for L2 snapshots and raw fills, if you are willing to parse and index them yourself. For older Bitquery data, use Parquet exports from the Bitquery Data Store (details); older ranges are available on request from sales@bitquery.io.

Where Bitquery is decisive

• L3 with wallet attribution, market-wide — not available from the native API at all.
• The state of every account at once — positions with entry price and unrealized PnL, stops, spot holders, vault depositors — where the native API answers one address at a time.
• Candles, order statuses and per-order book history — absent from Hyperliquid's free buckets, which hold fills only as raw node files.
• One stream for the entire market rather than per-coin, per-user subscriptions you merge client-side.
• Cross-chain. A Hyperliquid-only provider can tell you a wallet was liquidated. Only a multi-chain provider can tell you where the money went afterwards.
• One plan, not a separate product. Hyperliquid is served from the same real-time cubes as Solana, Ethereum, Base, BNB and Tron DEX data. There is no Hyperliquid add-on: any plan that covers your spot DEX data covers perps too, so a perps-vs-spot basis monitor or a cross-venue trader profile is one API key and one bill.

Next steps

Start streaming

• Real-time trades and candles — fills with PnL, direction and fees, market-wide
• Exchange-wide liquidation feed — every liquidation as it happens
• Funding stream — hourly settlements for every trader
• Kafka streams — protobuf delivery for production bots

Go deeper

• Hyperliquid API overview — every cube
• L3 Order Book API
• Snapshots API — every position, order, balance and vault, every ~12.5 minutes
• Track Order Flow by Wallet — including following a wallet to other chains
• Trading Data Overview — the cross-chain Trading cube Hyperliquid sits alongside
• Data Coverage & Retention — exact windows per cube