Buying vs building an odds data layer

A capable team can ship a first version. The question is who keeps it complete once users depend on it.

What building an odds data layer involves

It is five jobs, and only the first one ever feels finished. Teams scope the build as "collect the prices" and meet the other four once users arrive.

• Collection: getting prices out of every book your users expect. For every book, the headline match-odds price is the small part. The deeper markets are where coverage goes partial.
• Event matching: mapping each book's and each exchange's name for a fixture and a selection onto one event, so a price is compared like with like.
• Exchange pairing: pairing each back price with a current exchange lay price, and checking there is enough liquidity on the lay side for the pair to be usable.
• Freshness monitoring: knowing when a price went stale, a market dropped, or a book stopped returning selections.
• Being on call: coverage breaks at inconvenient hours, and someone has to notice and fix it. That is a rota and an escalation path.

Sources change without notice

A pipeline that returned complete markets in January can drift by March, whether or not you have time to follow the sites it reads. Nobody sends a release note. You find out when a user reports a gap, which is the most expensive moment to find out.

The quiet failure costs more than the loud one. A hard break throws an error and someone fixes it. A soft break keeps running: it serves a price the bookmaker withdrew an hour ago, or half a market, and nothing in your logs looks wrong. A user acts on that price, finds it gone, and trusts your product a little less.

That makes collection a standing commitment, and the commitment grows with every book and every exchange you add.

Should you scrape odds yourself?

Scrape bookmaker odds yourself only if collecting odds is the product you sell, or for prices a licensed feed does not carry. OddsRelay has carried in-play prices as well since 2 November 2026, though not from every book, and bet365 and William Hill have none on it. If you already collect pre-match prices, the four signs below show when the upkeep has started to crowd out your product.

Why teams stop scraping odds and buy a feed

Teams stop when the prices have become an input to what users pay for, and the collectors take the time that product needs. Each sign below is checkable in your own team this week:

• Upkeep outweighs features. Count last quarter's engineering hours. If more went to keeping collectors alive than to what users asked for, the collectors are setting your priorities.
• Users find breaks first. A support message about a missing or wrong price means your monitoring runs behind your users.
• A bookmaker request you cannot staff. Users ask for a venue and the answer is "next quarter", because each one is another collector to write and keep alive.
• Prices you cannot date. Someone asks how old a price is, and you cannot say, per venue, at that moment.

Two of these together are enough. For a team selling what it builds on the prices, collection is work every competitor also has to do, so doing it in-house buys no advantage.

What buying gives back

Buying hands the collection, matching, pairing and upkeep to someone whose standing job they are. OddsRelay covers 140+ bookmakers, 60+ of them live in the UK & Ireland, with bet365 for featured football and UK and Irish racing, paired against Betfair, Smarkets and Matchbook. The six matched boards and raw are on every plan, and plans differ only in tokens.

• Time to market: an oddsmatcher or comparison product reads paired prices from its first call, rather than after the months an event matcher and exchange integration take to build.
• No maintenance treadmill: when a source changes, following it is the supplier's job, and your engineers stay on your product.

Some work stays yours. The feed sets each back price beside its exchange lays and leaves out any lay too thin to use. The rating and the qualifying loss are your arithmetic, at your own commission rate, and the oddsmatcher widget shows what that arithmetic produces.

{
  "name": "Arsenal",
  "back": [{ "bookmaker": "william_hill", "price": 2.9, "link": null }],
  "lay":  [{ "exchange": "smarkets", "price": 3.0, "available": 175, "link": null }]
}

// commission is still yours to apply
const rating = (outcome.back[0].price / outcome.lay[0].price) * 100

If you would rather pair prices yourself, the raw product hands you each bookmaker's markets with a per-market last_update, the time that market last changed.

You also write the client. A self-serve key is pull only, so you poll, sending each reply's ETag back as If-None-Match, and a reply that has not changed comes back as a 304 that costs no tokens. The default envelope carries the board's time, so its ETag moves with every new board version. With format=bare it moves only when your events do.

The board's time is in the X-Processed-At header (and meta.processed_at in the default envelope), and the envelope's meta.last_seen gives each venue's last read per sport, so you can check a price's age yourself. Every product on sale meets a maximum update time of 10–20 s for match odds, and for every market within six hours of kick-off. Further from kick-off, prices in the other markets can be older. The freshness guide explains both fields.

Build vs buy, side by side

Effort only, not money.

What drives the cost of a feed breaks down where that effort concentrates, and how to choose an odds data provider covers what to check before you commit to any supplier, and an odds API checklist for matched betting narrows it for an oddsmatcher. The comparison pages set suppliers side by side, with sources. Free tiers, and what they hold back, are in is there a free odds API?. Once you lean towards buying, how to test an odds feed before you buy and switching providers without downtime cover the next steps, and responsible data supply sets out which obligations stay with your product.

A checklist for your own situation

1. Do you need bet365, paired against the exchanges? It is the book users check for first, so it has to be on your list from day one.
2. How many books must you cover? A handful of books is a manageable build. A comparison-sized list, paired against several exchanges, is a standing operation.
3. What does a stale or missing price cost you? If a wrong price breaks your users' trust, you are buying upkeep as much as data.