Hyperliquid WebSocket API: Live Order Book & Trades

If you are polling Hyperliquid's /info endpoint in a loop to keep a price or an order book current, you are doing more work than you need to and getting a worse result. Hyperliquid publishes a WebSocket feed that pushes updates as they happen, and for anything live — a dashboard, a bot, an order book view, a fill listener — it is the right tool. This post covers what you can subscribe to, how to think about each stream, and the handful of operational details that decide whether your connection survives contact with production.

It is the live-data companion to Hyperliquid Market Data & API; for deep history see Hyperliquid Historical Data, and for the lowest-latency path see Hyperliquid Low-Latency Data. Published July 26, 2026.

REST or WebSocket: pick by question shape

The distinction is not speed, it is the shape of the question. REST answers 'what is the state right now' — a good fit for one-off reads, startup snapshots, and anything you need on demand. The WebSocket answers 'tell me when this changes', which is what almost every live system actually wants. Polling a REST endpoint to simulate a subscription gives you stale data between polls, wastes your rate-limit budget, and gets worse the more instruments you watch.

The usual correct pattern uses both: take a REST snapshot to establish initial state, then subscribe for the deltas that keep it current, and re-snapshot if you detect a gap. Building only on the subscription leaves you with no defined starting state; building only on polling leaves you permanently behind.

The market-data subscriptions

Market streams cover the state everyone needs. There is a mid-price stream that pushes mids across all markets at once — the cheapest way to keep a broad watchlist current, and the right default when you need many symbols but not much depth. There is an L2 book subscription per coin for order book depth, which is what you want for anything that reasons about liquidity, spread or price impact rather than just last price. There is a trade stream per coin, the public tape of executions. And there is a candle subscription so you can follow OHLCV without rebuilding bars from trades yourself.

There is also a per-asset context stream carrying the state that sits alongside price — mark and oracle price, funding, open interest. If your strategy reads funding or OI, take it from here rather than polling metaAndAssetCtxs on a timer. Exact channel names, message shapes and subscription payloads live in Hyperliquid's official API documentation, which is the source of truth and does change; treat this post as the map rather than the schema.

The account subscriptions

The second family is account-scoped and it is what turns a read-only integration into a trading system. You can subscribe to your own fills, so your position state updates the moment an order executes rather than on your next poll. You can subscribe to account events and to an aggregated web-data stream that carries positions and balances together, which is the least work for a UI that needs to show everything at once.

One design point worth stating plainly: your fill stream is the authoritative record of what your system actually did, and it should be what drives your internal position state. Deriving position from the orders you believe you sent is how systems end up confidently wrong after a partial fill, a rejection or a reconnect. Listen to what happened, not to what you asked for.

Reconnects, gaps and the state you lose

Every long-lived WebSocket disconnects eventually, and the code that handles that is the difference between a demo and a production system. Reconnect with backoff rather than in a tight loop, re-subscribe explicitly on reconnect — do not assume subscriptions survive — and treat the reconnect as a gap: re-snapshot over REST rather than resuming as though nothing happened. An order book that silently missed thirty seconds of deltas looks completely normal and is completely wrong.

Keep a liveness check that is independent of the socket being open, because a connection can stay open while delivering nothing. Track the time since the last message per subscription and treat an unexpected silence as a failure, not as a quiet market. And respect the rate limits on the REST side of this design: they exist, they are enforced per IP and per address, and a reconnect storm that hammers snapshots is a good way to find them. Check the current limits in the official docs before you tune your retry policy.

HIP-3 and builder markets over the same socket

Builder-deployed HIP-3 markets — the equities, commodities and pre-IPO perps that sit alongside core BTC and ETH — stream over the same infrastructure. There is no second WebSocket to integrate. The thing to get right is coin naming: HIP-3 coins are namespaced by their dex and case-sensitive, so a symbol that works on core perps will silently return nothing on a builder dex. Resolve names from that dex's own universe rather than hardcoding tickers. Hyperliquid HIP-3 API covers the discovery calls and the dex parameter in detail.

Or let something else hold the socket open

Running a reliable streaming layer is a real, ongoing engineering job — reconnects, gap detection, state reconciliation, monitoring — and it is entirely upstream of having a trading edge. If your goal is the edge rather than the infrastructure, Signalview already runs this: you can browse scored Hyperliquid signals, deploy an AI trading agent that trades a backtested strategy 24/7 with a scoped, non-custodial key that can only place perp orders, or publish your own strategy as a signal and earn when others trade it. Free to run, and your funds stay in your wallet.

Risk note: Hyperliquid perps are leveraged, high-risk instruments and you can lose your entire margin. Better data plumbing does not reduce market risk. Nothing here is investment advice, and all channel names, payload shapes and rate limits should be confirmed against Hyperliquid's official API documentation.

Frequently asked questions

What is the Hyperliquid WebSocket endpoint?

Hyperliquid serves a WebSocket feed alongside the /info REST endpoint, and it covers both core perps and HIP-3 builder markets. You open a connection, send subscription messages for the channels you want — mids, L2 book, trades, candles, asset contexts, or account-scoped fills and events — and receive pushed updates. Confirm the current endpoint and message format in the official API docs.

Should I use the WebSocket or poll the /info endpoint?

Use both, for different jobs. REST answers 'what is the state now' and is right for startup snapshots and one-off reads; the WebSocket answers 'tell me when it changes' and is right for anything live. The standard pattern is a REST snapshot to establish state, then a subscription for deltas, re-snapshotting whenever you detect a gap.

How do I stream the Hyperliquid order book?

Subscribe to the L2 book channel for the coin you want, seeded by a REST snapshot so you have a defined starting state. The critical detail is reconnect handling: re-subscribe explicitly after any disconnect and re-snapshot rather than resuming, because a book that silently missed deltas looks normal and is wrong.

Can I stream HIP-3 builder markets?

Yes, over the same WebSocket — there is no separate feed. The gotcha is naming: HIP-3 coins are namespaced by their dex and case-sensitive, so a core-perp symbol will silently return nothing on a builder dex. Resolve coin names from that dex's own meta universe instead of hardcoding tickers.