Protocol

OCPI 2.3.0 testing

Validate OCPI 2.3.0 roaming workflows: hub_party_id credentials, the PTP role, HubClientInfo, and OCPPLab's Bookings extension for EVSE reservations.

Start your testing Book technical demo

What is OCPI 2.3.0 testing?

OCPI 2.3.0 testing covers the EVRoaming Foundation's 2.3.0 release. It reports hub clients as normal credentials roles and names the hub in Credentials.hub_party_id, adds the Payments module and the PTP (Payment Terminal Provider) role, and makes OCPI extensible with extra modules and fields. OCPPLab uses that extensibility for a Bookings module on its 2.3.0 schema; Bookings is an OCPPLab extension, not part of the published 2.3.0 specification.

Last reviewed September 15, 2026

Best for

eMSPs and CPOs prototyping EVSE pre-booking on the OCPPLab Bookings extension.
Roaming hubs and clearinghouses migrating from OCPI 2.2.1 to OCPI 2.3.0 routing architecture.
Platform developers verifying multi-party credential handshakes and modern roaming schema validation.

Message coverage

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

bookingsOCPPLab extension
Testing a CPO
8 cases
Testing an eMSP
9 cases
cdrs
Testing a CPO
2 cases
Testing an eMSP
6 cases
chargingprofiles
Testing a CPO
3 cases
Testing an eMSP
4 cases
commands
Testing a CPO
6 cases
Testing an eMSP
8 cases
credentials
Testing a CPO
7 cases
Testing an eMSP
7 cases
hubclientinfo
Testing a CPO
3 cases
Testing an eMSP
3 cases
locations
Testing a CPO
7 cases
Testing an eMSP
15 cases
payments
Testing a CPO
4 cases
Testing an eMSP
Not covered
sessions
Testing a CPO
3 cases
Testing an eMSP
11 cases
tariffs
Testing a CPO
3 cases
Testing an eMSP
5 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
`bookings`OCPPLab extension	8 cases	9 cases
`cdrs`	2 cases	6 cases
`chargingprofiles`	3 cases	4 cases
`commands`	6 cases	8 cases
`credentials`	7 cases	7 cases
`hubclientinfo`	3 cases	3 cases
`locations`	7 cases	15 cases
`payments`	4 cases	Not covered
`sessions`	3 cases	11 cases
`tariffs`	3 cases	5 cases
`tokens`	5 cases	5 cases
`versions`	6 cases	6 cases

Example OCPI 2.3.0 reservation & booking flow

An eMSP requests a booking on behalf of an EV driver through the OCPPLab Bookings extension. The CPO answers with the stored Booking, then updates its reservation_status when the driver arrives and charging starts.

eMSP

CPO

Bookings
1. eMSP → CPO
  POST /ocpi/cpo/2.3.0/bookings
  { "country_code": "NL", "party_id": "EMS", "request_id": "req-8821", "location_id": "LOC1", "booking_location_id": "BL1", "period": { "start_date_time": "2026-09-03T10:00:00Z", "end_date_time": "2026-09-03T11:00:00Z" }, "authorization_reference": "auth-8821" }
2. CPO → eMSP · response
  200 OK
  { "status_code": 1000, "data": { "id": "bk-8821", "reservation_status": "RESERVED", ... } }
3. CPO → eMSP
  PATCH /ocpi/emsp/2.3.0/bookings/DE/CPO/bk-8821
  { "reservation_status": "FULFILLED", "last_updated": "2026-09-03T10:04:00Z" }
4. eMSP → CPO · response
  200 OK
  { "status_code": 1000 }

Bookings frames use the OCPPLab Bookings extension on OCPI 2.3.0, not a core 2.3.0 module.

Raw frames

eMSP -> CPO: POST /ocpi/cpo/2.3.0/bookings
{ "country_code": "NL", "party_id": "EMS", "request_id": "req-8821",
  "location_id": "LOC1", "booking_location_id": "BL1",
  "period": { "start_date_time": "2026-09-03T10:00:00Z", "end_date_time": "2026-09-03T11:00:00Z" },
  "authorization_reference": "auth-8821" }

CPO -> eMSP: 200 OK
{ "status_code": 1000, "data": { "id": "bk-8821", "reservation_status": "RESERVED", ... } }

CPO -> eMSP: PATCH /ocpi/emsp/2.3.0/bookings/DE/CPO/bk-8821
{ "reservation_status": "FULFILLED", "last_updated": "2026-09-03T10:04:00Z" }

eMSP -> CPO: 200 OK
{ "status_code": 1000 }

What the workspace asserts

The states and enum values an OCPI 2.3.0 frame is validated against, taken from the OCPI 2.3.0 specification objects. Values marked OCPPLab extension are ours, not the specification's.

`reservation_status`Booking reservation_statusOCPPLab extension

PENDING
RESERVED
FULFILLED

RESERVEDtoCANCELEDNO_SHOW

AlsoREJECTEDFAILEDUNKNOWN

The CPO answers POST /bookings and PATCHes reservation_status on the eMSP side as the booking moves.

Role
Field
CredentialsRole role
Values
CPOEMSPNAPNSPOTHERSCSP
reservation_request_statusOCPPLab extension
Field
Booking booking_requests[].request_status
Values
PENDINGACCEPTEDDECLINEDFAILED

Enum	Field	Values
`Role`	`CredentialsRole role`	`CPOEMSPNAPNSPOTHERSCSP`
`reservation_request_status`OCPPLab extension	`Booking booking_requests[].request_status`	`PENDINGACCEPTEDDECLINEDFAILED`

Supported OCPI 2.3.0 roaming modules

OCPI 2.3.0 changes how hubs identify themselves in credentials. OCPPLab validates CPO and eMSP endpoints against 2.3.0 schemas, plus its Bookings extension.

Bookings extension
Coverage
POST booking requests, PATCH updates, cancellation, and reservation_status transitions
Typical validation
Verify NO_SHOW, CANCELED, and FULFILLED outcomes on the OCPPLab extension.
Hub Party ID Credentials
Coverage
Credentials endpoint with hub_party_id routing
Typical validation
Hub clients appear as normal credentials roles; the hub is named in hub_party_id.
HubClientInfo & Locations
Coverage
Participant discovery and EVSE status updates
Typical validation
Check that HubClientInfo and EVSE status pushes reach every connected party.

Profile	Coverage	Typical validation
Bookings extension	POST booking requests, PATCH updates, cancellation, and reservation_status transitions	Verify NO_SHOW, CANCELED, and FULFILLED outcomes on the OCPPLab extension.
Hub Party ID Credentials	Credentials endpoint with hub_party_id routing	Hub clients appear as normal credentials roles; the hub is named in hub_party_id.
HubClientInfo & Locations	Participant discovery and EVSE status updates	Check that HubClientInfo and EVSE status pushes reach every connected party.

What to test

Bookings extension lifecycle: reservation, amendment, cancellation, and fulfillment.
Credentials exchange with hub_party_id specification compliance.
Multi-party routing through HubClientInfo endpoints.
OCPI 2.3.0 schema conformance for Sessions, CDRs, and Tariffs.

Common scenarios

EVSE pre-booking validation

Check that booking requests from a driver app reach the CPO and that reservation_status moves through RESERVED to FULFILLED, CANCELED, or NO_SHOW.

Roaming hub cutover

Validate that bilateral and hub connections process Credentials with hub_party_id without dropping existing 2.2.1 connections.

Booking-to-Session handoff

Test authorization flows where a pre-booked driver taps an RFID tag, converting the booking into a live charge session.

Related resources

Validate OCPI 2.3.0 roaming before going live

Run CPO and eMSP endpoints against 2.3.0 schemas, test hub_party_id credentials, and try EVSE reservations on the Bookings extension.