The short answer
OCPP = how chargers talk to their backend. OCPI = how backends talk to each other.
That's it. Everything else is details.
Where teams get burned in deployment
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.
OCPP: Charger to backend
OCPP (Open Charge Point Protocol) handles communication between a physical EV charger and its central management system (CSMS/CPMS).
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.
OCPI: Backend to backend
OCPI (Open Charge Point Interface) handles communication between different EV charging platforms — typically between a CPO (Charge Point Operator) and an eMSP (e-Mobility Service Provider).
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
How they work together
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.
Common confusion
"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 to validate before launch
If your roadmap includes both charger operations and roaming, validate both layers 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.
How EV Cloud handles both
EV Cloud is the layer between your chargers and the world:
- OCPP gateway — accepts 1.6 and 2.0.1 connections from any charger
- OCPI bridge — connects to roaming networks as CPO, eMSP, or both
- Unified API — one application-facing API while OCPP and OCPI complexity stays underneath the platform layer
You don't need to implement either protocol yourself.
Next step for buyers
If this article clarified the protocol split, the next decision is not "which acronym matters more." The real question is whether your platform can keep charger control, roaming, migration, and data ownership aligned inside one rollout path.
Use these pages to move from protocol understanding into a shortlist:
- Use the OCPP platform scorecard to compare vendors on coexistence, rollback, roaming readiness, and lock-in risk.
- Use the OCPI rollout checklist if roaming, partner launch, or settlement workflows are part of the project scope.
- Review pricing and rollout options if you are already comparing implementation models and timelines.
