One feed. Explicit state.
The executable beta-0 delivery service pairs an authenticated versioned REST snapshot with an authenticated WebSocket stream of ordered deltas after the declared snapshot position.
How the stream fits together
A subscriber atomically applies the filtered REST snapshot, authenticates to the stream, declares that snapshot’s current position and filters, then processes contiguous ordered deltas.
Read by chapter
Protocol
Versioned REST snapshots, WebSocket authentication, declared positions, and ordered deltas.
OPEN CHAPTER →02Entity model
Canonical sports, leagues, participants, events, markets, outcomes, books, and quotes.
OPEN CHAPTER →03Payload catalog
Executable v1 shapes for snapshot, control, state, odds, source, and manifest messages.
OPEN CHAPTER →04Reliability
Ordering, freshness, explicit state transitions, and fresh-snapshot recovery.
OPEN CHAPTER →Contract principles
Consumers use stable OddsLoom objects rather than provider-native structures.
Hot-path updates replace a complete entity or quote instead of applying ambiguous patches.
Suspended, closed, corrected, and removed states are communicated rather than inferred.
A reconnect or sequence gap requires a new REST snapshot before deltas resume. Beta has no replay path.
Coverage follows the live manifest
The customer product includes every actively ingested sportsbook, every jurisdiction each feed actually represents, and every ingested sport and league—once the relevant book, jurisdiction, and event phase pass the release gate. The customer-visible manifest reports the exact coverage available now.
Within that released scope, OddsLoom publishes every observed canonical market. provider_specific and unresolved offers remain outside the customer product until their semantics are canonical.
Real-time odds infrastructure.
This contract is intentionally focused on live and pregame canonical odds delivery. It is not a picks API, settlement service, historical or replay product, injury feed, or general sports statistics product.