Two Feeds, One Match: The Fixture Mapping Problem<\/h2>\n
If you run a regulated book or a trading desk, you almost certainly consume more than one data feed. A licensed stats provider (Betradar, Genius Sports) handles official scores and settlement, because your regulator requires an audited source of truth. Then you pull pricing from somewhere cheaper and broader, because a single licensed feed only carries the books its owner wants you to see.<\/p>\n
The moment you run two feeds, you inherit a join problem: which row in feed A is the same real-world match as which row in feed B?<\/strong> Betradar calls Spain vs Saudi Arabia event 66456998<\/code>. Genius calls it 15457158<\/code>. Your pricing layer calls it something else entirely. Get the join wrong and you settle bets against the wrong result, which in a compliance audit is not a bug, it is a liability.<\/p>\n
OddsPapi aggregates pricing from 350+ bookmakers<\/strong>, and every fixture it returns ships with a pre-computed cross-provider ID map. You do not fuzzy-match team names. You read a key. This post shows the mapping table, the fill rates across providers, and a tested Python join that reconciles OddsPapi pricing back to your Betradar or Genius settlement feed.<\/p>\n
The Old Way: Fuzzy Matching on Names and Kickoff Time<\/h2>\n
Without shared IDs, teams reconcile feeds by matching on participant name plus kickoff timestamp. It works until it doesn’t, and it fails in exactly the situations that matter most for compliance.<\/p>\n
\n
\n\n
\n
Approach<\/th>\n
Name + Kickoff Fuzzy Match<\/th>\n
externalProviders ID Join (OddsPapi)<\/th>\n<\/tr>\n<\/thead>\n
\n
\n
“Man Utd” vs “Manchester United”<\/td>\n
Breaks on naming variants<\/td>\n
Exact ID, no string logic<\/td>\n<\/tr>\n
\n
Kickoff rescheduled 30 min<\/td>\n
Timestamp drifts, match fails<\/td>\n
ID is stable through reschedules<\/td>\n<\/tr>\n
\n
Two same-name fixtures same day<\/td>\n
Ambiguous, picks wrong one<\/td>\n
Unique per event<\/td>\n<\/tr>\n
\n
Audit defensibility<\/td>\n
“We think it matched”<\/td>\n
Deterministic key, logged<\/td>\n<\/tr>\n
\n
Maintenance<\/td>\n
Hand-tuned alias tables<\/td>\n
Read one JSON field<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
The fuzzy approach also degrades silently. A name-normaliser that worked for the Premier League quietly mismatches a Brazilian S\u00e9rie B fixture at 2am, and you don’t find out until a settlement dispute. An ID join either resolves or returns null, and a null is something you can alert on.<\/p>\n
The externalProviders Block<\/h2>\n
Every fixture from GET \/v4\/fixtures<\/code> carries an externalProviders<\/code> object. It is the same event, expressed in ten different providers’ ID systems:<\/p>\n
That is the real block for Spain vs Saudi Arabia<\/strong> (World Cup, OddsPapi id1000001666456998<\/code>), pulled live. The OddsPapi fixtureId<\/code> is your primary key; the ten provider fields are foreign keys into everyone else’s world.<\/p>\n
Coverage: Which IDs Are Actually Populated<\/h3>\n
Not every provider stamps every fixture. We sampled a five-day soccer window (1,011 fixtures) and measured how often each ID is present. Betradar is the workhorse, populated on 100% of fixtures, which makes it the safest universal join key:<\/p>\n
The practical takeaway: build your join on betradarId<\/code> if your settlement feed is Betradar, and keep betgeniusId<\/code> as the fallback if you are a Genius shop. Don’t assume the long-tail providers are present, code defensively for null.<\/p>\n
The Tutorial: Build a Cross-Provider Mapping Table<\/h2>\n
Step 1 \u2014 Authenticate<\/h3>\n
OddsPapi auth is a query parameter, never a header. One key, every endpoint.<\/p>\n
Step 2 \u2014 Pull Fixtures and Extract the Map<\/h3>\n
Hit \/fixtures<\/code> for a sport and date range (max 10 days apart), then flatten externalProviders<\/code> into a clean row per match. This is your raw mapping table.<\/p>\n
def fixture_map(sport_id, frm, to):\n r = requests.get(f\"{BASE}\/fixtures\", params={\n \"apiKey\": API_KEY, \"sportId\": sport_id, \"from\": frm, \"to\": to,\n })\n r.raise_for_status()\n rows = []\n for f in r.json():\n ep = f.get(\"externalProviders\") or {}\n rows.append({\n \"oddspapi_id\": f[\"fixtureId\"],\n \"match\": f\"{f['participant1Name']} v {f['participant2Name']}\",\n \"kickoff\": f[\"startTime\"],\n \"status\": f.get(\"statusName\"),\n \"betradar\": ep.get(\"betradarId\"),\n \"genius\": ep.get(\"betgeniusId\"),\n \"pinnacle\": ep.get(\"pinnacleId\"),\n \"opticodds\": ep.get(\"opticoddsId\"),\n \"sofascore\": ep.get(\"sofascoreId\"),\n })\n return rows\n\nrows = fixture_map(10, \"2026-06-21\", \"2026-06-24\")\nprint(len(rows), \"fixtures mapped\") # 685<\/code><\/pre>\n
Step 3 \u2014 Build the Reverse Index (Their ID \u2192 OddsPapi ID)<\/h3>\n
Your settlement feed pushes you a Betradar event ID. You need to go the other way: from their ID back to OddsPapi’s fixtureId<\/code> so you can attach pricing. Build a dictionary keyed by the provider you settle against.<\/p>\n
# Reverse index: betradar event id -> oddspapi fixture id\nby_betradar = {r[\"betradar\"]: r[\"oddspapi_id\"]\n for r in rows if r[\"betradar\"]}\n\nprint(len(by_betradar), \"fixtures keyed by Betradar id\") # 685\n\n# A Betradar event id arrives from your settlement feed:\nbetradar_event = 66456998\nopi_id = by_betradar.get(betradar_event)\nprint(opi_id) # id1000001666456998<\/code><\/pre>\n
Because betradarId<\/code> fills at 100%, this reverse index never silently drops a fixture. If you key on a sparser provider, guard the .get()<\/code> and route misses to a manual-review queue rather than dropping them.<\/p>\n
Step 4 \u2014 Join Pricing onto the Mapped Fixture<\/h3>\n
One detail that trips people up: the \/odds<\/code> endpoint does not return externalProviders<\/code><\/strong>. Pricing and mapping live in different responses. The shared key between them is the OddsPapi fixtureId<\/code>. So the workflow is: map on \/fixtures<\/code>, then fetch pricing on \/odds<\/code> by the fixture id you resolved.<\/p>\n
def pricing_for_external(provider_index, external_id):\n opi_id = provider_index.get(external_id)\n if opi_id is None:\n return None # send to manual-review queue\n o = requests.get(f\"{BASE}\/odds\", params={\n \"apiKey\": API_KEY, \"fixtureId\": opi_id,\n }).json()\n return o.get(\"bookmakerOdds\", {})\n\nbooks = pricing_for_external(by_betradar, 66456998)\nprint(len(books), \"books priced via the Betradar -> OddsPapi join\") # 18\nprint(sorted(books)[:6])\n# ['ballybet', 'bet365', 'betmgm', 'betparx', 'betrivers', 'borgata']<\/code><\/pre>\n
That is the whole reconciliation loop: your regulator-facing feed says “event 66456998 finished,” you resolve it to id1000001666456998<\/code>, and you have 18 books of pricing history attached to the same row your settlement engine just closed.<\/p>\n
Step 5 \u2014 Persist It for the Audit Trail<\/h3>\n
Compliance is not just about getting the join right today, it is about proving you got it right last March. Write the mapping table to a store with a captured timestamp, so every settled bet can be traced back to the exact ID resolution that produced it.<\/p>\n
import csv\n\nwith open(\"fixture_map.csv\", \"w\", newline=\"\") as fh:\n w = csv.DictWriter(fh, fieldnames=rows[0].keys())\n w.writeheader()\n w.writerows(rows)\n# Re-run on a schedule; keep dated snapshots as your reconciliation ledger.<\/code><\/pre>\n
Pair this with OddsPapi’s free historical odds endpoint and your audit trail covers both the mapping and the price history behind every graded market, at no extra cost.<\/p>\n
Worked Example: Spain vs Saudi Arabia<\/h2>\n
Here is the full resolution for one live World Cup fixture, every value pulled from the API:<\/p>\n
One \/fixtures<\/code> call gave us the seven-way ID map. One \/odds<\/code> call on the resolved fixtureId gave us 18 books, including Pinnacle’s sharp line and two prediction markets. No name normalisation, no timestamp matching.<\/p>\n
Honest Caveats<\/h2>\n
\n
Pricing and mapping are separate responses.<\/strong> \/odds<\/code> returns pricing keyed by fixtureId but no externalProviders<\/code>. Always resolve the map from \/fixtures<\/code> first.<\/li>\n
Long-tail IDs are sparse.<\/strong> Betradar is universal on soccer; Genius, LSports, Sofascore and Mollybet are partial. Build on the provider you actually settle against, and null-guard the rest.<\/li>\n
Virtual and simulated fixtures exist.<\/strong> In our 685-fixture window, 34 were simulated-reality-league (“SRL”) events. They still carry a betradarId<\/code>, but they settle on a different clock, so filter them out of regulated-market reconciliation by tournament.<\/li>\n
Fill rates vary by sport and season.<\/strong> The numbers above are a June soccer snapshot. Re-measure for your sport mix; esports leans on oddinId<\/code>, US majors on opticoddsId<\/code>.<\/li>\n<\/ul>\n
Why This Beats a Single Licensed Feed<\/h2>\n
A licensed stats provider gives you one authoritative result feed and the books it chooses to expose. OddsPapi sits next to it as the pricing layer: 350+ bookmakers, sharps (Pinnacle, SBOBet), exchanges, prediction markets and crypto books, with native market structures (Asian handicaps, player props) carried as first-class IDs rather than flattened strings. The externalProviders<\/code> map is what lets the two coexist, your regulator-approved feed stays the source of truth for settlement, and OddsPapi feeds the price discovery, CLV audit and risk signals around it, joined on a deterministic key.<\/p>\n