An odds API hands your software bookmakers' prices as structured data instead of a human reading betting sites by hand. Here's what one returns, how raw and matched feeds differ, and what to check before you commit.
An odds API is an interface that returns bookmakers' prices as structured data your software can read, instead of a human reading betting sites by hand. Your code makes a request, and the prices come back as JSON: events, markets, selections and the odds attached to them. That is the whole idea. Everything else in this guide is detail about what gets returned, how fresh it is, and how much work the API has done for you before you receive it.
This is the definitional entry point for builders new to odds data. If you want the one-line version, the odds API definition in the glossary states it plainly. The rest of this page expands it: what the data looks like, the spectrum from raw prices to a matched feed, the honest truth about latency, and what to evaluate before you pick one.
It returns the structure of a betting market: events, markets, selections, and a price for each selection, plus the metadata you need to make sense of them. A football match is an event. Its match-odds market holds three selections (home, draw, away). Each selection carries a decimal price. Wrap that in metadata and you have a row your software can act on.
The metadata is what makes a price trustworthy. Each row tells you which bookmaker the price came from, which region it applies to, and a timestamp for when it was last seen. A price with no bookmaker and no timestamp is a number you cannot reason about. A price with both is data.
Calling the API is an authenticated request to an endpoint: you send a key, you name the markets or region you want, and JSON comes back. There is no page to read and no screen to parse. For the full request and response shape, see the API docs.
The single biggest difference between odds APIs is how much processing they have done before you receive the data. At one end, a raw odds API hands you prices and nothing more. At the other, a matched feed pairs each price with an exchange lay price and adds the figures that turn a price into an opportunity. Most builders search for the first and discover they needed the second.
A raw row is just the back price a bookmaker is showing for a selection:
{
"event": "Arsenal vs Chelsea",
"market": "match_odds",
"selection": "Arsenal",
"back": { "bookmaker": "bet365", "odds": 2.10 }
// ... region, timestamp metadata elided
}That is usable for an odds-comparison table. It is not enough for matched betting or arbitrage, because those run on a relationship between two prices: the bookmaker back price and the current exchange lay price for the same selection. A matched feed does that pairing for you, then adds a rating and a qualifying_loss so your scanner can render results without building a matcher first:
{
"event": "Arsenal vs Chelsea",
"market": "match_odds",
"selection": "Arsenal",
"back": { "bookmaker": "bet365", "odds": 2.10 },
"lay": { "exchange": "betfair", "odds": 2.14, "liquidity": 1840 },
"rating": 98.1,
"qualifying_loss": -0.12
// ... region, feed_type, freshness fields elided
}The lay block paired to the back price, with rating and qualifying_loss computed, is the part a raw API cannot give you. Build it yourself and you take on an exchange integration, a matcher and a liquidity model on top of collecting the prices. That is the real fork in the road, and we walk it in full in odds API vs odds feed.
There are two delivery models, and most vendors blur the line between them. Polling means your software asks for the latest prices on a schedule. Streaming means the vendor pushes each change to you as it happens. Streaming sounds better in a sales deck, but in-play streaming is a much harder promise to keep, and many "real-time" claims do not survive contact with a dashboard.
Our honest posture is pre-match polling on roughly a few-second cycle. That suits pre-match matched betting and pre-match arbitrage well, which is where the durable value sits today. We do not claim sub-second in-play streaming, because that is not what we ship. Be cautious with any vendor that promises live in-play prices without showing you their freshness and latency. A checkable number beats a confident one.
Judge an odds API on coverage, lay support, freshness and reliability, in that order. A clean response shape is table stakes. The things below are where APIs genuinely differ, and where a quiet gap costs you later:
lay block is real, not a placeholder.The reason to insist on a dashboard is simple: coverage and freshness are claims, and claims should be checkable. You can see what is live for OddsRelay right now on the coverage dashboard, rather than taking a figure on trust. For a structured way to weigh these factors against each other, choosing an odds API lays out the buyer's checklist.
Three kinds of product lean on an odds API, and each wants a different level of processing from it:
| Product | What it needs from the API | Raw or matched? |
|---|---|---|
| Odds comparison | Many books, consistently, with fresh prices | Raw is enough; coverage and freshness decide it |
| Matched-betting / oddsmatcher | Back price paired with exchange lay, rated | Matched: the qualifying bet *is* the back/lay pair |
| Arbitrage scanner | A price against the best opposing price | Matched: an arb is a relationship, not one number |
If you are building an oddsmatcher or an arbitrage scanner, the deciding question is not whether you can get a price. It is whether you can get prices already matched against the exchanges, kept reliable, without owning the collection problem yourself. If you would rather source the prices directly, how to get bookmaker odds data covers the realistic routes and their trade-offs.
An odds API turns bookmakers' prices into structured data your software reads, instead of a human reading betting sites by hand. The raw version gives you prices; a matched feed pairs each price with an exchange lay price and adds a rating and qualifying_loss, so a matched-betting or arbitrage product works on day one. OddsRelay is the matched kind: 60+ UK books with bet365 included, matched against three exchanges, on a roughly few-second pre-match cycle. It powers a leading UK matched-betting platform today.
The fastest way to see the difference between a number and a matched row is to make a real call. Start a free trial to read the matched feed yourself, or check what is live first on the coverage dashboard.
Written by
Founder, OddsRelay
James is the founder of OddsRelay — the odds-data feed behind matched betting, arbitrage and odds-comparison products: 60+ UK bookmakers with bet365 included, matched against exchange lay prices and delivered as one clean, documented API. He writes here about how that data layer actually behaves — coverage, matching, freshness and the trade-offs — from the side that builds and runs it. The same feed powers a leading UK matched-betting platform today.
18+ · Data product for licensed operators. Please gamble responsibly.
Fundamentals
Builders hit two terms for the same data and assume they're choosing between products. They aren't. Here's what each word stresses, and the distinction that actually changes your build: raw versus matched.
· 5 min read
Fundamentals
There are two ways to get bookmaker odds into your app: collect it yourself, or license a feed. Here's how each works, what to decide first, and the integration sketch for the faster path.
· 4 min read
Buying vs building
A vendor-neutral framework for choosing an odds API. Five questions, asked in order, that separate a feed you can build on from one you'll regret. Raw book count is not one of them.
· 7 min read