If you are evaluating Smartcar, you are almost certainly trying to do one of two things: read vehicle data across many brands, or build a product that acts on vehicles: unlock, grant access, cap spend, and cleanly end it all. Smartcar is excellent at the first. DIMO is built for the second. Smartcar is a window into the car; DIMO is the checkout desk.
Smartcar reads data and issues commands through a clean API. What it does not provide is a session: a single object that bundles identity, a digital key, a scoped data grant, a spend cap, and atomic revocation, with a verifiable record when it ends. For a dashboard or an analytics feature, you may never need that. For a rental, a carshare, or any case where a stranger temporarily uses a vehicle, the session is the whole job.
The architectural difference underneath: Smartcar is pass-through with conversion. It translates an OEM feed and hands the result to you. It is not a system of record, it has no data sharing or consent model, and you cannot self-host it. DIMO is data storage with sharing: ingested signals become normalized time-series that vehicle owners can share, scope, and revoke, on infrastructure you can run yourself because the core is open source.
Side by side
| Capability | Smartcar | DIMO |
|---|---|---|
| Read vehicle data across brands | Yes | Yes (50+ brands already connected) |
| Issue commands (lock/unlock) | Yes | Yes |
| Stores data as a shareable system of record | — (pass-through with conversion) | Yes (consent-governed time-series) |
| Self-hostable | — | Yes (open-source core) |
| Ingests from other connectivity providers | — | Yes (including Smartcar, Flespi, Volteras) |
| Digital key as part of a session | — | Yes |
| Per-session spend cap | — | Yes |
| Atomic revocation of a whole session | — | Yes |
| Verifiable, signed access audit trail | — | Yes |
How the pricing models differ
Smartcar prices per connected vehicle with plan minimums, which works well when every connected car maps to a paying end user. DIMO separates the two decisions. The Hobbyist tier is free with vehicles at $1.25/month each, so you can validate an idea against your own car before any commitment. Core is $349/month with 100 vehicles included and higher rate limits for production apps. Enterprise adds custom SLAs, on-premise deployment, and volume pricing. There is no charge for the consent and session layer itself; it ships with every tier.
One structural difference matters more than the numbers: DIMO's core protocol is open source. If pricing or terms ever stop working for you, the exit path is running the infrastructure yourself rather than rewriting your product against a new proprietary API.
You may not need to migrate at all
This is the part most evaluations miss: DIMO and Smartcar are not mutually exclusive. DIMO can ingest data through Smartcar (and through Flespi or Volteras) the same way it ingests from OEM oracles or its own hardware. If your Smartcar integration works, keep it as the connectivity layer and put DIMO on top for what Smartcar does not do: storage, owner consent, sharing, sessions, and an audit trail. See the oracle example for how ingest sources plug in.
Migrating from Smartcar
If you do want to replace Smartcar outright, most migrations are endpoint mapping, not re-architecture. Smartcar's REST reads (odometer, location, battery, fuel) map to DIMO's GraphQL Telemetry API, and vehicle authorization maps to a SACD consent grant. The practical sequence: create a free account at console.dimo.org, generate API keys, point the TypeScript, Python, or C# SDK at your existing data model, and run both providers in parallel while your users re-consent. The platform comparison in the docs includes a field-by-field migration guide with code samples.
Where Smartcar is still the right call
Honest answer: if your product only reads data, never touches access control, and your users are all in Smartcar's coverage footprint, Smartcar is a mature, well-documented choice and switching would buy you little. The reason developers move to DIMO is almost always that their roadmap grew past read-only: they need keys, scoped grants, session-based billing, or an audit trail regulators will accept, and bolting those onto a read-only API means building the hard part themselves.
Common questions
Do I need hardware? No. Most of the 50+ supported brands connect through software integrations. The optional DIMO LTE R1 adapter adds high-frequency data for vehicles without a usable cloud API.
Can a vehicle owner revoke access mid-session? Yes. Revocation is atomic: the key, the data grant, and the spend authorization all end together, and the session record stays on the audit trail.
Is this compliant in Europe? The SACD consent model was built for GDPR and the EU Data Act; see the EU Data Act guide for specifics.
When to choose which
Choose Smartcar when your product is fundamentally about reading data: usage analytics, EV charging insights, a service that needs odometer or battery state. Choose DIMO when your product governs access: unmanned rental, carshare, fleet dispatch, per-session insurance. It needs identity, keys, data, spend, and revocation to behave as one consented, auditable unit.
The model behind that is vehicle session infrastructure; see it applied to rental operations. For the product itself, the connected car API overview and vehicle data API pages cover capabilities and signals, pricing is published (free Hobbyist tier, $349/month Core), and the developer docs take you to a first API call.