What to look for in a matched-betting feed

An oddsmatcher is only as trustworthy as the feed beneath it. A wrong pair, a stale price, or an offer that cannot be placed teaches users to stop trusting your numbers.

This checklist is specific to matched betting. The general criteria, coverage and update time and support among them, are in how to choose an odds-data provider. Below are the eight checks particular to a matched feed.

The checklist

1. Matched pairs

The first and biggest question. A matched feed returns each offer as a back price with its exchange lay beside it, and the money available at that lay. A raw feed returns prices and expects you to build the matching engine.

For a matched-betting product, buying raw means building and maintaining fixture matching and pairing yourself. That can be right if your edge is in that logic. Most teams want the matched feed.

2. bet365

bet365 is central to matched betting and one of the hardest bookmakers to cover, so it is often missing. A matched-betting feed without it is missing offers and prices users care about.

Confirm it is there today rather than a future promise.

3. No pairs without liquidity

A pair is no use if the exchange has no money behind it. The feed should drop those pairs, so the offers you render can be placed.

The first time someone tries to lay an offer and the money is not there, it is your product they stop trusting.

4. Every offer type

Matched betting is several calculations: Standard, Each-way, Extra place, Best odds guaranteed (BOG), Dutching and 2Up. A feed that only does 'standard' covers a fraction of what your users will want.

You do not need every type on day one, but you want a feed that offers them so you can expand without changing providers. Each type is expensive to build yourself.

• Standard, Each-way, Extra place, Best odds guaranteed, Dutching and 2Up as finished output.
• Selectable per request, from one endpoint.
• The same pair shape across types, so one rating function covers them all.

5. Freshness you can check

Odds move, and an offer has a shelf life. Every response should carry the time its data was processed, with each bookmaker's last-read time, and the provider should publish a page you and your users can load.

Be sceptical of 'real-time' with nothing behind it.

6. Cheap polling

Matched-betting products poll often. ETag and 304 support and gzip mean you refresh as often as you need without re-downloading a reply that has not changed. That is the difference between cheap polling and a runaway bill.

One endpoint per feed type keeps the integration small, too.

7. Mapping kept up to date

Bookmakers change markets constantly, and the failure here is nastier than a missing price: a mismapped market produces a confidently wrong pair your users act on.

Ask how that drift is caught, and whether the mapping is maintained for you so your product stays correct without you chasing every change.

8. A trial on real data

Can you call the real feed before committing? A provider confident in a matched feed will show you which bookmakers are live and let you test on real data.

Building on a feed you have only seen in a demo is a risk you do not need to take.

Related