Overview
Three V2 endpoints together give a complete picture of a vehicle’s current health:
All three join on the vehicle ID (
DeviceId in position data, vehicleId in battery health, and the {id} path parameter in engine-codes). These are all the same integer vehicle identifier.
Step 1 — Get live position and status
GET /v2/api/vehicles/{id}/last-position returns the latest GPS fix for a single vehicle. Key health fields:
cURL
Python
Step 2 — Get battery health predictions
GET /v2/api/battery-health returns a paginated list of predictions for all vehicles in the company. No companyId parameter is needed — scope comes from the token.
Python
items contains:
Step 3 — Get engine fault codes
GET /v2/api/vehicles/{id}/engine-codes returns paginated fault codes with full descriptions, severity ratings, and the location where the fault was detected.
cURL
Python
Step 4 — Join on vehicle ID
With all three data sources fetched, merge them into a single per-vehicle record:Limitations
- Safety score is a separate call.
GET /v2/api/safety-score/{id}returns per-tripriskLevel/riskScore(0–100) /duration/distancefor a single vehicle over a date range. It operates at trip granularity, not vehicle-snapshot granularity — use it alongside trip replay for driver safety dashboards. - Battery prediction is company-wide.
GET /v2/api/battery-healthfetches all vehicles. For large fleets, cache this response and join locally rather than calling it once per vehicle.
Gotchas
deviceId=vehicleId= engine-codes{id}. All three endpoints use the same integer vehicle identifier under different field names.utcTimehas noZsuffix but is always UTC — treat it as UTC when parsing.- Voltage is external battery voltage. Use
voltage(the vehicle’s 12 V battery) for health monitoring. Do not confuse with internal device backup battery. - Engine code data is paginated in V2. Unlike V1 which returned an array-of-arrays, V2 returns a flat paginated
itemslist — no flattening or deduplication needed.