The short answer
OCPP = how chargers talk to their backend. OCPI = how backends talk to each other.
That's it. Everything else is details.
Why do teams confuse OCPP and OCPI?
Most failures trace back to treating OCPP and OCPI as interchangeable when they solve different problems. The confusion is rarely academic. It creates real rollout mistakes:
- a team selects a CPMS with strong OCPP support but no realistic roaming path
- a product team assumes OCPI partner launch will solve charger-side instability
- finance expects roaming settlement to "just work" even though no one has validated CDR quality
The fastest way to waste time is to use protocol names as product labels. OCPP answers charger control. OCPI answers interoperability between platforms. A deployer needs to define which boundary is failing before buying or rebuilding anything.
What OCPP is and what it does
OCPP is the device-to-backend protocol that connects a charger to its management system. OCPP (Open Charge Point Protocol), maintained by the Open Charge Alliance, handles communication between a physical EV charger and its central management system (CSMS/CPMS). It is the language a charger speaks to report status, run transactions, and accept remote commands.
Treat OCPP as the control plane for hardware. Every action a driver triggers at the connector, plug-in, authorization, energy delivery, and stop, ultimately resolves to an OCPP message exchange between the charger and your backend. If this link is unreliable, no roaming or app layer above it can compensate.
It covers:
- Boot and configuration — charger reports its capabilities, receives configuration
- Status updates — connector available, occupied, faulted
- Transaction management — start/stop charging, meter values, billing data
- Remote commands — remote start/stop, unlock connector, reset
- Firmware management — update, diagnostics, log retrieval
- Smart charging — load management, charging profiles
OCPP runs over WebSocket (persistent connection). The charger connects to the backend and maintains the connection for bidirectional communication.
OCPP versions
- 1.6 — the industry workhorse. JSON or SOAP over WebSocket.
- 2.0.1 — the modern standard. New device model, security profiles, enhanced smart charging.
What OCPI is and what it does
OCPI is the platform-to-platform protocol that connects two charging backends. OCPI (Open Charge Point Interface), governed by the EVRoaming Foundation, handles communication between different EV charging platforms — typically between a CPO (Charge Point Operator) and an eMSP (e-Mobility Service Provider). It never touches a charger directly.
Think of OCPI as the business and interoperability plane. It moves locations, tokens, sessions, and billing records between organizations so a driver registered with one network can charge on another. The hard part is rarely the REST calls themselves; it is agreeing on tariffs, reconciling CDRs, and keeping availability data accurate across partners.
It covers:
- Location sharing — publish charger locations, availability, and pricing
- Authorization — validate tokens from other networks
- Session tracking — share real-time session data across networks
- Billing — exchange Charge Detail Records (CDRs) for settlement
- Commands — remote start/stop across networks
- Tariffs — publish pricing structures
OCPI uses REST APIs (HTTP request/response). Each party exposes endpoints that the other calls.
OCPI versions
- 2.1.1 — widely deployed, covers core roaming
- 2.2.1 — adds hub support, charging profiles, improved tariffs
For a side-by-side breakdown, see OCPI 2.1.1 vs 2.2.1; both releases are published in the official OCPI specification.
How do OCPP and OCPI work together?
The two protocols run in parallel, not in sequence. OCPP keeps the charger and the CPO backend in sync, while OCPI keeps the CPO and eMSP backends in sync. A single roaming session touches both at the same time, with the CPO acting as the translation point between them.
In a typical roaming scenario, both protocols are active simultaneously:
- Driver opens their eMSP app and starts a session
- eMSP → CPO sends a
START_SESSIONcommand via OCPI - CPO → Charger sends a
RemoteStartTransactionvia OCPP - Charger → CPO reports meter values via OCPP
- CPO → eMSP pushes session updates via OCPI
- Driver unplugs
- Charger → CPO sends
StopTransactionvia OCPP - CPO → eMSP sends the final CDR via OCPI
OCPP handles the physical charging. OCPI handles the business layer.
What do people get wrong about OCPP vs OCPI?
"Do I need both?"
If you only operate your own chargers for your own users: you need OCPP only. OCPI is for cross-network interoperability.
If you want your chargers to be usable by drivers from other networks: you need both. OCPP for charger communication, OCPI for roaming.
If you're an eMSP without your own chargers: you need OCPI only. Your roaming partners handle OCPP.
"Can OCPI replace OCPP?"
No. OCPI doesn't communicate with chargers at all. It communicates between backends. You always need OCPP (or a proprietary equivalent) to control the physical hardware.
"Is one harder than the other?"
OCPP is more complex at the protocol level — persistent WebSocket connections, dozens of message types, hardware-specific behavior.
OCPI is conceptually simpler (REST APIs) but operationally complex — bilateral agreements, tariff negotiations, CDR reconciliation, token management across networks.
Decision matrix
| You are… | Need OCPP? | Need OCPI? |
|---|---|---|
| CPO (own chargers, own users) | Yes | No |
| CPO (want roaming) | Yes | Yes (CPO role) |
| eMSP (no own chargers) | No | Yes (eMSP role) |
| eMSP + CPO (both) | Yes | Yes (both roles) |
| Building a CPMS | Yes | Optional |
| Building an EV app | No | Yes (eMSP role) |
What should you validate before launch?
Validate the charger-control path and the partner-data path as two separate layers before go-live. If your roadmap includes both charger operations and roaming, prove each layer explicitly:
- Charger control path: prove boot, status, remote commands, and meter values through OCPP across your real charger mix.
- Partner data path: prove OCPI locations, tokens, sessions, commands, tariffs, and CDRs with at least one representative roaming partner.
- Operational ownership: decide which team owns charger incidents, roaming disputes, and tariff mismatches before go-live.
- Internal abstraction: check whether your internal apps need to understand both protocols or can rely on a normalized platform layer.
This avoids a common failure mode where engineering finishes the protocol integration, but operations, finance, and support are still unprepared for production.
Where does the platform layer fit?
Most teams do not implement OCPP and OCPI by hand; they run a platform that terminates both and exposes a normalized interface. The pattern is consistent across mature CPMS deployments: an OCPP gateway accepts 1.6 and 2.0.1 connections from the charger fleet, an OCPI bridge connects to roaming partners and hubs in CPO, eMSP, or dual roles, and a single application-facing API sits above both so internal apps do not have to model the protocol differences themselves.
The value of that abstraction is operational, not cosmetic. When charger firmware behaves inconsistently or a roaming partner ships malformed CDRs, the platform layer is where you normalize, validate, and retry. Whether you build this yourself or adopt a managed platform, the boundary to protect is the same: keep charger control and partner interoperability behind one consistent contract so failures in one plane stay isolated from the other.
How do you apply this to a real decision?
Map your role first, then let the protocol split scope the work. The useful question is not "which acronym matters more," but which boundary your project actually has to own. Map your role first. A pure eMSP owns OCPI and outsources OCPP to partners. A single-network CPO owns OCPP and can defer OCPI. A roaming CPO owns both, and that combination is where most coordination cost lives.
From there, the protocol split becomes a scoping tool. Charger reliability problems are OCPP problems, so they belong with the team that owns hardware and the CPMS. Settlement and partner-data problems are OCPI problems, so they belong with the team that owns roaming and billing. Keeping those two lanes distinct, even when one platform handles both, is what prevents charger incidents and roaming disputes from being debugged as if they were the same failure.
