Skip to main content

​
Snapshot

Levels are aggregated — one entry per unique price, summed across all resting orders at that price.

​
Live updates

For real-time book updates use the WebSocket orderbook channel. See WebSocket messages. The snapshot carries a seq field; subsequent WS deltas carry an incrementing seq. If your local copy drifts, request a fresh snapshot.

​
Reconciliation with the WebSocket feed

The hash field is a canonical 16-hex SHA-256 prefix over the (bids, asks) pair — price + quantity only, computed by both core-api (on this response) and ws-gateway (on book_snapshot and book_update envelopes). For the same logical book state the two sides produce identical hashes. Typical reconciliation flow:
  1. Open the WebSocket and subscribe to token_book for the tokenId you care about.
  2. Buffer incoming book_snapshot / book_update frames keyed by their envelope seq.
  3. Call GET /api/markets/{symbol}/orderbook and read the response hash.
  4. Walk the buffered WS frames to find one with a matching hash — that seq is your alignment point; drop earlier frames, apply later ones onto the REST snapshot.
  5. From there each book_update you apply must produce the same hash as the envelope. If they ever diverge, issue get_book_snapshot to force a fresh server-side snapshot and restart alignment.
The hash domain is identical between REST and WS by construction — count is excluded from the hash on both sides, so an aggregated REST response (no count) and a book_snapshot.data (with count) produce the same hash for the same (bids, asks).

​
Cross-reference

The orderbook is the matcher’s view of resting orders. For your own orders, always cross-reference with GET /api/me/orders/open — that is authoritative from PG.