Vehicle data is fragmented on purpose: every manufacturer has its own cloud, schema, units, and gatekeeping. A vehicle data API earns its keep by normalizing that mess into one contract your code can trust. DIMO does the normalization once, network-wide. Signals stream in through the connectivity source you choose: a direct OEM oracle, a pass-through provider like Smartcar, Flespi, or Volteras, or DIMO hardware. Whatever the source, you query everything through a single GraphQL endpoint with consistent names and units.
One scoping note: if you need static reference data (VIN decoding, make/model/trim specs, market values), that is a lookup database, and this is not that. This API is live and historical sensor data from vehicles on the road, with owner consent attached. It is the data layer DIMO provides for the session-based economy.
Signals you can query
| Category | Signals |
|---|---|
| Location & motion | GPS coordinates, speed, heading, altitude |
| Energy | Battery state of charge, charging status, range, fuel level |
| Usage | Odometer, ignition state, trip data |
| Health | Tire pressure (per wheel), engine temperature, oil life, diagnostic trouble codes (DTCs) |
| State | Door lock status, window position, hood/trunk state |
Signal names follow the COVESA Vehicle Signal Specification, so speed means the same thing for a Tesla as for a Ford. Availability varies by make and connection type; the Telemetry API reference lists the full catalog. Update frequency ranges from 30 seconds through OEM cloud connections to sub-second with the optional DIMO LTE R1 adapter.
Storage with sharing, not pass-through
This is the difference between DIMO and connectivity providers. Smartcar, Flespi, and Volteras convert an OEM feed and pass it through to you; they are not a system of record, they have no consent or sharing model, and you cannot self-host them. DIMO ingests from those same providers (or from OEM oracles and hardware) and stores the signals as normalized time-series that vehicle owners can share, scope, and revoke. The open-source core means the whole stack can run on your own infrastructure.
Historical data with aggregation
Because DIMO stores the data, the same endpoint serves time-series history with server-side aggregation, so a week of driving becomes one query instead of a data pipeline:
query {
signals(
tokenId: 12345
from: "2026-07-01T00:00:00Z"
to: "2026-07-06T00:00:00Z"
interval: "1h"
) {
timestamp
speed(agg: MAX)
powertrainRange(agg: MIN)
obdBarometricPressure(agg: AVG)
}
}Consent and compliance are part of the API
Every query runs against a permission the vehicle owner explicitly granted. Grants are scoped (you see only the signal groups the user shared), revocable at any time, and recorded on a signed audit trail. That architecture is what makes GDPR, EU Data Act, and CCPA compliance a property of the platform rather than a project for your team. If you have watched the FTC's recent actions on vehicle data brokers, this is the part that matters.
Getting to a first API call
Create a free account at console.dimo.org, generate a license and API keys, and query. SDKs for TypeScript, Python, and C# handle auth and token exchange. No car handy? The vehicle simulator generates realistic telemetry so you can build before connecting real hardware.
Pricing
Hobbyist is free: all APIs, one AI agent, vehicles at $1.25/month. Core is $349/month with 100 vehicles included, higher rate limits, and data storage. Enterprise gets custom limits and on-premise options. Full pricing.
Related reading
For the broader platform picture (commands, identity, and consent on top of data), see the connected car API overview. For a head-to-head with other providers, read DIMO vs Smartcar. The developer docs cover everything else.