There is no verified, independent benchmark that ranks consumer-facing sportsbooks by API refresh rate or latency. Operators do not publish these figures for their retail apps, and the data-feed providers behind them disclose speed claims inconsistently — some give exact numbers, most give marketing language like “low-latency” with no figure attached. What can be documented is the architecture of the pipeline itself, the handful of numbers providers have put on the record, and a UK regulatory requirement that sportsbooks must disclose when bettors are at an information-lag disadvantage.
Key takeaways
- No regulator, provider or academic source publishes a per-sportsbook latency or API refresh-rate ranking for retail betting apps; claims to the contrary are not independently verifiable.
- In-play betting made up 37% of sports betting gross gaming revenue among EGBA member operators in 2025, versus 63% for pre-match — the segment where latency differences matter most.
- Data providers disclose wildly different numbers for different products: Sportradar’s media-facing Odds Comparison API refreshes every 15–30 seconds, while Genius Sports describes its Football DataCo feed as distributing “low latency” data to sportsbooks in under a second.
- The UK Gambling Commission’s RTS 15 standard requires operators to disclose information-lag disadvantages on in-play betting pages, rather than mandating a specific speed.
- Because no public benchmark exists, GamblScout’s algorithm tracks observable proxies — market suspension duration, bet acceptance behavior, and cash-out delay — instead of claiming to measure raw API latency.
Table of contents
The measurement problem with “fastest sportsbook” claims
A working title asking which in-play platform wins on “API refresh rates and latency” assumes a dataset that does not exist in public form. Sportsbooks do not publish their internal trading-engine latency, and third-party testing of retail apps produces inconsistent, non-reproducible numbers because odds update speed varies by sport, market type, time of day, and server load. What is measurable and sourced is the data-supply layer that feeds those engines — and even there, the numbers providers publish describe different products aimed at different customers (media partners versus sportsbook trading desks), which is why they look contradictory at first glance.
This matters because of scale.
Sports betting GGR rose 49% to €8.2bn in 2025 while in-play betting accounted for 37% of that sports revenue, with pre-match wagers generating the remaining 63%
. A market that size, growing that fast, with more than a third of its revenue tied to events that change odds mid-play, is exactly the kind of topic where unverified “fastest platform” claims circulate freely. Our position is that a claim should be rephrased rather than invented when the underlying evidence doesn’t support it — so this article explains what is actually documented about in-play data speed, rather than fabricating an operator league table.
From venue to bet slip: the real pipeline
In-play pricing involves at least four latency-adding stages: event capture at the venue, transmission to a data provider, recalculation by the sportsbook’s own pricing engine, and delivery to the customer’s device. Academic researchers studying in-play markets describe why this chain matters:
unlike pre-match odds, which are relatively stable and mainly respond to injuries or line-up changes, in-play betting is highly dynamic, with odds and stakes continuously responding to evolving match events such as goals, red cards, or momentum shifts
. Every stage in the pipeline adds delay before that dynamic information reaches a bettor’s screen.
A US patent filing on play-by-play wagering systems makes the stakes concrete for the fastest in-play format, micro-betting (a category covered in our micro-betting leaders analysis):
latency between the bettor and the offeror of the bet is a significant factor, and when a wagering market is only open for a matter of seconds, even latency measured in milliseconds can affect bettor experience
. The same filing flags a subtler problem:
latency for different types of data may cause multiple data streams to be out of sync
, meaning the video feed and the odds feed can drift apart even when each is individually fast.
Video-delivery latency illustrates how much this varies by sport. A Dolby case study on streaming infrastructure for betting notes that
for fast-paced, short-duration events like horse racing, ultra-low latency is critical, with an ideal target of under 500 milliseconds
, and that
one horse racing betting provider using Dolby’s streaming technology reduced latency from 12 seconds to just 500 milliseconds
. That gap — twelve seconds versus half a second — shows how far a single pipeline can move with investment, and why pari-mutuel formats covered in our horse racing payout analysis have different technical demands than a football match with a 90-minute window.
What data providers actually disclose
The two dominant official data suppliers to sportsbooks, Sportradar and Genius Sports, publish different figures for different products, and neither discloses a universal number that applies to every operator using their feeds. The table below collects only numbers that are documented on the record.
| Provider / product | Audience | Disclosed figure | Source type |
|---|---|---|---|
| Sportradar — Odds Comparison Live Odds API | Media partners, content platforms | Market updates every 15–30 seconds | Official marketplace listing |
| Sportradar — Books reference endpoint | Operators integrating bookmaker metadata | 5-minute cache, updated on bookmaker configuration changes | Official developer documentation |
| Genius Sports — Football DataCo feed | Regulated sportsbooks (football) | Low-latency official data distributed from over 4,000 UK fixtures per season to hundreds of regulated sportsbooks worldwide | Official company press release |
| Genius Sports — Data and Odds APIs (general) | Sportsbook trading desks |
Official, real-time data and low-latency odds across hundreds of global competitions — no numeric figure disclosed |
Official product page |
| Genius Sports — NFL “Watch and Bet” | US sportsbooks, NFL rights holder |
A low-latency live game video feed used for live in-game betting — no numeric figure disclosed |
Sports news report on official partnership |
Notice the pattern: the only hard number in that table — 15 to 30 seconds — belongs to a product explicitly built for media and content platforms, not for a sportsbook’s own live trading engine. Everything aimed at trading desks is described in qualitative terms (“low-latency,” “real-time”) without a published figure. That asymmetry is itself informative: it suggests the commercially sensitive number — how fast an operator’s own pricing engine reprices a market after a goal — is treated as proprietary, which is consistent with why no credible public ranking of sportsbooks by that metric exists.
Why architecture matters more than marketing copy
Within the limits of what’s disclosed, the more useful technical distinction isn’t a millisecond figure but the delivery architecture: whether a feed is pushed to the consumer (via streaming protocols) or has to be polled on a fixed interval. A polled feed is capped by its polling interval no matter how fast the underlying data changes — if a provider’s comparison API refreshes every 15–30 seconds, as Sportradar’s does for that product, no amount of downstream optimization recovers the seconds lost in that cycle. A pushed feed, by contrast, can in principle deliver a change the moment it’s published, which is why Genius Sports frames its Football DataCo and NFL partnerships around continuous, event-driven delivery rather than a refresh schedule.
This architectural split explains a real, documented trading problem rather than a hypothetical one. The patent filing on play-by-play wagering cited above exists specifically because
asynchronous delivery of data could cause betting markets to open before the video data shows the end of the last play, which could distract bettors or spoil the result of the current play
— a direct consequence of mismatched refresh cadences between a video stream and an odds stream sourced from different pipelines. It’s a structural reason why faster isn’t automatically better if the components of a platform aren’t synchronized to each other.
The regulatory angle on information lag
Rather than mandating a specific latency threshold, UK regulation addresses the consequence of latency directly: the risk that a bettor places a wager on information that’s already outdated. The Gambling Commission’s remote technical standards include a dedicated in-play betting rule, RTS 15, whose stated aim is to
make customers aware of information-lag disadvantages when betting on delayed broadcasts
. The implementation guidance specifies that
brief information should be included on main in-play pages or screens, such as the in-play home page or screen
, and comparable disclosure obligations apply to telephone betting products as well.
This is a meaningful regulatory choice: rather than setting a numeric latency floor that would be difficult to audit across hundreds of operators and sports, the UK regulator requires operators to tell customers that a lag exists, particularly when a bettor is watching a delayed TV or stream feed while the operator’s pricing engine may be working from a faster official data source. It’s the closest thing to an official acknowledgment that latency differences between bettors — and between platforms — are real enough to warrant a disclosure rule, even without a published benchmark for how large those differences are.
What this means for bettors
For bettors who prioritize speed — the audience covered in our analysis of sites built for high-frequency betting — the practical takeaway is to treat vendor claims of “real-time” or “low-latency” as directional rather than comparable across operators, since the underlying figures are rarely disclosed on equal terms. The more reliable signals a bettor can observe directly are indirect: how long a market stays suspended after a goal or point, how often in-play bets get rejected for “odds changed,” and how quickly a cash-out offer updates during a fast-moving sequence. None of these are a substitute for a true latency figure, but they are observable without needing access to a sportsbook’s internal infrastructure — unlike the raw API refresh rate itself.
It’s also worth separating “fast data” from “good pricing.” Our analysis of live odds across 10,000 bets looks at pricing outcomes directly rather than inferring them from infrastructure claims, which is a more defensible way to compare operators than relying on unverified speed marketing.
Frequently asked questions
What does “API refresh rate” mean for a sportsbook?
It refers to how often a data feed updates the prices, scores, or event data that a sportsbook’s trading engine consumes. Push-based feeds update the instant new data is published; polled feeds are limited to a fixed interval, such as the 15–30 second cycle Sportradar discloses for its media-facing odds comparison product.
Why isn’t there a verified ranking of sportsbooks by latency?
Operators don’t publish internal trading-engine latency, and the data providers behind them disclose figures inconsistently — some products get exact numbers, others only qualitative claims like “low-latency.” Without comparable, audited figures across operators, any ranking would be inferred rather than measured.
What’s the fastest documented speed for in-play sports data?
The fastest figures on record are sub-second claims from official rights-holder feeds, such as Genius Sports’ distribution of low-latency Football DataCo data to sportsbooks, and a Dolby case study showing horse racing stream latency reduced to 500 milliseconds. Neither figure applies universally to all sportsbooks using those pipelines.
Does faster data always mean a better betting experience?
Not necessarily. A patent filing on play-by-play wagering systems describes how mismatched latency between a video stream and an odds stream can cause betting markets to open before a play has actually finished on screen, creating confusion rather than an advantage — speed has to be synchronized across data types to help bettors.
Do regulators set latency standards for in-play betting?
The UK Gambling Commission’s RTS 15 standard doesn’t set a numeric latency threshold. Instead it requires operators to disclose information-lag disadvantages, particularly for delayed broadcasts, on their main in-play betting pages.
Methodology
Because no audited, per-operator API latency dataset exists publicly, GamblScout’s algorithm does not score sportsbooks on a fabricated latency metric. Instead, our data-scraping engine logs observable proxies — in-play market suspension duration around scoring events, bet-rejection frequency, and cash-out update speed — and these proxies feed into the broader in-play component of our scoring system and algorithmic weights. Where a claim can’t be independently verified against a primary source, we report the absence of evidence rather than present estimates as fact.
Gambling involves risk. Only play with money you can afford to lose and use the deposit limits and self-exclusion tools available in your jurisdiction.
