How to Scrape Sportsbook Odds for Models and Arbing Research
Odds move by the second, and the clean data isn't in the HTML - it's in the internal JSON the sportsbook's own front end calls. Here's how to poll it, normalise it across books, and stay unblocked while doing it.
Sportsbook odds are the fastest-moving public data most people ever try to scrape - lines shift by the second, and a stale number is a wrong number. The good news for anyone building models or researching arbitrage: you almost never need to parse the scoreboard HTML. Every modern sportsbook front end is fed by an internal JSON API, and that's where the clean, structured odds live. This guide covers how to scrape sportsbook odds from those APIs, poll them fast enough to be useful, normalise across books, and stay unblocked while you do it.
Find the internal odds API
Open a sportsbook's event page with your browser dev tools on the Network tab, filter to XHR/Fetch, and watch the requests. You'll see JSON endpoints returning events, markets and prices - the same data the page renders, but structured. Community scrapers that cover ten-plus North American and Australian books (DraftKings, BetMGM, Caesars, BetRivers, PointsBet, and others) all work this way: they call the undocumented internal API rather than parsing HTML, because the JSON is stable and complete. Read it once, and one request gives you every market for an event.
import requests
proxy = "http://USER:PASS@gate.quantumproxies.io:8000"
proxies = {"http": proxy, "https": proxy}
# endpoint + params come from watching the site's own network calls
API = "https://sportsbook.example.com/api/v2/events/{event_id}/markets"
def get_markets(event_id):
r = requests.get(API.format(event_id=event_id), proxies=proxies,
timeout=15, headers={"User-Agent": "Mozilla/5.0"})
return r.json() # events -> markets -> selections with prices
Poll fast, but not stupidly
For model training, a snapshot every minute is plenty; a public MLB scraper that polls moneylines every 60 seconds over a four-hour window is a sensible reference cadence. For live arbitrage research you'll want tighter, but tighter polling from a single IP is exactly the signature books watch for. The answer is to spread the load: rotate the exit IP each cycle so no single address is hammering the endpoint. Normalise everything to decimal odds and one row per selection so books are directly comparable:
import time
def american_to_decimal(a):
return round(1 + (a/100 if a > 0 else 100/abs(a)), 4)
def snapshot(event_id):
rows = []
for m in get_markets(event_id)["markets"]:
for sel in m["selections"]:
rows.append({
"ts": time.time(),
"market": m["name"],
"runner": sel["name"],
"decimal": american_to_decimal(sel["priceAmerican"]),
})
return rows
# poll on a steady interval; a rotating gateway gives a fresh IP each loop
while True:
save(snapshot("mlb-12345"))
time.sleep(60)A rotating residential gateway makes this a one-liner: point every request at one endpoint and it hands you a new IP automatically, so a minute-by-minute poll never looks like one machine. When a flow needs the same IP for a short burst - say, a session-bound market - switch to a sticky session. Our guide to sticky vs rotating sessions covers when each fits.
Get rotating residential IPs for odds data
Geo licensing is a data problem too
Sports betting is licensed jurisdiction by jurisdiction, so the odds a book shows - and whether it serves you at all - depend on where the request comes from. A DraftKings line in New Jersey can differ from the same market in another state, and some books geo-block entirely. That's not just a compliance detail; it changes the data. If you're benchmarking or arbing across regions, pin the proxy exit to the market you're studying so the odds are the ones a real bettor there would see. QuantumProxies covers 200+ countries and US states, so you can pull region-accurate lines without a rack of local machines. See our location-based scraping guide for the same geo principle applied to fares.
Store odds so line moves are queryable
Odds data is only useful if you can ask questions of its history, so store it as time series from day one. Append every snapshot rather than overwriting - one row per book, market, selection and timestamp - so you can reconstruct exactly what each book offered at any moment. That append-only shape is what lets you compute line movement (how a price drifted before kickoff), detect steam moves (many books shifting together), and back-test a model against the odds that were actually available, not today's. Overwrite the latest price only and you throw away the most valuable signal in the whole dataset.
Two practical notes. First, timestamp on capture, not on parse, and record the exit location alongside each row - odds are region-specific, so "DraftKings, NJ, 14:32:05" is a different data point from the same book in another state. Second, deduplicate on the natural key (book + market + selection + timestamp) so a retried request after a timeout doesn't double-count a price. With that structure, comparing books for cross-market edges becomes a simple query instead of a scramble, and your arbing or modelling research runs against clean, auditable history. It's the same monitoring discipline our guide to restock and availability monitoring applies to inventory - only here the values move by the second.
Bot walls and when to reach for an API
Not every book is equally easy. Some sit behind strong bot detection and will block a naive scraper fast; others are simply slow, forcing one request per market grouping. When a target renders odds only after heavy JavaScript, or fights you with fingerprinting, a raw request stops being enough. A Scraper API that carries a real browser fingerprint, rotates IPs and renders JS on demand is usually less work than maintaining that stack yourself - and it returns the parsed payload. One line on the legal side: scraping public odds for analytics is common, but sportsbook Terms often restrict automated access and the activity is regulated - this is guidance, not betting or legal advice, so check your jurisdiction.
Frequently asked questions
How do I scrape betting odds with Python?
Watch the sportsbook's Network tab to find the internal JSON API its front end calls, then request that endpoint directly through a proxy and parse the structured response. Normalise everything to decimal odds with one row per selection so books are comparable. This is far more stable than parsing the rendered scoreboard HTML, which changes constantly.
How often should I poll for odds?
For model training, every 30-60 seconds is usually enough; a common reference is a moneyline snapshot each minute. Arbitrage research needs tighter intervals, but fast polling from one IP gets flagged - rotate the exit IP each cycle through a residential pool so the load spreads across many addresses instead of one.
Why do odds differ when I scrape from another location?
Sportsbooks are licensed per jurisdiction, so lines and availability vary by state or country, and some books geo-block outright. The request's exit location decides which market you see. To collect region-accurate odds, pin your proxy exit to the jurisdiction you're studying rather than assuming one global price exists.
Is scraping sportsbook odds legal?
Collecting publicly displayed odds for analytics is widely done, but sportsbook Terms of Service often prohibit automated access, and sports betting is heavily regulated by region. Treat the data as public research input, respect each site's Terms and robots directives, and check the rules where you operate. This is general guidance, not legal or betting advice.
Scraping odds well comes down to four moves: read the internal JSON, poll on a steady cadence, rotate residential IPs so no address stands out, and match the exit geo to the market. Get those right and you have a clean, region-accurate odds feed - the raw material for any model or edge-hunting research.