How to choose an odds-data provider

The differences show up after you integrate: a major bookmaker is missing, two bookmakers' markets do not line up, or 'real-time' turns out to mean five minutes old.

Weight them for your product. A comparison site cares most about coverage and schema. A matched-betting product first needs to know whether the feed is matched at all.

The checklist

Raw or matched

Two very different products are sold under the same label. A raw feed gives you normalised bookmaker prices and leaves the analysis to you. A matched feed does the pairing for you and drops pairs with no money on the exchange, so you get back and lay prices side by side, ready for your tool to rate.

Getting this wrong costs the most. Need matched-betting output but buy raw, and you have signed up to build a matching engine. Need only prices but buy matched, and you pay for analysis you throw away. Decide which you need first.

Coverage, by name

A headline bookmaker count tells you little. Check that the bookmakers your users compare are there by name.

bet365 is the one to check first. Matched bettors and comparison users expect it, and it is one of the hardest bookmakers to cover.

• The bookmakers your product needs, listed by name
• bet365, live today
• A public page showing which bookmakers are live now

Update times you can check

'Real-time' is a marketing word. What you need is something your code can read: does every response carry the time its data was processed, and can you see when each bookmaker was last read?

Ask for both, and be wary of a provider that offers neither. A published refresh rate says what a feed means to do. A time on the response says what it did.

One schema for every bookmaker

Coverage is no use if two bookmakers' prices cannot be lined up. The feed should map every bookmaker and market to one event and selection model, so comparing prices is a lookup rather than a reconciliation project.

Ask to see a real response and the OpenAPI spec. If each bookmaker comes back in its own shape, the normalising becomes your job.

Cheap polling

How the bytes reach you matters once you are polling at production volumes. ETag and 304 support let you poll without re-downloading a reply that has not changed, gzip shrinks the payload, and one endpoint per feed type keeps your integration small.

Without them you choose between fresh prices and a smaller bill.

Reliability you can see

Your product is down when the feed is. Look for a public page that shows which bookmakers are live and when each was last read, rather than an uptime figure in a sales deck.

Then test it yourself: call the real feed on your own key before you commit.

Who fixes a broken mapping

When a bookmaker changes a market mid-fixture and a mapping breaks, the question is who fixes it and how fast: the people who run the feed, or a first-line queue. That failure mode is specific to odds data.

Ask how quickly a broken mapping is fixed, and by whom. A small provider can often answer from the people who run the feed.

Terms and scope

Check that keys can be scoped and revoked, that you can add regions or feed types without a new contract, and that you can test on real data first.

Be wary of a provider that will only show you a demo dataset.

From the blog

Related