OCPI Explained: The Protocol That Makes EV Roaming Possible

If you’ve ever wondered how a driver with a Shell Recharge account can plug into an Allego station and have the session work — payment, kWh tracking, receipt, all of it — without setting up a new account, the answer is OCPI.

This article is the pillar. By the end you’ll know what OCPI is, what problem it solves, who uses it, how it differs from the other “OC” protocols in the EV space, and what’s actually inside it.

The problem OCPI exists to solve

Before OCPI, every EV charging network operated as a walled garden:

• A driver with a ChargePoint account could charge at ChargePoint stations. Period.
• To charge at EVgo, they needed a separate EVgo account, separate app, separate payment method.
• A driver with no apps installed simply couldn’t charge at most public stations.

This was workable when EVs were rare. As adoption scaled, the friction became unacceptable. Imagine if every gas station required a different brand-specific credit card.

OCPI is the protocol that fixes this. It’s the technical layer that lets two different charging networks recognize each other’s customers, share station data, and settle the financial transactions afterward.

The user-facing version of OCPI is roaming: an EV driver with one account uses stations across many networks. Like cellular roaming — your phone works in countries where your carrier has agreements.

What “OCPI” stands for

Open Charge Point Interface. Three things baked into the name:

• Open — the spec is publicly available, royalty-free, anyone can implement it
• Charge Point — the EV charging 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. New versions are developed in working groups; major versions are released every 12-24 months.

The two main roles OCPI connects

OCPI defines several roles, but two are central to almost every implementation:

CPO — Charge Point Operator

The company that owns and operates charging stations. They install the hardware, maintain it, set the prices, monitor the sessions. Examples: Tesla (for non-Tesla access), Electrify America, EVgo, ChargePoint, Blink Charging, and FLO in North America; Allego, IONITY, and Fastned in Europe.

eMSP — e-Mobility Service Provider

The company that owns the driver relationship. They provide the app, manage the customer’s payment method, issue the RFID card. They typically don’t own any charging hardware. Examples: PlugShare, ChargePoint, EVgo’s app, Electrify America Pass, Tesla app, Chargeway in North America; Shell Recharge, Plugsurfing, EnBW mobility+, Octopus Electroverse in Europe.

Some companies play both roles (ChargePoint operates stations and offers a customer app). Others specialize in one.

OCPI lets a driver who’s a customer of eMSP X charge at a station owned by CPO Y, with the financial and data flows handled correctly between the two parties.

How OCPI compares to OCPP, OICP, and ISO 15118

The “open charge” protocol space has multiple acronyms. They 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: imagine an EV charging session as having four layers of communication.

1. EV to station (ISO 15118): “What voltage do you offer? What’s my SOC? Begin charging.”
2. Station to CPO backend (OCPP): “Driver authenticated. Session started. Delivering 47 kW. Session ended at 32.4 kWh.”
3. CPO to eMSP (OCPI): “Your customer just charged at our station. Here’s the session detail and the CDR for billing.”
4. eMSP to driver: Push notification, app dashboard update, monthly bill.

Each layer uses its own protocol. OCPI lives at the third layer — the business-to-business layer.

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 bill

What OCPI actually exchanges

OCPI is organized into modules. Each module covers one type of information that needs to flow between CPOs and eMSPs. The major ones:

Locations

Information about charging stations: where they are, what connectors they offer, what power level, current operational status. The CPO publishes this; eMSPs consume it to populate their app’s map and station detail pages.

Tariffs

Pricing. What does it cost per kWh, per minute, per session? Are there time-of-use rates? Idle fees? The CPO publishes; eMSPs consume to show pricing in their app and to bill customers afterward.

Sessions

Live charging session data — when a session starts, what kW it’s drawing, current SOC if available. Real-time updates flow from CPO to eMSP so the eMSP can show the driver progress in their app.

CDRs (Charge Detail Records)

The “receipt” — final session data after charging ends. kWh delivered, duration, calculated cost. Used for billing between CPO and eMSP (and ultimately, the driver).

Tokens

The customer-identity layer. The eMSP issues tokens (think of them as digital RFID cards) to its customers. When a driver plugs in at a CPO’s station, the CPO validates the token against the eMSP to confirm the customer is authorized.

Commands

Remote control. Allows an eMSP to start or stop a charging session via the CPO’s network — supporting features like “start charging from the app.”

There are more modules (Credentials, Versions, Hub Client Info, Locations subset filters, ChargingProfiles), but Locations, Tariffs, Sessions, CDRs, Tokens, and Commands are the core six that drive most of the value.

Each module has its own dedicated deep-dive article on the site as we build out the OCPI cluster.

The architectures OCPI supports

OCPI is flexible about how the connections are made. Three common patterns:

1. Direct peer-to-peer

CPO and eMSP integrate directly. They exchange credentials, establish a connection, and exchange data via OCPI APIs.

Pros: No third party in the data path. Lower per-transaction cost.

Cons: Each new partner requires a new bilateral integration. Doesn’t scale to dozens of partners.

2. Hub-mediated (one connection, many partners)

The CPO and eMSP each connect to a roaming hub (like Hubject or Gireve). The hub mediates between them. The CPO has one connection to the hub; the hub has connections to all participating eMSPs.

Pros: One integration per party connects you to the entire hub’s ecosystem. Faster to scale.

Cons: Hub fees. Dependency on the hub being operational.

3. Hybrid

Some CPOs maintain direct connections to their largest eMSP partners and use a hub for smaller ones (or vice versa). OCPI doesn’t care — it’s the same protocol either way.

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
    end

flowchart 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:2px

OCPI versions in 2026

A quick map of which versions matter:

• OCPI 2.1.1 (Oct 2017): Still deployed in some legacy systems. Lacks the role-based architecture and many modules introduced in 2.2. Mostly being migrated away from.
• OCPI 2.2 (Mar 2020): Big architectural shift — introduced explicit roles (CPO, eMSP, Hub, etc.), added the Tariffs/Tokens/Commands modules in their modern form, made hub interactions first-class. Most teams skipped straight to 2.2.1 because of early-release bugs.
• OCPI 2.2.1 (Jun 2020): Patch release with clarifications, bug fixes, and tighter spec language. This is the current mainstream version — widely deployed by major CPOs and eMSPs, and what most documentation refers to when it says “OCPI 2.2.”
• OCPI 2.3.0 (February 2025): Adds AFIR compliance (EU regulation requirements), North American tax level support, and an extensibility framework for vendor-specific additions. Adoption growing through 2025-2026.
• OCPI 3.0 (proposed, in development): Larger architectural changes; not yet widely deployed.

Most production integrations in 2026 are on 2.2.1, with 2.3.0 adoption growing. The OCPI Version History article covers what changed across versions in detail, and the 2.2 vs 2.2.1 comparison explains why those minor digits matter.

Why this matters for the EV charging industry

OCPI is one of the protocols that lets the EV charging market function as a market rather than a collection of walled gardens. Without it:

• Drivers would need separate accounts for every network they encounter
• New CPOs would struggle to build customer-facing apps from scratch (and thus would struggle to compete with incumbents)
• eMSPs couldn’t offer “all networks” coverage — their value prop would collapse
• Investment in charging infrastructure would be slower because revenue capture would be harder

By standardizing the connections, OCPI lets each party focus on their core competency. CPOs focus on operating stations well. eMSPs focus on customer experience. The protocol handles the integration plumbing.

This is the open-standards bet. The more it works, the faster the market scales.

The honest summary

OCPI is the plumbing that lets EV charging behave like a market rather than a collection of walled gardens. It’s not glamorous — it’s APIs, JSON payloads, and bilateral business agreements between operators — but it’s the layer that makes the user-facing experience (one account, charge anywhere) possible. If you operate in EV charging at any level, understanding OCPI is foundational.

The protocol is also a story about open standards winning over proprietary alternatives. OCPI’s existence and growth has steadily pushed the industry toward interoperability — and that’s good for drivers, good for new entrants, and good for the pace of EV adoption.

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, 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 a CPO or eMSP team and you want to implement OCPI, the canonical spec lives at evroaming.org.