Overview
Three V2 endpoints together give a complete picture of a vehicle’s current health:| Endpoint | Data |
|---|---|
GET /api/v2/vehicles/{id}/last-position | Live voltage, ignition state, speed, odometer, last GPS fix |
GET /api/v2/battery-health | Battery voltage and day-ahead prediction results (company-wide) |
GET /api/v2/vehicles/{id}/engine-codes | Active OBD-II / CAN fault codes with descriptions and severity |
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 /api/v2/vehicles/{id}/last-position returns the latest GPS fix for a single vehicle. Key health fields:
| Field | Type | Description |
|---|---|---|
deviceId | integer | Vehicle identifier — join key |
voltage | double | External battery voltage (V) |
ignition | boolean | Whether ignition is currently on |
speed | double | Last reported speed (km/h) |
odometer | double | Total odometer reading (km) |
utcTime | string | When this GPS fix was recorded (UTC, no Z suffix) |
isOnline | boolean | Whether the device is currently connected |
cURL
Python
Step 2 — Get battery health predictions
GET /api/v2/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:
| Field | Description |
|---|---|
vehicleId | Vehicle identifier (join key) |
vehicleName | Vehicle display name |
currentVoltage | Current battery voltage (V) |
band | Overall health band: "Critical", "Warning", "Fair", "Healthy" |
healthScore.score | Health score out of 100 |
forecast.score | Estimated days until maintenance needed |
forecast.comment | AI-generated forecast summary |
badges | Array of active badge IDs (e.g. "HEALTHY", "PARK_DRAIN", "TREND_DOWN") |
daysToReplace | Estimated days until battery replacement recommended |
scoredOn | Date the health score was last calculated (YYYY-MM-DD) |
Step 3 — Get engine fault codes
GET /api/v2/vehicles/{id}/engine-codes returns paginated fault codes with full descriptions, severity ratings, and the location where the fault was detected.
cURL
Python
| Field | Description |
|---|---|
code | Raw OBD-II code (e.g. P0420) |
description | Plain-English fault description |
severity | "Low", "Medium", or "High" |
whyThisMatters | Impact on vehicle operation |
possibleCauses | Likely root causes |
recommendedActions | Suggested remediation steps |
detectedAt | UTC timestamp when the fault was detected |
location.address | Reverse-geocoded address at detection |
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 /api/v2/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 /api/v2/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.