Skip to main content
The native Hyperliquid API places orders and reads account state. Its Info endpoint and WebSocket API also expose venue-native live market data. For route-addressed historical Hyperliquid and Lighter market data, you call 0xArchive. One key returns order books, trades, candles, funding, open interest, liquidations, and full order-level (L4) depth as normalized JSON. Order books and trades go back to April 2023; L4 order-level history from March 2026 on core and HIP-3, and from May 2026 on HIP-4; Spot order events and reconstructable checkpoints require separate coverage checks; lifecycle history is route-specific. 0xArchive runs collection, backfill, and reconstruction server-side and returns the resulting checkpoint/snapshot. If your application keeps a continuously updated local book, apply ordered diffs/replay after that checkpoint; a snapshot-only consumer can use the returned state directly.
Evidence checked August 28, 2026. The native boundary below uses Hyperliquid’s API overview, Info endpoint, historical data documentation, and WebSocket API. The 0xArchive route claims use Hyperliquid L4, Lighter L3, and Replay and reconstruction.

What One Key Returns

Where The Native API Fits

0xArchive does not place orders; execution belongs to the venue’s own API, and for that job the native endpoint is the correct choice. Order placement, cancels, and account state live on the exchange endpoint, signed by your wallet. The native Info endpoint answers live market questions such as current mids, a 20-level l2Book snapshot, recent trades, and funding history. The bounds show up when the question is historical, and Hyperliquid’s own docs state them: candleSnapshot returns only the most recent 5,000 candles, userFills returns at most 2,000 recent fills, userFillsByTime reaches only the 10,000 most recent, time-range responses page at 500 elements, and the native l2Book page does not describe a historical form. There is no native request documented on the cited pages that returns the book as it stood last Tuesday. If the job is execution or reading your own account, 0xArchive is not the right fit; that stays on the venue. If the job is a backtest, a research window, or anything older than those retention caps, use a route-addressed archive with a stated window.

When To Use 0xArchive

0xArchive removes venue collection and historical backfill work; supported reconstruction routes return a checkpoint/snapshot. A snapshot-only consumer can use that state directly. A continuously updated local L4 book still must apply ordered diffs or replay, detect gaps, and reconstruct state after the checkpoint; the API does not remove those local-state obligations. The market data comes back normalized, with named fields, live or historical: order-book records and trades back to April 2023, plus full order-level L4 history with wallet attribution from March 2026 on core and HIP-3, and from May 2026 on HIP-4; Spot order events and reconstructable checkpoints require separate coverage checks. Store the request ID when the response exposes it, and check data quality before a backtest trusts the window. Use one API for Hyperliquid and Lighter market-data routes, with coverage and freshness stated by family and window. Access is endpoint-specific: inspect the exact route and account/key contract before relying on a market family or schema. Plans can affect credits, request rate, and standard replay speed, which scales from 10x to 300x by plan and up to 500x on Enterprise. Agents can read the same market-data surface through the hosted MCP server at https://mcp.0xarchive.io/mcp, a remote endpoint that uses client-managed OAuth and requires no 0xArchive API key. There is nothing to install.

Run One Route

Next Step

Open Hyperliquid REST, run one BTC request, then check the per-family windows on Venue coverage and Data quality before a job depends on one. Compare plans. For order-level depth, see Hyperliquid Order Book Data API.
Last modified on August 28, 2026