Hyperliquid Market Data & API: Feeds, Historical Data & Low Latency

There are three ways to get market data out of Hyperliquid, and picking the wrong one is the most common mistake in a new integration. Most people who search for a 'Hyperliquid data feed', a 'data provider', 'fills API', 'low latency data' or 'S3 data' actually want one specific tier — and reaching for the heavy option when the light one would do (or vice-versa) costs days. This is the map: the live API for real-time reads, the S3 archive for history, and a self-run node for the lowest latency. Each is covered below, with what it gives you and what it costs.

The short version: if you're building a dashboard, a bot, or collecting data for backtests, the free HTTP and WebSocket API is all you need. If you need years of history to backtest against, that lives in S3, not the API. And if microseconds decide your PnL, you run a node and build state locally. Published July 1, 2026.

The live API: /info REST and the WebSocket feed

Hyperliquid's public API has two shapes and no API key. The REST side is a single POST endpoint, /info, whose request body's 'type' field selects what you get: allMids for every mid price, l2Book for a market's order book, candleSnapshot for OHLC candles, meta and metaAndAssetCtxs for the market universe plus live mark price, funding and open interest, and userFills / userState for account data. It's request/response — you ask, it answers — which is ideal for polling, one-off reads, and backfilling recent candles.

The WebSocket side, at wss://api.hyperliquid.xyz/ws, is push: you subscribe to channels (trades, l2Book, candle, and user-specific events) and updates stream to you as they happen. For anything live — a price ticker, a bot reacting to fills, an order-book view — the WebSocket is what you want instead of hammering REST. Both cover core perps and HIP-3 builder markets alike; builder markets just take an extra dex parameter. This free, permissionless pair is, for most people, the entire answer to 'is there a Hyperliquid market data API?'.

Historical data: the S3 archive

The API serves live and recent data, not deep history — that lives in S3, and it's a common surprise. Hyperliquid publishes two archives. The market-data bucket, s3://hyperliquid-archive, holds L2 book snapshots and asset contexts under the path market_data/[date]/[hour]/[datatype]/[coin].lz4. The node-data bucket, s3://hl-mainnet-node-data, holds outputs from the L1 node itself: node_fills_by_block for trade fills, plus explorer_blocks, replica_cmds (raw L1 transactions) and misc_events_by_block (transfers, staking, funding).

Three things to design around before you build on it. It's LZ4-compressed, so budget a decompression step. It's requester-pays — you cover the S3 transfer cost, not Hyperliquid. And it's uploaded roughly monthly with no guarantee of completeness or timeliness, so treat it as a bulk backfill source rather than a live feed, and reconcile it against data you collect yourself in real time. If you need a continuous, gap-free series, the archive seeds it and your own collection maintains it.

Fills and trade data

Trade and fill data is a frequent ask ('Hyperliquid fills API') and it splits by whether you want live or historical. For live fills, use the info endpoint's userFills for a given account, or subscribe to the relevant WebSocket channel for a push stream — that's your real-time trade tape. For historical fills across the exchange, go to the node-data S3 buckets: node_fills_by_block is the current format (fills batched by block), with node_fills and node_trades as older layouts kept for compatibility.

One nuance worth knowing: the exchange-wide historical fills come from node output, so the cleanest way to get a complete, ongoing fills dataset is to run a node with fill output enabled and stream it yourself, using the S3 archive to backfill the period before you started. For most analytics needs, though, the API plus the monthly archive is enough.

Low-latency data: running a node

The public API is fast — good to the millisecond — but it's not the fastest path, and latency-sensitive traders don't use it for reads. The lowest-latency approach is to run a non-validating node peered against a reliable peer (such as a Hyper Foundation non-validator) and construct the order book and other exchange state locally from the node's outputs, which are faster and more granular than the API. Disabling output-file buffering makes state land the instant a block executes rather than on a flush.

This is an infrastructure commitment, not a config flag. Hyperliquid's guidance points to roughly 32+ logical cores, 128 GB of RAM and fast disk to keep a node healthy, plus the operational burden of running it. On the write side, read and write priority fees can further tighten latency. Reach for a node only when microseconds genuinely pay for themselves — market making, latency arbitrage — and stay on the WebSocket API for everything else.

Oracle prices, funding, and open interest

Beyond trades and book, three per-market series come up constantly: the oracle/mark price that anchors the perp, the funding rate, and open interest. All three are live in the asset context — a single metaAndAssetCtxs call returns them for every market, and the WebSocket pushes updates. What the chain does not keep for you is a long history of these, open interest especially: you can read current OI, but reconstructing a multi-month OI series means polling and storing it yourself going forward. If your model depends on historical OI or a funding-rate history, budget to collect it from day one rather than expecting to backfill it.

What a 'Hyperliquid data provider' actually sells

Search 'Hyperliquid data provider' and you'll find third-party services — that's a real market, but be clear about what you're buying. Hyperliquid itself is the canonical source: the /info endpoint and WebSocket above are free and permissionless, and the S3 archive is public. A paid provider isn't selling access to otherwise-locked data; it's selling convenience — normalization into stable schemas, history retention beyond the monthly archive, mapping namespaced builder-market coin names to something durable, and uptime with an SLA. That can absolutely be worth it if you'd rather not run collection and storage yourself. Just know you're paying for the plumbing, not the data.

HIP-3 and builder-market data

Everything above applies to Hyperliquid's core perps and to HIP-3 builder markets — the equities, commodities and pre-IPO perps that independent builders deploy on the same L1. Builder markets flow through the exact same /info and WebSocket endpoints; you just add a dex parameter to select which perp dex you mean, and resolve coin names from that dex's own universe. For the HIP-3-specific details — the dex parameter, the namespaced and case-sensitive coin naming, and what builder markets do and don't have (short history, oracle-anchored marks, no free historical OI) — see Hyperliquid HIP-3 API & Market Data, the companion to this post.

Backtesting on Hyperliquid data

Once you can pull candles, the usual next step is to backtest a strategy against them — and that's where a lot of the value of this data actually gets realized. The signal engine we build at Signalview is open source for exactly this: perpsignal (Apache-2.0, github.com/mokshyaprotocol/signalview) is a signal DSL plus an honest backtester — fees, funding, stops and leverage modelled — that reads OHLCV like the candles above and turns a strategy into Sharpe, return and drawdown. It has no wallet, key or trading code, so it's safe to run anywhere, and it's open to contributions. If what you want is a backtested strategy executed on these markets without building the data or execution layer at all, that's what our non-custodial agents do.

Risk note: Hyperliquid perps, and HIP-3 builder markets especially, are leveraged, high-risk instruments — you can lose your entire margin. Data access does not reduce market risk. Nothing here is investment advice, and every API detail above should be confirmed against Hyperliquid's official documentation, which is the source of truth and changes over time.

Building a bot on this data? Skip the plumbing

If you're pulling this data to build a trading bot, there's a shortcut worth knowing. Signalview already runs the ingestion described above and turns it into scored, backtested strategies — so you can trade without writing a data or execution layer at all. Three ways in: browse scored Hyperliquid signals to see the current setups; deploy an AI trading agent that executes a signal 24/7 with a scoped, non-custodial key that can only place perp orders, never withdraw; or publish your own strategy as a signal and earn a share of the fees when others trade it.

It's free to run — you pay only Hyperliquid's normal fees — and your funds stay in your own wallet. Build the whole stack yourself from the map above, or skip straight to a live, backtested strategy; either path starts from the same data.

Frequently asked questions

Does Hyperliquid have a market data API?

Yes. Hyperliquid has a free, permissionless API in two forms: a REST endpoint (POST to /info, where the request 'type' selects prices, order book, candles, funding, open interest and account data) and a WebSocket feed at wss://api.hyperliquid.xyz/ws for pushed real-time streams. Both cover core perps and HIP-3 builder markets. No API key is required.

Where can I get historical Hyperliquid data?

Historical data lives in S3, not the API. Hyperliquid publishes a market-data archive (s3://hyperliquid-archive, L2 book snapshots and asset contexts) and node-data buckets (s3://hl-mainnet-node-data, including node_fills_by_block for trades). It's LZ4-compressed, requester-pays, and uploaded roughly monthly, so it's for bulk backfill rather than a live feed.

How do I get low-latency Hyperliquid data?

Run a non-validating node peered against a reliable peer and construct the order book and exchange state locally from its outputs — that's faster and more granular than the API, especially with output buffering disabled. It needs real hardware (roughly 32+ cores and 128 GB RAM) and ongoing ops, so it's only worth it when microseconds affect PnL. For everything else, the WebSocket API is fast enough.

How do I get Hyperliquid fills or trade data?

For live fills, use the info endpoint's userFills for an account or subscribe to the WebSocket. For historical, exchange-wide fills, use the node-data S3 buckets (node_fills_by_block is the current format). For a complete ongoing dataset, run a node to stream fills and use the S3 archive to backfill earlier history.