Engineer Live Odds Feeds, 400–800ms Latency and 1,000+ Event Bursts

Pre-match odds typically shift over longer intervals, with update frequency increasing as kick-off approaches, and prices moving very rapidly once a match goes live. For anything in-play, use a WebSocket or SSE push feed rather than polling. Drive your logic with two fields: bookmakerChangedAt for reconstructing true market history, and changedAt for real-time alerting.

TL;DR:

• Polling is suitable for pre-match discovery and dashboard updates, but it can waste resources on unchanged data and miss rapid market moves.
• In-play odds updates happen every 40 to 60 seconds for top leagues, with push streams offering sub-second delivery for real-time market tracking.
• Setting polling intervals according to market state, such as 30-60 seconds pre-match and 2-5 seconds near kick-off, optimizes accuracy and rate limit usage.
• Median live feed latency typically ranges from 400 to 800 milliseconds, with bursts during major events requiring proper backpressure management and instrumentation.
• Raffle markets update every ten minutes, reflecting lower volatility and allowing a trade-off between accuracy and infrastructure cost.

Table of Contents

• How odds update across market states: pre-match, near start and in-play
• REST polling vs WebSocket and SSE: which delivery method fits?
• What polling interval and rate limits should you actually use?
• What latency and burst capacity should you plan for?
• Reference cadence table for common market types
• Why raffles and prize competitions run on slower cadences
• Author checklist: quick rules for wiring an odds feed
• See live odds refreshed the smart way
• Sources

How odds update across market states: pre-match, near start and in-play

Update frequency tracks liquidity, not the clock. A quiet mid-table fixture three days out might not reprice for hours; a televised derby with heavy trading volume can move a dozen times before you refresh your browser tab. This is the core mechanic developers building against live sports feeds tend to underestimate: the market decides the cadence, and the API simply reports it.

Rough cadence bands to plan around:

• Pre-match, days out: minutes to hours between moves, driven mainly by team news and market-maker positioning.
• Final hour before start: seconds to minutes, as lineup confirmations and late money push prices.
• In-play: sub-second to a few seconds during active phases of play.

The Odds API’s published interval data shows featured markets refreshing roughly every 60 seconds pre-match and every 40 seconds in-play, while betting exchanges, which reprice on order-book pressure rather than bookmaker discretion, often move faster still. Futures markets sit at the opposite end, sometimes static for days between line moves. Providers also apply priority bands, giving top-tier leagues and marquee fixtures tighter polling windows than lower-tier or niche markets, so two events kicking off at the same time can carry very different refresh guarantees.

REST polling vs WebSocket and SSE: which delivery method fits?

Polling means your client asks “anything new?” on a schedule; push means the server tells you the moment something changes. The choice is really about how much staleness you can tolerate.

Polling is straightforward to build and easy to cache, and it remains perfectly adequate for pre-match browsing, dashboards, or backtesting pipelines where a delay of thirty seconds costs nothing. Its weakness is waste: most polling requests return unchanged data, which burns rate limit budget for no benefit and can still miss a rapid double move between requests.

Push streams (WebSocket or SSE) flip that model. The connection stays open, and the provider emits an event only when a price genuinely moves, which is how professional feeds hit sub-second delivery for fast-moving books. Providers like ParlayGeeks build sport-scoped subscriptions and per-book latency metrics into their streams, letting clients discard or downweight stale quotes automatically.

• Use polling for pre-match discovery, catalogue sync and backtesting.
• Use push for live in-play, arbitrage, or any UI claiming “real-time” odds.
• A hybrid pattern works well: pull a REST snapshot on connect, then resume via stream for live updates, so you never start from an empty state.

Pro Tip: Never rely on connection uptime alone to prove your feed is current. Track the provider’s heartbeat or resync marker and reload the full snapshot after any gap, otherwise you’ll silently drift out of sync with the real market.

What polling interval and rate limits should you actually use?

Matching your poll interval to the market state saves both money and accuracy. Too slow, and you miss line moves; too fast, and you burn through rate limits fetching identical data.

1. Pre-match, more than six hours out: poll every 30 to 60 seconds. Nothing moves fast enough to justify tighter polling.
2. Final hour before kick-off: tighten to every 2 to 5 seconds, since this is where team news and sharp money concentrate.
3. Live, only if push isn’t available: 1 to 2 second polling as a last resort, accepting that you’ll still lag genuine push delivery.

Always compare the changedAt timestamp before processing a response. If it hasn’t moved since your last call, discard the payload rather than reprocessing it. Conditional requests and short TTL caching cut redundant load further, and exponential backoff protects you when a provider starts throttling. Sportmonks documents a fixed 10-second update window on its standard feed and recommends polling at that exact interval, which is a useful sanity check: polling faster than a provider’s own refresh window achieves nothing except a wasted quota.

Pro Tip: Ask every provider for their documented update window before writing your polling loop. Polling faster than the source refreshes is the single most common way teams burn through rate limits for zero gain.

What latency and burst capacity should you plan for?

Median refresh on professional feeds runs 400 to 800 milliseconds for live in-play markets, tight enough for arbitrage but comfortably fast for most UI refresh needs too. The harder planning problem is bursts: normal in-play windows generate roughly 100 to 500 price-change events per second, spiking past 1,000 per second during major scoring plays, according to Polynode’s WebSocket documentation. Pre-filter by sport or market before ingestion, batch writes, and apply backpressure rather than letting a queue grow unbounded.

Pro Tip: Instrument per-source freshness and heartbeat gaps as a first-class metric, not an afterthought. A feed that silently stalls for ninety seconds during a goal is far more damaging than one that’s simply slow.

Reference cadence table for common market types

Different market types warrant different refresh expectations, and building this into your config up front saves a lot of reactive firefighting later.

A useful mental model is the six-hour ramp: cadence tightens progressively as kick-off approaches, so a request six hours out and a request six minutes out against the same endpoint can behave completely differently. Always check the as_of timestamp against your API’s documented TTL before trusting a value as current.

Why raffles and prize competitions run on slower cadences

Not every real-time system needs sub-second precision. Raffle Genius refreshes odds and prize data every ten minutes, a deliberate trade-off rather than a limitation. Raffle markets don’t reprice on live events the way sports books do; ticket counts change as people enter, not as a match unfolds, so volatility is measured in hours, not milliseconds.

A ten-minute cadence keeps undersold competitions genuinely current for browsing and comparison without the infrastructure cost of a streaming pipeline. If you’re building something similar, map your own market’s real volatility to the cadence, rather than defaulting to “as fast as possible” out of habit.

Author checklist: quick rules for wiring an odds feed

Choose push for anything live. Deduplicate every event by changedAt, never by arrival order. Provision for bursts before you need them, not after a queue overflows. Instrument per-book freshness from day one.

Do: reload the full snapshot after any resync. Do: cache aggressively pre-match. Don’t: poll faster than a provider’s documented refresh window. Don’t: trust uptime as a proxy for data freshness.

— matt

See live odds refreshed the smart way

Some raffle platforms offer a refresh rate matched to how the market actually moves, rather than an arbitrary speed chosen to look impressive. Odds and prize data update every ten minutes, frequently enough to catch genuinely undersold competitions before the crowd does, without the noise of a market that doesn’t need millisecond precision.

If you want to see that cadence in action, browse live listings on the Raffle Genius comparison page, or try the free Play to Win game to earn entries while you’re at it. Running a raffle yourself? You can list your competition and get it in front of players who are already comparing odds properly.

Sources

• Sports Betting API — Betstamp
• How Often Do Odds APIs Update? Polling vs WebSockets in Python | OddsPapi Blog
• Odds API Update Intervals — The Odds API
• GET Last Updated Odds — Sportmonks API docs

Recommended

• Undersold Competitions
• Best odds this week: five UK competitions worth a look
• How to spot an undersold competition before it closes
• Trusted Operators