OCPI roaming and interoperability testing
What is OCPI?
The Open Charge Point Interface (OCPI) is the protocol that enables EV roaming between Charge Point Operators (CPOs) and e-Mobility Service Providers (eMSPs). It handles everything from location data sharing to real-time authorization, charging session management, and billing reconciliation through Charge Detail Records (CDRs).
Testing OCPI is challenging because it requires two parties. You can’t test your CPO implementation without an eMSP to connect to, and vice versa.
OCPI modules by version
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Not in this version
- Not in this version
- Not in this version
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Not in this version
OCPI 2.3.0Adds the PTP role and hub_party_id
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
- Supported
| Version | Credentials | Locations | Sessions | CDRs | Tariffs | Tokens | Commands | ChargingProfiles | HubClientInfo | Bookings |
|---|---|---|---|---|---|---|---|---|---|---|
| OCPI 2.1.1 | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Not in this version | Not in this version | Not in this version |
| OCPI 2.2.1 | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Not in this version |
| OCPI 2.3.0Adds the PTP role and hub_party_id | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Supported | Supported |
OCPI hub connections
If you roam through an OCPI hub such as GIREVE, OCPPLab connects to it as a CPO or eMSP party (or as a PTP on OCPI 2.3.0), validates HubClientInfo and hub-routed objects, and runs the OCPI conformance cases. It does not emulate the hub, and it does not speak Hubject’s OICP.
- Connect to an OCPI hub as a CPO or eMSP party (PTP on OCPI 2.3.0)
- Run the credentials handshake, including hub_party_id on OCPI 2.3.0
- Validate HubClientInfo and the objects the hub routes from other parties
- Check session and CDR exchange over the hub connection
- Score GIREVE workbook cases from the OCPI conformance suite
Testing scenarios
CPO registration
POST /credentials
Test the full OCPI credentials handshake between your platform and an OCPPLab eMSP counterparty.
Cross-platform authorization
POST /tokens/{token_uid}/authorize
Validate that tokens from partner eMSPs are correctly authorized at your charge points.
Real-time session sync
PATCH /sessions/{country_code}/{party_id}/{session_id}
Verify that charging sessions are correctly reported to roaming partners in real time.
CDR reconciliation
POST /cdrs
Test CDR generation, transmission, and reconciliation across CPO-eMSP boundaries.
Location data updates
PATCH /locations/{country_code}/{party_id}/{location_id}/{evse_uid}
Validate that EVSE availability, pricing, and connector status propagate correctly.
Error handling
status_code 2001 Invalid or missing parameters
Test how your platform answers malformed requests and missing parameters, and that it returns status_code 2001 for them.
Related resources
Test roaming without roaming partners
Run CPO and eMSP counterparties and connect to hubs. Validate OCPI end-to-end.