The odds API: a complete developer's guide to real-time sports odds
Every betting tool starts with the same problem. You need live odds, and the sportsbooks are not going to hand them to you.
An odds API is a REST service that returns live and pre-match betting odds (moneyline, spreads, totals, and player props) as structured JSON across many sportsbooks. You send one authenticated request and get normalized lines back. No headless browser, no proxy pool, no parser to rewrite every time DraftKings ships a new layout.
This guide covers what an odds API actually returns, what you can build with it, how the billing traps work, and how to make your first call today. I'll use propzapi for the examples because that's what I know best, but most of this applies to any provider you pick.
What is an odds API, really?
An odds API gives you odds as data instead of as a web page. Where a sportsbook site renders prices in HTML for humans, an odds API returns the same prices as JSON built for code: a tree of events, the bookmakers pricing each event, the markets each book offers, and the priced outcomes inside every market. One call, one predictable shape, every sport.
The shape is the important part. It's the same whether you ask for the NBA tonight or the Premier League in March.
Because the structure is stable, you write your parser once. A scraper has to handle each book's markup separately, and re-handle it every time the markup changes. That difference is the whole pitch.
What can you build with a sports odds API?
Plenty, because the market is huge and every product in it runs on odds data. Odds comparison sites, arbitrage and positive-EV finders, Discord alert bots, model backtests, fantasy and props tools, and AI agents that answer betting questions all need the same feed. A sports odds API is the data layer under all of them.
The numbers explain why this is a real market and not a hobby. In 2025, regulated US sportsbooks took $165.58 billion in total handle, according to the American Gaming Association. Revenue hit a record $16.96 billion, per ESPN.
Sports betting is now live in 38 states plus DC, and more than 80% of those wagers happen on a phone. Every one of those apps needs odds, and most of them get it from an API rather than a scraper.
One trend matters more than the rest if you're picking what to build. Player props are eating the market.
Same-game parlays, which are stacks of player props, now make up roughly 35% to 40% of sportsbook gross gaming revenue, up from under 20% in 2021. Props are where the growth is. They're also the market most odds feeds cover worst, which is the gap propzapi was built for.
Odds API vs scraping sportsbooks: which should you use?
Use an odds API unless you're building a throwaway script for one book. Scraping looks free because there's no invoice, but you pay in engineer-hours: anti-bot defenses, IP bans, layout changes, and missing data on the exact nights traffic spikes. An API trades a predictable bill for reliability you can build a product on.
Here's the honest comparison, without the marketing gloss.
| Scrape it yourself | Use an odds API | |
|---|---|---|
| Setup | A weekend per book | One API key, one request |
| Maintenance | Ongoing, breaks silently | Stable contract |
| Multi-book | A parser for each site | Many books in one response |
| Reliability | Fails under rate limits | Built for uptime |
| Legal footing | Against most books' terms | Licensed data feed |
| Real cost | Your time, unpredictably | A metered bill you can read |
Scraping is fine for a one-off: one book, low frequency, a project you'll throw away. The moment you need two books, uptime, or props, the math flips.
How do odds API credits work, and why do they bite people?
Most odds APIs bill in credits, and the trap is that a credit is not a request. A common model charges markets times regions, so a single call for three markets across two regions costs six credits, not one. On a 500-credit free tier that's about 83 calls before the feed cuts off. Read the meter before you write any code.
The Odds API is the category default and a clear example of this model. Its free tier gives you 500 credits a month, but a live call costs markets times regions. Ask for moneyline, spreads, and totals across the US and UK and that's 3 by 2, or 6 credits per call. Your 500 credits become about 83 calls. Historical data multiplies by 10, so the same call costs 60 credits, or roughly 8 snapshots a month.
propzapi meters by market instead, and returns the exact cost of every call in an X-Credits-Cost header. There's no region multiplier to reason about, and you never have to guess what a request will cost. That's the whole reason the header exists: you read it, not a pricing table.
None of this makes one provider objectively cheaper at every scale. At very high volume, big credit buckets can win on price. But for the entry and mid tiers most developers actually buy, a per-market meter is easier to predict and usually easier on the wallet.
How do you make your first odds API call?
Get a free key, send one authenticated GET request, and parse the JSON. With propzapi you sign up, confirm your email, grab the key from the dashboard, and call /v1/odds with the key in an X-API-Key header. You'll have live lines in your terminal in under ten minutes, no card required.
Start with cURL to prove the key works.
curl "https://api.propzapi.com/v1/odds?league=NBA&market=h2h" \
-H "X-API-Key: $PROPZAPI_KEY" Then wire it into your language. Python first.
import requests
r = requests.get(
"https://api.propzapi.com/v1/odds",
params={"league": "NBA", "market": "h2h"},
headers={"X-API-Key": "YOUR_KEY"},
)
data = r.json()
print("credits spent:", r.headers["X-Credits-Cost"])
for event in data["data"]:
for book in event["books"]:
print(event["home"], "vs", event["away"], "-", book["name"]) Or Node, if that's your stack.
const res = await fetch(
"https://api.propzapi.com/v1/odds?league=NBA&market=h2h",
{ headers: { "X-API-Key": process.env.PROPZAPI_KEY } }
);
const { data } = await res.json();
console.log("credits:", res.headers.get("X-Credits-Cost")); What comes back is the tree from earlier, as JSON you can walk.
{
"data": [
{
"home": "Celtics",
"away": "Lakers",
"start": "2026-01-14T00:30:00Z",
"books": [
{
"name": "DraftKings",
"markets": {
"h2h": [
{ "team": "Celtics", "price": -145 },
{ "team": "Lakers", "price": 124 }
]
}
}
]
}
]
} Notice the X-Credits-Cost header in the Python and JS examples. Log it while you build. It's the cheapest way to keep a surprise off your next invoice.
Which sportsbooks and player props does an odds API cover?
Coverage is the thing to check first, and it's where providers differ most. The Odds API covers around 40 mainstream books but skips sharp books like Pinnacle. propzapi covers major US sportsbooks including DraftKings, FanDuel, and Pinnacle, exposes the live list at /v1/books, and treats player props as a first-class market rather than an afterthought.
There's no public DraftKings or FanDuel odds API. The books don't publish one. So your two options are scraping their sites or calling a provider that already has the lines. If you want DraftKings and FanDuel prices side by side, one odds API request beats two scrapers you have to babysit.
Props are the part worth pressing on. Because parlays built on props now drive a third of sportsbook revenue, thin prop coverage is a real limit on what you can build. propzapi is props-first: you pull player props from /v1/props filtered by league and market, and get player, line, and per-book price in the same clean shape as game odds.
How do you run an odds API in production without blowing the budget?
Cache read-through, poll each market only as often as it moves, and filter every request to the leagues and books you actually use. Pre-match lines don't need second-by-second polling; live lines do. Add webhooks or an agent layer so you react to changes instead of hammering the endpoint. Those three habits keep both latency and credits down.
A simple pattern works for almost everyone. Put a cache in front of the API, set a short time-to-live for live markets and a longer one for pre-match, and serve your own thin API to your clients from that cache. You pull from the odds API on cache misses, not on every user request.
If you're building for AI agents, propzapi ships an MCP server so an assistant can call odds directly, plus installable agent skills. That turns "fetch the lines" into something a model does on its own.
For the exact endpoints, parameters, and limits, the docs have the full reference. When you're comparing providers on price and coverage, the alternatives breakdown and the 2026 odds API comparison go deeper than I can here.
Frequently asked questions
- What is an odds API?
- An odds API is a REST service that returns live and pre-match betting odds — moneyline, spreads, totals, and player props — as structured JSON across many sportsbooks. You send one request and get normalized lines back, so you never scrape a sportsbook's website or maintain a parser per book.
- Is it legal to use a sports odds API?
- Consuming odds through a licensed odds API is standard for analytics, tooling, and research, and it's the compliant alternative to scraping a sportsbook. You are responsible for how you use the data under your local rules. propzapi is a data provider, not a sportsbook, and does not take wagers.
- How much does an odds API cost?
- It depends on the billing model. The Odds API starts free at 500 credits a month, then $30 to $249. propzapi has a free tier, then $19, $49, and $149 a month, and meters by market with the exact cost returned on every call. Watch how a provider counts credits before you commit.
- How do I get DraftKings and FanDuel odds without scraping?
- Call an odds API that already covers those books and returns them in one response. With propzapi you filter by bookmaker and get DraftKings and FanDuel lines side by side as JSON. There is no public DraftKings or FanDuel odds API, so the alternative is scraping, which breaks under rate limits and layout changes.
- How do I get player prop odds via API?
- Pull them from a props-capable endpoint. With propzapi you call /v1/props filtered by league and market to get player, line, and per-book price as JSON. Most general odds APIs expose props thinly, which matters because parlays built on props now drive a large share of sportsbook revenue.
- How real-time is the odds data?
- Lines move most in the hours before kickoff, and an odds API reflects the latest available prices when you call it. For live betting you poll the endpoint on a short interval; for pre-match you can poll less often and cache between pulls to keep both latency and credit spend down.
Start with one call
You don't need a plan or a credit card to see whether an odds API fits your project. Get a free key, run the cURL command above, and watch live lines print. If props are anywhere in your roadmap, start there — it's the market growing fastest and the one propzapi covers deepest.