Betfair delays data on a delayed application key; live, undelayed prices need a live key that meets Betfair's requirements. Here's what that means for your build, and when it matters.
James··5 min read
Betfair applies a delay to data returned on a delayed-data application key. To get live, undelayed prices you need a live application key, and Betfair grants that against its own requirements. For pre-match matched betting the delay is usually fine. For time-sensitive work it matters. This post explains the distinction, why it exists, and what it means for your build.
Why does the Betfair API return delayed data?
The delay comes from the type of application key you are using, not from a bug in your code. Betfair issues two kinds of application key, and the delayed one is what most developers start with. If your prices look consistently behind what the exchange shows, you are almost certainly reading from a delayed key rather than a live one.
This is a documented, deliberate limitation. Betfair's developer documentation describes the two key types and states that the delayed key returns data on a delay; the live key returns undelayed data. The exact figure is Betfair's to set and can change, so it is safest to treat it as "a delay on the delayed key" rather than to hard-code a number you read in a forum thread.
Delayed application key vs live application key
The two keys differ in one decisive way: whether the data is delayed. Everything else about the request, the endpoints and the response shape is the same. The gate is access, not code.
Delayed application key
Live application key
Data freshness
Returned on a delay
Undelayed
How you get it
Available to developers to start building
Granted by Betfair against its own requirements
Suits
Development, pre-match reads where the delay is tolerable
Time-sensitive and in-play reads
What changes in your code
Nothing
Nothing: same endpoints, same response
The split is publicly documented by Betfair; check its developer docs for the current terms.
Because upgrading is an access question, you cannot engineer your way past a delayed key. Retrying faster, polling harder or caching cleverly does not remove the delay: the data arrived late by design. The only fix is a live key that meets Betfair's conditions.
Does the delay actually matter for what you're building?
It depends entirely on how time-sensitive your use is. For a lot of matched-betting and arbitrage work, the delay is a non-issue; for in-play, it is fatal. Sort your use into one of these before you chase a live key.
Pre-match matched betting: you are pairing a bookmaker back price with a Betfair lay price ahead of kick-off. A short delay rarely changes the qualifying bet, so a delayed key is often workable.
Pre-match arbitrage: tighter than matched betting, because arbs move faster, but still workable pre-match if your cycle is quick and your prices are consistent.
In-play: prices move second to second, so a delayed key is unusable. This is the case that genuinely needs a live key.
If your product is pre-match, the delay is likely a smaller problem than the one next to it: getting the lay price paired to the right back price, with enough liquidity behind it to be real. We cover that in how to get Betfair lay odds.
The delay is only part of the exchange-integration cost
Even with a live key, Betfair alone is not the whole job. Matched betting and arbitrage compare a back price against the best available lay price, and the best lay is not always on Betfair. Some events sit tighter on Smarkets or Matchbook. Reading one exchange means you occasionally lay at a worse price than you could have.
So the real integration is three exchanges, not one: the Betfair API with its key rules, plus Smarkets and Matchbook, each with their own auth and response shapes. Then you have to pair each lay price to the correct bookmaker back price, hold a liquidity figure so the lay is genuinely fillable, and keep all of it fresh. The delayed key is the first wall you hit, not the last.
How a managed feed handles this for you
A managed feed consolidates the exchanges and does the pairing before you receive the data, so the delayed-key question never lands on your desk. Instead of holding three exchange integrations, you make one authenticated call and get back rows that already carry the matched back and lay prices, with a rating and a qualifying_loss computed.
OddsRelay delivers exactly that: 60+ UK books with bet365 included, matched against three exchanges (Betfair, Smarkets, Matchbook) for the lay side, as one clean API. Each row pairs a bookmaker back price with the best exchange lay price and the liquidity behind it, so your oddsmatcher renders on day one instead of after you have wrestled with three exchange keys. Read more on the shape of that in exchange and lay coverage, and on why the liquidity figure matters as much as the price in why lay liquidity matters.
How fresh is the feed?
Our honest posture is pre-match polling on roughly a few-second cycle. That suits pre-match matched betting and pre-match arbitrage, which is where the durable value sits. We do not claim sub-second in-play streaming, because that is not what we ship: if you need genuine in-play, a live Betfair key on your own integration is the right tool. For pre-match work, the feed removes the delayed-key problem along with the rest of the exchange plumbing.
The short answer
The Betfair API delays data on a delayed application key; a live key returns undelayed data and is granted against Betfair's own requirements. For pre-match matched betting the delay is usually tolerable, and the harder problem is pairing lay prices across three exchanges with real liquidity. A managed feed removes both. You can see the matched coverage live on the coverage dashboard, and put the feed through your own build with a free trial. It powers a leading UK matched-betting platform today.
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.