TL;DR: OCPI (Open Charge Point Interface) is a REST/HTTPS protocol that lets CPOs and eMSPs exchange locations, sessions, CDRs, tariffs, tokens, and commands so drivers can charge across networks. Implement only the modules your role needs, get the credentials handshake right before anything else, target 2.2.1 while keeping 2.1.1 compatibility, and treat CDR reconciliation as an audited ledger rather than a feed.
What is OCPI?
OCPI (Open Charge Point Interface) is an open protocol, maintained by the EVRoaming Foundation, that enables roaming between EV charging networks. If OCPP is how chargers talk to their backend, OCPI is how backends talk to each other.
Think of it like credit card networks. Your Visa card works at any merchant, regardless of which bank issued it. OCPI creates the same interoperability for EV charging — a driver with one eMSP account can charge on any CPO's network without a separate contract for each operator.
The protocol is REST over HTTPS with JSON payloads, organized into modules that each party implements based on its role. That modularity is the practical strength of OCPI: a pure eMSP and a pure CPO exchange the same objects but from opposite directions, and neither has to build features it will never use.
The two OCPI roles: CPO and eMSP
OCPI defines two roles: the CPO that runs the physical hardware and the eMSP that owns the driver relationship. A single platform can play both roles at once over the same connection, sending data as a CPO and receiving it as an eMSP.
CPO (Charge Point Operator)
The CPO owns and operates the physical charging infrastructure. They publish their locations, connectors, and tariffs via OCPI so that eMSPs can offer them to their customers. The CPO is the source of truth for availability, pricing, and the final billing record after a session ends.
eMSP (e-Mobility Service Provider)
The eMSP provides the customer-facing service — the app, the RFID card, the billing relationship. They subscribe to CPO location data and authorize charging sessions on behalf of their users. The eMSP owns the token, sets the retail price the driver pays, and reconciles what each CPO charges against what it invoices.
A single company can be both CPO and eMSP simultaneously. Many large charging networks operate in both roles, which is why OCPI describes capabilities per connection rather than per company.
How does the OCPI credentials handshake work?
The credentials handshake is the trust anchor of every OCPI connection. Two parties exchange a one-time registration token, call each other's versions and credentials endpoints, then swap the long-lived tokens that authorize all future traffic. Get this wrong and nothing else in the integration matters.
In practice the flow runs like this. Each side hosts a versions endpoint that lists the OCPI versions it speaks and a version details endpoint that lists the module endpoints for a given version. During registration, party A receives a registration token (Token A) out of band, then POSTs its own credentials to party B's credentials endpoint. Party B responds with a fresh token (Token C), and both sides discard the registration token. From then on, A authenticates to B with one token and B authenticates to A with another. Tokens are directional, which is the detail teams most often miss.
Citation capsule: The OCPI credentials handshake replaces the one-time registration token with two directional, long-lived tokens after both parties resolve each other's
versionsandcredentialsendpoints. Token confusion — reusing one side's token for the reverse direction — is among the most common first-connection failures in roaming onboarding.
A few operational notes from real onboarding. The registration token expires the moment the handshake completes, so a half-finished exchange leaves you needing a fresh token from the partner. Version negotiation should pick the highest version both sides support, not a hardcoded default. And when a partner rotates credentials, the connection re-runs the handshake rather than patching a token in place — build that re-registration path early, because you will use it.
In mixed-fleet rollouts, the first connection to a new partner almost always stalls on one of three things: a versions URL that resolves to the wrong environment, a token sent in the wrong direction, or a TLS chain the partner's client rejects. None of those are spec violations. They are integration hygiene, and they cost days if you discover them during launch instead of during a controlled handshake test.
OCPI core modules
OCPI is modular, and you implement only the modules your role needs. The core set defined in the OCPI specification — Locations, Sessions, CDRs, Tariffs, Tokens, and Commands — covers the standard roaming use case where an eMSP's driver charges on a CPO's network and gets billed cleanly.
Locations module
The core of OCPI. CPOs publish their charging locations, including:
- Geographic coordinates and address
- EVSEs (charging points) with connector types
- Real-time availability status
- Opening hours and access restrictions
eMSPs pull this data to show available chargers in their apps. Locations is also the module where pagination and incremental sync matter most, because a national network can hold tens of thousands of EVSEs.
Sessions module
Tracks active charging sessions in real time. When a driver starts charging on a CPO's network via an eMSP, both parties exchange session data:
- Session start/stop times
- Energy delivered (kWh)
- Costs incurred
- EVSE and connector used
Sessions give the eMSP a live view so its app can show cost accumulating, but the session object is not the billing record. That is the CDR.
CDRs module (Charge Detail Records)
The billing backbone. After a session ends, the CPO generates a CDR containing the final cost breakdown. The eMSP uses this to invoice the driver. CDRs are immutable once issued — a correction means a new record, not an edit.
CDRs include:
- Total energy consumed
- Charging duration
- Tariff applied
- Total cost with tax breakdown
Tariffs module
CPOs publish their pricing structures. OCPI supports complex tariff models:
- Per-kWh pricing
- Per-minute pricing (charging time and/or parking time)
- Flat fees
- Time-of-day variations
- Reservation fees
Tokens module
How eMSPs authorize their users on CPO networks. When a driver taps their RFID card or opens their app, the CPO sends a token validation request to the eMSP, or checks a cached copy of the token list it has already pulled.
OCPI supports:
- RFID tokens
- App-based tokens
- Ad-hoc (QR code) tokens
Commands module
Allows eMSPs to send commands to CPO chargers on behalf of users:
START_SESSION— remote startSTOP_SESSION— remote stopRESERVE_NOW— reserve a connectorUNLOCK_CONNECTOR— remote unlock
Citation capsule: OCPI organizes roaming into independent modules — Locations, Sessions, CDRs, Tariffs, Tokens, and Commands — that each party implements according to its role. A pure eMSP and a pure CPO exchange the same objects from opposite directions, so neither builds capabilities its business model never uses.
Hub or bilateral: how should you connect partners?
You can connect to roaming partners directly (bilateral) or through a roaming hub like Hubject or Gireve. Bilateral gives you direct control and avoids hub fees; a hub gives you one integration that reaches many partners. Most operators end up running both.
A bilateral connection is a single OCPI link between your platform and one partner's platform. You own the handshake, the sync schedule, and the debugging session when CDRs disagree. That control is valuable for your largest partners, where direct contracts and direct support relationships already exist. The cost is linear: every new partner is another integration to onboard, monitor, and maintain.
A hub inverts that math. You integrate once with the hub, and the hub fans your data out to every partner connected to it. Onboarding a new partner becomes a contractual step rather than an engineering one. The trade-offs are hub fees, a shared dependency on the hub's availability and its interpretation of the spec, and slightly less visibility into the end partner's behavior when something breaks. The version you negotiate is also the hub's version, not the end partner's, so a hub can quietly insulate you from a partner still on 2.1.1 — which is convenient until you need a 2.2.1-only feature to actually reach that partner.
| Dimension | Bilateral connection | Roaming hub |
|---|---|---|
| Integrations to maintain | One per partner | One per hub |
| Onboarding a new partner | Engineering effort each time | Mostly contractual |
| Per-session cost | No hub fee | Hub fee applies |
| Control and visibility | Direct, end to end | Mediated by the hub |
| Dependency risk | Per-partner | Concentrated on the hub |
| Best fit | Large strategic partners | Long tail of partners |
The pattern we see most often is a small number of bilateral links to the operators that drive real volume, plus one or two hub connections to cover the long tail. It keeps per-session economics sane on your biggest partners while letting you say yes to the next forty without an integration sprint each time.
What changed between OCPI 2.1.1 and 2.2.1?
OCPI 2.1.1 is still the most widely deployed version and covers the full core roaming use case. OCPI 2.2.1 adds first-class hub support, charging profiles, a richer tariff model, and a cleaner registration flow. New builds should target 2.2.1 and keep 2.1.1 compatibility for partners that need it.
The practical differences matter when you scope modules. 2.2.1 introduces ChargingProfiles, which lets an eMSP or hub apply smart-charging limits across a roaming boundary — relevant for fleet and depot use cases. Its tariff model adds steps and elements that express time-of-day and parking pricing more precisely, reducing the gap between what the CPO charges and what the eMSP can represent. Registration gains explicit roles per credentials object, which is what makes clean both-role and hub connections possible.
Citation capsule: OCPI 2.2.1 extends 2.1.1 with native hub messaging, the
ChargingProfilesmodule for cross-network smart-charging limits, a more granular tariff structure, and role-aware credentials. OCPI 2.1.1 remains widely deployed, so production roaming platforms typically support both and negotiate the highest mutually supported version per connection.
Here is the short version of where they diverge in day-to-day implementation work.
| Capability | OCPI 2.1.1 | OCPI 2.2.1 |
|---|---|---|
| Hub connectivity | Workarounds via bilateral links | Native hub messaging and routing |
| Charging profiles | Not available | ChargingProfiles module |
| Tariff granularity | Basic elements | Stepped, time-aware tariff model |
| Credentials roles | Implicit | Explicit roles per credentials object |
| Deployment status | Most widely deployed | Recommended for new builds |
If you are still settling version strategy, our deeper comparison in OCPI 2.1.1 vs 2.2.1 walks through the module-by-module decision.
OCPI implementation architecture
A typical OCPI implementation has three layers: an HTTP API layer, a data synchronization layer, and the business logic where most complexity actually lives. The API surface is the easy part; sync and tariff logic are where projects slip.
HTTP API layer. OCPI uses REST with JSON payloads. Each party exposes endpoints for the modules it supports. Authentication uses the directional tokens exchanged during the credentials handshake, and every object carries an id and a last_updated timestamp.
Data synchronization. Locations, tariffs, and tokens are synchronized between parties. OCPI supports both pull (the receiver fetches updates) and push (the sender pushes updates). Real systems combine the two: an initial full pull, then incremental updates driven by last_updated, with a periodic reconciliation pull to catch anything a missed push dropped.
Business logic. Authorization decisions, tariff calculations, and CDR generation. This is where the complexity lives, because it is where your data model meets a partner's interpretation of the same spec.
How do you reconcile CDRs across partners?
CDR reconciliation is the process of making sure every billable session produces exactly one agreed Charge Detail Record on both sides. It is where roaming money is won or lost, and it fails quietly — a session that never becomes a CDR is revenue nobody invoices.
The core problem is that a CDR is the CPO's final word, but the eMSP has its own session view and its own retail tariff. Three failure modes recur. First, a session ends but no CDR arrives, usually because of a push that was never retried or a pull window that missed it. Second, a CDR arrives but its total disagrees with the eMSP's expectation, almost always a tariff interpretation gap — parking time, minimum fees, or a time-of-day boundary applied differently on each side. Third, duplicate CDRs land for one session after a retry, which double-bills unless you dedupe on the CDR id.
The reliable defense is to treat CDRs as an audited ledger, not a feed. Pull CDRs on a schedule even when you also accept pushes, match every closed session to a CDR within a defined window, and alert on any session older than that window with no matching record. The mismatches you want to catch are not the loud HTTP errors; they are the silent gaps where a session simply never becomes money. Our breakdown of OCPI CDR and billing flows goes deeper on the reconciliation ledger pattern.
Citation capsule: CDR reconciliation matches every closed roaming session to exactly one Charge Detail Record across CPO and eMSP. The recurring failures are missing CDRs, tariff-driven total mismatches, and duplicates from retries — caught reliably by scheduled CDR pulls and session-to-CDR matching within a defined window, not by relying on push alone.
Common OCPI implementation mistakes
Most OCPI failures are integration hygiene, not protocol misunderstanding. Pagination, last_updated handling, hardcoded tariffs, and skipping real partner tests cause more launch delays than anything in the specification itself.
Not handling pagination. OCPI uses Link headers for pagination. If you ignore them, you'll only get the first page of locations and silently miss most of a large network.
Ignoring the last_updated field. Every OCPI object has a last_updated timestamp. Use it to implement incremental sync instead of repeatedly pulling everything, which does not scale past a few partners.
Hardcoding tariff calculations. OCPI tariff structures are complex. Build a proper tariff engine rather than special-casing each pricing model, or every new partner tariff becomes a code change.
Not testing with real roaming partners. OCPI implementations vary. What works against the specification doesn't always work against a real partner's implementation, which is why a controlled handshake-and-CDR test with each partner pays for itself.
How does EV Cloud handle OCPI?
EV Cloud supports OCPI 2.1.1 and 2.2.1 workflows for both CPO and eMSP roles:
- Automatic location sync — your charger locations are published to roaming partners in real time, with incremental updates driven by
last_updated - Token authorization — incoming authorization requests are validated against your token database
- CDR generation and reconciliation — charge detail records are generated from OCPP session data and matched back to closed sessions
- Hub connectivity — connect to major roaming hubs (Hubject, Gireve, e-clearing) through a single integration
The platform can compress technical integration work materially, but partner onboarding, tariff alignment, and launch governance still need deliberate coordination. See pricing for how that maps to roaming scope.
What should you do before you launch roaming?
Most OCPI projects fail in rollout, not in the first demo. The real work is the credentials handshake with each partner, tariff alignment, token ownership, CDR reconciliation, and support readiness across multiple teams.
If you are moving from research into implementation planning, use this sequence:
- Use the OCPI rollout checklist to structure launch readiness before partner onboarding starts.
- See how EV Cloud supports OCPI 2.1.1 and 2.2.1 if you still need to settle module scope and version strategy.
- Talk to EV Cloud if your team needs help with roaming architecture, hub connectivity, or phased launch support.
