The Open Charge Point Interface (OCPI) is the protocol that makes EV roaming work. It connects Charge Point Operators (CPOs) and eMobility Service Providers (eMSPs) so that drivers can charge on any network without separate accounts, apps, or contracts. In a market with dozens of competing networks per country, OCPI is the reason cross-network charging functions at all.

But reading the spec and running OCPI in production are very different experiences. The protocol’s modularity — its greatest strength — is also what makes implementation deceptively complex. Most teams underestimate the gap between a working API and a reliable roaming connection that handles real sessions, real tariffs, and real CDR reconciliation across multiple partners.

This guide covers what practitioners actually need: the module architecture, version differences from OCPI 2.1.1 through 2.3.0, the implementation challenges nobody warns you about, and where the OCPI protocol fits in your software stack.

What OCPI Is — And What It Actually Does in Production

The Open Charge Point Interface in 60 Seconds

OCPI is an open, RESTful protocol maintained by the EVRoaming Foundation. It standardizes data exchange between CPOs (who own and operate chargers) and eMSPs (who manage driver accounts and payments). The protocol handles location data, session management, charge detail records (CDRs), tariff information, and remote commands — everything required for a driver on Network A to charge seamlessly on a charger owned by Network B.

Unlike OCPP, which governs communication between a charger and its backend (CSMS), OCPI operates one layer up — between backends. A CPO’s platform talks to an eMSP’s platform, or both talk through a roaming hub. This distinction matters because OCPP implementation is a prerequisite, not a substitute. You need both protocols, working in concert, to deliver the seamless charging experience that drivers expect and that regulators increasingly mandate.

OCPI’s Role in the EV Roaming Ecosystem (CPO ↔ eMSP ↔ Hub)

In practice, most OCPI connections run through roaming hubs — platforms like Gireve, Hubject, or e-clearing.net that aggregate CPO and eMSP connections. Instead of establishing bilateral peer-to-peer links with every partner (which doesn’t scale), a CPO connects once to a hub and gains access to dozens or hundreds of eMSPs.

The hub model simplifies connectivity but adds a translation layer. Each hub may support different OCPI versions, interpret optional fields differently, or impose its own CDR format requirements. The result is that “OCPI-compliant” doesn’t mean “plug-and-play.” Every hub integration requires configuration, testing, and — inevitably — debugging session-linking mismatches.

OCPI Module Architecture: How the Protocol Is Structured

The OCPI specification is organized into independent modules. Each module handles a specific data domain, and platforms can implement only the modules they need. This modularity is what makes OCPI flexible, but it also means two “OCPI-compliant” platforms may support entirely different feature sets.

Core Modules

Module Function Push Pull Used By
Locations Charger locations, EVSEs, connectors, real-time availability Yes Yes CPO → eMSP
Sessions Active charging session data (energy delivered, duration, cost) Yes Yes CPO → eMSP
CDRs Charge Detail Records for billing reconciliation after session ends Yes Yes CPO → eMSP
Tariffs Pricing structures (per kWh, per minute, flat fee, combinations) Yes Yes CPO → eMSP
Tokens Driver authorization tokens (RFID, app-based, contract IDs) Yes Yes eMSP → CPO
Commands Remote actions: StartSession, StopSession, ReserveNow, UnlockConnector — — eMSP → CPO
ChargingProfiles Smart charging limits set by eMSP (added in 2.2.1) — — eMSP → CPO
HubClientInfo Connected party discovery through roaming hubs (added in 2.2.1) Yes Yes Hub → All

Commands and ChargingProfiles use a request/response pattern rather than push/pull data synchronization — an eMSP sends a command, the CPO executes it and returns a result.

How Push and Pull Interfaces Work

Every data synchronization module supports two interaction patterns. Pull means the receiver periodically requests updates (polling). Push means the sender proactively delivers updates when data changes. Most production deployments use push for time-sensitive data (sessions, commands) and pull as a fallback synchronization mechanism.

The practical implication: your OCPI implementation needs both a client (to send requests) and a server (to receive pushed data) for every module you support. This doubles the API surface compared to what most teams initially estimate.

The Hub Model vs. Peer-to-Peer Connections

Peer-to-peer OCPI connections are simpler to reason about but scale poorly — connecting to 50 partners means maintaining 50 bilateral integrations. Hubs solve this with a star topology, but they introduce their own complexity: credential management with each hub, version negotiation (the hub may translate between OCPI versions), and CDR routing rules that vary by hub.

Most mature CPOs and eMSPs maintain 2-3 hub connections plus a handful of strategic peer-to-peer links for high-volume partners. The architecture must support both patterns simultaneously.

OCPI Version Timeline — From 2.1.1 to 2.3.0

OCPI 2.1.1 — The Baseline

Released as the first widely adopted stable version, OCPI 2.1.1 established the core module architecture: Locations, Sessions, CDRs, Tariffs, and Tokens. It remains in production at many operators, particularly those who connected to roaming hubs before 2022. The protocol at this stage focused on basic roaming — sharing charger locations, authorizing sessions, and exchanging billing records.

Limitations became apparent quickly. Tariff structures were too rigid for dynamic pricing. There was no mechanism for smart charging coordination. And Calibration Law compliance — mandatory in Germany — had no protocol-level support.

OCPI 2.2.1 — Smart Charging and Calibration Law

OCPI 2.2.1 addressed the most pressing gaps. Smart charging support arrived through the ChargingProfiles module, enabling eMSPs to set charging limits on behalf of drivers. The Tariffs module gained support for time-based and energy-based pricing combinations. Calibration Law compliance (Eichrecht) got dedicated fields for signed meter values, critical for the German market.

This version also introduced the HubClientInfo module — a small but practical addition that lets hubs communicate which parties are connected and what versions they support. For operators managing multiple hub connections, this significantly reduced the guesswork in partner discovery.

OCPI 2.3.0 — AFIR Compliance, NAP, and Beyond

The most recent major release, OCPI 2.3.0, responds directly to the EU’s Alternative Fuels Infrastructure Regulation (AFIR). AFIR mandates that all public charging infrastructure in the EU must support ad-hoc (contract-free) charging and publish static and dynamic data to National Access Points (NAPs).

OCPI 2.3.0 adds structured NAP data exchange, improved ad-hoc payment flows, and expanded location attributes to meet AFIR reporting requirements. For operators targeting European markets, this version isn’t optional — it’s the compliance baseline.

Feature OCPI 2.1.1 OCPI 2.2.1 OCPI 2.3.0
Core roaming: Locations, Sessions, CDRs, Tariffs, Tokens Yes Yes Yes
Smart charging: ChargingProfiles module No Yes Yes
Calibration Law (Eichrecht): Signed meter values No Yes Yes
Hub discovery: HubClientInfo module No Yes Yes
AFIR compliance: NAP data exchange, ad-hoc payments No No Yes
Dynamic pricing: Time + energy + flat combinations Limited Yes Enhanced
Primary use case Basic roaming Roaming + smart charging + German market Full EU compliance + roaming
Adoption status (2026) Legacy — still in production at many operators Current mainstream standard Adoption accelerating (AFIR deadline-driven)

What’s Coming in OCPI 3.0

The EVRoaming Foundation has signaled that OCPI 3.0 will be a more substantial architectural revision. Early discussions point to improved real-time data streaming (replacing the current poll/push hybrid), better support for bidirectional charging scenarios (V2G), and tighter alignment with ISO 15118 Plug & Charge workflows. No release date has been confirmed, but the direction suggests a protocol that’s preparing for a grid where EVs are active participants, not passive loads.

The Real Challenges of Implementing OCPI

The specification is open and well-documented. The implementation is where things get difficult.

Version Fragmentation and Interpretation Gaps

The most immediate challenge is that your OCPI partners will be running different versions. A CPO on 2.2.1 connecting through a hub to an eMSP on 2.1.1 must handle version negotiation, field mapping, and graceful degradation for features the older version doesn’t support. The spec allows for this, but the details — which optional fields to populate, how to handle null vs. absent values — are where interpretation gaps create real bugs.

CDR Consistency and Session-Linking Failures

Charge Detail Records are the financial backbone of roaming. A CDR mismatch — where the CPO’s session data doesn’t reconcile with the eMSP’s billing record — means disputed charges, delayed settlements, and unhappy partners. In practice, CDR inconsistencies are the single most common source of OCPI integration issues. They arise from timezone handling differences, rounding behavior, tariff interpretation mismatches, and session ID propagation failures across hubs.

Testing Without Public Emulators

Unlike OCPP, which has mature testing tools and emulators, the OCPI ecosystem lacks a standardized public test suite. As one practitioner described it, implementing OCPI can feel like “the scary world” precisely because validation depends on bilateral testing with each partner. The INL/ChargeX recommendations have highlighted this gap, noting that US deployments face additional interoperability challenges due to fewer established testing frameworks compared to Europe.

Scaling Multi-Hub Connections

Each hub connection adds operational complexity: separate credential management, monitoring for uptime, CDR reconciliation pipelines, and version-specific adapters. Scaling from one hub to three doesn’t triple the work — it tends to increase it by an order of magnitude, because cross-hub edge cases (a session that starts on one hub’s partner and ends on another’s) introduce failure modes that don’t exist in single-hub deployments.

OCPI Implementation Architecture: A Practitioner’s View

Where OCPI Fits in Your Software Stack

OCPI sits between your core platform (CSMS/eMSP backend) and the external roaming ecosystem. It needs access to your location database, session management layer, tariff engine, and billing system. It also needs its own credential store, module registry, and webhook infrastructure for push notifications.

The common mistake is treating OCPI as a thin API layer on top of your existing platform. In reality, it requires its own bounded context — a dedicated service (or set of services) with clearly defined interfaces to your internal systems. Bolting OCPI handlers directly onto your CSMS creates tight coupling that becomes painful when you need to support multiple OCPI versions or connect to multiple hubs simultaneously.

API Gateway, Credential Handshake, and Module Registration

Every OCPI connection begins with a credential handshake: both parties exchange tokens and register which modules they support. This handshake establishes the “contract” — which data flows are active, which endpoints to call, and which OCPI version governs the connection.

In production, you’ll need an API gateway that handles TLS termination, rate limiting, and request routing to the correct version-specific handler. Behind the gateway, a credential manager stores per-partner tokens and module registrations. This is infrastructure that has nothing to do with charging but is essential for OCPI to function.

When to Build vs. Use an Accelerator

Building an OCPI implementation from the spec is feasible — the protocol is well-documented and the REST patterns are standard. The challenge is the long tail of edge cases: CDR reconciliation logic, version negotiation, hub-specific quirks, Calibration Law signed meter value handling, and AFIR NAP data formatting.

For teams that need to reach production quickly, a pre-built foundation — like Codibly’s OCPI Accelerator — covers the module implementations, credential handshake flow, and hub integration patterns out of the box. The accelerator ships as source code under a perpetual license, which means full customization without vendor lock-in. Teams building from scratch should budget 4-6 months for a production-grade OCPI implementation; with an accelerator, the same scope typically compresses to 4-6 weeks.

In a project with IMP PAN — a Horizon 2020 research initiative spanning Poland, Denmark, and the Netherlands — Codibly’s protocol engineering team delivered a scalable server that handled multi-site charging management with V2G capabilities. That kind of multi-country, multi-protocol integration is exactly where deep OCPI and OICP interoperability expertise compresses timelines that would otherwise stretch to quarters.

One Protocol, Many Implementations — That’s the Point

OCPI’s value is that it creates a common language for an inherently fragmented market. Dozens of CPOs, hundreds of eMSPs, and a handful of roaming hubs all need to exchange data reliably, in real time, across borders and business models. The protocol delivers that foundation.

But a foundation is not a finished building. The distance between reading the OCPI specification and operating a production roaming integration is measured in edge cases, version mismatches, and CDR reconciliation pipelines. Teams that treat OCPI as a simple REST API to bolt on will spend months discovering why their sessions don’t reconcile and their hub connections keep dropping.

The organizations that succeed with OCPI are those that invest in the architecture — dedicated services, proper credential management, version-aware routing — or partner with teams that have already mapped the terrain. The OCPP vs OCPI comparison is a useful starting point for understanding where each protocol sits. From there, the real work begins.

As GreenFlux observed, the EV charging industry is converging on OCPI as the roaming standard. The question is no longer whether to implement it, but how well.