> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Hyperliquid WebSocket Streaming API

> Stream Hyperliquid order books, trades, and L4 events live, with timed replay on supported channels and checkpoint-anchored L4 replay.

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. L4 replay on Hyperliquid core, HIP-3, HIP-4, and Spot uses checkpoint-anchored bulk delivery.

```javascript theme={"theme":"github-dark"}
ws.send(JSON.stringify({ op: "subscribe", channel: "orderbook", symbol: "BTC" }));
```

<CardGroup cols={2}>
  <Card title="Connect" icon="plug" href="/websocket/connection">
    Open the socket, authenticate, keep it alive, reconnect cleanly.
  </Card>

  <Card title="Channels" icon="radio" href="/websocket/channels">
    The full channel and symbol matrix by venue family.
  </Card>
</CardGroup>

## 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, a separate venue family, streams live books on `lighter_orderbook` along with live trades, open interest, and funding; `lighter_l3_orderbook` is replay-only, and current Lighter L3 reads use REST. See [Lighter WebSocket channels](/websocket/lighter). HIP-4 streams `hip4_orderbook`, `hip4_trades`, and `hip4_open_interest` live, and all three also replay.

## L2 Book Streaming And L4 Book Streaming

Pick the depth by the downstream job, not by habit:

| Need | Channel | What arrives |
| - | - | - |
| Aggregated depth (L2 book) | `orderbook` | Price levels with size, live or through standard timed replay |
| Order-level book (L4) | `l4_diffs` | Per-order book changes live, with checkpoint-anchored bulk replay; Spot, HIP-3, and HIP-4 use prefixed variants |
| Order events | `l4_orders` | Placements, fills, cancels, and status changes live, with checkpoint-anchored bulk replay; Spot, HIP-3, and HIP-4 use prefixed variants |
| Fill stream | `trades` | Executions as they happen |

Published channel access is not sold as a higher-tier feature, with one exception: the live [`mempool`](/websocket/mempool) channel comes with the Pro, Scale and Enterprise plans. Otherwise, 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](/websocket/l4-orderbook) 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:

```javascript theme={"theme":"github-dark"}
ws.send(JSON.stringify({
  op: "replay",
  channel: "orderbook",
  symbol: "BTC",
  start: 1681516800000,
  end: 1681603200000,
  speed: 10
}));
```

The standard replay path answers with `replay_started`, a `replay_snapshot` baseline when several channels replay together, 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`. The Spot, HIP-3, and HIP-4 L4 channels and the full-depth `orderbook_full` and `hip3_orderbook_full` channels replay the same way. 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](/websocket/replay) and the [Protocol reference](/websocket/schema).

## Standard Replay Speed And Subscriptions By Plan

| Plan | Max standard replay speed | Max subscriptions |
| - | - | - |
| Free | 10x | 10 |
| Build | 50x | 500 |
| Pro | 100x | 3,000 |
| Scale | 300x | 20,000 |
| Enterprise | 1,000x | Unlimited |

Plans govern standard replay-speed and subscription caps, plus Free's rolling 30-day replay window, not route or channel entitlement, except that the live `mempool` channel comes with Pro, Scale and Enterprise; Build and above keep the full retained archive. Core L4 checkpoint-anchored bulk replay is available on every tier and ignores `speed`. It is a replay format, not bulk WebSocket streaming: the `stream` command has been discontinued, and large dataset downloads use the [Data Catalog](/data-catalog) Parquet export. Higher tiers raise standard replay-speed and subscription caps; see [WebSocket limits](/websocket/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. L4 history on core, HIP-3, HIP-4, and Spot replays over WebSocket from the nearest usable checkpoint. For reproducible runs, store the replay window, delivery model, speed when applicable, gap events, and output state as [Backtesting](/guides/point-in-time-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](/core-concepts/replay-and-reconstruction) to pick the primitive before writing client code.

See the [Hyperliquid market data API](https://0xarchive.io/hyperliquid) for other data types.

## Next Step

Open [WebSocket connection](/websocket/connection) to get a socket up, pick channels in [WebSocket channels](/websocket/channels), then run one bounded replay from [WebSocket replay](/websocket/replay). For research workflows, continue to [Prepare data for a reproducible backtest](/guides/point-in-time-backtesting).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.