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.
Oddsmatcher-ready means the data arrives already matched. Each bookmaker back price is paired with the current exchange lay price for the same selection, with a rating and a qualifying_loss computed before you receive it. You render rows in an oddsmatcher instead of building a matcher to produce them. The term describes a finished shape, not a richer pile of prices, and the difference decides how much of the system you have to build yourself.
Oddsmatcher-ready data is data that already carries everything an oddsmatcher row needs to display. A matched-betting oddsmatcher shows the user a back bookmaker, a price, the exchange to lay at, the lay price, and a rating that says how good the qualifying bet is. Oddsmatcher-ready means each of those is present in the row when it arrives, so your job is presentation and filtering, not computation.
Concretely, a ready row pairs the back side and the lay side of the same selection and adds the figures a user sorts on. Here is the shape of one row (illustrative, not live data):
{
"event": "Brighton vs Newcastle",
"market": "match_odds",
"selection": "Brighton",
"back": { "bookmaker": "bet365", "odds": 3.40 },
"lay": { "exchange": "matchbook", "odds": 3.45, "liquidity": 760 },
"rating": 98.6,
"qualifying_loss": -0.09
// ... region, feed_type and freshness fields elided
}The pairing is the point. The back block and the lay block describe the same selection, so the row is a qualifying bet rather than two unrelated prices you still have to reconcile. The rating ranks it against every other row, and qualifying_loss tells the user the small expected cost of the qualifier. That is what "ready" refers to: the row is complete on arrival.
Raw odds data is back prices only. It gives you what each bookmaker is showing, as structured prices, and leaves the matching, the rating and the liquidity check to you. Raw data is a feed of numbers; oddsmatcher-ready data is a feed of opportunities. The gap between them is where almost all the engineering cost of an oddsmatcher lives.
With raw data, a row arrives as a single bookmaker price with no opposing side. To turn it into something a user can act on, you integrate one or more exchanges, fetch the lay price for the same selection, compute the implied position between back and lay, and confirm there is enough liquidity for the lay to be real. Every one of those steps is yours to build and maintain. With oddsmatcher-ready data those steps are already done, and the row carries the result.
| Raw odds data | Oddsmatcher-ready data | |
|---|---|---|
| What a row contains | A bookmaker back price | Back price paired with the exchange lay price |
| Exchange lay side | You integrate and fetch it | Already attached (Betfair, Smarkets, Matchbook) |
| Rating / qualifying loss | You compute them | Computed for you (rating, qualifying_loss) |
| Liquidity check | Your liquidity model | liquidity carried on the lay side |
| Time to a usable oddsmatcher | Months of build | Render rows on day one |
Ready removes three sub-systems you would otherwise have to build and keep running. These are the parts of an oddsmatcher that are invisible to the user and expensive to the engineer:
rating, so the matcher is not on your roadmap.liquidity figure on the lay side, so you filter on a number instead of estimating one.A row is oddsmatcher-ready when it carries the paired back/lay sides plus the two computed figures an oddsmatcher sorts and filters on. The fields in the sample above are the whole contract:
back: the bookmaker and decimal price you are backing, including bet365 as standard.lay: the exchange, the lay price for the same selection, and the liquidity behind it.rating: how good the qualifying bet is, so rows sort by quality out of the box.qualifying_loss: the small expected cost of placing the qualifier, shown to the user directly.Those four are what a raw feed cannot give you, because they only exist once the back side has been matched to an exchange. The full envelope, with the region and freshness fields, is in the API docs. For a deeper walk through each field and how an oddsmatcher consumes it, see oddsmatcher data, explained.
Yes: the feed covers 60+ UK bookmakers with bet365 included as standard, each matched against three exchanges (Betfair, Smarkets, Matchbook) for the lay price. Coverage matters as much as shape, because an oddsmatcher is only as useful as the books it can pair. Coverage is also built to extend into the domestic South African and Nigerian books that the larger aggregators tend to skip, which matters if your oddsmatcher serves an emerging market.
On freshness, the honest posture is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting well. We do not claim in-play streaming, because that is not what we ship. What is live right now, book by book, is published on the coverage dashboard so the figure is checkable rather than asserted.
Oddsmatcher-ready data is not always the right buy. If your matcher and your exchange integration are your core product and your moat, owning them can be the point, and raw prices are the cheaper input. The honest framing is build versus buy: ready data removes the matcher, the exchange integration and the liquidity model, which is most of the work, so it wins for teams whose product is the oddsmatcher rather than the matching. If you are weighing that build, how to build an oddsmatcher walks through what you take on when you do it yourself.
Oddsmatcher-ready means the matching is done before the data reaches you: each back price paired with the exchange lay price, with rating and qualifying_loss computed, so your oddsmatcher renders rows on day one. Raw data leaves the exchange integration, the matcher and the liquidity model to you. The feed delivers the ready version across 60+ UK books with bet365 included, and it powers a leading UK matched-betting platform today. The quickest way to see the shape is a free trial, or check what is live now 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.
Part of the Matched betting & oddsmatcher cluster
Oddsmatcher data, explained18+ · Data product for licensed operators. Please gamble responsibly.
Matched betting & oddsmatcher
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.
· 6 min read
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
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