Handling Selections and Odds

Every Sportradar betting widget that lets a punter pick an outcome, hands that selection back to your application through a callback — onItemClick, onAction, or the Data Adapter addToBetSlip function. Once you receive it, the rest is yours: validating the selection and placing the bet.

This guide explains the shared data flow for all selection-emitting widgets and answers the questions integrators ask most often:

• Are the odds in the selection trustworthy?
• Could those odds already be out of date?
• How do I fetch the current, authoritative odds?
• Must I validate a selection before placing the bet — and how?

#Intended Audience

• Frontend developers wiring a betting widget into a bet slip.
• Sportsbook engineers responsible for bet acceptance.
• Technical integrators who need to understand where the widget's responsibility ends and the bookmaker's begins.

Prerequisites: familiarity with widget integration (see Getting Started) and your own bet slip / trading system.

#Scope: which widgets this applies to

Any widget that pushes a selection into a bet slip follows the same principles, regardless of the callback name:

• Bet Insights and Tournament Bet Insights — onItemClick
• Bet Recommendation (Event List, Highlights, Leagues, Markets, My Combo, Swipe Bet) — onItemClick
• Bet Concierge — onAction
• BET 3-in-1 — onAction / onItemClick (delegates to the composed widgets)
• Player Prop Zone — onItemClick
• Custom Bet — Data Adapter addToBetSlip

#The selection data flow

The diagram below shows the lifecycle of a single selection, from the moment the widget receives odds to the moment your platform accepts or rejects the bet. The dashed boundary marks the hand-off: everything below it is your responsibility.

Generalized, the steps your integration must implement are:

1. Receive the selection. The widget invokes your callback with the identifiers needed to locate the market and outcome, plus the odds that were on screen at click time.
2. Re-validate the selection. Confirm with your own system that the market is still open and the outcome is still active.
3. Re-price the selection. Fetch the authoritative current odds from your trading platform — do not place a bet at the widget's snapshot price.
4. Reconcile and present. If the price moved, decide how to handle it (accept, ask the user to confirm, or reject) and update your bet slip UI.
5. Validate again at acceptance. Immediately before the bet is placed, revalidate availability and price one final time.

#What's in a selection payload

The exact shape differs per widget, but every selection carries two things:

1. Identifiers that locate the market and outcome.
2. An odds snapshot — the price that was displayed when the user clicked.

Selections use one of two identifier formats, discriminated by a type field:

A representative selection object:

{
  type: 'uf',
  event: 'sr:match:12345',     // event / match identifier
  market: '18',                // market identifier
  specifiers: 'total=2.5',     // optional, only for markets with a variant line
  outcome: '12',               // outcome identifier
  odds: {                      // the SNAPSHOT shown at click time
    type: 'eu',                // 'eu' (decimal), 'uk' (fractional), 'us' (american)

#Can I trust the odds the widget gives me?

Treat the odds in the selection as indicative, not authoritative.

The odds value in the payload is a snapshot of what the user saw at the instant they clicked. It exists so you can:

• display the price immediately for a responsive UI,
• detect whether the price has moved by the time you re-price, and
• show "odds changed" feedback to the user.

It is not a guaranteed price and must not be the price you settle the bet at. The single source of truth for the price you accept is always your own trading / pricing platform.

#Are the odds up to date?

The snapshot reflects the last update the widget received before the click — not necessarily the live market. Widgets refresh odds on a polling or streaming cadence that depends on the widget and its data source:

• The odds you receive can be a few seconds old, which matters most for fast- moving in-play markets.
• A market can suspend or an outcome can deactivate between the last refresh and the click. When a market is suspended the widget disables its outcomes, but a change can still occur in the brief window around the click.

So: the snapshot is "as fresh as the last refresh," which is good enough to display, but you must re-fetch before you commit.

#How do I get the current odds?

Use the identifiers in the selection to look up the authoritative price in your own system:

• Self-hosted / custom adapter: query your trading or pricing service directly using event / market / outcome (and specifiers). These are the same identifiers your adapter already maps, so the lookup is straightforward.
• Sportradar-hosted odds: refresh via the Unified Odds Feed (UOF), Sportradar’s low-latency, real-time betting data service. Use your UOF integration (Bookmaker SDK or direct feed) to look up the current price and event state before reconciling to your book.

// Example: Handling a selection click from the widget
widget.onItemClick = async function(selection) {
  // selection contains event, market, outcome, specifiers, and odds (the user's snapshot)

  // Log the user's selection for debugging
  console.log('Selection received:', selection);

  // Fetch current/official odds from your backend or trading service

#Do I need to verify before accepting the ticket?

Yes — always. Verification is a two-stage responsibility that belongs to your platform, not the widget:

1. On add to bet slip — revalidate availability and refresh the price so the bet slip shows a realistic, current price.
2. Immediately before placement — revalidate and re-price one final time, because the market can move while the user is choosing a stake.

#Validation and acceptance checklist

When you receive a selection, run these checks before treating it as a placeable bet:

• Market open? The market is not suspended or closed.
• Outcome active? The specific outcome is still available.
• Specifiers match? For markets with a line (handicap, totals, etc.) the specifiers value still corresponds to an offered variant.
• Re-priced? You fetched the current odds from your own platform.
• Price reconciled? You compared the snapshot to the current price and decided how to handle any movement.

#Handling an odds change

When the current price is different from the originally displayed snapshot, you must follow a policy that aligns with your sportsbook's operational and regulatory requirements. Typically, this involves checking the current availability and price of the selection just before adding it to the bet slip. If the selection is no longer available (for example, if the market has closed or the outcome has been disabled), you should inform the user with a clear notification and prevent the addition.

If the odds have changed between the snapshot and the current price, you must decide how to handle this difference according to your site's policy. Options include: automatically accepting the better price if the odds have improved for the user, requiring the user to confirm any change in odds, or blocking the addition until the user explicitly acknowledges the new price. Regardless of which policy you implement, selections should always be added to the bet slip at the latest, authoritative price obtained from your own backend or trading system.

Common policies:

• Accept higher odds automatically (price moved in the user's favour) and add the selection silently.
• Confirm on any change — surface a clear "odds changed from X to Y" prompt and require the user to re-accept.
• Reject and refresh — drop the selection and show the latest available price for the user to re-add.

#Rejecting a selection

When you reject a selection, give the user an actionable, localized reason rather than failing silently. Where a widget's callback supports a rejection result (for example the Custom Bet Data Adapter addToBetSlip callback), return the failure with a localized message so the widget can display it; otherwise show the feedback in your own UI.

// Example: Custom Bet Data Adapter rejection
function addToBetSlip(args, callback) {
  if (!isSelectionValid(args)) {
    callback({
      succeeded: false,
      reason: localize('selection_unavailable'), // shown in the widget
    });
    return;
  }

  yourBetSlip.

#Putting it together

A robust integration treats the widget as a fast, indicative source of intent and its own trading platform as the authoritative source of price and validity:

1. Display the snapshot price immediately for responsiveness.
2. Re-validate and re-price against your platform when adding to the bet slip.
3. Keep the widget's selection indicators in sync via betSlipSelection.
4. Re-validate and re-price one final time at the moment of placement.
5. Reject with a clear, localized reason when a selection can't be honoured.

#Per-widget callback reference

#Further Reading

• Adapter Types — SelectionOutcome, Odds, and the betSlipSelection endpoint.
• Adapter Overview — how the adapter bridges your data and the widget.
• Integration Best Practices — production-ready integration patterns.
• Custom Bet Data Adapter — the addToBetSlip flow in detail.
• Bet Insights — a worked onItemClick + betSlipSelection example.