oid and user_address for book reconstruction. Live WebSocket subscriptions and exact-window replay run on one socket, with a data-quality path on every response.
What One Key Returns
Every Hyperliquid row resolves to a concrete route, a family, and a coverage date you can confirm against/v1/symbols.
| Hyperliquid market data | 0xArchive returns | Start |
|---|---|---|
| Core perp order books and trades | Native L2 (20 levels/side) and trades since April 2023, 24.6B+ records, 176 symbols, continuous to the current hour | Hyperliquid REST |
| Funding and open interest | Since May 2023 | Hyperliquid REST |
| Liquidations | Since December 2025 | Hyperliquid REST |
| Full-depth and order-level (L4) | Full-depth L2 and L4 since March 2026, every resting order with oid and user_address for reconstruction | SDK reconstruction |
| Order flow and attribution | Per-order flow with wallet attribution via /v1/hyperliquid/orders/{symbol}/flow | SDK reconstruction |
| Spot pairs | Trades since March 2025, native L2 since May 2026, L4 since March 2026, plus TWAP and freshness | Hyperliquid Spot REST |
| HIP-3 builder markets | Trades since October 2025; books, funding, and OI since February 2026; L4 since March 2026 | HIP-3 REST |
| HIP-4 outcome markets | Outcome IDs, probability-priced books, trades, and OI since May 2026 | HIP-4 REST |
| Live stream and replay | WebSocket subscriptions for real-time data and exact-window replay on one socket | WebSocket replay |
Route Families Stay Separate
Each Hyperliquid family keeps its own namespace, so a human or a coding agent gets a precise path instead of one flattened symbol model:/v1/hyperliquid/orderbook/BTC for core perp books, /v1/hyperliquid/spot/orderbook/HYPE-USDC for Spot pairs, /v1/hyperliquid/hip3/orderbook/km:US500 for HIP-3, and /v1/hyperliquid/hip4/outcomes before working with outcome IDs. The OpenAPI contract pins every path, so a generated client matches the route on the first request.
Why Teams Choose 0xArchive
One key returns the full Hyperliquid record set, live and historical, normalized and named: 24.6B+ order-book records and trades back to April 2023, full order-level (L4) depth with wallet attribution since March 2026, and per-order flow you can attribute to a wallet. That is the layer DIY collectors and native stitching try to rebuild and rarely keep continuous. For order-level research,/v1/hyperliquid/orderbook/BTC/l4/history returns every resting order with its oid and user_address, so you reconstruct the book at any point in the window. Pair it with WebSocket replay when sequence and timing matter, and gate the window with a freshness check before a model acts. Order placement, account state, wallet signing, and venue breadth beyond Hyperliquid are a different job. Every order, trade, and fill. One API.
What To Run First
Start with one symbol and one route, then widen.| Job | 0xArchive route |
|---|---|
| Historical order books | /v1/hyperliquid/orderbook/{symbol}/history |
| Order-level (L4) history | /v1/hyperliquid/orderbook/{symbol}/l4/history |
| Order flow | /v1/hyperliquid/orders/{symbol}/flow |
| Trades | /v1/hyperliquid/trades/{symbol} |
| Funding | /v1/hyperliquid/funding/{symbol} |
| Open interest | /v1/hyperliquid/openinterest/{symbol} |
| Liquidations | /v1/hyperliquid/liquidations/{symbol} |
Selection Checklist
Name the family, symbol style, data family, time window, depth layer, and downstream use before you wire the route. A core perp dashboard, a Spot export, a HIP-3 builder-market backtest, and a HIP-4 outcome study each map to a distinct namespace and history.Which Hyperliquid family is this?
Which Hyperliquid family is this?
Use core routes for standard perp symbols such as
BTC and ETH. Use HIP-3 routes for namespaced builder symbols such as km:US500. Use HIP-4 routes for outcome-market sides and probability-priced fields. Use Spot routes for pairs such as HYPE-USDC.Does the job need point-in-time state?
Does the job need point-in-time state?
Use history routes or WebSocket replay when order and timing matter, including L4 reconstruction with
oid and user_address. Use snapshots when a point response is enough.Will a downstream model or alert act on the result?
Will a downstream model or alert act on the result?
Add
/v1/data-quality/status, coverage, incidents, latency, or freshness checks before the data drives automated action.