Order lifecycle

Use this stream when fills alone don't tell the story: order management systems confirming their own placements and cancels, execution research measuring time-from-open-to-fill, risk systems watching trigger (stop/TP) orders arm and fire, and flow analytics on cancel-to-trade ratios. Every event carries the order's full parameters, so you never need a lookup to interpret a status change.

At 725M+ events a day platform-wide, this is not a feed to drink unfiltered. Subscribe with coin and user filters and the server drops everything else before it reaches you.

// stream.hyperliquidrpc.com:443 — gRPC over TLS (HTTP/2)// auth: API key in x-api-key metadata · server reflection enabledpackage hyperliquid; service Streaming {  // Bidirectional: send one subscription, then read updates.  // Subscribe with stream_type: ORDERS.  rpc StreamData (stream SubscribeRequest) returns (stream SubscribeUpdate);}

StreamData is the QuickNode-compatible multiplexed service; the subscription names the stream_type and an optional filters map. Each update carries the block number and the event payload as JSON.

# StreamData is bidirectional; grpcurl sends the subscription for you.grpcurl -H 'x-api-key: YOUR_KEY' \  -d '{"subscribe":{"stream_type":"ORDERS","filters":{"coin":{"values":["ETH"]}}}}' \  stream.hyperliquidrpc.com:443 \  hyperliquid.Streaming/StreamData

Filter values are exact matches: coin takes market symbols, user takes wallet addresses. Add start_block to the subscription to replay before going live.

Fields typed string that carry numbers are byte-exact decimal strings, verbatim from the node. Compare and store them as strings or arbitrary-precision decimals. Never parseFloat a price you intend to reconcile.

• coins[]
• wallets[]
• replay from a block height

Filters are applied on the server, so filtered-out messages never leave our edge. You only pay for what you subscribe to. Request shapes for every stream family are on Filtering; backfill semantics on Replay & backfill.

Pure event stream in block order: one message per order-status transition. No snapshot phase.

• Filter, or pay for the firehose. 725M+ order updates a day (~8,400/s average) arrive if you subscribe bare. Server-side coin and user filters are strongly recommended.
• Statuses are transitions, not state. You receive one message per transition (open, filled, canceled, triggered, rejected). Keep your own order table keyed by oid; there is no snapshot of currently-open orders.
• Trigger orders fire in two steps. A stop or take-profit first appears with its trigger_px and trigger_condition, then emits triggered when it activates and rests or executes as a normal order.
• Partial fills keep the order open. Join against the trades stream by oid to see the fills behind an order; filled arrives only when the order completes.

{  "block_height": 612408135,  "block_time": "2026-06-09T08:14:03.121Z",  "user": "0x91b3c07a4de2f6cc185a0fd2b94e7a30c8d1572e",  "coin": "ETH",  "side": "B",  "limit_px": "3498.25",  "sz": "12.4400",  "order_type": "Limit",  "tif": "Gtc",  "trigger_px": null,  "trigger_condition": null,  "reduce_only": false,  "oid": 91834221384,  "cloid": null,  "status": "open"}

725M+ order updates/day platform-wide (~8,400/s average). Server-side coin and wallet filters are strongly recommended.

• Trades & swapsThe fills behind every filled status. Join by oid.
• FilteringThe StreamData filters map, field by field.
• Replay & backfillstart_block semantics for rebuilding order state from history.
• Operations guideKeeping a high-volume subscription healthy in production.