Live vs pre-match odds data: what's realistic

Pre-match odds data and live in-play odds data are two different problems, and you should decide which you need before you shop. Pre-match data is the prices before an event starts; live data is the prices while it runs. In-play needs sub-second streaming and is far harder to deliver reliably. Pre-match on a few-second cadence is well-suited to matched betting and arbitrage, which is where most of the durable value sits. This post separates the two so you don't pay for a capability you won't use.

What's the difference between live and pre-match odds data?

Pre-match data covers the window before kick-off; live in-play data covers the window during play. They sound like the same feed at two speeds, but they are different engineering problems with different failure modes.

Pre-match prices move on the timescale of minutes and hours. A poll every few seconds catches every meaningful change, and the data stays stable long enough to match a bookmaker back price against an exchange lay price cleanly. In-play prices move on the timescale of seconds or less. A goal, a red card, a break of serve, and every price on the market re-prices at once. To be useful in-play, data has to arrive as a stream, not a poll, and it has to keep arriving without gaps at exactly the moment volume spikes.

Why is live in-play data so much harder to deliver?

In-play is harder because it stresses three things at once: volume, speed, and reliability under load. Each is manageable alone. Together, at the exact moment a match gets interesting, they compound.

• Volume: an in-play market re-prices continuously across every selection, so the data rate is orders of magnitude higher than the same market pre-match.
• Speed: a price is only useful in-play if it reaches you before it moves again, which means sub-second delivery, not a polling loop you can tune later. See polling efficiently for why polling and streaming are different disciplines.
• Reliability under load: the moments you most need the feed are the moments everyone else does too. A stream that drops for two seconds after a goal has failed precisely when it mattered.

This is also where matching gets fragile. Pairing a bookmaker back price with an exchange lay price for the same selection assumes both sides are stable for long enough to compare. In-play, both sides move mid-comparison, and exchange liquidity thins out exactly when prices swing. A matched in-play signal can be stale by the time it renders. That is a real product, but it is a harder and more specialised one than pre-match, and it is not what most teams reaching for odds data need.

Where does the matched-betting and arbitrage value actually sit?

For matched betting and most arbitrage, the value is overwhelmingly pre-match. The qualifying bet, the free-bet extraction, the pre-match arb: these are opportunities you find, weigh, and place before the event starts. They do not require sub-second data. They require accurate, complete, well-matched prices on a steady cadence, across enough books to find the pair.

That is a coverage-and-matching problem, not a speed problem. What makes a pre-match feed good is breadth (60+ UK books with bet365 included), a real lay side (each back price paired against three exchanges: Betfair, Smarkets and Matchbook), and the matching already done, so each row carries a rating and a qualifying_loss you can act on. A feed that streamed in-play prices but covered fewer books, or skipped the exchange lay side, would be worse for matched betting, not better. Speed is the wrong axis to optimise here.

What is OddsRelay's honest position on speed?

We ship pre-match polling on roughly a few-second cycle, and we do not ship in-play streaming. We say so plainly rather than stretching the word "live" to cover a poll. That cadence catches every meaningful pre-match move and suits pre-match matched betting and pre-match arbitrage well, which is the value we can deliver reliably today.

We would rather be honest about the boundary than sell a sub-second claim we can't stand behind under load. If a vendor promises "real-time" in-play odds without showing you freshness and uptime at peak, treat the claim with caution. Ours is published on the coverage dashboard so it is checkable, and the freshness fields travel in every response so you can see how recent each price is: read the response envelope for where they sit.

How do I tell which one my product needs?

Work backwards from where the money is placed. If your users act before the event starts, you need pre-match, and paying for in-play is paying for a capability you won't use. If your users act during the event and can't wait, you need in-play streaming, and a pre-match feed won't serve them.

• Pre-match is enough for an oddsmatcher, a matched-betting scanner, a pre-match arbitrage tool, or an odds-comparison page. The prices you compare are the ones showing before kick-off.
• You need in-play for live trading, in-play hedging, or any tool whose whole promise is reacting to a score change as it happens.
• When in doubt, it's pre-match. Most products that think they want in-play actually want reliable pre-match coverage across more books. Reach for in-play only when a delay of a few seconds genuinely breaks the use case.

The risk runs one way. Paying for live streaming you won't use costs you money for complexity you then have to integrate and monitor, all to serve a workflow that never touches it. Under-buying is easy to fix later; over-buying quietly taxes every release. If you're still mapping the basics, what an odds API is sets the vocabulary this decision rests on.

The short answer

Pre-match and in-play are different products. In-play is genuinely hard, and most matched-betting and arbitrage value is pre-match, so decide which you need before you buy. OddsRelay ships pre-match polling on roughly a few-second cycle, 60+ UK books with bet365 included, matched against three exchanges, and it powers a leading UK matched-betting platform today. If that fits your product, the fastest way to judge the fit is to see it live: check the coverage dashboard or start a free trial.