OCPI 2.1.1 Testing
Validate the core OCPI 2.1.1 roaming modules used for CPO and eMSP interoperability without waiting on partner systems.
What is OCPI 2.1.1 testing?
OCPI 2.1.1 testing focuses on the core roaming version many EV charging teams still need for interoperability. It typically includes credentials exchange, location and EVSE synchronization, session updates, charge detail records, token authorization, tariffs, and commands between a CPO and an eMSP.
Supported modules and flows
- Credentials, versions, and endpoint discovery workflows needed to establish a roaming connection.
- Core modules: locations, sessions, CDRs, tariffs, tokens, and commands.
- CPO and eMSP sender/receiver interactions without live partner dependencies.
- Core roaming interoperability without the newer hub-specific OCPI 2.2.1 modules.
Best for
- Teams integrating with roaming partners that still rely on OCPI 2.1.1 as the practical baseline.
- Implementations that need the core roaming modules without the wider OCPI 2.2.1 hub feature set.
- Early partner certification and interoperability validation before going live.
Example OCPI 2.1.1 roaming flow
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 OKSupported roaming profiles
OCPI 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. |
What to test
- Credentials handshake and version discovery.
- Locations, EVSEs, and connector synchronization.
- Sessions, CDRs, tariffs, tokens, and command coverage.
- CPO and eMSP role simulation without real roaming partners.
Common scenarios
Partner readiness
Validate your implementation before connecting to roaming partners so credential, token, and session flows work on first integration.
Regression testing
Run repeatable tests around locations, tariffs, and CDR exchange whenever your roaming backend changes.
Platform interoperability
Check how your CPO or eMSP stack behaves across common OCPI 2.1.1 request and response patterns.
Related resources
Validate OCPI 2.1.1 before connecting to live partners
Simulate both sides of the roaming exchange and de-risk interoperability issues before launch.