Choosing a stream

One endpoint, nine streams. Start from what your system needs — a price, fills, book state, or full microstructure — and take the narrowest stream that carries it. Narrower streams mean less bandwidth, less parsing, and lower bills.

Decision table

You needUseMethod
Just the BTC priceDedicated BTC pricehyperliquid_btc_price.v1.BtcPriceStreaming/StreamBtcPrices
A price ticker for any marketL2 Order Bookhyperliquid.OrderBookStreaming/StreamL2Book (n_levels: 1)
Fills with wallet, PnL, feesTrades / Swapshyperliquid_swaps.v1.SwapStreaming/StreamSwaps
Aggregated depth by levelL2 Order Bookhyperliquid.OrderBookStreaming/StreamL2Book
Every resting order, with ownerL4 Order Bookhyperliquid.OrderBookStreaming/StreamL4Book
Order-status eventsOrder lifecyclehyperliquid.Streaming/StreamData (stream_type: ORDERS)
Every book delta (microstructure)Raw book diffshyperliquid.Streaming/StreamData (stream_type: BOOK_UPDATES)
TWAP / large-order detectionTWAP algoshyperliquid.Streaming/StreamData (stream_type: TWAP)
Funding, liquidations, transfersEventshyperliquid.Streaming/StreamData (stream_type: EVENTS)
Raw L1 blocksBlockshyperliquid.BlockStreaming/StreamBlocks
Your existing Dwellir clientDwellir-compatible gatewayhyperliquid_l1_gateway.v2.HyperliquidL1Gateway

Price only

For BTC, use the dedicated Dedicated BTC price ticker — one message per last-trade price change, three fields, a few messages per second at most. It is the cheapest stream on the endpoint and available on every tier including Free.

For any other market, subscribe to L2 Order Book with n_levels: 1: a snapshot, then one top-of-book update per block. Predictable rate, tiny payload.

Fills and attribution

Trades / Swaps is the richest feed: every executed fill with the trader's wallet, direction, realized PnL (closed_pnl), fee and rebate flag, maker/taker role, and TWAP linkage. This is the stream for copy-trading, flow analysis, and anything that needs to know who traded — around 6.5M fills a day across 462 markets, so filter by coins or wallets unless you want the full tape.

If you only care about order-status transitions (placed, canceled, triggered, rejected) rather than executions, use Order lifecycle — but note its volume: 725M+ order updates a day platform-wide. Server-side filters are strongly recommended.

Book state

L2 Order Book gives aggregated depth by price level (1–100 levels, guaranteed never crossed) — the right surface for quoting, spread monitoring, and execution checks. L4 Order Book gives the full order-by-order book with each resting order's owner: queue position, order ownership, and per-block diffs after an initial snapshot.

Microstructure

Raw book diffs is the lowest-level surface: every new/update/modified/remove delta on every book, in strict block order. Pair the deltas with a snapshot to reconstruct the exact book at any block. It is also the highest-volume stream on the endpoint — filter by coin unless you genuinely need the firehose.

Everything else

  • TWAP algos — native TWAP status and execution progress; low volume, useful for large-order detection.
  • Events — funding payments with rates, liquidations, deposits and withdrawals; bursty around funding intervals and volatility.
  • Blocks — the raw L1 block stream, if you run your own decoding or verification.
  • Dwellir-compatible gateway — keep your existing Dwellir stubs and just change the endpoint.

Cross-cutting

Every stream filters server-side (by coin, and where applicable by wallet), covers all markets — perps, spot @N, HIP-3 dex:SYMBOL — and carries byte-exact decimal strings for every financial value. Streams on Pro and above can replay from a past block height to backfill before going live. See Filtering and Replay & backfill.