How to Integrate Odds and Sports Data Providers into a Sportsbook

A connection is healthy and odds keep arriving, but one event is mapped to the wrong competition and another market was suspended upstream before the platform applied the message. The feed dashboard is green; the sportsbook’s decisions are not reliable.

Integrating sports data is more than converting a provider payload. The platform must preserve which event, market line and outcome a price describes, know whether that state is complete and usable, and retain the evidence behind an accepted bet. Recovery and provider switching must respect the same meanings.

This guide is for sportsbook engineers, trading teams and technical decision makers. It explains a path from feed contracts to controlled acceptance and settlement. Examples are hypothetical. Provider documentation illustrates specific protocols; it does not prove that every feed behaves the same or that a particular integration is already available in SPINDO.TECH. See sportsbook product development for the surrounding product scope.

Agree the provider contract and separate data from decisions

Distinguish fixtures and identities, scores and event status, offered odds, market availability, results and settlement instructions. They may come from different products or producers, even under one provider agreement. A scoreboard’s final score is not automatically an instruction to settle every market.

Assign responsibility for the trading decision. A feed may supply reference prices, an operator may apply its own pricing and limits, or a managed service may make specified decisions. Document the boundary rather than letting a field named “active” become a universal permission to accept a bet.

• Coverage: sports, competitions, market types, pre-match and live availability, territories and required subscriptions.
• Delivery: snapshots or deltas, ordering scope, event identity, producer handover, recovery limits and supported restart behaviour.
• Use rights: permitted display, redistribution, retention and replay, including access to evidence after termination.
• Operations: support coverage, escalation, planned maintenance, rate limits and how provider notices reach the trading team.
• Changes: schema evolution, market-description versions, test environments and the process for changing a production contract.

Choose streaming or polling for the actual requirement and provider support. Streaming can reduce polling work, while polling may be adequate for an allowed low-frequency use. Neither transport establishes freshness on its own. Test the production access level, filters and configuration; a delayed or limited test feed is not evidence of live coverage.

Give the integration team, trading owner and operating team a shared inventory of these obligations. Compare platform integration services when deciding which adapter and operational responsibilities belong in the engagement.

Map events and market lines without losing their meaning

Create internal identities with a retained mapping to provider namespaces. Do not use a display name as the event key. The same club can have senior, youth and women’s teams, while a rescheduled fixture can change its start time without becoming a different match.

Use sport, competition, participant identities and roles, fixture context and schedule as mapping evidence. Record the provider IDs, mapping version, reason and any manual approval. Ambiguous candidates need an explicit unresolved state; keep their markets unavailable for acceptance until the mapping is trusted. Preserve the history of a correction, especially where accepted bets already reference the previous mapping.

A market is more specific than an event and a label. Match its type, period, parameters, outcome meaning and settlement rules. A regular-time winner and qualification winner are different propositions even if the same two teams appear. Reversing home and away can also reverse a handicap’s meaning.

For a concrete format, Sportradar UOF market identification distinguishes lines using the market ID and specifiers. Its specifier documentation distinguishes identity-bearing parameters from extended descriptive information. Preserve the provider’s actual semantics in the adapter.

In an illustrative totals market, over 2.5 and over 3.5 are separate selections. An internal key that keeps only the event and “total goals” will overwrite one line with the other. Define a canonical identity that includes the relevant period and parameters, normalise their representation deterministically and distinguish a missing value from a meaningful zero.

Keep provider status and the operator’s offer status separately traceable. Canonicalisation should make meanings explicit, not erase source-specific qualifications. The integration-layer guide explains that adapter boundary in the wider platform.

Apply messages using the actual delivery contract

Classify a message before applying it: a full image, partial update, deletion, suspension, result or correction. A field absent from a delta may mean “unchanged”; a replacement image may require clearing previous state. The decoder must implement the particular contract rather than a generic merge of non-empty fields.

For example, Betfair’s Market Stream description starts with an initial market image followed by updates to a cache. That is an exchange protocol example, not a universal sportsbook feed format.

Retain an envelope with provider, producer or stream scope, source identity, message kind, contract version, source timestamp and local receipt time. Preserve a replayable payload or appropriate evidence within the permitted retention policy. The source time and receipt time answer different questions; neither is automatically a cross-provider version number.

Use the documented ordering and recovery mechanism for each stream. Betfair identifies clk as its sequencing mechanism. Do not invent a numeric sequence from an opaque token or compare it with another provider’s token.

Apply a relevant state update and its processing checkpoint under a controlled durable protocol. A restart must not advance past an unapplied change. Design duplicate handling at the right granularity: one message can contain multiple markets, and a replay may be grouped differently. If the contract supplies no safe ordering basis, quarantine conflicts or recover a baseline rather than claiming “latest” from an arbitrary timestamp.

Separate stale price updates from legitimate delayed results and rollback instructions. A rule that drops every message older than the latest odds timestamp can lose a required settlement correction. Unknown status values or changed identity semantics should stop the affected acceptance path and create a diagnosable exception.

Recover a trustworthy state before reopening markets

After a disconnect, the next price message does not necessarily reconstruct every status, line or result missed during the gap. Record the last durable checkpoint for the relevant scope, what recovery can supply and what must be reconciled separately. Keep affected acceptance unavailable until the chosen recovery conditions are met.

Sportradar UOF recovery can supply current odds rather than every intermediate change; recovery completes with snapshot_complete and prescribes handling of concurrent live updates and stateful messages. Implement that protocol instead of assuming recovery is a complete historical replay.

Another protocol uses different markers: Betfair’s reconnection guidance preserves subscription filters and clock tokens, and requires replacement of price points when img=true. A generic “reconnect, then merge” routine misses these distinctions.

• Establish scope: identify the affected subscription, producer and markets; stop acceptance where their state is uncertain.
• Restore state: request the supported recovery or fresh baseline, associate responses with that recovery and apply its conflict rules.
• Complete processing: verify the required completion signal and local application, including queued results or corrections.
• Reconcile: resolve missing or incompatible lines, check current authority and status, and reopen only the eligible scope.

Define what happens when the checkpoint is outside the supported recovery window. It may require a fresh baseline plus separate reconciliation of results, not an endless retry. Persist the recovery attempt, progress and unresolved items so another operator or process can continue it.

If replay runs in an isolated test environment, prevent it from publishing production offers or financial effects. Reusing captured messages should validate the state machine, not create a second live writer.

Connect freshness and suspension to bet acceptance

Measure connection liveness, source delivery delay, local queue age, completeness and market availability separately. A heartbeat can arrive while event updates are missing or while the local processor is behind. A quiet market is not automatically stale merely because its price has not changed; use the provider’s activity and validity semantics.

Sportradar’s alive guidance ties producer interruption to recovery and controlled reopening. Use the applicable provider procedure and a trading-approved policy for the relevant pre-match or live scope, rather than one invented timeout for every market.

Track where a suspension is observed, applied and enforced. The player interface may be cached, so disabling a button is insufficient. The acceptance service must evaluate the required market state, freshness and trading permission at the defined decision point. Handle the race between reading that state and committing acceptance with an appropriate consistency mechanism. For example, evaluate and record acceptance against a versioned offer; if that version changes before the commit, re-evaluate instead of completing against a stale read. A wallet hold and the final bet decision also need an explicit recovery protocol so a failed decision does not leave funds indefinitely reserved.

For an illustrative race, a player saw version 42 at decimal odds 1.90. Version 43 suspends the selection before the acceptance decision. A request referring to 42 must not bypass the newer suspension merely because its displayed price matches an old cache. If the price changes instead, apply the disclosed re-quote or rejection policy and any required player confirmation.

Retain the accepted selection identity, line, price, applicable rules, authority and decision evidence. Link them to the bet and wallet workflow. This does not eliminate the delay before an upstream change reaches the platform; that residual risk belongs in the trading and latency model, not in a claim of perfect real-time knowledge.

See bets, wallets and settlement architecture for the financial acceptance boundary. Do not let a feed update retrospectively overwrite the terms of an already accepted bet.

Switch providers through an explicit authority change

A second provider is useful only if its coverage and meanings can support the intended fallback. Confirm event and market equivalence, line parameters, result authority, subscriptions and operating rights before treating it as a replacement. It may support only a subset of the primary offer.

Assign authority by an explicit scope, such as event, market or data purpose. A fallback score feed does not automatically become the authority for prices or settlement. Preserve each source’s observations and the reason one is chosen. Different providers’ clocks or IDs do not establish a common order of truth. Tag offer publication with the authority version and fence the previous writer: a late update from the old source can remain an observation without regaining permission to publish.

• Qualify the alternative: validate mappings, current state, required coverage and known differences while it is not authoritative.
• Pause the affected offer: prevent new acceptance during an uncertain transition; keep existing bets and financial history intact.
• Promote deliberately: record the authority change and version, then publish only validated eligible markets.
• Return deliberately: recover and compare the original source before restoring it, using the same controlled transition.

Do not silently combine a price from one source with the other source’s suspension or result. A composite policy is possible only when its rules and ownership are explicit and tested. Unresolved disagreement should create a bounded exception, with a trading owner and a permitted action, rather than repeated automated switching.

Provider handover within one feed also needs its documented rules; a pre-match producer and a live producer are not interchangeable writers. Test overlapping updates, a missing handover and the case where the destination never supplies a usable line.

Maintain a history of authority for later explanation. Switching the source of new offers should not automatically replace the agreed settlement basis for existing bets.

Process results and corrections as a separate lifecycle

Keep prices, sport results and bet-settlement decisions as distinct records. A score update may not settle a period-specific or specially defined market. Apply the accepted market’s rules and designated result source, with an explicit state for incomplete or disputed information.

UOF’s message catalogue includes settlement, cancellation and rollback messages. Those operations need a lifecycle beyond “event ended”. Receiving a correction is not the same as authorising every possible financial action.

Record the result or instruction, source, relevant version, affected market and processing outcome. Deduplicate the effect for each affected bet or settlement operation; relying only on a transport message ID can fail when recovery combines or splits content differently.

For a hypothetical case, the designated result settles a selection as won, then a valid correction withdraws that result. The platform should preserve the original settlement and create the authorised reversal or revised decision linked to it. It must not pay the original win twice on replay or silently erase the history. The treatment of already withdrawn funds and player communication follows the permitted product and market policy, not an improvised balance update.

Reconcile instruction processing, bet state and ledger effects. A processed feed message is not proof that the downstream financial operation completed. Keep unresolved transitions visible with an owner, evidence and a recovery path. Protect manual result or mapping overrides with appropriate permissions, reasons and review.

Separate result-processing capacity from disposable display work. A busy live-price stream must not indefinitely starve low-volume corrections that determine the final financial state.

Monitor the betting boundary and prove the failure cases

Monitor the integration at each boundary: receipt, parsing, mapping, state application, publication, acceptance and settlement. Track rejected schemas, unresolved mappings, recovery progress, local queue age, affected market count and delayed result processing. Use provider and internal references so an operator can move from an alert to the relevant evidence.

Page the team for actionable product impact. “Socket connected” is useful transport information, but it does not answer whether a live market is safely open or whether settlement is stuck. Record the detection condition, affected scope, owner and first permitted response. The observability guide provides the wider monitoring context.

Start with a deliberately limited set of sports and market families that the team can map, recover and settle correctly. Build a replay harness and demonstrate the failure cases below with licensed or synthetic data. Compare expected canonical state, acceptance decisions and financial effects; matching the number of incoming messages is insufficient.

Then observe the new adapter without making it authoritative where appropriate, investigate differences and enable a controlled scope. Keep the prior configuration, pause controls and correction procedures available. Rollback preserves accepted bets, authority history and outstanding settlement work.

Choose thresholds from measured behaviour, provider requirements and trading tolerance. State the workload and failure assumptions behind any latency claim. Do not promise a universal millisecond target or uninterrupted betting from the fact that two providers are connected.

The integration is ready when the team can explain what a price means, why a market was offered, what happened during a gap and how a corrected result reaches the ledger. That evidence is more useful than a dashboard showing continuous message traffic.

• Identity: present similarly named teams, a rescheduled fixture and an ambiguous match; verify stable identities, preserved mapping history and blocked uncertain offers.
• Market semantics: load different totals, periods and participant orientations; verify separate lines and the correct meaning of each selection.
• Delivery: replay duplicates and provider-supported ordering cases; verify the canonical result, checkpoint behaviour and treatment of images versus deltas.
• Recovery: disconnect during updates, resume with the relevant completion marker and exceed a recovery window; verify a safe baseline and unresolved-work handling.
• Acceptance: race a suspension against an old quote and delay the local processor; verify the defined acceptance decision and retained evidence.
• Authority: switch to a partially covering fallback and return to the primary; verify scoped offers, explicit authority history and unchanged accepted terms.
• Settlement: repeat, regroup and correct a result instruction; verify one authorised effect per operation and linked correction history.
• Operations: trigger mapping, freshness and settlement incidents; verify useful alerts, scoped permissions, a named owner and a rehearsed recovery action.