OCPP and OCPI differ by one letter and are both described as "open charging protocols", so they are often confused. In reality they sit at different layers of the charging ecosystem. One talks to hardware; the other talks to business partners. A modern charging network almost always needs both.
This article compares the two protocols side by side, shows how they interact during a real charging session and explains what to look for in a platform that supports them.
- OCPP (Open Charge Point Protocol) connects a charging station to its charging station management system (CSMS).
- OCPI (Open Charge Point Interface) connects one company's back-office to another's, usually a CPO and an eMSP.
- OCPP is about controlling and monitoring chargers; OCPI is about sharing locations, tariffs, sessions and billing records.
- In a roaming session, both protocols run at the same time, at different layers.
The short answer
Think of a charging network as a building. OCPP is the internal wiring that lets the control room switch the lights and read the meters. OCPI is the telephone line the building uses to talk to other companies. You need the wiring to run the building at all; you need the phone line to do business with partners.
Side-by-side comparison
| Aspect | OCPP | OCPI |
|---|---|---|
| Full name | Open Charge Point Protocol | Open Charge Point Interface |
| Connects | Charger ↔ CSMS | CSMS (CPO) ↔ eMSP or roaming hub |
| Maintained by | Open Charge Alliance | EVRoaming Foundation |
| Transport | WebSocket, JSON messages (OCPP-J) | HTTPS REST API, JSON |
| Main purpose | Control, monitoring, authorisation, metering, firmware, smart charging | Roaming: locations, tariffs, tokens, sessions, CDRs, remote commands |
| Typical messages | BootNotification, StatusNotification, MeterValues, RemoteStart | Locations, Tariffs, Sessions, CDRs, Commands |
| Current versions | 1.6J, 2.0.1, 2.1 | 2.1.1, 2.2.1, 2.3.0 |
| Who implements it | Charger manufacturers and CSMS vendors | CPO platforms, eMSPs and roaming hubs |
What OCPP does
OCPP is the language between a charger and its back office. The charger opens a WebSocket connection to the CSMS and keeps it open. Over this connection, the charger reports its status and meter readings, asks whether a card may charge and records transactions. The CSMS sends commands such as remote start and stop, configuration changes, resets, firmware updates and charging profiles for load management. Our plain-language guide to OCPP and version comparison go deeper.
What OCPI does
OCPI is the language between charging companies. A CPO uses it to tell eMSPs where its chargers are, what they cost and whether they are available, and to send records of completed sessions for billing. An eMSP uses it to share which tokens its customers use and to send remote commands, for example when a driver starts charging from the eMSP's app. Our OCPI guide explains each module.
How they work together in one session
A driver with eMSP A's app starts charging at CPO B's charger:
| Step | Protocol | What happens |
|---|---|---|
| 1. Driver presses start in eMSP A's app | OCPI | eMSP A sends a START_SESSION command to CPO B |
| 2. CPO B instructs the charger | OCPP | CSMS sends RemoteStartTransaction (1.6) or RequestStartTransaction (2.0.1) |
| 3. Charging runs | OCPP | Charger sends status, transaction and meter value messages |
| 4. Driver sees progress | OCPI | CPO B pushes session updates with kWh and cost |
| 5. Session ends | OCPP | Charger reports the end of the transaction and final meter value |
| 6. Billing | OCPI | CPO B sends a CDR; eMSP A bills the driver |
The quality of the OCPI data depends directly on the OCPP data. If connector status is wrong or meter values are missing on the OCPP side, partners receive wrong availability and incorrect CDRs. Reliable OCPP handling is therefore the foundation of good roaming.
Common misconceptions
- "OCPI replaces OCPP." No. They work at different layers and are used together.
- "Chargers need to support OCPI." No. Chargers speak OCPP; OCPI is implemented in back-office systems.
- "OCPP is enough for roaming." OCPP alone does not share data with other companies. You need OCPI, another roaming protocol or a hub.
- "A newer OCPP version upgrades OCPI too." The versions are independent and evolve separately.
What to look for in a platform
- OCPP support for the versions your chargers use (1.6J, 2.0.1, 2.1) on one dashboard.
- OCPI support for the versions your partners use, ideally 2.1.1, 2.2.1 and 2.3.0.
- Accurate mapping between OCPP connectors and OCPI EVSEs, including connector IDs and EVSE IDs.
- Tariff modelling that can be published through OCPI exactly as charged.
- Logs of both OCPP messages and OCPI calls to resolve disputes with partners.
Frequently asked questions
Is OCPI a newer version of OCPP?
No. They are separate protocols from different organisations with different purposes. OCPP connects chargers to their back office; OCPI connects back offices to each other.
Does my charger need OCPI?
No. Chargers only need OCPP. OCPI is handled by your charging station management system.
Can I do roaming without OCPI?
Yes, through other roaming protocols or proprietary hub interfaces, but OCPI is the most widely used open protocol and is required for open data in some markets, such as the UK.
Which should I implement first?
OCPP, because without it you cannot operate chargers at all. Add OCPI when you want your chargers to be used by drivers of other networks.
Run OCPP 1.6J, 2.0.1 and 2.1 chargers and OCPI roaming from one platform, with logs for both. Explore Üreticy OCPP software or contact us to discuss your setup.