Understanding Race Results, Driver, Team and Track Data in v3
One of the most significant changes in Motorsport API v3 is how race results and driver data are structured. In v1, 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 v1 data fields go in v3?"
High-level structural changes
From single properties to arrays
In v1, many data points were direct properties on objects. In v3, most data is organised into typed arrays for better structure and extensibility.
v1 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 entry?
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: v1 → v3
Here's the definitive guide for finding your v1 fields in v3.
Core identifiers
Example:
v1:
v3:
Result times
driver_time
lineups[].details[].data.time
"Time"
time
driver_time_int
lineups[].details[].data.gap
"Gap To Leader"
gap-to-leader
driver_time_int*
lineups[].details[].data.interval
"Interval"
interval
(*)The driver_time_int field in v1 normally contained the time relative the leader (Gap To Leader), unlike the 'int' in the name suggests. In v3, the naming of those times is corrected and both types of relative time are available.
Finding time in v3:
Complete example:
v1:
v3:
Fastest lap data
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
Finding fastest lap in v3:
Complete example:
v1:
v3:
Laps completed
laps
lineups[].details[].data.laps
"Laps"
laps
Finding laps in v3:
Complete example:
v1:
v3:
Grid position
grid
lineups[].grid_position
Available as direct property, and in details array
Good To Know: Grid position is a direct property on the lineup object, which you can use instead of the object in the details array.
Complete example:
v1:
v3:
v3, alternative way:
grid
lineups[].details[].data.position
"Grid Position"
grid-position
Pitstops
pit
lineups[].details[].data.stops
"Pitstops"
pitstops
Finding pitstops in v3:
Complete example:
v1:
v3:
Additional detail types
Based on actual v3 data, here are the additional detail types available in lineups:
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
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:
v1:
v3:
Complete side-by-side comparison
v1 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
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 v1, status codes and data types could vary. In v3, they are consistent and safe to cache long-term.
Caching strategy
Common Lineup Detail Types:
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
Getting all states
Common fixture states:
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
Driver information
In v1, 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:
Code Example: Retrieving driver information
Team information (per season)
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
v1 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:
Code Example: Getting team details for the 2025 season
Track information
In v1, track information was included in track responses. In v3, all track-specific metadata (length, direction and type) is now in a dedicated metadata object.
Accessing track data
Endpoint:
Response structure:
Code Example: Retrieving track information
Quick reference: Common scenarios
Scenario 1: "I need race finishing positions"
v1:
v3:
Scenario 2: "I need to check who DNF'd"
v1:
v3:
Scenario 3: "I need fastest lap times"
v1:
v3:
Scenario 4: "I need starting grid positions"
v1:
v3:
Scenario 5: "I need driver IDs"
v1:
v3:
Migration checklist
Use this checklist when migrating from v1 to v3:
Data access
Replace
resultsarray withlineupsarrayChange
driver_idtoplayer_idChange
track_idtovenue_id(at fixture level)Update
gridtogrid_position
Result details
Implement helper function to find details by type code
Update time extraction:
driver_time→details[type=time].data.timeUpdate interval extraction:
driver_time_int→details[type=interval].data.intervalUpdate fastest lap:
best_lap_time→details[type=fastest-lap].data.timeUpdate fastest lap number:
fastest_lap→details[type=fastest-lap].data.lap_numberUpdate laps:
laps→details[type=laps].data.lapsUpdate pitstops:
pit→details[type=pitstops].data.stopsUpdate status:
retiredboolean →details[type=status].data.statusenum
Includes
Add
include=lineupsto fixture requestsAdd
include=lineups.details.typefor typed result dataAdd
include=lineups.driverfor driver namesAdd
include=lineups.driver.metadatafor 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:
Email: support@sportmonks.com
Documentation: Motorsport API v3 Docs
Migration Guide: Main Migration Page
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?