--- updatedAt: 2026-10-05T19:00:00.000Z agentTools: siteIndex: https://developer.sportradar.com/llms.txt projectIndex: https://developer.sportradar.com/odds/llms.txt --- # Update Frequencies Every response carries a `cache-control: max-age` header: the feed's TTL, meaning how long that payload may be served from cache before a fresh copy is available. A TTL is a **cache floor, not a polling recommendation**: drive your cadence from the change logs and your product's freshness needs, and read the header on the responses you actually receive.
*** ## Frequency Chart The shared discovery feeds (Books, Sports, Sport Competitions) exist in every package and carry the same TTL in each. The recommended-pull column holds recommendations, not limits. | Feed | Package | TTL (cache) | Data updates | Recommended pull | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------- | ----------- | -------------------------------------------------------------------- | -------------------------------------------------------- | | Books | Every package | 5 minutes | On bookmaker configuration changes | Daily | | Category Futures | Futures | 5 minutes | As futures prices move; bookmaker prices refresh every 3 minutes | A few times per day; more often around season milestones | | Competition Futures | Futures | 5 minutes | As futures prices move; bookmaker prices refresh every 3 minutes | A few times per day; more often around season milestones | | Daily Schedules | Prematch | 1 second | As events gain odds for that date | Every hour or less on dates you cover | | Daily Sport Event Schedule | Live Odds | 1 second | As event statuses change | Every few minutes on game days | | Daily Sport Player Props | Player Props | 60 seconds | As props post and move for that date | Every hour or less on dates you cover | | Competition and Player Mappings | Every package | 6 minutes | As entities are added | Daily, cached locally | | Sport Event Mappings | Every package | 6 minutes | Entries appear 14 days before an event, once odds are available | Daily, cached locally | | Player Props Change Log | Player Props | 1 second | Continuously; each response covers a five-minute window | Every 1 to 5 minutes while you track bettable events | | Sport Competitions | Every package | 5 minutes | As competitions gain or lose odds coverage | Daily | | Sport Event Markets | Prematch | 1 second | As bookmaker odds move; bookmaker prices refresh once per minute | When the change log reports the event | | Sport Event Markets | Live Odds | 1 second | Bookmaker prices refresh every 15 seconds while the event is in play | Every 30 seconds for events in play | | Sport Event Markets Change Log | Prematch | 1 second | Continuously; each response covers a five-minute window | Every 1 to 5 minutes while you track bettable events | | Sport Event Player Props | Player Props | 60 seconds | As prop odds move; bookmaker prices refresh once per minute | When the change log reports the event | | Sport Event Player Props | Live Odds | 60 seconds | Bookmaker prices refresh every 15 seconds while the event is in play | Every 60 seconds for events in play | | Sports | Every package | 5 minutes | As sports gain or lose odds coverage | Daily | The Futures package has no change log, so the futures feeds are their own refresh trigger; see [Tracking Futures Odds](https://developer.sportradar.com/odds/docs/oc-ig-tracking-futures). The Live Odds package has none either: poll its event feeds directly during play, as on [Tracking Live Odds](https://developer.sportradar.com/odds/docs/oc-ig-tracking-live-odds). Bookmaker prices refresh into each package on a fixed cycle (the table under Bookmaker Price Refresh by Package below), so a 1-second TTL bounds cache staleness rather than how often prices change.
### TTLs Are Cache Floors A 1-second TTL on Sport Event Markets means the cache will not serve stale data beyond a second, not that you should call every second. The change logs tell you which events moved; re-pull markets only for those, and let each response's own header guide anything you cache.
*** ## Bookmaker Price Refresh by Package Separately from each feed's TTL, bookmaker prices are refreshed into each package on a fixed cycle. Polling a feed faster than its package refreshes returns the same prices, so these cycles are the practical ceiling on freshness: | Package | Bookmaker prices refresh | | ------------ | ------------------------ | | Prematch | Once per minute | | Player Props | Once per minute | | Futures | Every 3 minutes | | Live Odds | Every 15 seconds | The change logs report an event as soon as its prices refresh, so the loop on [Monitoring Odds Changes](https://developer.sportradar.com/odds/docs/oc-ig-monitoring-odds-changes) already runs at the right cadence for Prematch and Player Props. Futures and Live Odds have no change log, so these cycles are the shortest polling interval that can return new prices.
*** ## Reading TTL from Responses Every response states its own TTL: ```http HTTP/1.1 200 OK cache-control: max-age=300, private ``` The value is in seconds (`300` is the 5-minute tier). The header on each response is definitive for that feed, so check it rather than hardcoding the chart's values.
*** ## Cadence and the Change Logs The change logs are the cadence backbone for the Prematch and Player Props packages: poll them every 1 to 5 minutes, re-pull markets or props only for the events they report, and skip every event they do not. The full loop, including how to reconcile after a gap longer than the five-minute window, is on [Monitoring Odds Changes](https://developer.sportradar.com/odds/docs/oc-ig-monitoring-odds-changes).
*** ## Best Practices * Read `cache-control` on every response rather than hardcoding TTLs; values differ by feed * Refresh the discovery feeds (Books, Sports, Sport Competitions) daily rather than alongside odds pulls * Pull the mappings feeds once, cache them locally, and refresh daily; they page at 1000 rows * Let the change logs decide which events to re-pull; a fixed per-event timer wastes most of its calls