OCPI 2.1.1 testing focuses on the core roaming version many EV charging teams still need for interoperability. It covers credentials exchange, location and EVSE synchronization, and session updates. It also covers charge detail records, token authorization, tariffs, and commands between a CPO and an eMSP.
A typical OCPI 2.1.1 integration begins with the credentials handshake and version discovery, then moves into ongoing module traffic such as locations, tokens, sessions, and CDR exchange.
Party A -> Party B: GET /versions
Party A -> Party B: GET /versions/2.1.1
Party A -> Party B: POST /credentials
Party B -> Party A: 200 OK with token + endpoints
CPO -> eMSP: PUT /locations/{country_code}/{party_id}/{location_id}
eMSP -> CPO: 200 OK
CPO -> eMSP: PUT /sessions/{country_code}/{party_id}/{session_id}
eMSP -> CPO: 200 OK
CPO -> eMSP: POST /cdrs
eMSP -> CPO: 200 OKOCPI 2.1.1 remains the practical baseline for many roaming integrations where teams need stable core modules before they expand into newer hub-oriented workflows.
| Profile | Coverage | Typical validation |
|---|---|---|
| Direct CPO to eMSP flows | Credentials, locations, sessions, CDRs, tariffs, tokens, and commands | Validate bilateral roaming without depending on a live partner. |
| Partner onboarding baseline | Core OCPI interoperability | Use 2.1.1 when the main requirement is reliable baseline roaming behavior. |
| Regression-friendly roaming stacks | Repeatable core-module validation | Re-run session, tariff, and CDR flows after backend changes. |
Validate your implementation before connecting to roaming partners so credential, token, and session flows work on first integration.
Run repeatable tests around locations, tariffs, and CDR exchange whenever your roaming backend changes.
Check how your CPO or eMSP stack behaves across common OCPI 2.1.1 request and response patterns.
Simulate both sides of the roaming exchange and de-risk interoperability issues before launch.