Skip to content
OddsRelay

Choosing an odds API: a buyer's guide

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.

James7 min read

Choosing an odds API comes down to five questions, asked in this order: which specific books does it cover, is the data raw or matched, can you verify the reliability, which regions does it reach, and what happens when something breaks. Answer them in order and most of the market rules itself out before you ever compare a data sample. Notice what is missing from that list: the raw number of books. A feed that claims hundreds of bookmakers but skips bet365, or delivers stale prices, is worse than a smaller feed that covers what you actually use and keeps it current.

This is a framework, not a pitch. OddsRelay appears once, near the end, as one option among several. The point of the guide is to give you the questions a vendor would rather you didn't ask.

1. Which specific books does it cover, bet365 included?

Ask for the named list, not the headline count. "600+ bookmakers worldwide" tells you almost nothing if the twelve books your users actually bet with are not on it. The right question is narrow: name the specific books you need, then ask each vendor to confirm each one, by name, at the market depth you need.

For a UK product the sharpest test is bet365. It has no public API, it is widely regarded as the hardest book to cover well, and a vendor's honesty about it is a good proxy for the honesty of everything else. Some aggregators reach bet365; several skip it or carry only match odds. Ask directly: is bet365 included as standard, and at what depth. A vendor that is vague on bet365 will be vague on the books you check less carefully.

2. Is the data raw or already matched?

Raw prices are the back odds a book is showing, as JSON, on some cadence; matched data pairs each back price with the current exchange lay price for the same selection, plus the position between them. This is the fork that rules out whole categories, so decide it early, before you shortlist anyone. Matched betting, arbitrage and any lay-based product run on the second kind. If that is your product, a raw-only vendor is not a cheaper version of what you need; it is a different product that leaves the hardest engineering to you.

The reason the fork is so decisive: building the matched layer yourself means an exchange integration, a matcher, and a liquidity model on top of whatever collection you were already weighing. A matched feed carries fields a raw API structurally cannot give you. Each row pairs the back price with a lay block against Betfair, Smarkets or Matchbook, and adds a rating and a qualifying_loss so your oddsmatcher renders results on day one:

Raw vs matched · the same selection, illustrative shape
// Raw: a price, and nothing to act on
{ "bookmaker": "bet365", "selection": "Arsenal", "odds": 2.10 }

// Matched: the back/lay pair, rated and priced
{
  "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
}

If you are still weighing whether the matched layer is worth licensing at all, that is the buy versus build question, and it deserves its own answer before you compare vendors on anything else.

3. Can you verify the reliability, or only read a promise?

A reliability number you cannot check is marketing. "99.9% uptime" on a sales page is a claim; a live dashboard showing current freshness, uptime and latency is evidence. Prefer the vendor that shows you the second thing. If a supplier will not expose their own reliability, treat the freshness and uptime claims with caution, because the ones who can show you usually do.

Freshness matters more than raw speed, and honesty about it is a buying signal. Be wary of any vendor promising "real-time" odds without qualification. An honest latency posture for a collected feed is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting and pre-match arbitrage well. A vendor claiming sub-second in-play streaming across every book is either doing something you should ask hard questions about, or overstating. What you want is a published, checkable freshness figure, not a superlative.

4. Which regions does it reach?

Match the region map to where your users bet, not to the longest list. A feed strong in UK books may thin out fast in the markets you are expanding into, and the big global aggregators often skip domestic South African and Nigerian books entirely, precisely the ones an emerging-market product depends on. Ask which regions are covered today, which are on the roadmap, and whether you can filter the feed by region so you are not paying to parse books you will never show.

Regions interact with question two. A region with deep exchange liquidity can be delivered matched; a region with no usable exchange can only be delivered raw, no matter what the vendor implies. An honest supplier will tell you where matched coverage stops and raw coverage begins, rather than claiming lay prices for a region that has no exchange to lay against.

5. What happens when something breaks?

You are buying a relationship, not a one-off download, so ask what support looks like on a bad day. When a book's coverage degrades or a market goes stale, who notices first, you or them, and how fast is the fix. A feed is a living thing: bookmaker surfaces change, and a supplier whose whole job is keeping coverage whole will catch drift before you do. A supplier who treats collection as a side project will let you find the gaps in production.

Concrete questions worth asking: is there a status page, a change log, and a named contact; how are breaking changes communicated; and how quickly are new books or markets added when you ask. The answers separate a data vendor from a data partner.

The five questions, side by side

QuestionWeak answerStrong answer
CoverageA big headline countYour named books confirmed, bet365 included, at depth
Raw or matched"You can match it yourself"Back/lay paired, rating and qualifying_loss computed
ReliabilityA promised uptime figureA live dashboard you can open right now
RegionsThe longest possible listThe regions you need, filterable, honest on matched vs raw
SupportA shared inboxA status page, a change log, a named contact
Raw book count is deliberately not a row. It correlates with none of what matters.

Where OddsRelay fits

Against this framework, OddsRelay is one honest option, and it fits best for a specific buyer. If you need a managed matched feed with UK depth, bet365 included as standard, delivered already paired against three exchanges (Betfair, Smarkets and Matchbook), it lines up well. Coverage is 60+ UK books with bet365 included; matched data ships with the rating and qualifying_loss fields done for you; reliability is published on a live dashboard rather than asserted; and regions are expanding beyond the UK. It powers a leading UK matched-betting platform today.

It is not the right answer for everyone. If you need raw prices only, or in-play streaming, or a region OddsRelay does not yet reach, another vendor may fit better, and the framework above will tell you which. If your product is a matched or lay-based UK build, it is worth putting on the shortlist. For the matched-betting angle specifically, see best odds API for matched betting.

How to run the comparison

Take the five questions to every vendor on your list and make them answer in the same order. Coverage and the raw-versus-matched fork will usually cut the list in half on their own. Reliability you can verify cuts it again. Regions and support decide between the finalists. You will end with a short, defensible shortlist instead of a spreadsheet of headline counts.

If OddsRelay makes your shortlist, the honest way to compare it is to open the coverage dashboard and see the books and freshness live, read the field list in the API docs, then take a free trial and check the matched rows against your own product. No number on a sales page beats data you have queried yourself.

Buying vs building

Written by

James

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.