If you’ve ever wondered how a driver can pull up to a station run by a company they’ve never heard of, open their own app, and get a working session with the right price and a receipt afterwards, the answer is OCPI.
This is the pillar article for the OCPI cluster on this site. By the end you’ll know what OCPI is, who uses it, how it relates to the other protocols in EV charging, and what’s actually inside it.
The problem OCPI exists to solve
Before OCPI, each charging network was a closed loop. An account with one network worked at that network’s stations and nowhere else. Arrive at a station run by anyone else and you needed a new account, a new app, and a payment method typed in at the curb in the rain.
That was tolerable while EVs were rare and almost all charging happened at home. It stopped being tolerable once public charging became routine. Imagine a gas station that only accepted a credit card issued by the company that owned it.
OCPI is the technical layer that fixes this. It lets two charging networks recognize each other’s customers, share station data, and settle the money afterwards.
The user-facing name for this is roaming: one account, many networks. Cellular roaming is the usual analogy, and it’s a good one, with one difference worth noting. In telecoms the interconnect specs sit behind operator membership. In EV charging the data model is public, so a two-person startup implements the same interface as the largest operator on the continent.
What “OCPI” stands for
Open Charge Point Interface. Three parts, all of them load-bearing:
- Open: the spec is published at no cost and anyone can implement it without a license fee.
- Charge Point: the industry’s term for a charging station.
- Interface: it’s a communication interface (an API), not a piece of hardware.
The protocol is managed by the EVRoaming Foundation, an independent nonprofit governed by industry stakeholders. Changes are drafted in working groups and shipped as numbered versions. That numbering carries more weight here than in a typical API, because the version you agree on with a partner determines exactly which modules and fields either side is allowed to ask for.
The two main roles OCPI connects
OCPI defines several roles. Two of them are the ones the whole protocol is arranged around.
CPO: Charge Point Operator
The company that owns and operates charging stations. It installs the hardware, keeps it running, sets the prices, and sees every session on its own network. On an OCPI connection, the CPO is the side that publishes data.
eMSP: e-Mobility Service Provider
The company that owns the driver relationship: the app, the account, the stored payment method, the RFID card. An eMSP doesn’t need to own a single piece of charging hardware. On an OCPI connection, the eMSP is the side that consumes data and vouches for the driver.
Nothing in the protocol stops one company from registering in both roles. The role describes which side of a given interface you’re standing on for a given session, not what kind of company you are, and a firm that operates stations and also ships a consumer app is simply registered twice. For a longer treatment of the two roles and the money that moves between them, see what a CPO and an eMSP actually do.
How OCPI compares to OCPP, OICP, and ISO 15118
The “open charge” acronym space is crowded. The protocols serve different layers:
| Protocol | What it connects | Who manages | Where in the stack |
|---|---|---|---|
| OCPP (Open Charge Point Protocol) | Charging station ↔ CPO’s backend | Open Charge Alliance | Device level (station-to-server) |
| OCPI (Open Charge Point Interface) | CPO ↔ eMSP (and to/from hubs) | EVRoaming Foundation | Business level (server-to-server) |
| OICP (Open InterCharge Protocol) | CPO ↔ eMSP via central hub | Hubject | Business level (hub-mediated) |
| ISO 15118 | EV ↔ Charging station | ISO | Device level (vehicle-to-station) |
The cleanest mental model is to picture one charging session as four conversations happening in sequence.
- EV to station (ISO 15118 (coming soon)): “What voltage do you offer? Here’s my state of charge. Begin charging.”
- Station to CPO backend (OCPP): “Driver authenticated. Session started. Delivering 47 kW. Session ended at 32.4 kWh.”
- CPO to eMSP (OCPI): “Your customer just charged at our station. Here’s the session detail and the CDR for billing.”
- eMSP to driver: push notification, app dashboard update, monthly bill.
Each layer runs its own protocol and fails in its own way. OCPI lives at the third one, the business-to-business layer, which is also the only layer where a failure shows up as an invoice rather than an error code.
Here’s how a single session flows through all four protocols:
sequenceDiagram
participant EV
participant Station
participant CPO as CPO Backend
participant eMSP
participant Driver
EV->>Station: ISO 15118: authorize, negotiate power
Station->>CPO: OCPP: session started
CPO->>eMSP: OCPI: validate token (Tokens module)
eMSP-->>CPO: OCPI: authorized
Station->>CPO: OCPP: delivering 47 kW
CPO->>eMSP: OCPI: session update (Sessions module)
eMSP->>Driver: Push: charging in progress
Station->>CPO: OCPP: session ended (32.4 kWh)
CPO->>eMSP: OCPI: final CDR (CDRs module)
eMSP->>Driver: Push: receipt + monthly billWhat OCPI actually exchanges
OCPI is organized into modules. Each one covers a single type of information that has to flow between CPO and eMSP. The major ones:
Locations
Where the stations are, what connectors they offer, what power level, current operational status. The CPO publishes it; the eMSP consumes it to fill in its map and station detail pages.
Tariffs
Pricing. Cost per kWh, per minute, per session, time-of-use bands, idle fees. The CPO publishes; the eMSP consumes it both to display a price before the session and to bill the customer after it.
Sessions
Live session data: start time, power currently being drawn, state of charge where the vehicle reports it. Updates flow from CPO to eMSP so the driver watches progress in an app that belongs to a company with no physical connection to the charger.
CDRs (Charge Detail Records)
The receipt. Final session data once charging ends: kWh delivered, duration, calculated cost. This is the record the two parties settle against, which makes it the module where a disagreement costs real money. See the CDRs module deep dive.
Tokens
The customer-identity layer. The eMSP issues tokens (digital RFID cards, in effect) to its customers. When a driver plugs in at a CPO’s station, the CPO checks that token against the eMSP to confirm the customer is good for it. The Tokens module article covers the caching and whitelist behaviour that decides whether this works when the link is down.
Commands
Remote control. Lets an eMSP start or stop a session on the CPO’s network, which is what sits behind a “start charging” button in an app.
There are more modules (Credentials, Versions, HubClientInfo, ChargingProfiles), but Locations, Tariffs, Sessions, CDRs, Tokens, and Commands are the six to build first. Each of them has its own deep dive on this site, starting with Locations.
The architectures OCPI supports
OCPI doesn’t dictate how the connections get wired. Three patterns come up.
1. Direct peer-to-peer
CPO and eMSP integrate with each other. They exchange credentials, establish the connection, and move data over OCPI endpoints they each host.
Pros: no third party in the data path, and no per-transaction fee to anyone.
Cons: every new partner is a new bilateral integration, a new set of credentials to rotate, and a new counterparty to chase when CDRs don’t reconcile. The workload scales with the number of partners, not the number of sessions.
2. Hub-mediated (one connection, many partners)
The CPO and the eMSP each connect to a roaming hub, and the hub relays between them. The CPO maintains one connection; the hub maintains the connections to every participating eMSP. Hubject and Gireve are examples of roaming hubs, and hubs are not a European-only arrangement: Hubject is German-founded but operates in North America as well.
Pros: one integration reaches everyone already connected to that hub.
Cons: hub fees, plus a dependency on the hub staying up.
If you’re weighing this decision, what a roaming hub actually does and hub vs peer-to-peer OCPI go through it properly.
3. Hybrid
Direct connections to the partners carrying real volume, a hub for the long tail. OCPI is the same protocol on both paths, which is precisely what makes the mix workable: to your stack, a hub is just a peer that happens to speak on behalf of many parties.
Side by side:
flowchart LR
subgraph p2p["Direct peer-to-peer (every party-pair has its own connection)"]
direction LR
pA(CPO 1) --- pX(eMSP A)
pA --- pY(eMSP B)
pB(CPO 2) --- pX
pB --- pY
endflowchart LR
subgraph hub["Hub-mediated (one connection per party, hub fans out)"]
direction LR
hA(CPO 1) --- H{{Roaming Hub}}
hB(CPO 2) --- H
H --- hX(eMSP A)
H --- hY(eMSP B)
H --- hZ(eMSP C)
end
style H fill:#3b82f6,color:#fff,stroke:#1e40af,stroke-width:2pxOCPI versions in 2026
A quick map of which versions matter:
- OCPI 2.1.1 (Oct 2017): predates the role-based architecture and several of the modules that arrived in 2.2. There’s no reason to target it for new work. You’ll meet it where a partner hasn’t upgraded, and the fix is a migration rather than a workaround.
- OCPI 2.2 (Mar 2020): the architectural shift. Explicit roles (CPO, eMSP, Hub and others), Tariffs, Tokens and Commands in their modern form, and hub interaction treated as a first-class case rather than something bolted on.
- OCPI 2.2.1 (Jun 2020): the current mainstream release. It corrects errata in 2.2 rather than adding features, so if you’re choosing between the two there’s no argument for picking 2.2.
- OCPI 2.3.0 (February 2025): adds AFIR compliance for the EU regulation, North American tax level support, and an extensibility framework for vendor-specific fields. If your stations fall under AFIR, the regulation is what sets your timeline for this version, not any technical preference. See what’s new in 2.3.0.
- OCPI 3.0 (in development): larger architectural changes, not something to build against yet.
For a new integration in 2026, 2.2.1 is the version to build against, with 2.3.0 as the upgrade you plan for rather than defer. The OCPI version history covers what changed between releases, and 2.2 vs 2.2.1 explains why the third digit is worth arguing about.
Why this matters for the EV charging industry
OCPI is one of the protocols that lets EV charging behave like a market instead of a set of walled gardens. Strip it out and the consequences stack up fast. Drivers carry an account per network. A new CPO has to build a consumer app before it can sell a single kWh, which hands incumbents a moat that has nothing to do with running chargers well. An eMSP can’t credibly promise coverage, so its whole proposition collapses. And infrastructure investment slows, because capturing revenue from a driver you have no relationship with becomes a bespoke negotiation every time.
Standardizing the connection lets each party specialize. The CPO competes on uptime, siting and price. The eMSP competes on the app and the account. Neither has to solve the other’s problem to reach the driver.
There’s a second-order effect worth naming: standardizing the interface also standardizes the comparison. Once every operator publishes price and availability in the same shape, tariffs become machine-comparable across the whole roaming network, and an eMSP app can quietly route a driver to the cheaper charger. OCPI creates that pressure on CPO margins rather than relieving it. Interoperability is not a neutral gift to everyone who adopts it.
The honest summary
OCPI is unglamorous by design. It’s a JSON API, a version negotiation handshake, and a set of modules, wrapped in bilateral business agreements the protocol says nothing at all about.
The part that’s easy to underestimate is that OCPI is a settlement protocol wearing an API’s clothes. Locations and Sessions are pleasant to build and easy to demo, because nothing about them is contested. CDRs are where a mismatched tariff, a clock skew or a dropped record turns into an invoice dispute weeks after the driver has forgotten the session, with two finance teams and no shared source of truth to appeal to. That’s the module to over-engineer first, precisely because it’s the only one of the six with nothing to show in a demo.
The related trap is assuming that a successful integration means roaming works. The protocol only defines the interface. It will happily and correctly connect two parties who disagree about what they owe each other.
Where to go from here
If you want to go deeper:
- OCPI vs OCPP vs OICP vs ISO 15118, a plain-English comparison
- What is a CPO? What is an eMSP?, the roles in detail
- OCPI version history, what changed across 2.1.1, 2.2, 2.2.1 and 2.3.0
- The OCPI Locations module, first of the per-module deep dives
- Hub vs peer-to-peer OCPI, which architecture fits your scale
If you’re on a CPO or eMSP team about to implement OCPI, the canonical spec lives at evroaming.org.