OCPI vs OCPP: How EV Charging Protocols Work Together
EV charging relies on two protocols that sound similar but operate at entirely different layers. OCPP — the Open Charge Point Protocol — governs how a physical charger communicates with its backend management system. OCPI — the Open Charge Point Interface — governs how different charging networks exchange data to enable EV roaming. One manages the hardware. The other manages the business relationships.
The confusion between OCPI and OCPP is understandable. Both are open standards maintained by organizations with overlapping membership. Both are critical for modern EV charging infrastructure. And both often appear in the same RFPs and procurement specs. But conflating them — or assuming that implementing one gives you the other — leads to architectural decisions that become expensive to unwind.
This guide explains what each protocol does, how they compare, and when your platform needs both.
What OCPP Does — Station-to-Backend Communication
OCPP’s Role in the Charging Stack
OCPP is the communication layer between a physical charge point (the hardware on the wall or pedestal) and its central management system (CSMS). Every time a charger reports its status, authorizes a charging session, sends a meter value, or receives a firmware update command, that message flows through OCPP.
The protocol was developed by the Open Charge Alliance (OCA) and has become the global standard for charger-to-backend communication. Without OCPP, every hardware vendor would use a proprietary protocol, and operators would be locked into single-vendor ecosystems.
Key OCPP Capabilities (1.6J, 2.0.1, 2.1)
Three OCPP versions are actively deployed:
- OCPP 1.6J — The workhorse. JSON over WebSocket transport. Covers core operations: boot notification, status updates, authorization, transactions, meter values, remote start/stop. The vast majority of deployed chargers still run 1.6J.
- OCPP 2.0.1 — Adds device management, improved security profiles (TLS mutual authentication), ISO 15118 Plug & Charge support, smart charging with detailed profiles, and display messaging. Designed for grid-integrated charging.
- OCPP 2.1 — The latest release. Adds V2G (vehicle-to-grid) support, tariff management at the protocol level, dynamic pricing, and enhanced OCPP 2.1 features for demand response integration.
For a deeper look at version differences, see our OCPP 1.6 vs 2.0 comparison.
What OCPI Does — Network-to-Network Roaming
OCPI’s Role in the Roaming Ecosystem
OCPI operates one layer above OCPP. Where OCPP connects chargers to backends, OCPI connects backends to each other. Maintained by the EVRoaming Foundation, OCPI enables a driver registered with one charging network to use chargers owned by a different network — without creating a new account, downloading a new app, or carrying a different RFID card.
The protocol handles location data exchange, session tracking across networks, Charge Detail Record (CDR) reconciliation for inter-network billing, tariff transparency, and remote commands routed through roaming hubs.
Key OCPI Capabilities (2.2.1, 2.3.0)
- OCPI 2.2.1 — The current mainstream version. Modular architecture with independent modules for Locations, Sessions, CDRs, Tariffs, Tokens, Commands, and ChargingProfiles. Supports smart charging coordination between eMSPs and CPOs, plus Calibration Law (Eichrecht) compliance for the German market.
- OCPI 2.3.0 — Adds AFIR compliance (EU’s Alternative Fuels Infrastructure Regulation), National Access Point (NAP) data exchange, and enhanced ad-hoc payment flows.
For comprehensive coverage of OCPI architecture, versions, and implementation challenges, see our OCPI protocol deep dive.
OCPI vs OCPP: Head-to-Head Comparison
| Dimension | OCPP (Open Charge Point Protocol) | OCPI (Open Charge Point Interface) |
|---|---|---|
| Purpose | Charger ↔ backend communication | Backend ↔ backend roaming data exchange |
| Scope | Single network (CPO manages its own chargers) | Cross-network (CPO ↔ eMSP ↔ roaming hub) |
| Direction | South-bound (backend to hardware) | East-west (backend to backend) |
| Primary users | CPOs, CSMS vendors, charger OEMs | CPOs, eMSPs, roaming hub operators |
| Transport | WebSocket (JSON or SOAP) | RESTful HTTP/HTTPS |
| Core data | Charger status, transactions, meter values, firmware, diagnostics | Locations, sessions, CDRs, tariffs, tokens, commands |
| Smart charging | Yes — ChargingProfile messages to charger | Yes — ChargingProfiles module between backends (from 2.2.1) |
| Governance | Open Charge Alliance (OCA) | EVRoaming Foundation |
| Current versions | 1.6J, 2.0.1, 2.1 | 2.1.1, 2.2.1, 2.3.0 |
| V2G / V2X support | Yes (from 2.1) | Not yet (expected in 3.0) |
| AFIR compliance role | Ensures charger reports required data | Ensures data reaches NAPs and cross-network access (from 2.3.0) |
Different Layers, One Ecosystem
The most important thing to understand is that OCPI and OCPP are not alternatives — they’re complementary layers. OCPP is the “south-bound” protocol (backend ↔ charger). OCPI is the “east-west” protocol (backend ↔ backend). A CPO’s platform uses OCPP to manage its chargers and OCPI to connect with eMSPs and roaming hubs.
Replacing one with the other is not architecturally possible. A platform that implements OCPP but not OCPI can manage chargers but cannot participate in roaming. A platform that implements OCPI but not OCPP can exchange roaming data but has no way to control or monitor the physical chargers that create that data.
Where They Overlap (Smart Charging, Tariffs)
There is a narrow area of functional overlap: smart charging and tariff management. OCPP 2.0.1+ includes ChargingProfile messages that let the backend set power limits on a charger. OCPI 2.2.1+ includes a ChargingProfiles module that lets an eMSP request charging limits through the roaming layer.
In practice, an eMSP sends a charging limit via OCPI to the CPO’s backend, which then translates and forwards it to the charger via OCPP. The protocols don’t compete here — they form a chain, with OCPI carrying the business intent and OCPP executing it at the hardware level.
When You Need Both — And How They Fit Together
A CPO’s Protocol Stack
A Charge Point Operator needs OCPP from day one — it’s how the platform communicates with chargers. OCPI becomes necessary when the CPO wants to:
- Allow drivers from other networks to charge on its stations (roaming)
- Publish charger locations and availability to aggregator apps
- Participate in hub-based roaming networks (Gireve, Hubject)
- Meet AFIR requirements for cross-network interoperability
Most CPOs implement OCPP first, then add OCPI as their network scales beyond a single-brand experience. Codibly’s OCPP implementation services and OCPI & OICP interoperability cover both layers.
An eMSP’s Protocol Stack
An eMobility Service Provider typically doesn’t manage chargers directly, so OCPP is less central to its platform. Instead, the eMSP’s core protocol is OCPI — it’s how the eMSP discovers available chargers, authorizes its drivers on partner networks, and receives session data and CDRs for billing.
However, some eMSPs also operate their own charging stations (a hybrid CPO/eMSP model), in which case they need both. The IMP PAN research project, where Codibly built a scalable OCPP server for a multi-country V2G deployment, illustrates how protocol layers combine in practice: OCPP managed the charger fleet while higher-level roaming and grid integration protocols coordinated across sites.
Two Protocols, One Charging Experience
OCPP and OCPI serve different purposes at different layers, but they produce a single outcome: a driver plugs in, the session works, and the billing reconciles — regardless of which network owns the charger or which app the driver uses.
The practical takeaway for EV charging software teams: plan for both protocols from the start, even if you implement them sequentially. Architectural decisions made during OCPP implementation (data models, session management, tariff structures) directly affect how cleanly OCPI integrates later. Teams that treat these as separate, unrelated projects end up with expensive refactoring when roaming enters the picture.
The OCPI vs OICP comparison covers the roaming protocol decision in more detail for teams evaluating their options.
Frequently Asked Questions
An API (Application Programming Interface) is a general term for any software interface that allows two systems to communicate. OCPI is a specific, standardized API designed exclusively for EV charging roaming. OCPI defines the exact data models, endpoints, authentication flows, and module structure that CPOs and eMSPs must use to exchange charging data. Any custom API could theoretically handle the same data, but OCPI ensures interoperability across the industry — a CPO implementing OCPI can connect to any eMSP that also implements it, without custom integration work.
It depends on your role. A CPO that only serves its own registered drivers may need OCPP alone. But as soon as roaming, third-party driver access, or regulatory interoperability mandates (like AFIR) enter the picture, OCPI becomes necessary. An eMSP almost always needs OCPI. If you also operate chargers, you need both. For most commercial charging platforms targeting growth, both protocols are on the roadmap — the question is sequencing, not whether.
Yes — they are designed to. OCPP manages the physical charging infrastructure (charger to backend), while OCPI manages the roaming layer (backend to backend). A typical architecture has OCPP handling station communication and OCPI handling partner data exchange, with the CPO backend translating between the two. Smart charging commands, for example, flow from an eMSP through OCPI to the CPO backend, which then sends the corresponding OCPP message to the charger.