OCPI 2.3.0 Testing
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
Supported modules and flows
- Bookings extension: reservation requests and reservation_status tracking (PENDING, RESERVED, FULFILLED, CANCELED, NO_SHOW, FAILED, REJECTED, UNKNOWN).
- Credentials exchange with Credentials.hub_party_id, and PTP as a credentials role.
- HubClientInfo participant registry and message routing across complex multi-tenant networks.
- Enhanced Locations, Sessions, CDRs, and Tariffs aligned with OCPI 2.3.0 schema models.
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.
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: 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 }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
- 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.
| 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.