{"id":3922,"date":"2026-09-16T10:00:00","date_gmt":"2026-09-16T10:00:00","guid":{"rendered":"https:\/\/oddspapi.io\/blog\/?p=3922"},"modified":"2026-09-08T20:49:03","modified_gmt":"2026-09-08T20:49:03","slug":"odds-feed-provider-sportsbooks-trading-desks","status":"publish","type":"post","link":"https:\/\/oddspapi.io\/blog\/odds-feed-provider-sportsbooks-trading-desks\/","title":{"rendered":"Odds Feed Provider: Settle 289 Markets a Fixture From One Feed"},"content":{"rendered":"

Looking for an Odds Feed Provider? Start With What the Feed Has to Do<\/h2>\n

Search “odds feed provider” and you meet two kinds of vendor. The enterprise data houses sell to licensed operators through a sales call. The developer APIs sell a short list of soft books and stop at the price. A sportsbook or a trading desk needs the pipeline in between: a stream you can price off, a cursor you can resume from, a closing line you can audit against, a grade for every outcome once the fixture finishes, and an ID you can join to the feed you already run.<\/p>\n

OddsPapi ships that pipeline as one provider. The B2B documentation at docs.oddspapi.io<\/a> states that “the majority of the top-10 prediction markets run on OddsPapi data”, and lists market makers, hedge-fund desks, bookmakers and betting exchanges as production clients. This post walks the pipeline from the first WebSocket message to the settled bet, and runs every step below against the live API on a self-serve key. Every number was measured on September 8, 2026.<\/p>\n

If you already hold a key and want the integration order, the trading desk onboarding playbook<\/a> sequences the same pieces into a five-day build. This post is the map; that one is the runbook.<\/p>\n

Why the Usual Two Options Fail a Trading Desk<\/h2>\n

Sportradar and Genius Sports price per deal and gate access behind a sales process. The Sportradar alternative<\/a> post covers what that costs a small operator in weeks. The developer-tier APIs solve access and stop there: you get a price, and you build stale detection, closing-line capture, settlement and fixture reconciliation yourself, or you license four more vendors to do it. The odds API pricing comparison<\/a> shows what the public tiers charge for the price alone.<\/p>\n

The OddsPapi feed covers the whole loop. The v4 REST API on a self-serve key carries the catalogue of 350+ bookmakers (357 slugs on \/v4\/bookmakers<\/code> today, 117 of them flagged as clones of another feed), free historical price timelines, per-outcome settlement and period scores. The v5 gateway documented at docs.oddspapi.io adds the WebSocket channels, the opening and closing line endpoints, mapping lookups, and the lineups, injuries and stats channels.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
What the desk needs<\/th>\nOn a price-only API<\/th>\nOddsPapi<\/th>\n<\/tr>\n<\/thead>\n
Realtime prices<\/td>\nPoll a short list of soft books<\/td>\nWebSocket push from 350+ bookmakers, conflated on a ~10 ms window<\/td>\n<\/tr>\n
Reconnect without a gap<\/td>\nRebuild state by hand<\/td>\nserverEpoch<\/code> + entryId<\/code> cursors, 60-second replay buffer, snapshot_required<\/code> fallback<\/td>\n<\/tr>\n
Stale-book detection<\/td>\nA frozen price looks live<\/td>\nstaleOdds<\/code> flag per bookmaker per fixture<\/td>\n<\/tr>\n
Closing line<\/td>\nCapture it yourself at kick-off<\/td>\nGET \/fixtures\/odds\/clv<\/code> on v5; free \/v4\/historical-odds<\/code> timelines<\/td>\n<\/tr>\n
Settlement<\/td>\nLicense a results feed<\/td>\n\/v4\/settlements<\/code>: WIN, LOSE, HALFWIN, HALFLOSS, PUSH per outcome<\/td>\n<\/tr>\n
Join to Betradar or Genius<\/td>\nBuild a mapping table<\/td>\nexternalProviders<\/code> on every fixture; betradarId<\/code> on 1,731 of 1,731 finished fixtures<\/td>\n<\/tr>\n
Size at price<\/td>\nUnknown<\/td>\nlimit<\/code> field carried for close to every sharp book<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Step 1: Price Off the Stream, Recover From the Cursor<\/h2>\n

The production gateway is wss:\/\/v5.oddspapi.io\/ws<\/code>. You send one login<\/code> message with your key, the channels you want and the filters that cut the noise, and the server pushes every change after login_ok<\/code>. The documented login shape:<\/p>\n

{\n  \"type\": \"login\",\n  \"apiKey\": \"YOUR_API_KEY\",\n  \"channels\": [\"fixtures\", \"bookmakers\", \"odds\", \"scores\"],\n  \"receiveType\": \"zstd\",\n  \"sportIds\": [10],\n  \"bookmakers\": [\"pinnacle\", \"betfair-ex\", \"draftkings\"]\n}<\/code><\/pre>\n
Three design points from the docs matter more than the rest for a desk that trades on the feed.<\/p>\n
The odds channel is state, not a tick ledger<\/h3>\n
The odds channel conflates updates on a fixed batching window of about 10 milliseconds. If a price moves twice inside one window you receive the newer value. The final value of every move arrives, and a delivered price is never more than one window behind the observation at the bookmaker. For full tick history you go to the REST history endpoints in Step 2.<\/p>\n
A disconnect is a cursor problem, not an outage<\/h3>\n
Every message carries an entryId<\/code> of the form <ts_ms>-<seq><\/code>. The login_ok<\/code> reply carries a resume<\/code> block with the serverEpoch<\/code>, a resumeWindowMs<\/code> buffer (the docs show 60,000) and the server’s latest cursor per channel. Persist the epoch and your last processed entryId<\/code> per channel. On reconnect you send both back and the gateway replays what you missed inside the window. Outside the window it sends snapshot_required<\/code> with a reason (server_restarted<\/code>, resume_window_exceeded<\/code> or client_backpressure<\/code>) and you rebuild those channels from one REST snapshot. Before a release the server pushes a reconnect<\/code> control frame and keeps streaming for a few seconds, so you reconnect on the message and never wait for the socket to die. The WebSocket pricing pipeline<\/a> post wires this loop in Python.<\/p>\n
Every price carries its own delivery chain<\/h3>\n
Each odds update ships bookmakerChangedAt<\/code> (the book’s own clock, where the book publishes one), changedAt<\/code> (when OddsPapi observed the change) and the envelope ts<\/code> (when the gateway sent it). You measure the last hop yourself. The reliability page publishes representative rolling p50 observation delays per book: 0.05 s for Polymarket, 0.10 s for Betfair Exchange, 0.38 s for Pinnacle, and an estimated 1 s in-play for Singbet. It puts the internal pipeline at about 30 ms p50 to gateway egress, and the delivery hop as low as about 5 ms when you colocate in Central Europe. The same page publishes no uptime percentage; SLA terms are set per agreement.<\/p>\n
Step 2: Audit Every Line Against the Close<\/h2>\n
A desk that cannot measure its own closing line value is guessing about its edge. On v5 the endpoints are GET \/fixtures\/odds\/historical<\/code> for the full timeline and GET \/fixtures\/odds\/clv<\/code> for opening versus closing values, both keyed on the same oddsId<\/code> as the live stream, so a fill joins to its closing record on one string. On the self-serve v4 key the same audit runs off \/v4\/historical-odds<\/code>, which returns every snapshot from the first price to the final whistle and costs nothing extra.<\/p>\n
The script below reads Arsenal v Chelsea from last Sunday (Premier League, kick-off 15:30 UTC on September 6) at three books and prints the opening and closing 1X2 prices. The closing price is the last active snapshot before kick-off; snapshots keep arriving after the clock starts, so the filter on createdAt<\/code> is load-bearing.<\/p>\n
import time\nfrom datetime import datetime, timezone\nimport requests\n\nAPI_KEY = \"YOUR_API_KEY\"\nBASE = \"https:\/\/api.oddspapi.io\/v4\"\n\n# Arsenal v Chelsea, Premier League, kicked off 2026-09-06 15:30 UTC.\n# Both values come from the \/fixtures record.\nFIXTURE = \"id1000001772221232\"\nKICKOFF = datetime(2026, 9, 6, 15, 30, tzinfo=timezone.utc)\n\n# \/historical-odds accepts at most 3 bookmakers per call.\nr = requests.get(f\"{BASE}\/historical-odds\", params={\n    \"apiKey\": API_KEY, \"fixtureId\": FIXTURE,\n    \"bookmakers\": \"pinnacle,bet365,draftkings\"})\nr.raise_for_status()\ntimeline = r.json()[\"bookmakers\"]\ntime.sleep(4.6)   # cooldown after a successful \/historical-odds call\n\ndef ts(s):\n    return datetime.fromisoformat(s[\"createdAt\"].replace(\"Z\", \"+00:00\"))\n\nlabels = {\"101\": \"home\", \"102\": \"draw\", \"103\": \"away\"}\nprint(f\"{'book':11s}{'side':6s}{'open':>7s}{'close':>7s}{'move':>8s}\")\nfor book, data in timeline.items():\n    for oid, outcome in data[\"markets\"][\"101\"][\"outcomes\"].items():\n        snaps = outcome[\"players\"][\"0\"]          # oldest first\n        opening = snaps[0][\"price\"]\n        # The closing price is the last ACTIVE snapshot before kick-off.\n        # Snapshots keep arriving after kick-off, so filter on the clock.\n        pre = [s for s in snaps if ts(s) < KICKOFF and s[\"active\"] and s[\"price\"] > 1]\n        closing = pre[-1][\"price\"]\n        move = (closing \/ opening - 1) * 100\n        print(f\"{book:11s}{labels[oid]:6s}{opening:7.3f}{closing:7.3f}{move:+7.1f}%\")<\/code><\/pre>\n
Output, measured September 8, 2026:<\/p>\n
book       side     open  close    move\nbet365     home    1.570  1.660   +5.7%\nbet365     draw    3.750  3.800   +1.3%\nbet365     away    5.250  4.750   -9.5%\ndraftkings home    1.645  1.714   +4.2%\ndraftkings draw    3.600  3.900   +8.3%\ndraftkings away    5.250  4.800   -8.6%\npinnacle   home    1.675  1.751   +4.5%\npinnacle   draw    3.800  3.900   +2.6%\npinnacle   away    4.850  5.000   +3.1%<\/code><\/pre>\n
Arsenal won 2-1. Between the opening print on August 23 and kick-off, bet365 recorded 689 snapshots on the home price and Pinnacle 620. All three books drifted Arsenal out by 4 to 6 percent. They split on Chelsea: bet365 and DraftKings cut the away price from 5.25 to 4.75 and 4.80, while Pinnacle pushed it out to 5.00. A book that closed Chelsea at 4.75 sat 5.3 percent under the sharp close on the same outcome, which is the number a CLV audit exists to surface. The operator CLV audit<\/a> post turns this read into a per-market report across your own book.<\/p>\n
Step 3: Grade Every Outcome When the Fixture Finishes<\/h2>\n
Settlement is where most feeds stop and hand you to a results vendor. OddsPapi grades the outcomes it priced. On v5 the endpoint is GET \/fixtures\/settlement<\/code>; on the self-serve v4 key it is GET \/v4\/settlements?fixtureId=<\/code>, paired with GET \/v4\/scores<\/code> for the period scores. The grades are a frozen vocabulary: WIN<\/code>, LOSE<\/code>, PUSH<\/code>, HALFWIN<\/code>, HALFLOSS<\/code>, CANCELLED<\/code> and UNDECIDED<\/code>. The two half grades settle Asian quarter lines natively, so a -0.25 handicap on a draw grades as a half loss without a rule table on your side.<\/p>\n
Two traps. A finished fixture flips hasOdds<\/code> to false<\/code>, so select finished fixtures on statusName<\/code> and never on that flag. And \/settlements<\/code> has its own cooldown: two of ten calls spaced 1.1 seconds apart returned 429 during this test, and 2 seconds cleared it.<\/p>\n
import time\nimport requests\n\nAPI_KEY = \"YOUR_API_KEY\"\nBASE = \"https:\/\/api.oddspapi.io\/v4\"\n\ndef get(path, **params):\n    params[\"apiKey\"] = API_KEY\n    r = requests.get(f\"{BASE}\/{path}\", params=params)\n    r.raise_for_status()\n    return r.json()\n\n# 1. Finished fixtures in one tournament. hasOdds is false once a fixture\n#    finishes, so select on statusName, never on hasOdds.\nfixtures = get(\"fixtures\", tournamentId=325,          # Brasileiro Serie A\n               **{\"from\": \"2026-09-06T00:00:00Z\", \"to\": \"2026-09-08T00:00:00Z\"})\nfinished = [f for f in fixtures if f[\"statusName\"] == \"Finished\"]\nfx = finished[0]\nprint(fx[\"participant1Name\"], \"v\", fx[\"participant2Name\"], fx[\"fixtureId\"])\n\n# 2. Final score by period.\nscores = get(\"scores\", fixtureId=fx[\"fixtureId\"])[\"scores\"][\"periods\"]\nfor period in (\"p1\", \"fulltime\", \"result\"):\n    p = scores[period]\n    print(f\"  {period:9s} {p['participant1Score']}-{p['participant2Score']}\")\ntime.sleep(2)\n\n# 3. Per-outcome grades. UNDECIDED means nobody priced that rung.\nsettlement = get(\"settlements\", fixtureId=fx[\"fixtureId\"])\ngraded, results = 0, {}\nfor market_id, market in settlement[\"markets\"].items():\n    grades = [p[\"result\"] for o in market[\"outcomes\"].values()\n              for p in o[\"players\"].values()]\n    for g in grades:\n        results[g] = results.get(g, 0) + 1\n    if all(g != \"UNDECIDED\" for g in grades):\n        graded += 1\n\nprint(f\"  markets returned: {len(settlement['markets'])}, fully graded: {graded}\")\nprint(\"  \", {k: v for k, v in sorted(results.items())})\nlabels = {\"101\": \"home\", \"102\": \"draw\", \"103\": \"away\"}\nfor oid, o in settlement[\"markets\"][\"101\"][\"outcomes\"].items():\n    print(f\"  1X2 {labels[oid]}: {o['players']['0']['result']}\")<\/code><\/pre>\n
Output for the first finished fixture in the window, Fluminense v Vasco da Gama:<\/p>\n
Fluminense FC RJ v CR Vasco da Gama RJ id1000032566886978\n  p1        0-0\n  fulltime  1-0\n  result    1-0\n  markets returned: 1066, fully graded: 289\n   {'HALFLOSS': 12, 'HALFWIN': 12, 'LOSE': 283, 'PUSH': 13, 'UNDECIDED': 1622, 'WIN': 282}\n  1X2 home: WIN\n  1X2 draw: LOSE\n  1X2 away: LOSE<\/code><\/pre>\n
The response carries 1,066 market IDs. 289 of them come back fully graded, 602 outcomes in all, and the rest read UNDECIDED<\/code> because nobody priced that rung. Eight finished Brasileiro Serie A fixtures from the same weekend and an Ecuador Serie B fixture from the same week returned the same grid: 1,066 market IDs and 289 graded markets each, with the WIN and LOSE split moving fixture to fixture. Scores arrive keyed by the generic period vocabulary (p1<\/code>, fulltime<\/code>, result<\/code>), so the same parser reads a soccer half and a basketball quarter. Day 4 of the onboarding playbook<\/a> closes the loop from this call to the ledger.<\/p>\n
Step 4: Join the Feed to the IDs You Already Hold<\/h2>\n
A regulated book runs a licensed data feed for official results and a pricing feed for the market. The two have to agree on which fixture is which. Every OddsPapi fixture record ships an externalProviders<\/code> block, so the join is a dictionary lookup on a key you already hold rather than a name-matching project. On v5, GET \/fixtures\/mapping<\/code> also runs the lookup in reverse: pass a bookmaker and its own fixture IDs and get the OddsPapi IDs back.<\/p>\n
import requests\n\nAPI_KEY = \"YOUR_API_KEY\"\nBASE = \"https:\/\/api.oddspapi.io\/v4\"\n\n# Every fixture record carries an externalProviders block. Read it off\n# the same \/fixtures call you already make for the schedule.\nr = requests.get(f\"{BASE}\/fixtures\", params={\n    \"apiKey\": API_KEY, \"sportId\": 10,\n    \"from\": \"2026-09-06T00:00:00Z\", \"to\": \"2026-09-08T00:00:00Z\"})\nr.raise_for_status()\nfinished = [f for f in r.json() if f.get(\"statusName\") == \"Finished\"]\n\n# One fixture, every provider key it ships.\nfx = next(f for f in finished if f[\"fixtureId\"] == \"id1000032566886978\")\nprint(fx[\"participant1Name\"], \"v\", fx[\"participant2Name\"])\nfor provider, ext_id in fx[\"externalProviders\"].items():\n    print(f\"  {provider:13s} {ext_id}\")\n\n# Population rate per provider across the whole finished window.\ncounts = {}\nfor f in finished:\n    for provider, ext_id in f[\"externalProviders\"].items():\n        if ext_id is not None:\n            counts[provider] = counts.get(provider, 0) + 1\nprint(f\"\\n{len(finished)} finished soccer fixtures, Sep 6-7 2026\")\nfor provider, n in sorted(counts.items(), key=lambda kv: -kv[1]):\n    print(f\"  {provider:13s} {n:5d}  {100 * n \/ len(finished):5.1f}%\")<\/code><\/pre>\n
Output:<\/p>\n
Fluminense FC RJ v CR Vasco da Gama RJ\n  betradarId    66886978\n  mollybetId    2026-09-06,26061,773\n  opticoddsId   202609068ADA0CB6\n  lsportsId     19906694\n  txoddsId      None\n  sofascoreId   None\n  betgeniusId   13391445\n  flashscoreId  MwalAAYH\n  pinnacleId    1634729439\n  oddinId       None\n\n1731 finished soccer fixtures, Sep 6-7 2026\n  betradarId     1731  100.0%\n  pinnacleId     1089   62.9%\n  flashscoreId    882   51.0%\n  opticoddsId     850   49.1%\n  betgeniusId     697   40.3%\n  lsportsId       631   36.5%\n  mollybetId      212   12.2%\n  sofascoreId      35    2.0%<\/code><\/pre>\n
The Betradar ID is present on every one of the 1,731 finished soccer fixtures in the window, from the Premier League down to the Spanish fourth tier. The Pinnacle ID covers 62.9 percent, which tracks the share of that slate Pinnacle prices, the OpticOdds ID sits at 49.1 percent and the Genius ID at 40.3. The fixture mapping for compliance<\/a> post builds the reconciliation table and the exception report on top of this block.<\/p>\n
Lineups, Injuries, Futures and the Rest of the Board<\/h2>\n
The v5 gateway added injuries<\/code>, lineups<\/code> and stats<\/code> channels in December 2025 and a clocks<\/code> channel in April 2026, all with the same resume and replay semantics as odds. Futures run on their own channels (futures<\/code>, oddsFutures<\/code>, bookmakersFutures<\/code>) with their own history and CLV endpoints, and the same model covers non-sports prediction-market topics as futures on sportId<\/code> 69 to 78. The docs state that futures settlement is rolling out and the endpoint does not yet serve results, so grade outrights off the fixture pipeline until it does. Exchanges and prediction markets ship their order books in the meta<\/code> field as uniform back<\/code> and lay<\/code> ladders, and a currencies<\/code> channel streams fiat and crypto rates for odds conversion.<\/p>\n
What the Limits Are<\/h2>\n
The v5 docs set 10 requests a second on the odds snapshot endpoints and 200 a minute on everything else, per key and per endpoint, with X-RateLimit-Remaining<\/code> and Retry-After<\/code> headers on every response. The WebSocket gateway allows 5 concurrent connections per key group and closes a client that cannot keep up with close code 4002<\/code>. Filters on sportIds<\/code>, tournamentIds<\/code> and bookmakers<\/code>, plus receiveType: \"zstd\"<\/code> (5 to 6 times smaller frames on the odds channel, per the docs), keep a single connection inside those bounds. Distributed systems that need more raise the limits by agreement.<\/p>\n
Pricing and Access<\/h2>\n
Access is self-serve. Sign up for a free key<\/a>, run the three scripts above against last weekend’s fixtures, and scale from there. Pricing is usage-based: the pricing page<\/a> is a calculator that prices the bookmakers and sports you select, multiplied by your requests per month, so a desk that reads three sharp books on two sports pays for that and not for the catalogue. The 2026 pricing comparison<\/a> puts the public tiers of four providers side by side. Licensed operators who need SLA terms, raised limits or the v5 gateway write to contact@55-tech.com, and the B2B reference for everything in this post is docs.oddspapi.io<\/a>.<\/p>\n
For a plain REST introduction to the same feed, the odds feed API<\/a> post starts from the first call.<\/p>\n
One Provider From First Price to Settled Bet<\/h2>\n
A WebSocket you resume from a cursor, a closing line you audit against, a grade for 289 markets a fixture and a Betradar ID on every record: that is the pipeline a sportsbook or a trading desk needs from an odds feed provider, and it runs on one key. Get your free key<\/a>, then open docs.oddspapi.io<\/a> for the channel schemas.<\/p>\n
Frequently Asked Questions<\/h2>\n
What does an odds feed provider need to deliver for a sportsbook?<\/h3>\n
Five things: a realtime price stream, a recovery path that replays what you missed, a closing line to audit against, per-outcome settlement, and fixture IDs that join to your official data feed. OddsPapi delivers all five: a WebSocket with resume and replay across 350+ bookmakers, OLV\/CLV endpoints, settlement grades and an externalProviders block on every fixture.<\/p>\n
Does OddsPapi settle bets?<\/h3>\n
Yes, for fixtures. GET \/v4\/settlements returns WIN, LOSE, HALFWIN, HALFLOSS or PUSH for every priced outcome; on a finished Brasileiro Serie A fixture it graded 289 markets and 602 outcomes. GET \/v4\/scores returns the period scores. The v5 endpoint is GET \/fixtures\/settlement, and futures settlement is rolling out per the docs.<\/p>\n
How does the feed recover from a disconnect?<\/h3>\n
Every message carries an entryId cursor. On reconnect you send your serverEpoch and last entryId per channel, and the gateway replays what you missed inside the resume window (60 seconds in the documented example). Past the window it sends snapshot_required and you rebuild those channels from a single REST snapshot.<\/p>\n
Can I run OddsPapi next to Betradar or Genius Sports?<\/h3>\n
Yes. Each fixture record ships externalProviders with betradarId, betgeniusId, pinnacleId, opticoddsId, lsportsId, flashscoreId and more. On September 8, 2026 the Betradar ID was present on all 1,731 finished soccer fixtures from the previous two days, so the join is a dictionary lookup.<\/p>\n
Is there an enterprise tier or an SLA?<\/h3>\n
Access is self-serve with usage-based pricing: the calculator prices the bookmakers and sports you pick, multiplied by requests per month. The reliability page publishes a live status page and states that uptime targets and support response times are set per agreement for B2B customers, through contact@55-tech.com.<\/p>\n