Sports betting data is the record of what the market offered and what happened: the prices and lines each book posted, how much you could bet at them, the final results, and the closing line just before the start. Each kind comes from a different place, and each goes wrong in its own way.
The part that decides whether any of it is useful is the clock. A price without the time it was observed is a rumor. A dataset that covers some books and quietly leaves out others will bias every number you build on it. So before you ask where the data comes from, ask how it records time and how it tells you what's missing.
The five kinds, and where each one lives
| Kind | What it is | Usual source | What goes wrong |
|---|---|---|---|
| Prices | The odds on each side, such as -110 or +150 | Each operator's own site or app | Read late, cached, or copied |
| Lines | The number a spread, total or prop is set at | Same as prices | A moved line is a different market |
| Depth or limits | How much you can bet at a price | Exchanges publish it, sportsbooks mostly don't | Missing, or shown as zero |
| Results | Final scores and settled outcomes | League feeds, box scores, the books' own settlement | Delays, corrections, voids |
| Closing lines | The last price before the start | Derived from a price history | Taken too early or too late |
Prices and lines are the core of any betting data set. A line is part of what a market is: a total at 224.5 and a total at 225.5 are two different bets, with two different price histories. Store them that way, or a move from one to the other looks like a price change when it isn't.
Depth is the hardest to get honestly. An exchange shows the amount waiting at each price, because that's how it works. A sportsbook sets its own limits per customer and per market and usually doesn't publish them, so you should treat a sportsbook's size as unknown, not as unlimited.
Results look simple and aren't. Games get postponed, props get voided when a player doesn't play, and stat corrections change a settled number after the fact. Keep the result, where it came from and when you recorded it, and expect to update it.
What makes a price trustworthy
Three timestamps matter, and good sports betting data keeps them apart:
- When the venue changed the price. Some venues publish this, many don't.
- When the price was observed. The time someone actually read it, or the time a cached copy was made.
- When you received it. The moment the response reached you.
The second one is the one people lose. A page served from a cache can be minutes old the moment it arrives. If you stamp it with your receipt time, a stale price looks fresh, and a stale price is exactly where fake edges come from.
Here's what that looks like in ZippyOddsAPI. Each book in an odds response carries updated_at and time_basis. Say a response's meta.generated_at is 2026-11-06T18:00:00.000Z and a book's updated_at is 2026-11-06T17:59:40.000Z. The prices from that book were 20 seconds old when the answer was built. If time_basis is snapshot, the copy's clock is earlier than the time it was received, which is the cached case above. If it's read, the copy is as of receipt.
The docs are blunt about the limits of this too: prices are polled from each venue, so they are minutes old rather than milliseconds. That's the honest answer for any collected source. A dataset that claims every price is instant is either rare or wrong.
Coverage honesty
The other half of trust is knowing what isn't there. A board that's missing a book doesn't announce it. Your average closing price, your hold figures and your best-line counts all shift when a source drops out, and nothing in the numbers tells you.
Three habits help:
- Record which sources fed each event. If a book wasn't there, your comparison excluded it, and you should know that.
- Keep old prices at their real age. Deleting a price because it's old destroys history. Showing it as current is worse. Keep it, label it.
- Treat a book on a list as a claim, not a fact. Check what's actually feeding at the time you read.
ZippyOddsAPI handles the last one with a coverage page that shows which books are feeding now, and the event detail endpoint lists the sources that read each game. A book appearing in an example in the docs doesn't mean it is feeding.
Where ZippyOddsAPI fits, and where it doesn't
ZippyOddsAPI reads prices from operators' own public data (publisher snapshots of some books are labelled raw-only and never scored), and every price keeps the time it was observed. That covers prices, lines and, where the venue publishes it, depth through the liquidity field on an outcome.
Results are the gap to plan for. A game leaves the board when a source reports it final, so /v1/scores has no finished games to return. For settled results you'll need a separate source.
Closing lines you can derive. /v1/history stores a point each time a market changes and keeps points for 30 days, for full-game moneyline, spread and total markets only. The last point before the event's start_time is that book's closing price on that line. Save it yourself if you want it past 30 days. The API docs cover each endpoint's fields, and they're the only place to trust for exact names.
Using the data for something
Most people collect betting data to answer one of two questions: is a price good now, or did my prices beat the market over time. The first needs fresh prices and a fair reference. The second needs closing lines and results.
If you're building a forecast, the data comes first and the model second. Our guide on how to build a sports betting model starts from a clean price history, and the sports betting model overview covers what a model can and can't tell you. For measuring how your bets did once you have the data, see sports betting analytics: hold, closing line value, ROI and its variance.
Whichever you build, keep the clocks. Every later question depends on knowing when a number was true.