/api/snapshotreturns the current state and gives you atoken. This is where you declare your scope./api/updated?since=<token>returns only the rows that changed since that token, plus a fresh token for the next call.
/api/updated never returns a snapshot — without a since it answers 400. The two jobs are deliberately separate: an endpoint called updated that hands back the entire book would be surprising, and expensive.
window_seconds field tells you how much time your delta covered — handy to pace your polling.
Scoping your session
The snapshot call is also where you say what your session is about. Add any ofsport_id, league_id, event_id, market or period (comma-separated lists are accepted): the snapshot is limited to that scope, and the token you receive carries the scope with it.
From then on you send the token alone. The server knows which base to compute the delta against, and your scope cannot drift mid-session because you forgot a parameter.
scope, so you can always see what your token means. To change scope, open a new session with a new snapshot.
What it costs
A call costs 1 + the number of rows returned. Frequency is nearly free; volume is what you pay for. Two consequences are worth planning around. Scope is the main lever on your bill. Measured on the live book, a moneyline / full-time scope is around 5% of all movements — so roughly 5% of the cost of following everything. Your snapshot is billed the same way, which is the other reason to scope it: a full-book snapshot is over 20,000 rows. Polling faster does not get you fresher data for free. A price that moves five times in thirty seconds appears once in a 30-second delta and up to five times at 5-second intervals, because the cursor tracks each market’s last real change. Faster polling buys granularity, not freshness.Keep the last
token you received and send it back on every call. Tokens are opaque — treat them as a cursor, not as a timestamp you can compute.