Protocol

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 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.

Last reviewed August 17, 2026

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.

Message coverage

Runnable OCPI 2.1.1 conformance cases per module, for each side the workspace can test. Cases the runner cannot express are not counted.

cdrs
Testing a CPO
2 cases
Testing an eMSP
6 cases
commands
Testing a CPO
5 cases
Testing an eMSP
7 cases
credentials
Testing a CPO
7 cases
Testing an eMSP
4 cases
locations
Testing a CPO
6 cases
Testing an eMSP
16 cases
sessions
Testing a CPO
2 cases
Testing an eMSP
11 cases
tariffs
Testing a CPO
3 cases
Testing an eMSP
7 cases
tokens
Testing a CPO
5 cases
Testing an eMSP
5 cases
versions
Testing a CPO
6 cases
Testing an eMSP
6 cases

Module	Testing a CPO	Testing an eMSP
`cdrs`	2 cases	6 cases
`commands`	5 cases	7 cases
`credentials`	7 cases	4 cases
`locations`	6 cases	16 cases
`sessions`	2 cases	11 cases
`tariffs`	3 cases	7 cases
`tokens`	5 cases	5 cases
`versions`	6 cases	6 cases

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.

Credentials
Party A
Party B
1. Party A → Party B
  GET /versions
2. Party A → Party B
  GET /versions/2.1.1
3. Party A → Party B
  POST /credentials
4. Party B → Party A · response
  200 OK with token + endpoints
Locations
CPO
eMSP
1. CPO → eMSP
  PUT /locations/{country_code}/{party_id}/{location_id}
2. eMSP → CPO · response
  200 OK
Sessions
CPO
eMSP
1. CPO → eMSP
  PUT /sessions/{country_code}/{party_id}/{session_id}
  {status: ACTIVE}
2. eMSP → CPO · response
  200 OK
CDRs
CPO
eMSP
1. CPO → eMSP
  POST /cdrs
2. eMSP → CPO · response
  200 OK

Raw frames

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} {status: ACTIVE}
eMSP -> CPO: 200 OK

CPO -> eMSP: POST /cdrs
eMSP -> CPO: 200 OK

What the workspace asserts

The states and enum values an OCPI 2.1.1 frame is validated against, taken from the OCPI 2.1.1 specification objects.

`SessionStatus`Session status

PENDING
ACTIVE
COMPLETED

AlsoINVALID

The CPO pushes each change to the eMSP Sessions endpoint with PUT or PATCH; the CDR follows once the session is COMPLETED.

Status
Field
EVSE status
Values
AVAILABLEBLOCKEDCHARGINGINOPERATIVEOUTOFORDERPLANNEDREMOVEDRESERVEDUNKNOWN
CommandResponseType
Field
CommandResponse result
Values
NOT_SUPPORTEDREJECTEDACCEPTEDTIMEOUTUNKNOWN_SESSION

Enum	Field	Values
`Status`	`EVSE status`	`AVAILABLEBLOCKEDCHARGINGINOPERATIVEOUTOFORDERPLANNEDREMOVEDRESERVEDUNKNOWN`
`CommandResponseType`	`CommandResponse result`	`NOT_SUPPORTEDREJECTEDACCEPTEDTIMEOUTUNKNOWN_SESSION`

`status_code` ranges

1xxx: Success
2xxx: Client errors
3xxx: Server errors

Supported 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.

Direct CPO to eMSP flows
Coverage
Credentials, locations, sessions, CDRs, tariffs, tokens, and commands
Typical validation
Validate bilateral roaming without depending on a live partner.
Partner onboarding baseline
Coverage
Core OCPI interoperability
Typical validation
Use 2.1.1 when the main requirement is reliable baseline roaming behavior.
Regression-friendly roaming stacks
Coverage
Repeatable core-module validation
Typical validation
Re-run session, tariff, and CDR flows after backend changes.

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.

Start your testing Book technical demo