What Is an Odds API? A Beginner's Guide to Sports Odds Data
A plain-language introduction to odds APIs. Where the prices come from, how they are normalized and delivered over REST and WebSocket, what a response looks like, who uses one and how to choose.
If you have ever wanted to put sportsbook prices into a spreadsheet, an app or a model, you have probably asked the question this post answers: what is an odds API, and how is it different from just looking at a betting site? The short version is that an odds API is a web service that hands you the prices posted by many sportsbooks as structured data, so a program can read them instead of a person.
This guide is written for people who are new to the idea. It covers where the prices come from, how odds APIs work behind the scenes, the difference between REST and WebSocket delivery, what a real response looks like, who uses one, and how to pick a provider. Think of it as the sports odds API explained from the ground up, with real requests against the PreciseAPI feed as examples.
What is an odds API, in one paragraph
An odds API is a data service. It gathers the prices that sportsbooks, betting exchanges, prediction markets and daily fantasy (DFS) apps post for sporting events, converts them into one consistent format, and serves them over the internet. Your code sends a request such as "NBA moneylines from Pinnacle and DraftKings" and gets back JSON listing each game, each book's markets and the price on every outcome. You decide what to do with it: show it, store it, compare it or feed it into a model.
It helps to be clear about what it is not. An odds API is not a sportsbook. It does not take bets, hold money or pay anything out, and a data provider like PreciseAPI does not publish picks or tell anyone what to bet. It is closer to a market data feed for stocks: the prices, delivered reliably, with everything else left to you.
Where the odds come from
Every price in an odds data feed starts at a source that sets or matches prices. In the PreciseAPI catalog there are 36 of them across 17 leagues, in three groups:
- Sportsbooks (23). Regulated US books such as DraftKings and FanDuel, offshore books, and sharp books such as Pinnacle and Circa. Each sets its own prices and margin.
- Exchanges and prediction markets (7). Platforms such as Novig and Kalshi, where prices come from users' orders rather than a bookmaker.
- DFS pick'em apps (6). Apps such as PrizePicks that post player stat lines for fixed-payout entries instead of per-selection prices.
Providers obtain prices in different ways. Some have data agreements with individual books; others collect the prices each source publicly posts. PreciseAPI collects prices from sportsbooks, exchanges, prediction markets and DFS apps independently, and is not affiliated with the books it covers. If you want to understand where the books themselves get their numbers, the companion post on how sportsbooks get odds covers oddsmakers, market makers and line movement.
How odds APIs work: collect, normalize, deliver
Behind a single request there are three jobs, and the quality of an odds API mostly comes down to how well it does each one.
Collect. Prices change constantly, so the provider has to read every source continuously and notice when a market is pulled. A price that has stopped updating is worse than no price, because it looks real.
Normalize. Every book names things differently. One calls a team "LA Clippers" and another "Los Angeles Clippers"; one labels a market "1st Half Spread" and another "Handicap - First Half". The API maps all of that onto one schema with stable ids for events, teams, players, markets and individual outcomes. That is what lets you compare a price at one book with the same outcome at another without writing a matching layer yourself. The normalization post explains how PreciseAPI builds those ids.
Deliver. Finally, the data has to reach your code, either when you ask for it or the moment it changes. That choice is the next section.
REST vs WebSocket delivery
There are two common ways to receive odds, and many products use both.
| REST | WebSocket | |
|---|---|---|
| How it works | Your code asks; the API answers with the current prices | You connect once; the API pushes each change |
| Freshness | As fresh as your polling interval | Changes arrive as they happen |
| Good for | Pre-game screens, scheduled jobs, spreadsheets, models | Live in-play products, alerts, trading tools |
| PreciseAPI cost | Credits per request (2 for /v1/odds) | 1 credit per connection-minute |
REST is the simpler model. You send an HTTPS request, get JSON back, and repeat on a schedule. It works with any language and is the right starting point for most projects. The catch is that you only see changes as often as you poll, and every poll costs a request.
WebSocket keeps a connection open. On PreciseAPI's stream you subscribe to leagues or events, receive a full snapshot, then receive only the markets that change. In-play prices update in under 500 ms on the Syndicate plan, which is where the stream and live odds are included. The polling versus streaming post works through when the switch pays off, and the live odds API page summarizes the live product.
What a response looks like
Here is a real request shape. It asks for full-game moneylines and spreads on NBA games from two books:
curl "https://api.preciseapi.com/v1/odds?league=nba&markets=moneyline,spread&books=pinnacle,draftkings" \
-H "Authorization: Bearer $PRECISEAPI_KEY"And a trimmed response, showing one game and one book:
{
"data": [
{
"id": "evt_1iazqk4srnb",
"league": "nba",
"start_time": "2026-10-14T23:50:00.000Z",
"status": "scheduled",
"home": { "id": "nba_phx", "name": "Phoenix Suns", "abbr": "PHX" },
"away": { "id": "nba_sas", "name": "San Antonio Spurs", "abbr": "SAS" },
"bookmakers": [
{
"id": "pinnacle",
"name": "Pinnacle",
"type": "sportsbook",
"markets": [
{
"id": "mkt_1dougx7qnw5",
"key": "moneyline",
"period": "full_game",
"outcomes": [
{ "id": "sel_2d3ja0zugwd", "name": "Phoenix Suns", "side": "home", "price": -202 },
{ "id": "sel_1pojklgy6cc", "name": "San Antonio Spurs", "side": "away", "price": 179 }
],
"suspended": false,
"updated_at": "2026-10-14T23:33:15.863Z"
}
]
}
]
}
],
"meta": { "count": 1, "format": "american", "credits_used": 2 }
}Reading the fields
| Field | Meaning |
|---|---|
id (event) | A stable id for the game, reused by every other endpoint |
bookmakers[] | One entry per source that prices the game |
markets[].key | The market type: moneyline, spread, total, a player prop and so on |
markets[].period | Full game, a half, a quarter, first five innings and so on |
outcomes[].price | The price, in American odds unless you pass format=decimal or format=probability |
outcomes[].id | The selection id, identical for the same outcome at every book |
suspended, updated_at | Whether the market is open, and when the price last changed |
Prices of -202 and +179 are American odds: the favorite pays $100 for every $202 staked, the underdog $179 for every $100. If that notation is new, the odds formats guide converts between American, decimal and fractional odds, and the implied probability calculator does it for any single price.
Who uses an odds API
Developers and businesses of very different sizes build on the same data:
- Odds comparison sites and screens show every book's price side by side. See the real-time odds screen use case and the odds comparison API, which returns the best price per outcome.
- Analysts and modelers store prices over time to test models and measure closing line value. The historical odds API covers line history.
- Alert bots watch for price moves and post them to Discord or Slack; the Discord bot tutorial builds one.
- Media and affiliates embed odds tables in articles and previews.
- DFS and pick'em tools compare app lines with sportsbook props using the player props API.
- Trading desks at books and market makers watch the wider market while they price their own.
The use cases hub has the full list with example architectures.
What an odds API does not do
It is worth repeating, because beginners often expect more. An odds API will not place bets for you, will not tell you which bets are good, and cannot promise that a price will still be there when you get to the book. Prices move, books pull markets, and a price you saw a minute ago may be gone. Anything built on top, from a comparison table to a model, has to treat each price as a timestamped observation.
How to choose an odds API
Once "what is an odds API" has an answer, the next question is which one to use. That comes down to a handful of checks:
- Coverage. Does it carry the books, leagues and markets you need, including props, futures and periods such as first halves?
- Delivery. Is REST enough, or do you need a WebSocket stream and in-play prices?
- Normalization. Are there stable ids that line up across books, or will you be matching team names yourself?
- History. Can you get opening and closing prices, or only the current snapshot?
- Pricing. How does cost scale with the way you will call it: per request, per market or flat?
The buyer's checklist for choosing a sports odds API goes through each question in depth with a two-week evaluation plan.
For reference, PreciseAPI's plans work like this. The Sandbox is free with 50 credits for asking questions in the dashboard chat, but it has no API access. API keys start on Edge at $49.99 a month with 150,000 credits; Sharp at $199.99 and Syndicate at $249.99 are unlimited, and Syndicate adds live in-play odds and the WebSocket stream. The pricing page has the full comparison, and the quickstart gets a first request working in a few minutes.
Frequently asked questions
What is an odds API used for?
It is used to get sportsbook, exchange and DFS prices into software. Common uses are odds comparison screens, betting models and research, price alerts, media widgets and DFS tools. The API supplies the prices; the product built on top decides how to use them.
Is there a free odds API?
Some providers offer free tiers with limits. PreciseAPI's Sandbox is free with 50 credits, spent in the dashboard chat rather than through API keys; API access starts on the Edge plan. The free odds API post compares the free options.
Do I need WebSocket, or is REST enough?
REST is enough for most pre-game products, scheduled jobs and research. A WebSocket stream matters when you need in-play prices or want changes the moment they happen. On PreciseAPI the stream and live in-play odds are part of the Syndicate plan.
Can I place bets through an odds API?
No. An odds API delivers prices only. To bet you use a sportsbook or exchange directly. PreciseAPI is a data provider: it does not accept wagers or give picks.