Endpoint
Production gateway:Recommended Integration Flow (Production)
Use REST for snapshots and WebSocket for realtime updates:- Fetch an initial snapshot via REST (e.g.
/fixtures,/fixtures/odds) - Connect to the WebSocket and send
loginwith filters - Start processing updates after receiving
login_ok - Persist
serverEpochand per-channellastSeenId(fromentryId) - On reconnect, send
serverEpoch+lastSeenIdto resume - If you receive
snapshot_required, re-fetch the snapshot via REST
Login Mode
WebSocket supports login-only subscriptions. To change filters or channels, reconnect with a newlogin.
Message Envelope
All updates share a common envelope:channel– stream name (e.g.odds,fixtures)type– message type (currently alwaysUPDATE)payload– channel-specific datats– UTC timestamp (milliseconds)entryId– cursor for replay/resume
entryId is not guaranteed to be contiguous. See Resume & Replay for full explanation.
Encoding: JSON vs Binary
Control at login usingreceiveType.
"json"(default) — all messages arrive as UTF-8 JSON"binary"— data frames use MessagePack; control frames remain JSON
Control messages likelogin_ok,snapshot_required, andresume_completeare always JSON, even in binary mode.
Channel Types
- Fixture-scoped:
fixtures,scores,odds,bookmakers. — payloads includefixtureId - Future-scoped:
futures,bookmakersFutures,oddsFutures— includefutureId - Global:
currencies— no ID
See /websocket/channels/* for per-channel schemas.
Throughput Guidance
- Prefer
receiveType: "binary"for high-volume channels likeodds - Use filters (
sportIds,bookmakers) to reduce noise oddsshould be treated as latest state, not a tick ledger
WebSocket Limits
| Limit Type | Description |
|---|---|
| Concurrent connections | Enforced per apiKey group (max: 5). See error 4003. |
| Backpressure | If your client can’t keep up, connection is closed (4002). |
| Replay window | See resumeWindowMs in Resume & Replay |
| Message rate | Not explicitly limited, but filters are recommended for performance |