Skip to main content

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.

Replay and reconstruction are the right primitives when sequence, local state, gap handling, or order-book rebuilding matters more than a single response. Replay and reconstruction are stricter than ordinary historical pulls. If a model, chart, or strategy depends on event order, every message and request must carry enough metadata to reproduce the sequence.

​
Choose The Primitive

NeedPrimitiveStart
One current snapshotREST snapshotOrder Book Routes
Bounded historical pullREST historyHistorical Market Data
Event-order playbackWebSocket replayWebSocket Replay
Local book maintenanceWebSocket channels and diffsWebSocket L4 Order Book
Reconstruction helpersSDK reconstructionSDK Reconstruction
File-style rebuildData Catalog export plus schema metadataExport Schemas

​
Source Metadata

Every replay or reconstruction workflow should record:
  • venue family and symbol
  • route, channel, or export schema key
  • start and end time
  • cursor or replay sequence
  • snapshot source
  • diff or event source
  • gap, reconnect, and retry events
  • data-quality result
  • meta.request_id where REST is involved

​
State Boundaries

Replay sends ordered historical events. Reconstruction turns a baseline plus ordered changes into local state. Keep those concepts separate in code and output labels. A replay file can be correct while a reconstruction is unsafe if the client applied messages out of order, ignored a gap, or rebuilt from the wrong snapshot.
BoundaryRecord
Baselinesnapshot route, replay snapshot, checkpoint, timestamp, and request ID when REST is used
Updateschannel, diff source, cursor, replay window, and message order
Gap behaviorgap start/end, whether the run stopped, and rebuild decision
Output statecomplete, partial, rejected, or rebuilt from a named checkpoint
State labels matter for downstream users. A chart can show a partial replay window, but a trading model or backtest should not treat partial reconstruction as clean input.

​
When Not To Use Replay

Do not use replay when a REST snapshot answers the question. Replay is heavier and stricter because sequence mistakes can silently corrupt local state. Use it when timing, causality, diffs, or historical event order are part of the product requirement. If the same workflow later moves from WebSocket replay into exported files, keep the replay metadata with the file output so the rebuild can be explained later.

​
Minimal Run Manifest

{
  "venue_family": "hyperliquid_core",
  "symbol": "BTC",
  "primitive": "websocket_replay",
  "channels": ["orderbook", "trades"],
  "window": { "start": 1681516800000, "end": 1681603200000 },
  "baseline": "replay_snapshot",
  "gap_events": [],
  "output_state": "complete"
}
Use the same manifest idea for SDK reconstruction and export-backed rebuilds. The exact fields can vary, but the file should name the source, window, gap state, and output state.

WebSocket Backtesting

Replay historical windows for backtests and incident review.

SDK Reconstruction

Client-side reconstruction patterns and state handling.

Responses

Envelope, request ID, pagination, error, and parser rules.

Data Gaps

Treat gaps as data, not as parser noise.
Last modified on May 18, 2026