What is OCPI?
OCPI (Open Charge Point Interface) is an open protocol that enables roaming between EV charging networks. If OCPP is how chargers talk to their backend, OCPI is how backends talk to each other.
Think of it like credit card networks. Your Visa card works at any merchant, regardless of which bank issued it. OCPI creates the same interoperability for EV charging — a driver with one eMSP account can charge on any CPO's network.
The two roles
CPO (Charge Point Operator)
The CPO owns and operates the physical charging infrastructure. They publish their locations, connectors, and tariffs via OCPI so that eMSPs can offer them to their customers.
eMSP (e-Mobility Service Provider)
The eMSP provides the customer-facing service — the app, the RFID card, the billing. They subscribe to CPO location data and authorize charging sessions on behalf of their users.
A single company can be both CPO and eMSP simultaneously. Many large charging networks operate in both roles.
OCPI module breakdown
OCPI is modular. You don't need to implement everything — just the modules relevant to your use case.
Locations module
The core of OCPI. CPOs publish their charging locations, including:
- Geographic coordinates and address
- EVSEs (charging points) with connector types
- Real-time availability status
- Opening hours and access restrictions
eMSPs pull this data to show available chargers in their apps.
Sessions module
Tracks active charging sessions in real time. When a driver starts charging on a CPO's network via an eMSP, both parties exchange session data:
- Session start/stop times
- Energy delivered (kWh)
- Costs incurred
- EVSE and connector used
CDRs module (Charge Detail Records)
The billing backbone. After a session ends, the CPO generates a CDR containing the final cost breakdown. The eMSP uses this to invoice the driver.
CDRs include:
- Total energy consumed
- Charging duration
- Tariff applied
- Total cost with tax breakdown
Tariffs module
CPOs publish their pricing structures. OCPI supports complex tariff models:
- Per-kWh pricing
- Per-minute pricing (charging time and/or parking time)
- Flat fees
- Time-of-day variations
- Reservation fees
Tokens module
How eMSPs authorize their users on CPO networks. When a driver taps their RFID card or opens their app, the CPO sends a token validation request to the eMSP.
OCPI supports:
- RFID tokens
- App-based tokens
- Ad-hoc (QR code) tokens
Commands module
Allows eMSPs to send commands to CPO chargers on behalf of users:
START_SESSION— remote startSTOP_SESSION— remote stopRESERVE_NOW— reserve a connectorUNLOCK_CONNECTOR— remote unlock
OCPI versions: 2.1.1 vs 2.2.1
OCPI 2.1.1 is the most widely deployed version. It covers the core roaming use case — locations, sessions, CDRs, tariffs, and tokens.
OCPI 2.2.1 adds:
- Hub support — connect to a roaming hub instead of bilateral connections
- Charging profiles — eMSPs can set charging limits (e.g., for fleet management)
- Improved tariff model — more granular pricing structures
- Platform registration — streamlined onboarding between parties
Most new implementations should target 2.2.1 unless your roaming partners only support 2.1.1.
Implementation architecture
A typical OCPI implementation has three layers:
HTTP API layer — OCPI uses REST with JSON payloads. Each party exposes endpoints for the modules they support. Authentication uses a token-based system with credentials exchanged during registration.
Data synchronization — Locations, tariffs, and tokens are synchronized between parties. OCPI supports both pull (the receiver fetches updates) and push (the sender pushes updates) mechanisms.
Business logic — Authorization decisions, tariff calculations, and CDR generation. This is where the complexity lives.
Common OCPI implementation mistakes
Not handling pagination. OCPI uses Link headers for pagination. If you ignore them, you'll only get the first page of locations.
Ignoring the last_updated field. Every OCPI object has a last_updated timestamp. Use it to implement incremental sync instead of full pulls.
Hardcoding tariff calculations. OCPI tariff structures are complex. Build a proper tariff engine rather than special-casing each pricing model.
Not testing with real roaming partners. OCPI implementations vary. What works against the specification doesn't always work against a real partner's implementation.
How EV Cloud handles OCPI
EV Cloud supports OCPI 2.1.1 and 2.2.1 workflows for both CPO and eMSP roles:
- Automatic location sync — your charger locations are published to roaming partners in real time
- Token authorization — incoming authorization requests are validated against your token database
- CDR generation — charge detail records are automatically generated from OCPP session data
- Hub connectivity — connect to major roaming hubs (Hubject, Gireve, e-clearing) through a single integration
The platform can compress technical integration work materially, but partner onboarding, tariff alignment, and launch governance still need deliberate coordination.
What to do before you launch roaming
Most OCPI projects fail in rollout, not in the first demo. The real work is partner onboarding, tariff alignment, token ownership, reconciliation, and support readiness across multiple teams.
If you are moving from research into implementation planning, use this sequence:
- Use the OCPI rollout checklist to structure launch readiness before partner onboarding starts.
- Compare OCPI 2.1.1 and 2.2.1 if you still need to settle module scope and version strategy.
- Talk to EV Cloud if your team needs help with roaming architecture, hub connectivity, or phased launch support.
