Real-time market data means live subscription behavior. Reach for it when REST snapshots and historical replay are the wrong primitives. Real-time WebSocket is the right surface when the application needs continuing updates: live dashboards, monitors, alerts, local order-book state, or agent workflows that watch a bounded market. Use REST when you need one response. Use WebSocket replay when the job needs historical stream order.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.
Real-Time Fit
| Need | Use |
|---|---|
| Latest point-in-time snapshot | REST order-book, trades, or summary routes |
| Continuing live updates | WebSocket subscription |
| Historical event order | WebSocket replay |
| Backtest input file | REST history or replay depending on sequencing |
| Freshness evidence | Data-quality routes before trusting output |
Subscription Design
Choose route family
Pick Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter before choosing a channel.
Choose one channel and symbol
Start with the minimum channel-symbol pair that confirms the consumer can keep up.
Handle state changes
Track snapshots, updates, gaps, unsubscribe events, reconnects, and local state rebuilds.
Live Subscription Packet
Use this packet before opening or regenerating a live subscription.| Field | Capture |
|---|---|
| Venue family | Core, Spot, HIP-3, HIP-4, or Lighter |
| Channel-symbol pair | One channel and one symbol for the first run |
| Consumer | Dashboard, alert, local book, model input, incident monitor, or agent task |
| Keep-alive policy | Ping interval, idle timeout, reconnect cap, and resubscribe behavior |
| Lag signal | Queue depth, last message time, processing delay, and dropped UI updates |
| Exit path | Unsubscribe, close, retry budget, or fail-visible state |