What Is OCPI? EV Charging Roaming Protocol Explained

Quick answer: OCPI (Open Charge Point Interface) is an open REST/HTTPS protocol from the EVRoaming Foundation used between EV charging back-office systems — typically a CPO (Charge Point Operator) and an eMSP (e-Mobility Service Provider) — to enable roaming. The most widely deployed versions are OCPI 2.1.1 (the broad interoperability baseline, no role field and no Hub role) and OCPI 2.2.1 (adds an explicit role list with Hub/NSP/NAP/SCSP, a roles[] array in credentials, and the ChargingProfiles and HubClientInfo modules). OCPI 2.3.0 is the latest published version.

OCPI (Open Charge Point Interface) is the protocol that enables EV charging roaming between backend systems such as CPO and eMSP platforms. Developed and maintained by the EVRoaming Foundation, OCPI standardizes how networks exchange locations, sessions, tariffs, tokens, and billing records so drivers can charge outside their home network. The current specifications and reference implementations are hosted on GitHub at ocpi/ocpi.

If you are implementing or validating a roaming stack, continue with OCPI 2.1.1 testing and OCPI 2.2.1 testing for version-specific coverage.

If you are deciding which version to implement, read the full OCPI 2.1.1 vs 2.2.1 comparison.

If you are preparing for partner onboarding or hub validation, see OCPI roaming testing or book an OCPI demo.

Why Does OCPI Exist? The EV Charging Roaming Problem

Without a roaming protocol, every EV charging network operates as a walled garden. A driver subscribed to Network A cannot use Network B's chargers without creating a separate account, downloading another app, and managing another payment method. This fragmentation is the single largest friction point for EV adoption today.

OCPI solves this by standardizing how charging networks exchange data. The result is an experience similar to mobile phone roaming: one subscription, universal access. Here is what OCPI enables in practice:

• Driver convenience: A single app or RFID card works across all participating networks, eliminating the need for dozens of accounts
• Network growth: CPOs gain access to a larger customer base without incremental marketing spend
• Automated settlement: Billing, invoicing, and revenue sharing between networks happen programmatically through standardized Charge Detail Records
• Market expansion: eMSPs can offer nationwide or continent-wide coverage without owning or operating a single charger
• Regulatory compliance: The EU Alternative Fuels Infrastructure Regulation (AFIR) requires ad-hoc access to all public chargers, which in practice demands roaming capability

As of February 2026, GIREVE's monthly Roaming in Europe barometer reported roughly 695,000 charge points connected to its OCPI-mediated platform across dozens of European countries, making it the largest roaming hub on the continent. Hubject's intercharge network — which carries both OCPI and OICP traffic — reports connecting over 1,000,000 charge points across 70+ countries on four continents. These figures reflect the protocol's central role in EV roaming today. The OCPI 2.2.1 specification itself defines 8 modules (Locations, Sessions, CDRs, Tariffs, Tokens, Commands, ChargingProfiles, HubClientInfo) on top of Credentials + Versions — published openly by the EVRoaming Foundation.

How Does OCPI Work? Architecture and Technical Design

OCPI is a REST API protocol built on standard HTTP. Two parties — typically a CPO (Charge Point Operator) and an eMSP (e-Mobility Service Provider) — establish a peer-to-peer connection and exchange structured JSON data over HTTPS. Unlike OCPP, which uses persistent WebSocket connections between chargers and backends, OCPI uses stateless HTTP requests between backend systems.

The OCPI Credential Handshake

Before any data exchange occurs, both parties must complete a credential handshake. This is a mutual authentication process:

1. Token A: Party B gives Party A a pre-shared TOKEN_A out-of-band
2. Version negotiation: Party A calls Party B's /versions with TOKEN_A and both agree on the highest mutually supported OCPI version
3. Endpoint discovery: Party A retrieves Party B's module endpoints via GET /versions/{version_number}
4. Token exchange: Party A sends POST /credentials with a new TOKEN_B for Party B to use; Party B stores it and responds with TOKEN_C. From this point, Party A uses TOKEN_C to call Party B, and Party B uses TOKEN_B to call Party A. TOKEN_A is discarded. The flow is the same in OCPI 2.1.1, 2.2.1 and 2.3.0
5. Connection active: Both parties can now exchange data through the agreed-upon module endpoints

This handshake ensures that credentials are never static. Either party can re-register at any time to rotate tokens, which is a significant security advantage over protocols that rely on fixed API keys.

Push and Pull Communication Modes

OCPI supports two data synchronization modes, and most production deployments use both:

Pull mode (Client-Owned): The receiving party periodically requests data from the sender using standard GET requests with pagination. For example, an eMSP pulls location data from a CPO by calling GET /locations?date_from=2025-01-01T00:00:00Z&offset=0&limit=50. This is simple to implement but introduces latency between updates.

Push mode (Server-Owned): The sending party proactively pushes updates to the receiver using PUT, PATCH, or DELETE requests. When a CPO updates a charger's status, it immediately sends a PATCH /locations/{location_id}/{evse_id} to the eMSP. This provides near-real-time data but requires the receiver to expose endpoints that accept incoming requests.

In practice, most implementations use pull mode for initial data synchronization (fetching the full dataset) and push mode for incremental updates (real-time status changes, new sessions, etc.).

OCPI Versioning and Endpoint Discovery

Every OCPI implementation exposes a versions endpoint that lists all supported protocol versions:

GET /ocpi/versions

This returns a list of version objects, each containing a version number and URL. The connecting party then queries the specific version URL to discover available module endpoints. This design means a single OCPI server can support multiple protocol versions simultaneously, enabling gradual migration without breaking existing connections.

All OCPI Modules Explained

OCPI is organized into modules, each handling a specific domain of the roaming workflow. A party does not need to implement every module — only those relevant to its role and business needs.

Locations Module

The Locations module is the foundation of OCPI. It describes where chargers are, what capabilities they have, and whether they are currently available. A Location object contains one or more EVSEs (Electric Vehicle Supply Equipment), each with one or more Connectors.

Data hierarchy: Location > EVSE > Connector

Key fields: address, coordinates, operator info, opening hours, EVSE status (AVAILABLE, BLOCKED, CHARGING, INOPERATIVE, OUTOFORDER, PLANNED, REMOVED, RESERVED, UNKNOWN), connector type (Type 2, CCS2, CHAdeMO), power output, and pricing.

Example use case: An eMSP pulls all locations from a CPO to populate its driver-facing app with a map of available chargers. When an EVSE status changes from AVAILABLE to CHARGING, the CPO pushes the update so the app reflects real-time availability.

Sessions Module

The Sessions module provides real-time data about active charging sessions. While a session is in progress, both parties can track energy delivered, current power, cost accrued, and session state.

Key fields: session ID, start timestamp, kWh delivered, CDR token (identifying the driver), status (ACTIVE, COMPLETED, INVALID, PENDING), and total cost.

Example use case: An eMSP displays a live charging dashboard in its app showing the driver how much energy has been delivered, current charging speed, and estimated cost so far.

CDRs Module (Charge Detail Records)

CDRs are the billing backbone of OCPI. A CDR is generated after a session completes and contains all information needed for invoicing and settlement between the CPO and eMSP.

Key fields: start/stop timestamps, total energy (kWh), total time, total parking time, total cost, tariff applied, charging periods (time-based breakdown of the session), and the authorization token used.

Example use case: After a driver finishes charging, the CPO generates a CDR and pushes it to the eMSP. The eMSP uses this CDR to invoice the driver and reconcile payments with the CPO at the end of the billing cycle.

Tariffs Module

The Tariffs module defines pricing structures that CPOs apply to their charge points. OCPI tariffs support complex pricing models including time-of-use rates, energy-based pricing, flat fees, parking fees, and combinations thereof.

Key fields: tariff ID, currency, tariff elements (each containing price components and restrictions like time-of-day, min/max kWh, day of week), and tariff type (AD_HOC_PAYMENT, PROFILE_CHEAP, PROFILE_FAST, PROFILE_GREEN, REGULAR — added in 2.2.1; not present in 2.1.1).

Example use case: A CPO publishes a tariff that charges 0.35 EUR/kWh during peak hours (08:00-20:00) and 0.25 EUR/kWh during off-peak hours, plus a 0.05 EUR/min idle fee after the session completes. The eMSP displays this pricing to the driver before they start charging.

Tokens Module

The Tokens module handles driver authorization. An eMSP pushes its driver tokens (RFID UIDs, app-based virtual tokens, or vehicle-based tokens) to the CPO so the CPO can authorize charging sessions locally without a real-time callback.

Key fields: token UID, token type (RFID, OTHER in 2.1.1; RFID, APP_USER, AD_HOC_USER, OTHER in 2.2.1), contract ID, issuer, valid flag, and whitelist type (ALWAYS, ALLOWED, ALLOWED_OFFLINE, NEVER).

Example use case: An eMSP pushes all its active driver tokens to a CPO. When a driver taps their RFID card at the CPO's charger, the CPO can authorize the session instantly by checking its local token cache, even if the network connection to the eMSP is temporarily unavailable.

Commands Module

The Commands module enables remote control of charging sessions. An eMSP can send commands to a CPO to start or stop a session, reserve a charger, or unlock a connector on behalf of a driver.

Supported commands:

• START_SESSION: Remotely start a charging session at a specific EVSE
• STOP_SESSION: Remotely stop an active session
• RESERVE_NOW: Reserve an EVSE for a specific driver for a limited time
• UNLOCK_CONNECTOR: Remotely unlock a connector (useful if the cable is stuck)

Example use case: A driver opens their eMSP app, selects a charger on the map, and taps "Start Charging." The eMSP sends a START_SESSION command to the CPO via OCPI, and the CPO relays it to the charger via OCPP.

ChargingProfiles Module

Added in OCPI 2.2, the ChargingProfiles module allows an eMSP to set power limits or charging schedules on behalf of the driver. This is essential for smart charging and demand response scenarios.

Key fields: charging profile (containing schedule periods with power limits), response URL (for async result notification).

Example use case: A driver tells their eMSP app they need 80% charge by 7 AM and want the cheapest rate. The eMSP calculates an optimal charging schedule and sends a ChargingProfile to the CPO, which applies it to the charger via OCPP charging profiles. The charger modulates power delivery according to the schedule.

HubClientInfo Module

The HubClientInfo module is specific to hub-based deployments. It allows a roaming hub (like GIREVE) to inform connected parties about all other parties connected to the hub, including their roles and connection status.

Key fields: party ID, country code, role (CPO, eMSP, HUB), status (CONNECTED, OFFLINE, PLANNED, SUSPENDED).

Example use case: An eMSP connected to GIREVE receives HubClientInfo updates listing all CPOs currently connected to the hub. The eMSP uses this to know which CPO networks are available for its drivers and can display coverage accordingly.

OCPI 2.1.1 vs 2.2.1: What Changed?

OCPI has gone through several iterations. The two versions you will most often encounter in production today are 2.1.1 and 2.2.1; OCPI 2.3.0 is the latest published version. Understanding the differences is critical for implementation planning.

OCPI 2.1.1

OCPI 2.1.1 is the most widely deployed version. It covers all core roaming functionality and remains the baseline requirement for most roaming hub connections. If you are building your first OCPI integration, you will almost certainly start here.

OCPI 2.2.1

Released in 2021, OCPI 2.2.1 is a significant upgrade that adds hub support, smart charging, and improved tariff handling. Adoption is growing rapidly as roaming hubs and larger operators migrate.

Detailed Version Comparison

Recommendation: Implement OCPI 2.2.1 if you are connecting through a roaming hub, need smart charging capabilities, or operate in Germany (Eichrecht compliance). Start with 2.1.1 if you need the fastest path to production for basic roaming.

OCPI vs OCPP: What Is the Difference?

This is the most common question in EV charging protocol discussions. The short answer: OCPP (Open Charge Point Protocol) manages communication between a charger and its backend system (CPMS). OCPI manages communication between backend systems of different charging networks. They operate at different layers of the stack and are complementary, not competing.

How they work together: When a roaming driver starts a session, the eMSP sends an OCPI command to the CPO's backend. The CPO's backend then sends an OCPP RemoteStartTransaction message to the physical charger. Session data flows back up through OCPP (MeterValues, StopTransaction) and is then shared with the eMSP via OCPI (Sessions, CDRs).

OCPI vs OICP vs OCHP: EV Charging Roaming Protocols Compared

OCPI is not the only roaming protocol in the EV charging industry. Two other protocols serve similar purposes: OICP (Open InterCharge Protocol) and OCHP (Open Clearing House Protocol). Understanding the differences helps when choosing which ecosystem to join.

OCPI has the broadest adoption and the most open governance model. It is the default choice for most new implementations. OICP is tightly coupled with Hubject and offers mature Plug&Charge support through Hubject's PKI infrastructure, making it strong in the German-speaking market. OCHP is the oldest of the three and is most common among e-clearing.net members, but has seen less adoption growth in recent years.

Many large operators implement multiple protocols. A CPO connected to both GIREVE (via OCPI) and Hubject (via OICP) maximizes its roaming reach.

Roaming Hubs: GIREVE, Hubject, and e-clearing

Rather than establishing direct OCPI connections with every partner (which does not scale), most CPOs and eMSPs connect through a roaming hub. A single hub connection gives access to all other parties connected to that hub.

GIREVE

GIREVE is the largest OCPI-based roaming hub in Europe. Founded in France in 2013, it has grown into the dominant roaming platform on the continent.

• Coverage: As of February 2026, roughly 695,000 charge points across dozens of European countries (GIREVE Roaming in Europe barometer)
• Partners: Several hundred connected CPOs and eMSPs
• Protocol support: OCPI 2.1.1 and 2.2.1 (primary), plus eMIP (GIREVE's legacy protocol)
• Key features: Quality scoring of charge points, B2B marketplace for roaming agreements, data analytics
• Certification: GIREVE runs a certification process for new OCPI connections, including test scenarios that validate your implementation

Hubject

Hubject operates the intercharge network, the largest global roaming platform by geographic reach.

• Coverage: As of 2026, over 1,000,000 charge points across 70+ countries on four continents (Hubject)
• Protocol support: OICP (primary), OCPI 2.2.1 (growing)
• Key features: Plug&Charge PKI infrastructure (ISO 15118), eRoaming marketplace, global interoperability
• Market position: Strongest in Germany, Austria, and Switzerland; expanding aggressively in North America and Asia-Pacific

e-clearing.net

e-clearing.net is a pan-European clearing house originally developed by Smartlab (now part of the Recharge group).

• Coverage: Primarily Central Europe (Germany, Netherlands, Belgium, Austria)
• Protocol support: OCHP (primary), OCPI (supported)
• Key features: Clearing and settlement services, contract management, direct roaming facilitation
• Market position: Smaller than GIREVE and Hubject but well-established among Central European utilities

How Do CPOs Use OCPI?

A Charge Point Operator (CPO) uses OCPI to expose its charging infrastructure to external networks. Here is what a CPO typically implements:

Data provider role (CPO pushes data to eMSPs):

• Locations: Publish all charge point locations, EVSE statuses, connector types, and real-time availability
• Sessions: Share active session data so eMSPs can display live charging information to their drivers
• CDRs: Generate and push Charge Detail Records after each roaming session for billing and settlement
• Tariffs: Publish pricing structures so eMSPs can display accurate costs to drivers before they start charging

Data receiver role (CPO receives data from eMSPs):

• Tokens: Receive and cache driver authorization tokens for local, offline-capable authorization
• Commands: Accept remote start/stop, reservation, and unlock commands from eMSP apps

Business impact: A mid-sized CPO that connects to GIREVE via OCPI can immediately access hundreds of thousands of eMSP subscribers without any direct sales or marketing effort. For public charging operators, roaming sessions can account for a meaningful and growing share of total revenue.

How Do eMSPs Use OCPI?

An eMSP (e-Mobility Service Provider) uses OCPI to aggregate charging infrastructure from multiple CPOs and present it to its subscribers. Here is what an eMSP typically implements:

Data receiver role (eMSP pulls/receives data from CPOs):

• Locations: Aggregate charge point data from all connected CPOs to build a comprehensive charging map
• Sessions: Receive real-time session updates to display in the driver app
• CDRs: Receive billing records to invoice drivers and reconcile with CPOs
• Tariffs: Receive pricing data to display accurate cost estimates

Data provider role (eMSP pushes data to CPOs):

• Tokens: Push driver authorization tokens to all connected CPOs for local authorization
• Commands: Send remote start/stop and reservation commands on behalf of drivers
• ChargingProfiles: Send smart charging schedules (OCPI 2.2.1) based on driver preferences

Business impact: An eMSP connected to one roaming hub can offer its drivers access to hundreds of thousands of charge points across multiple countries without deploying any hardware. The entire value proposition — "charge anywhere with one app" — depends on OCPI working reliably.

How Do You Implement OCPI? A Step-by-Step Guide

Implementing OCPI requires building a REST API server and client that conforms to the OCPI specification. Here is a high-level roadmap:

Step 1: Define Your Role and Scope

Determine whether you are implementing as a CPO, eMSP, or both. This determines which modules you need and whether you are primarily a data sender or receiver.

Step 2: Choose Your OCPI Version

For most new implementations, start with OCPI 2.2.1. If your target roaming hub only requires 2.1.1, start there. Support both versions if possible — OCPI's version discovery mechanism makes this straightforward.

Step 3: Implement Core Endpoints

Build the required endpoints in order of dependency:

1. Versions and Credentials: These are mandatory. Without them, no connection can be established.
2. Locations (if CPO): This is the most data-intensive module and typically requires the most development effort.
3. Tokens (if eMSP): Push your driver tokens to enable authorization.
4. Sessions and CDRs: These handle the billing workflow and are required for any commercial roaming.
5. Tariffs: Needed for price transparency.
6. Commands: Needed for remote start/stop from eMSP apps.

Step 4: Implement Push and Pull Synchronization

Build both pull endpoints (for initial sync and periodic reconciliation) and push endpoints (for real-time updates). Implement proper pagination handling with offset, limit, and date_from parameters.

Step 5: Connect to a Roaming Hub

Contact your target hub (GIREVE, Hubject, or e-clearing) and begin their onboarding process. Each hub has a staging environment for testing.

Step 6: Test End-to-End

Validate the full workflow: credential handshake, location sync, token exchange, remote start, session tracking, CDR generation, and settlement. This is where most implementations encounter issues with edge cases — malformed data, timeout handling, concurrent updates, and tariff calculation discrepancies.

How Do You Test OCPI Implementations?

Testing OCPI is challenging because it requires simulating both sides of the protocol. You need to act as both a CPO and an eMSP, generate realistic data, and validate complex interactions across multiple modules.

Common testing challenges include:

• Simulating the credential handshake and token rotation
• Generating realistic location data with proper EVSE/Connector hierarchies
• Testing push and pull synchronization, including conflict resolution
• Validating CDR calculations against published tariffs
• Simulating hub-based routing (for OCPI 2.2.1)
• Testing error handling and edge cases (network timeouts, invalid tokens, concurrent session updates)

OCPPLab provides OCPI testing tools alongside its OCPP emulator, letting you validate both protocols in a single environment. You can simulate CPO and eMSP endpoints, generate realistic sessions and CDRs, test tariff calculations, validate GIREVE-compatible hub integration, and run full end-to-end roaming scenarios without needing a live roaming partner.

Frequently Asked Questions About OCPI

What does OCPI stand for?

OCPI stands for Open Charge Point Interface. It is an open protocol maintained by the EVRoaming Foundation that standardizes data exchange between EV charging networks to enable roaming. The name is often confused with OCPP (Open Charge Point Protocol), but they serve different purposes: OCPI handles network-to-network roaming, while OCPP handles charger-to-backend communication.

Is OCPI mandatory in Europe?

OCPI is not legally mandated by any European regulation. However, the EU Alternative Fuels Infrastructure Regulation (AFIR), which took effect in April 2024, requires that all public charging stations offer ad-hoc (contract-free) access and interoperable payment. While AFIR does not specify a protocol, meeting its interoperability requirements in practice requires roaming capability, and OCPI is the dominant protocol for achieving this.

Can I use OCPP without OCPI?

Yes. OCPP manages communication between your chargers and your CSMS (Charging Station Management System) — OCPP 1.6 Central System, industry slang CPMS. You only need OCPI if you want to enable roaming — allowing drivers from other networks to use your chargers, or allowing your drivers to use chargers on other networks. Many small CPOs operate OCPP-managed networks for years before adding OCPI when they are ready to join a roaming ecosystem.

What is the difference between OCPI and OICP?

OCPI is an open community protocol governed by the EVRoaming Foundation, with its specification freely available on GitHub. OICP (Open InterCharge Protocol) is developed and controlled by Hubject, with its specification available under NDA. Both protocols enable roaming between charging networks. OCPI has broader industry adoption and supports peer-to-peer connections, while OICP is tightly integrated with Hubject's intercharge network and offers more mature Plug&Charge (ISO 15118) support.

How long does it take to implement OCPI?

Implementation timelines vary significantly based on scope and team experience. A minimum viable OCPI implementation (Credentials, Locations, Tokens, and CDRs) typically takes 2-4 months for a development team new to the protocol. Adding all modules, comprehensive error handling, and hub certification extends this to 4-8 months. The credential handshake and CDR reconciliation logic tend to be the most time-consuming aspects.

What programming languages can I use for OCPI?

OCPI is a REST API specification, so it can be implemented in any language that supports HTTP servers and clients. Common choices in the industry include Python, Java, Go, C#, and Node.js. There are several open-source OCPI libraries on GitHub, though most production implementations are custom-built to handle the specific business logic of tariff calculation, CDR validation, and hub integration.

Does OCPI support Plug&Charge?

OCPI 2.2.1 includes partial support for Plug&Charge through the Tokens module (using the AD_HOC_USER token type and authorization_reference field). However, the full Plug&Charge workflow (ISO 15118 certificate management, contract certificate provisioning) is not part of the OCPI specification. Hubject's OICP protocol currently offers more complete Plug&Charge support through its integrated PKI infrastructure. The EVRoaming Foundation is actively working on enhanced Plug&Charge support for future OCPI versions.

How does OCPI handle pricing and billing?

OCPI handles pricing through two modules: Tariffs (published pricing structures) and CDRs (actual billing records). A CPO publishes its tariffs via the Tariffs module, which the eMSP uses to display estimated costs to drivers. After a session completes, the CPO generates a CDR containing the actual cost calculated against the applicable tariff. The eMSP then invoices the driver based on the CDR. Settlement between CPO and eMSP typically happens monthly through the roaming hub or via direct bilateral agreements.

Is OCPI used outside of Europe?

OCPI adoption originated in Europe but is expanding globally. GIREVE has partners in North Africa, the Middle East, and parts of Asia. Hubject (which supports both OICP and OCPI) reports operating across 70+ countries on four continents. In North America, OCPI adoption is growing as operators seek interoperability, though the market has historically relied more on proprietary integrations. Australia, South Korea, and India are emerging OCPI markets as their public charging networks mature.

What is the latest version of OCPI?

The latest version published by the EVRoaming Foundation is OCPI 2.3.0. Most production deployments today still run 2.1.1 or 2.2.1, so a roaming backend usually needs to support those as well.