Roaming is one of the first things a growing charge point operator is asked about — by drivers who want to use one app everywhere, and by partners who want your sites in their network. OCPI (the Open Charge Point Interface) is the protocol that makes that possible. It is also widely misunderstood, usually because the role model is skipped.
CPO and eMSP are roles, not companies
OCPI defines two roles. The CPO (Charge Point Operator) runs the physical infrastructure: the chargers, the sites, the tariffs. The eMSP (e-Mobility Service Provider) holds the driver relationship: the app, the RFID card, the contract.
A single company can hold both roles, but the protocol keeps them separate — and that separation is the whole point. As a CPO, your job in an OCPI exchange is to publish what you operate and receive authorizations and session data back. You are not trying to bill the roaming driver directly; you are settling with their eMSP.
What a CPO publishes
An OCPI integration is mostly about keeping a small set of objects accurate and current:
- Locations, EVSEs, and connectors — where your chargers are, what they support, and their live status.
- Tariffs — the price structure a roaming partner shows their driver before a session starts.
- Tokens — the identifiers a partner’s drivers present, which you validate in real time.
- Sessions and CDRs — the live session feed, and the Charge Detail Record that closes it for billing.
The CDR is the one that matters financially. It is the document a roaming partner settles against, so a CDR that is wrong, late, or never sent is not a protocol curiosity — it is lost revenue.
Where roaming integrations actually break
The protocol itself is not the hard part. The hard part is operational consistency:
- Tariff drift. If the tariff a partner displayed does not match the tariff you priced the session at, you get disputes. Tariff versioning — and snapshotting the price applied to each session — is what prevents that.
- Status accuracy. A connector shown as available that is actually faulted produces a failed roaming session and a frustrated driver who blames the partner’s app, not you.
- CDR delivery. Push failures happen — endpoints move, credentials rotate, networks blip. The question is whether a failed CDR push is caught or silently lost.
That last point is why roaming should not be treated as a fire-and-forget integration. A CDR that fails to reach a partner needs to surface somewhere a human will see it.
How Sparqly approaches it
Sparqly implements a full OCPI 2.2.1 CPO surface — credentials, locations, EVSEs, connectors, tariffs, tokens, sessions, and CDRs. Publishing runs on the same evidence chain used internally, so a CDR push that fails is raised as a revenue assurance exception rather than disappearing. Tariffs are versioned, and the price applied to a session is snapshotted at transaction time, so the number a partner displayed and the number you settle against are the same number.
Roaming should expand your network’s reach without expanding your reconciliation risk. Treated as an operational surface — not just a protocol checkbox — it can.