Integration GuidesDocs
Coverage MatrixDocumentationChange LogLog InContact Us
Integration Guides

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

FeedDetects
Deleted StagesStages (events or sessions) removed from a season
Competitor Merge MappingsCompetitor records merged into one
Stage Schedule / Stage SummaryStatus, 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 Cancelled

A 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 scheduled times and status transitions (for example an event moving to Cancelled).
  • 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_at timestamp and the cache-control TTL on each response to decide when a re-poll is worthwhile.

📡

Polling Is the Model

Change detection is poll-based. Drive your poll cadence off stage status and 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_at between polls to avoid reprocessing unchanged payloads.
  • Refresh standings and results only when the relevant stage status indicates a change, not on a fixed timer. See Update Frequencies.


Did this page help you?