An oddsmatcher finds the best back/lay pairs across books and exchanges. Here is the data behind it: each back price matched to an exchange lay price, with a rating that shows how close the two are.
An oddsmatcher finds the best back/lay pairs across bookmakers and exchanges. The data behind it is simple to state: each bookmaker back price matched to the current exchange lay price for the same selection, with a rating that shows how close the two prices are. The closer they sit, the smaller the cost of placing the bet. This post explains that data, what each field means, and where the consumer tools stop and a developer feed begins.
An oddsmatcher is a tool that scans bookmaker odds against exchange lay odds and ranks the pairs you can act on. For a matched bettor it answers one question: of all the offers and selections available right now, which back price sits closest to its lay price, so a qualifying bet costs the least to place? You can see the formal oddsmatcher definition in the glossary, but the working idea is a ranked list of back/lay pairs, freshest and closest at the top.
Every oddsmatcher is only as good as the data feeding it. Two prices are needed for each row: the back price a bookmaker is showing, and the lay price on an exchange for the identical selection. Pair those across 60+ UK books, bet365 included, and three exchanges, and you have the raw material an oddsmatcher ranks.
The rating measures how close the back price is to the lay price. It is the single number a matched bettor reads first. A rating near 100 means the bookmaker back odds and the exchange lay odds almost agree, so the cost of placing a qualifying bet is small. A lower rating means the gap is wider and the bet costs more to place. The rating turns two raw prices into one comparable score, which is why it sits at the top of every ranked row.
Here is a single matched row, with the rating field prominent (illustrative, not live data):
{
"event": "Brighton vs Newcastle",
"market": "match_odds",
"selection": "Newcastle",
"back": { "bookmaker": "bet365", "odds": 3.40 },
"lay": { "exchange": "betfair", "odds": 3.45, "liquidity": 1260 },
"rating": 98.6,
"qualifying_loss": -0.09
// ... region, feed_type and freshness fields elided
}The rating of 98.6 is what an oddsmatcher sorts on. It is derived from the relationship between back.odds and lay.odds: when they are this close, the row ranks near the top of the list. Strip the lay block out and the rating cannot exist, because there is nothing to measure the back price against.
Qualifying loss is the small, expected cost of placing a matched bet before any free bet or offer is applied. In the row above it is -0.09: a tiny loss per unit staked, because the back and lay prices are close and the exchange takes a commission on the lay side. Qualifying loss is the practical companion to the rating. The rating tells you how close the pair is; the qualifying loss tells you what that closeness costs in money terms. A high rating and a near-zero qualifying loss describe the same desirable row from two angles.
Liquidity is the money available to match your lay on the exchange, and without enough of it a pair is not really usable. A row can show a perfect rating and a near-zero qualifying loss, but if the lay.liquidity is thin you cannot get your full stake matched at that price. The bet is theoretical, not placeable. That is why an honest oddsmatcher carries liquidity on every lay block, and why a feed that omits it leaves you to discover the gap at the worst moment.
A consumer oddsmatcher is a subscription tool an end user logs into; a developer data feed is an API your own product reads. Both run on the same kind of matched data, but they serve different people. The consumer tools are well-built and serve their users well: a matched bettor signs in, reads the ranked list, and places bets. That is the right shape for an individual.
The gap appears when you are building software rather than using it. Consumer oddsmatchers ship no public feed: there is no documented endpoint your product can call, because the matched data lives inside their interface, not behind an API you can license. So a team building an oddsmatcher, a scanner, or a tipster dashboard cannot consume those tools as data. They have to source and match the prices themselves, which is exactly the work a B2B feed exists to remove.
| Consumer oddsmatcher | Developer data feed | |
|---|---|---|
| Who uses it | An individual matched bettor | A team building a product |
| Shape | A website you log into | An API your code calls |
| Public feed to build on | None | Documented endpoint, per-client key |
| Matching | Done, shown in the interface | Done, delivered as data rows |
Neither is better in the abstract: they answer different questions. If you are an end user, a consumer tool is the right choice. If you are shipping a product that needs the matched data as an input, you need a feed.
Oddsmatcher-ready data is matched data your oddsmatcher can render on day one, with no matcher of your own to build. Each row already carries the bookmaker back price, the paired exchange lay price, the liquidity, the rating and the qualifying_loss. The hardest part of building an oddsmatcher, pairing every back price with a live, liquid exchange lay price and scoring it, is done before the data reaches you. We unpack the term in full in oddsmatcher-ready data.
This is what removes the matcher from your build. Without ready data you commit to an exchange integration, a selection-matching layer, a liquidity model, and the collection that feeds all three. With it, your oddsmatcher is a view over rows that are already ranked. If you want to understand the engineering you are skipping, how to build an oddsmatcher walks through the parts, and the complete guide to matched-betting data sets the wider picture.
OddsRelay delivers exactly this: bet365 and 60+ UK books matched against three exchanges (Betfair, Smarkets, Matchbook), each row rated and ready, kept current by a team dedicated to maintaining it. Our honest freshness posture is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting well. It powers a leading UK matched-betting platform today.
An oddsmatcher ranks back/lay pairs; the data behind it is each back price matched to a live exchange lay price, scored by a rating and costed by a qualifying loss, and only usable where the lay has real liquidity. If you are building on that data rather than logging into a tool, you can see what is live on the coverage dashboard, or start a free trial and read matched, oddsmatcher-ready rows from the feed before you commit.
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.
Matched betting & oddsmatcher
Matched betting runs on one thing: a bookmaker back price paired with the current exchange lay price, with a rating and qualifying loss attached. This is the complete picture of that data layer, and how to ship it without building the matcher.
· 7 min read
Matched betting & oddsmatcher
Oddsmatcher-ready data arrives already matched, with the exchange lay price, rating and qualifying loss attached, so you render rows instead of building a matcher. Here is exactly what the term removes from your build.
· 6 min read
Matched betting & oddsmatcher
Building an oddsmatcher means building two things: the data that feeds it, and the product around it. This is how to tell them apart, and which one is worth your engineering time.
· 6 min read