Sportsbook data buying: rights, recovery and settlement tests

A sportsbook data acceptance pack

Do not inject failures or create test wagers in production. Agree the sandbox, test authority and expected money movements before running the plan.

Write the coverage and entitlement schedule first

Start the buying document with the sports, competitions, event types, territories, brands and intended uses. Separate pre-match odds, live odds, results, statistics, visualisation and video rather than placing everything under “sports content”. Ask the contracting party to identify which uses it can authorise, any onward-distribution restrictions, the contract term and the effect of a rights change. Treat that schedule as an item for qualified contractual review. A sales coverage count cannot answer whether your precise product may use every component, or whether a capability is live, optional or merely planned.

Map a competition to a bet, not just a logo

For a representative event, trace the competition identifier, fixture, participants, market, line or specifier, and outcome into your sportsbook’s own records. Include an event rescheduled across a date boundary and a participant name change. Decide who owns mappings and how a correction reaches trading, settlement and customer support. Our suggested comparison sheet records required coverage, demonstrated coverage, excluded cases and evidence date. Do not give credit for an event merely appearing in a calendar when the required live markets or settlement data have not been demonstrated.

Separate price delivery from permission to accept a bet

Sportradar’s UOF documentation distinguishes active, suspended and inactive markets. A suspended market can still receive odds updates; the presence of a new price is therefore insufficient evidence that betting is permitted in that feed. Its settled state can also be followed by cancellation or rollback handling. These are documented UOF semantics, not universal codes for every provider. Require the integrator to map the chosen feed’s states into your own acceptance rules and demonstrate that a late price cannot silently reopen a market.

Sportradar UOF — Market status semantics

Rehearse an outage beyond a simple reconnect

The UOF recovery documentation describes recovery windows that vary by producer and tells consumers to suspend affected markets when the relevant live producer connection is lost. It also notes that recovery may combine settlement information that originally arrived in separate messages. A reconnected socket is consequently not proof that the local state has caught up, and recovered traffic need not be a byte-for-byte replay. Ask the supplier to document the applicable window, completion signal and procedure when the outage exceeds recoverable history. Test whether the operator can identify the affected population before resuming service.

Sportradar UOF — Recovery using the API

Treat settlement as a sequence with explicit scope

UOF bet-settlement messages identify results for specified markets and can carry void factors. Its documentation distinguishes live and confirmed settlement certainty, while warning that a confirmed message does not imply every market in the event has settled. Your acceptance plan should therefore exercise partial settlement, later corrections and the agreed policy for provisional results. Trace each test to the affected wagers and resulting accounting entries. A duplicate or corrected message must be interpreted according to its identity and meaning, rather than blindly creating another payout or overwriting the audit trail.

Sportradar UOF — Bet settlement messages

Measure delay where it changes the customer outcome

Define separate timestamps for provider creation, your receipt, validation, market-state update and customer display. Keep clocks and timezone handling consistent before comparing them. Test ordinary load and a deliberately delayed message with a known generation time; the useful output is the resulting trading decision as well as the elapsed time. Set acceptable thresholds with your trading and risk owners for the relevant product. Our recommendation is to record delay distributions and stale-message cases, rather than accepting a single impressive average without knowing the measurement boundary.

Price the operating model and exceptions

Give competing providers the same assumptions: sports and competitions, required markets, transaction or traffic basis, environments, support coverage and expected recovery volume. Ask which items change the invoice, what support can do during an incident, and whether data exports or historical retrieval incur separate charges. Cost the operator work needed for mappings, testing, trading exceptions and reconciliation. A cheaper headline quote may still require more internal handling, but that is a hypothesis to calculate from the actual offer, not a reason to prefer a particular pricing model.

Make acceptance and exit evidence portable

Use the matrix below as a proposed starting test pack. Save the package version, synthetic event and bet identifiers, injected failure, observed transitions, expected ledger result and reviewer’s decision. Require every failed case to have an owner and retest outcome; a demonstration recording alone is not sign-off. For exit, ask what mapping data, operational history and settlement evidence can be retained or exported under the contract. Rehearse how already accepted bets remain serviceable while a replacement feed is introduced, with an agreed authority for resolving inconsistent results.