Skip to main content

Endpoint

The session id alone addresses the log — the server resolves which sport the session belongs to. This returns the full event log for one game: the events only, oldest to newest, in the same wire format as the live feed, plus the contract version they were recorded under. The current state is not included — for a live game the WebSocket carries the full snapshot on every frame. To rebuild state from the log alone (a closed game, offline analysis), replay the events oldest to newest: there is no client library — each sport page specifies every event’s exact effect on state, and each undo cancels the most recent earlier press, so keep undo rows in the replay. The response’s own sport field tells you which sport’s event vocabulary and state shape apply, so a stored session id is self-describing even without a catalog row (a closed game leaves the open slice of the catalog, though it stays listed under ?status=closed). The endpoint works across every contract version. It reads the stored log directly, with no version check, so a game recorded under an older schema stays available long after the live format has changed. The schema identity is the pair (sport, contractVersion); compare both — versions count independently per sport, so “v4” alone is ambiguous.

Path parameters

Authentication

Use a Bearer token or the ?token= query parameter — the same credential as /subscribe. You can read a game if it is public, or if your account was granted that session. Finished games stay readable, which is what public viewer links rely on. See Authentication.
This endpoint never checks the contract version — historical logs must stay readable across schema changes, so any X-Contract-Version header is ignored. Use the contractVersion in the response body to know which schema the events were recorded under.

Error responses

A 404 always means the session was never published (or the id is malformed) — it never stands in for a lost log. In the rare case a published session’s stored log is lost (storage incident), the answer is 410, so a backfill pipeline can tell “this tape is gone” apart from “this session never existed”. The catalog flags the same condition up front via each row’s historyAvailable field, so you can skip a dead link without fetching it.

Response


Events

Each entry is one scout press, in the same WireEvent format the WebSocket uses for live frames. The full log is returned — there is no pagination.
serverIngestTs is a receipt stamp, not an ordering key. Events are returned oldest to newest and seq is the ordering authority — a press that arrives out of order is placed by its seq, so sorting by serverIngestTs can differ from the log’s own order. Treat the fractional part as informative precision, not a tiebreaker.

Reconnect and deduplication

On reconnect, re-fetch /history and remove duplicates against your existing log by seq before appending live frames. Events you already buffered from the WebSocket will appear again in the backfill — seq is the key that identifies them.