Skip to main content
0xArchive runs one WebSocket surface for Hyperliquid real-time subscriptions and available historical replay. Connect from a server-side client with Authorization: Bearer $OXARCHIVE_API_KEY. Standard replay uses timed delivery on replay-supported channels. Core L4 replay uses checkpoint-anchored bulk delivery, while HIP-3, HIP-4, and Spot L4 channels are real-time only.

Connect

Open the socket, authenticate, keep it alive, reconnect cleanly.

Channels

The full channel and symbol matrix by venue family.

Stream The Hyperliquid Order Book

The orderbook channel streams aggregated (L2) depth updates for core perp symbols such as BTC and ETH. Spot and HIP-3 use venue-prefixed live channels (spot_orderbook, hip3_orderbook) with their own symbol shapes. Lighter channels use historical replay for stored lighter_orderbook and lighter_l3_orderbook data, while current Lighter reads use REST. HIP-4 serves live hip4_trades; stored hip4_orderbook and hip4_open_interest history remains replayable, and current order-book and outcome-side OI reads use REST.

L2 Book Streaming And L4 Book Streaming

Pick the depth by the downstream job, not by habit: Published channel access is not sold as a higher-tier feature. Plans govern capacity and request windows, while the selected route, family, symbol, and schema determine data availability. For stateful L4 workflows, WebSocket L4 order book covers snapshots, diffs, gaps, and rebuilds.

Replay Available History On The Same Socket

Standard replay sends available historical data over the WebSocket in timeline order. The command names the channel, symbol, window, and speed:
The standard replay path answers with replay_started, a replay_snapshot baseline, ordered historical_data messages, and replay_completed at the end of the window. gap_detected marks missing intervals so the client can stop or rebuild instead of silently corrupting local state. Controls are replay.pause, replay.resume, replay.seek, and replay.stop. Core L4 replay is single-channel for l4_diffs or l4_orders. It starts from the latest usable checkpoint at or before start, emits l4_snapshot, then one or more l4_batch events. For this path, speed is ignored. Core L4 supports pause, resume, and stop; replay.seek is rejected. A request can be rejected when no usable checkpoint exists for the symbol and window. Full command and event shapes live in WebSocket replay and the message schema.

Standard Replay Speed And Subscriptions By Plan

Plans govern standard replay-speed and subscription caps, plus Free’s rolling 30-day replay window, not route or channel entitlement; Build and above keep the full retained archive. Core L4 checkpoint-anchored bulk replay is available on every tier and ignores speed. This wire delivery format is separate from the plan-level Bulk streaming capability. Higher tiers raise standard replay-speed and subscription caps; see WebSocket tier limits for the full capacity table.

Latency And Freshness Boundaries

The data-quality response separates service checks and stored-data freshness. websocket.current_ms is the latest stored order-book freshness value, not client WebSocket round-trip time. It does not measure WebSocket upgrade time or application ping/pong latency. There is no published end-to-end WebSocket latency percentile today. Measure one connection with application ping/pong and treat that result as specific to the requesting client’s path.

History Behind The Stream

Live channels answer what is happening now; replay answers what happened on channels and windows with replay coverage. Hyperliquid native L2 order books and trades reach back to April 2023. L4 coverage is newer and varies by family, symbol, and usable checkpoint. Core L4 has the WebSocket replay path. HIP-3, HIP-4, and Spot L4 history is not replayable over WebSocket. For reproducible runs, store the replay window, delivery model, speed when applicable, gap events, and output state as WebSocket backtesting describes.

When To Use This Surface

Use WebSocket when sequence matters: local books, monitors, strategy harnesses, incident review, and backtests that react to event cadence. Use REST when one snapshot or one bounded historical window answers the question; it is simpler to retry and audit. If the job is a bounded data pull that later becomes a stream, start with Replay and reconstruction to pick the primitive before writing client code.

Next Step

Open WebSocket connection to get a socket up, pick channels in WebSocket channels, then run one bounded replay from WebSocket replay. For research workflows, continue to WebSocket backtesting and Point-in-time backtesting.
Last modified on August 31, 2026