Monitoring Data Changes
The Formula 1 API is poll-based, so you keep stored data current by polling. This page covers the feeds that report removals and merges, and how to re-poll the schedule and summaries to catch status and timing changes.
Relevant Feeds
| Feed | Detects |
|---|---|
| Deleted Stages | Stages (events or sessions) removed from a season |
| Competitor Merge Mappings | Competitor records merged into one |
| Stage Schedule / Stage Summary | Status, timing, and result changes (via re-poll) |
High-Level Workflow
Poll the change feeds on a schedule → reconcile each result against your store → re-poll the schedule and summaries for everything else
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8EAF6", "primaryTextColor": "#1A237E", "primaryBorderColor": "#7986CB", "lineColor": "#7986CB", "textColor": "#3949AB", "edgeLabelBackground": "#FFFFFF"}}}%%
flowchart TD
P1["Deleted Stages<br/>(daily, per season)"] -->|"entry returned"| A1["Prune the stored stage"]
P2["Competitor Merge Mappings<br/>(daily)"] -->|"mapping returned"| A2["Repoint the stored competitor ID<br/>(within the one-week window)"]
P3["Stage Schedule / Stage Summary<br/>(re-poll per Update Frequencies)"] --> D{"Compare with stored data"}
D -->|"status: Cancelled"| A3["Keep the stage; hide or flag it"]
D -->|"time, status, or result changed"| A4["Update the stored record"]
A1 --> S[("Your stored data")]
A2 --> S
A3 --> S
A4 --> S
classDef feed fill:#1A237E,stroke:#070D44,color:#FFFFFF
classDef action fill:#E8EAF6,stroke:#7986CB,color:#1A237E
classDef destructive fill:#FFCFCF,stroke:#FF0000,color:#B71C1C
classDef decision fill:#FFFFFF,stroke:#2962FF,stroke-width:2px,color:#1A237E
classDef store fill:#070D44,stroke:#070D44,color:#FFFFFF
class P1,P2,P3 feed
class A2,A3,A4 action
class A1 destructive
class D decision
class S store
linkStyle 0,5 stroke:#FF0000,stroke-width:2px
The three paths are independent: the two change feeds report removals and merges directly, and everything else is caught by comparing a re-polled response against what you have stored. Each is covered in a section below.
1. Detect Removed Stages
Call Deleted Stages with a season stage ID to get the stages removed from that season. Use it to prune events or sessions you have stored that no longer exist upstream.
GET https://api.sportradar.com/formula1/trial/v2/en/seasons/sr:stage:1189123/deleted_stages.json
x-api-key: YOUR_API_KEY{
"generated_at": "2026-06-13T13:04:18+00:00",
"schema": "https://schemas.sportradar.com/sportsapi/formula1/v2/schemas/deleted_stages.json",
"stages": []
}An empty stages array (above) means nothing was deleted from the season. When populated, each entry identifies a removed stage by its sr:stage: ID so you can delete the matching record.
Deleted vs CancelledA deleted stage is removed from the data set and reported by Deleted Stages. A cancelled stage still exists but will not be run; it stays in the schedule with
status: "Cancelled". Handle both: prune deletions, and hide or flag cancellations. See Race Status Workflow.
2. Detect Merged Competitors
Call Competitor Merge Mappings to find competitor records that have been merged. When two records are found to be the same entity, one ID is retained and the other is mapped to it. Entries are retained for one week, so poll regularly if you persist sr:competitor: IDs.
GET https://api.sportradar.com/formula1/trial/v2/en/competitors/merge_mappings.json
x-api-key: YOUR_API_KEY{
"generated_at": "2026-06-13T13:04:20+00:00",
"schema": "https://schemas.sportradar.com/sportsapi/formula1/v2/schemas/competitor_merge_mappings.json",
"mappings": []
}When populated, each mapping carries the merged (retired) ID, the retained ID, and the name, so you can repoint stored references before the entry ages out of the one-week window. See ID Handling.
3. Detect Status and Timing Changes by Re-polling
Schedule, status, and result changes surface in the feeds themselves; catch them by re-requesting and comparing against what you have stored:
- Re-poll Stage Schedule to catch new
scheduledtimes andstatustransitions (for example an event moving toCancelled). - Re-poll Stage Summary for the season to catch standings updates after a race, and for a session to catch live and post-race result changes.
- Use the
generated_attimestamp and thecache-controlTTL on each response to decide when a re-poll is worthwhile.
Polling Is the ModelChange detection is poll-based. Drive your poll cadence off stage
statusand the response TTL so you refresh often during live sessions and rarely otherwise. See Update Frequencies.
Best Practices
- Poll Deleted Stages and Competitor Merge Mappings on a daily cadence; reconcile your stored stage and competitor IDs against them.
- Reconcile merged competitor IDs before the one-week retention window closes.
- Compare
generated_atbetween polls to avoid reprocessing unchanged payloads. - Refresh standings and results only when the relevant stage
statusindicates a change, not on a fixed timer. See Update Frequencies.
Updated 8 days ago
