Skip to content

WebSocket Workbench

Subscribe to any channel, watch the ack, snapshot and live stream with freshness, record a session, simulate a disconnect and diff state before and after.

Last verified against protocol docs: 2026-10-11
Source: WebSocket subscriptions
rules: websocket@1.2.0 · rate-limits@1.2.0

Subscription

Channels on mainnet. Parameters are validated before anything is sent.

Info/WS coin string (resolve with the Asset Resolver).

Aggregate to 2–5 significant figures.

1, 2 or 5 (only with nSigFigs 5).

Subscription message
{
  "method": "subscribe",
  "subscription": {
    "type": "l2Book",
    "coin": "BTC"
  }
}

One connection at a time. Limits: 10 connections, 1000 subscriptions and 10 distinct users per IP; idle connections close after 60 s, so the workbench pings every 30 s.

Connectionidle

Not connected.

no data yet0 messages0.0 KB
The subscriptionResponse ack appears here.
The first message on the channel (the snapshot, where the channel has one) appears here.

L2 book semantics

Aggregated order book levels (20 per side).

Message channel
l2Book
Model
Each message is the full current state
Sequence number / resume cursor
none
Dedupe / ordering key
time
Ordering & recovery
No sequence number. Messages arrive in block order on a single connection; after reconnect there is no way to request missed messages. Full book snapshot pushed on blocks at least 0.5 s apart; `time` is the block time and increases monotonically — use it to discard stale snapshots.

Live stream

Newest first; last 300 messages kept in memory. Click a row to expand it.

Messages appear here as they arrive, newest first.

Record & replay

Recordings are stored in this browser (IndexedDB), bounded to 5,000 messages / 8 MB / 30 minutes. Exports are sanitised: every address is replaced with a stable pseudonym.

Replay speed

No recordings yet. Connect, press Record, then Stop & save — or import a session file.

Ordering and recovery by channel

No Hyperliquid WebSocket channel has a sequence number or resume cursor. What a client can do after a reconnect depends on whether the channel sends full snapshots, a snapshot followed by deltas, or bare events.

channelsnapshot on subscribesequence / cursordedupe keyafter a reconnect
allMids
every messagenone—Replace state with the next message.
l2Book
every messagenonetimeReplace state with the next message.
trades
first messagenonetidRe-subscribe, merge the snapshot by key; gaps longer than the snapshot need REST backfill.
bbo
every messagenonetimeReplace state with the next message.
candle
every messagenonetReplace state with the next message.
activeAssetCtx
every messagenone—Replace state with the next message.
userFills
first messagenonetidRe-subscribe, merge the snapshot by key; gaps longer than the snapshot need REST backfill.
orderUpdates
nononeorder.oidEvents during the gap are lost; backfill via REST (e.g. openOrders, historicalOrders).
userHistoricalOrders
first messagenoneorder.oidRe-subscribe, merge the snapshot by key; gaps longer than the snapshot need REST backfill.
userEvents
arrives on "user"
nonone—Events during the gap are lost; backfill via REST (e.g. openOrders, historicalOrders).
userFundings
first messagenonetimeRe-subscribe, merge the snapshot by key; gaps longer than the snapshot need REST backfill.
userNonFundingLedgerUpdates
first messagenonehashRe-subscribe, merge the snapshot by key; gaps longer than the snapshot need REST backfill.
clearinghouseState
every messagenone—Replace state with the next message.
allDexsClearinghouseState
every messagenone—Replace state with the next message.
openOrders
every messagenone—Replace state with the next message.
spotState
every messagenone—Replace state with the next message.
webData3
every messagenone—Replace state with the next message.
activeAssetData
every messagenone—Replace state with the next message.
twapStates
every messagenone—Replace state with the next message.
notification
nonone—Events during the gap are lost; backfill via REST (e.g. openOrders, historicalOrders).
allDexsAssetCtxs
every messagenone—Replace state with the next message.
outcomeMetaUpdates
nonone—Events during the gap are lost; backfill via REST (e.g. openOrders, historicalOrders).