Hyperliquid API: REST vs WebSocket for Trading Bots

A market maker quoting both sides of the book on Hyperliquid cares about one number: how many milliseconds pass between something happening on HyperCore and the bot reacting to it. Everything else — SDK ergonomics, how clean the code looks — is secondary. Pick the wrong transport and you're either burning rate-limit budget on a polling loop or maintaining a WebSocket handler you didn't actually need.

Hyperliquid exposes the same underlying actions through two doors. The REST API has two POST endpoints: /info for reads (order books, mid prices, user state, fills, funding history, meta) and /exchange for writes (place order, cancel, modify, update leverage, transfer). The WebSocket at wss://api.hyperliquid.xyz/ws lets you subscribe to pushed channels — l2Book, trades, allMids, bbo, userEvents, userFills, orderUpdates — and it also accepts "post" messages that wrap the exact same info/exchange payloads you'd send over REST, just over a socket that's already open.

That last part trips people up, so start there.

The order-placement latency myth

A lot of bot builders assume REST is slow because "HTTP" and switch to WebSocket order placement expecting a free latency win. The real cost isn't the protocol, it's the connection setup. A fresh HTTPS request pays for DNS, TCP handshake, and TLS negotiation before your signed payload even leaves the box — that can add 50-150ms depending on your region relative to Hyperliquid's validators. A WebSocket pays that cost once, at connect time, then every subsequent post message rides the open socket for a few milliseconds of framing overhead.

So the honest comparison isn't REST vs WebSocket, it's cold-connection REST vs warm-connection anything. If you keep a persistent HTTP/1.1 connection alive with keep-alive and connection pooling (which most HTTP clients support and most bot code doesn't bother configuring), REST order placement gets close to WS-post latency. The gap that remains is real but smaller than the marketing around WebSocket "speed" suggests. Every order, over either transport, still needs an EIP-712 signature and a strictly increasing nonce, and it still has to reach consensus on HyperCore — that part doesn't change no matter how you deliver the bytes.

Where the transport choice actually matters is nonce and rate-limit bookkeeping. /exchange calls consume your address's action budget regardless of whether you sent them over REST or the WS post wrapper, so batching multiple orders into one action (Hyperliquid supports bulk order arrays) saves more latency and quota than switching transports ever will.

Where WebSocket actually wins: state, not orders

The clear-cut case for WebSocket isn't sending orders, it's receiving fills and book updates. Polling /info with userFills or openOrders every 200ms to catch a fill means you're averaging 100ms of staleness even in the best case, you're spending rate-limit weight on requests that return "nothing changed" most of the time, and you're guaranteed to eventually miss a fill-then-cancel race if your poll interval is coarser than the event.

Subscribe to userEvents or userFills on the socket instead and you get pushed the fill the instant HyperCore emits it, with no polling waste. Same story for l2Book and bbo if you're quoting — REST snapshots go stale the moment you receive them, while the WS feed gives you a continuous stream of deltas you can apply to a local order book copy. Any market maker or liquidation bot reacting to book depth in real time should be running on the WS feed for market data, full stop; REST is fine for a one-time snapshot at startup and not much else.

One operational detail that catches people out: the socket needs a ping roughly every 50 seconds or Hyperliquid will drop it as idle, and after any disconnect you have to resubscribe to every channel from scratch — there's no server-side session that remembers your subscriptions. Build reconnect logic that resubscribes and reconciles state (diff your local order book against a fresh snapshot) rather than assuming the stream picks up where it left off.

A minimal pattern that works

# Market data + fills: WebSocket, long-lived, auto-resubscribe
ws.subscribe({"type": "l2Book", "coin": "ETH"})
ws.subscribe({"type": "userFills", "user": address})

# Order placement: REST /exchange with a pooled/keep-alive session,
# OR the WS post wrapper if you're already latency-obsessed
session = requests.Session()  # reused across every order
resp = session.post(f"{BASE_URL}/exchange", json=signed_order_action)

Most production bots end up running both transports simultaneously: WS for everything read-time-sensitive, REST (pooled) for order actions, because REST gives you a synchronous request/response pattern that's much easier to reason about for retries and error handling than correlating async WS post responses by request ID.

Comparison table

Dimension	REST (/info, /exchange)	WebSocket
Order placement latency	Good with pooled/keep-alive connections	Marginally better once socket is warm
Fills / order updates	Requires polling, inherently stale	Pushed instantly via userEvents/userFills
Order book / mid price	Snapshot only, ages immediately	Continuous delta stream (l2Book, bbo)
Rate-limit exposure	Weight consumed per poll, wasteful if polling	No polling waste; one subscription covers a stream
Failure handling	Simple request/response, easy retries	Needs reconnect + resubscribe logic, dedupe
Implementation complexity	Low	Moderate (session/heartbeat management)
Best for	One-off queries, order actions, startup snapshots	Fills, book state, anything latency-sensitive

Which to pick when

Don't treat this as an either/or transport decision — it's a per-function one. Use REST for order placement with a properly pooled HTTP client; the latency delta versus WebSocket is small enough that it's rarely the bottleneck in your fill rate, and REST's request/response model is simpler to build reliable retry logic around. Use the WebSocket feed for everything you need to react to: fills, order state changes, and book depth. A funding-rate arbitrage bot that rebalances every few minutes can get away with REST polling for most things. A market maker adjusting quotes on every book tick cannot — it needs the WS l2Book stream or it's trading against stale prices, which is the fastest way to get picked off.

If you're deciding this for a bot you're actually about to ship, it's worth reading how the two-layer design behind HyperCore and HyperEVM affects execution guarantees, since that architecture is why the API is split into /info//exchange and a separate push feed in the first place — see our breakdown of HyperCore vs HyperEVM's dual architecture. It's also useful context if you're benchmarking Hyperliquid against dYdX v4's architecture or weighing order book versus AMM-style liquidity for a given strategy, since the transport question only matters once you've picked the venue.

We build both sides of this for clients regularly — dual-transport execution engines for perps bots, quote engines for market makers, and monitoring dashboards that consume the same WS fill stream discussed here, plus liquidation bots and funding arbitrage systems that lean on the same architecture, all wired into a live trading dashboard for visibility.

If your bot's edge depends on reacting to book changes before the next tick, talk to us about a Hyperliquid market maker build that's architected around the WS feed from day one.