ID Handling

The Formula 1 API identifies entities by Sportradar sr: IDs, not GUIDs. This page explains the ID families you will encounter, the one ID that drives all navigation (the stage ID), and what to know before you persist IDs.

The sr: Identifier Families

The Stage ID Is the Navigation Key

Because the API is stage-based, the stage ID is the one identifier that ties everything together. The same sr:stage: namespace covers the sport, every season, every event, every session, and every lap. You navigate by swapping the stage ID into the path:

GET https://api.sportradar.com/formula1/trial/v2/en/sport_events/sr:stage:1189123/summary.json

Season IDs, event IDs, and race IDs are all stage IDs, distinguished by their type attribute (season, event, race, lap, and so on). Start from Seasons and let each response hand you the stage IDs for the level below. See Fundamentals.

ℹ️

Stage IDs vs Stable Slots

A regular sr:stage: ID is unique to one stage in one season; the same Grand Prix gets a new stage ID each year. To follow the same event across seasons, use unique_stage_id (below), not the stage ID.

unique_stage_id: Tracking an Event Across Seasons

Events and sessions carry a unique_stage_id (an sr:stage_unique: value) that stays the same for the equivalent slot from year to year. Use it to link, for example, the Australian Grand Prix in 2024, 2025, and 2026 even though each has a different sr:stage: ID.

{
  "id": "sr:stage:1189125",
  "description": "Australian Grand Prix 2025",
  "type": "event",
  "unique_stage_id": "sr:stage_unique:1"
}

Build cross-season joins on unique_stage_id, not on the per-season stage ID or the localized description.

Drivers and Teams Share the sr:competitor: Namespace

Both drivers and teams (constructors) are sr:competitor: entities. A driver row carries its team as a nested team object, and both have sr:competitor: IDs:

{
  "id": "sr:competitor:495898",
  "name": "Norris, Lando",
  "team": {
    "id": "sr:competitor:4514",
    "name": "McLaren"
  }
}

The same competitor_id is what you pass to the Competitor Profile feed (for a driver) and the Team Profile feed (for a team). Decide which feed to call based on whether the ID came from a driver row or a team object, not from the ID itself. See Retrieving Competitor and Team Details.

Merged Competitors

Occasionally two competitor records are discovered to be the same entity and are merged. The Competitor Merge Mappings feed reports the surviving (retained) ID for a merged-away ID so you can update stored references. Entries are retained for one week after the merge.

{
  "generated_at": "2026-06-13T13:04:20+00:00",
  "schema": "https://schemas.sportradar.com/sportsapi/formula1/v2/schemas/competitor_merge_mappings.json",
  "mappings": []
}

An empty mappings array (above) means no merges occurred in the retention window. When populated, each entry maps a merged ID to its retained ID and name. Poll this feed if you persist sr:competitor: IDs; see Monitoring Data Changes.

Best Practices

• Persist sr: IDs as your join keys; they are stable for a given entity within a season.
• Use unique_stage_id for cross-season event joins.
• Resolve drivers and teams through the nested team / competitor objects, not by guessing from a bare sr:competitor: ID.
• Reconcile stored competitor IDs against Competitor Merge Mappings before they age out of the one-week window.
• Do not parse meaning out of the numeric portion of an ID; treat IDs as opaque.