Understanding Race Results & Driver Data in v3

One of the most significant changes in Motorsport API v3 is how race results and driver data are structured. In v2, result fields were individual properties on each driver/result object. In v3, this data has moved into structured arrays that provide better organization and more detailed information.

This guide specifically addresses the question: "Where did my v2 data fields go in v3?"

circle-info

Key change: Race result data now lives in the lineups array, where each lineup entry represents a driver's participation in a fixture (race/qualifying/practice).

This guide shows examples as Javascript/Node.JS code, however you can use similar approaches in your programming language of choice.


High-level structural changes

From single properties to arrays

In v2, many data points were direct properties on objects. In v3, most data is organised into typed arrays for better structure and extensibility.

v2 Approach (flat structure):

{
  "driver_id": 123,
  "team_id": 456,
  "position": 1,
  "driver_time": "1:32:03.456",
  "best_lap_time": "1:23.456",
  "laps": 58,
  "grid": 3
}

v3 Approach (structured arrays):

Why this change?

Benefits of the new structure:

  • Extensibility: Easy to add new data types without changing the schema

  • Type safety: Each data point has an explicit type

  • Consistency: Same pattern across all motorsport series

  • Clarity: Clear separation between driver info and result details


Understanding lineups

The lineups array is the core container for all driver participation and result data in a fixture.

What is a lineup rntry?

Each item in the lineups array represents one driver's participation in a specific fixture (race, qualifying, or practice session).

Lineup Structure

Accessing lineups

Basic request:

With driver details:


Complete field mapping: v2 β†’ v3

Here's the definitive guide for finding your v2 fields in v3.

Core identifiers

v2 Field
v3 Location
Notes

driver_id

lineups[].player_id

Direct mapping; different IDs (see Drivers)

team_id

lineups[].team_id

Direct mapping; different IDs (see Teams)

track_id

venue_id

Now at fixture level, not driver level; different IDs (see Tracks / Venues)

Example:

v2:

v3:

circle-info

You can enrich data with normal and nested includes, like include=venue and include=lineups.driver. However, we recommend caching and/or storing data, and relating them using IDs.

Result times

v2 Field
v3 Location
Type Name
Type Code

driver_time

lineups[].details[].data.time

"Time"

time

driver_time_int

lineups[].details[].data.interval

"Interval"

interval

Finding time in v3:

Complete example:

v2:

v3:

circle-info

Important to note: For the "type" fields to be available, the nested include 'lineups.details.type' must be used.

Fastest lap data

v2 Field
v3 Location
Type Name
Type Code

best_lap_time

lineups[].details[].data.time

"Fastest Lap"

fastest-lap

fasted_lap_time

lineups[].details[].data.time

"Fastest Lap"

fastest-lap

fasted_lap

lineups[].details[].data.lap_number

"Fastest Lap"

fastest-lap

circle-info

Important: Both fasted_lap_time and fasted_lap (lap number) are now in the same detail object with type "Fastest Lap" and keys time and lap_number. best_lap_time was a duplicate field and can also be found in this object via the key time.

Finding fastest lap in v3:

Complete example:

v2:

v3:

Laps completed

v2 Field
v3 Location
Type Name
Type Code

laps

lineups[].details[].data.laps

"Laps"

laps

Finding laps in v3:

Complete example:

v2:

v3:

Grid position

v2 Field
v3 Location
Notes

grid

lineups[].grid_position

Available as direct property, and in details array

circle-check

Complete example:

v2:

v3:

v3, alternative way:

v2 Field
v3 Location
Type Name
Type Code

grid

lineups[].details[].data.position

"Grid Position"

grid-position

Pitstops

v2 Field
v3 Location
Type Name
Type Code

pit

lineups[].details[].data.stops

"Pitstops"

pitstops

Finding pitstops in v3:

Complete example:

v2:

v3:

Additional detail types

Based on actual v3 data, here are the additional detail types available in lineups:

v3 Detail Type
Type Code
Data Fields
Description

Points

points

points

Championship points earned

Gap To Leader

gap-to-leader

gap

Time gap to race leader

Tyre

tyre

compound, age_since_start

Current tyre compound and age

Example - Getting tyre information:

Example - Getting gap to leader:

Retirement status

v2 Field
v3 Location
Type Name
Type Code

retired

lineups[].details[].data.status

"Status"

status

Status values:

  • "DNF" - Did Not Finish

  • "DNS" - Did Not Start

  • "DSQ" - Disqualified

Finding status in v3:

Complete Example:

v2:

v3:

circle-info

The fixture-level state indicates overall race status (NS, LIVE, FULL_TIME, CANCELLED, etc.), not individual driver status.


Complete side-by-side comparison

v2 race result response

v3 race result response


Practical code examples

Extracting race results

Goal: Get finishing position, time, and fastest lap for each driver.

Output:

Building a results table

Output:

Identifying drivers who didn't finish

Since there's no direct "retired" or "DNF" status field, determine this by comparing lap counts:

Finding fastest lap of the race


Driver debut information

In v2, debut information was sometimes included in driver responses. In v3, all driver-specific metadata (including debut info) is now in a dedicated metadata object.

Accessing debut data

Endpoint:

Response structure:

circle-info

A full list of available types can be found here: Driver

Example: Finding debut information


States & Types: Cacheable reference data

One major improvement in v3 is that states and types are now standardised across all motorsport series.

Why this matters

In v2, status codes and data types could vary. In v3, they are consistent and safe to cache long-term.

Caching strategy

circle-info

Best Practice: Cache types and states for 30+ days. They rarely change and are consistent across all fixtures.

Common Lineup Detail Types:

Type ID
Name
Code
Usage

9711

Position

position

Live or final race position

9708

Time

time

Latest lap time

9733

Interval

interval

Time behind car ahead

9732

Gap To Leader

gap-to-leader

Time behind race leader

9716

Fastest Lap

fastest-lap

Fastest lap time & lap number

9710

Laps

laps

Laps completed

9709

Pitstops

pitstops

Number of pit stops

9707

Points

points

Championship points earned in this race

9712

Grid Position

grid-position

Starting grid position

9729

Tyre

tyre

Current tyre compound & age

circle-info

A full detailed list can be found here: Result Type Reference

Getting all states

Common fixture states:

State ID
State Code
Name
Additional notes

1

NS

Not Started

27

LIVE

Live

Transition to this state indicates the start of the first lap in races (excluding the formation lap) and green light in other session types

5

FT

Full Time

Known in v1 as 'Finished', indicates a chequered flag is waved in races, and full session time elapsed in other session types

12

CANCELLED

Cancelled

16

DELAYED

Delayed

18

INTERRUPTED

Interrupted

Session is paused, usually when a red flag is waved

20

DELETED

Deleted

The fixture is removed from the API, it is no longer active in standard calls but can still be fetched with filter=deleted.

Using cached types


Teams & season relations

In v3, teams now have richer season-specific information via the seasondetails include. The advantage of this, is that the season-specific data for previous seasons will stay in place.

We'll cover the car and lead information here, however the data also contain previous team names and logos, so you can retrieve the older branding for displaying historical data.

Getting teams for a specific season

v2 approach:

v3 approach (Option 1 - All teams and data):

v3 approach (Option 2 - Specific season):

Understanding season details

The seasondetails include provides season-specific team information:

circle-info

A full list of available types can be found here: Team

Example: Getting constructor details


Quick reference: Common scenarios

Scenario 1: "I need race finishing positions"

v2:

v3:

Scenario 2: "I need to check who DNF'd"

v2:

v3:

Scenario 3: "I need fastest lap times"

v2:

v3:

Scenario 4: "I need starting grid positions"

v2:

v3:

Scenario 5: "I need driver IDs"

v2:

v3:


Migration checklist

Use this checklist when migrating from v2 to v3:

Data access

  • Replace results array with lineups array

  • Change driver_id to player_id

  • Change track_id to venue_id (at fixture level)

  • Update grid to grid_position

Result details

  • Implement helper function to find details by type code

  • Update time extraction: driver_time β†’ details[type=time].data.time

  • Update interval extraction: driver_time_int β†’ details[type=interval].data.interval

  • Update fastest lap: best_lap_time β†’ details[type=fastest-lap].data.time

  • Update fastest lap number: fastest_lap β†’ details[type=fastest-lap].data.lap_number

  • Update laps: laps β†’ details[type=laps].data.laps

  • Update pitstops: pit β†’ details[type=pitstops].data.stops

  • Update status: retired boolean β†’ details[type=status].data.status enum

Includes

  • Add include=lineups to fixture requests

  • Add include=lineups.details.type for typed result data

  • Add include=lineups.driver for driver names

  • Add include=lineups.driver.metadata for debut info

Caching

  • Implement types caching (30+ days)

  • Implement states caching (30+ days)

  • Cache type IDs for faster detail lookups


Getting Help

If you encounter issues or have questions during migration:

We're here to help make your migration as smooth as possible!


Tip: Start by updating one endpoint at a time. Test thoroughly before moving to the next. The structure is consistent across all fixtures, so once you understand lineups and details, the pattern repeats everywhere.

Last updated

Was this helpful?