Update Frequencies

The Formula 1 API is poll-based: all data, including live timing, is retrieved by polling the REST feeds. This page explains how to poll efficiently: read each response's cache TTL, key your cadence off the stage status, and avoid polling finalized stages.

🛠️
Recommended Pull Rates Are Guidance
The TTL (cache) values in the table come from the cache-control header each feed returns. The Recommended pull columns are general guidance: tune them to your product's needs and the stage status, and always respect the live cache-control TTL on each response.

How to Find a Feed's TTL

Every response returns a cache-control header giving the cache lifetime in seconds. Poll no faster than the max-age value; polling faster returns the same cached payload and wastes quota.

cache-control: max-age=1, public

The TTL varies by feed:

Stage Summary returns max-age=1 regardless of whether the stage is live or closed, so lap-by-lap changes surface within a second.
All other feeds (Seasons, Stage Schedule, Stage Probabilities, Competitor Profile, Team Profile, Deleted Stages, and Competitor Merge Mappings) return max-age=300 (5 minutes).

Read the cache-control header on each call rather than hardcoding an interval.

Cadence Is Driven by Stage Status

Because everything is a stage, the right polling rate follows the stage status (see Race Status Workflow):

Not started: poll the schedule occasionally to catch time or status changes.
Running: poll at the live TTL (about every second) for lap-by-lap updates.
Finished / Completed: poll occasionally; results are still being validated.
Closed: stop high-frequency polling and cache; the data is final.

Live Coverage

Race sessions update in real time on a lap-by-lap basis. Beginning with the 2025 season, qualifying and practice sessions also update in real time, lap by lap. During these sessions the lap-level Stage Summary and the parent session summary refresh at the short live TTL.

Update Frequencies by Endpoint

The TTL (cache) column shows each feed's cache lifetime, taken from the cache-control header. The Data updates column describes when each feed changes. The Recommended pull columns give general guidance for non-live and live conditions.

Feed	TTL (cache)	Data updates	Recommended pull (non-live)	Recommended pull (live)
Stage Summary (live session / lap)	1 second	Real-time, lap-by-lap while a session is `Running`	Pull once for the final classification; cache `Closed` sessions	As fast as about 1 second (the TTL) while `Running`
Stage Summary (season / standings)	1 second	After each race; during post-race validation	After results post (for example, daily)	After each race finishes; hourly on race day
Seasons	5 minutes	Once per season; rare corrections	Daily or on app start	Not applicable
Stage Schedule	5 minutes	When the calendar or session times change	Daily	Hourly on an event weekend
Stage Probabilities	5 minutes	Leading up to and during an event	Per the response TTL when relevant	Per the response TTL during the event
Competitor Profile	5 minutes	Rarely (career milestones)	Weekly	Not applicable
Team Profile	5 minutes	Per season (car details); rarely otherwise	Weekly; re-pull at season start	Not applicable
Deleted Stages	5 minutes	When a stage is removed	Daily	Not applicable
Competitor Merge Mappings	5 minutes	When competitors merge (retained one week)	Daily	Not applicable

⚠️
TTL Is Not a Recommended Pull Rate
A short cache-control TTL means data could change that often, not that you must poll that often. Outside live sessions, poll on the cadence your product needs (the right column above), not on the raw TTL.

Best Practices

Respect the cache-control TTL on every response; never poll faster than max-age.
Drive cadence off stage status: fast only while Running, slow once Closed.
Prefer the lap-level stage for live timing; it carries the running order at the short live TTL.
On 429 Too Many Requests, pause and retry, increasing the wait after each repeat. See API Basics.
Use Monitoring Data Changes to refresh stored data only when something actually changed.