GIREVE OCPI Testing
Test your CPO or eMSP backend against GIREVE-style hub routing — the OCPI credentials handshake, Locations, Sessions, CDRs, Tokens, Tariffs, and Commands — before you onboard to the live IOP platform.
What is GIREVE OCPI testing?
GIREVE is an OCPI roaming hub that connects CPOs and eMSPs through its IOP platform over OCPI 2.1.1 and 2.2.1. GIREVE OCPI testing validates how your backend registers as a CPO or eMSP, completes the OCPI credentials handshake, and exchanges Locations, EVSEs, Sessions, CDRs, Tokens, Tariffs, and Commands routed through the hub — so you can prove interoperability before you onboard to the live IOP platform.
Why this matters
- GIREVE routes every message between you and the counterparty through IOP, so one wrong country_code, party_id, or endpoint URL in the credentials handshake blocks the whole exchange.
- Test OCPI 2.1.1 and 2.2.1 separately: 2.2.1 changes how parties are identified and adds modules, and the hub expects the exact version your party registered for.
- Exercise both the CPO push (Locations, CDRs) and the eMSP pull plus Commands so you confirm both directions of hub routing before a live counterparty is connected.
What to validate
- Credentials handshake, version discovery, and token exchange across GIREVE-facing flows.
- Locations, sessions, CDRs, tariffs, commands, and token validation for CPO and eMSP roles.
- OCPI 2.1.1 baseline interoperability plus OCPI 2.2.1 hub-oriented or extended workflows where needed.
- Error handling for malformed payloads, delayed callbacks, and hub-style async exchange patterns.
Example GIREVE OCPI validation flow
A GIREVE readiness test starts at the OCPI Versions endpoint and the credentials handshake against the IOP platform, then exercises the modules the hub routes between CPO and eMSP: Locations, Sessions, Commands, and CDRs.
CPO -> IOP: GET /ocpi/versions
CPO -> IOP: GET /ocpi/2.2.1 (version details + module endpoints)
CPO -> IOP: POST /ocpi/2.2.1/credentials (register with Token A, receive Token C)
IOP -> CPO: 200 OK credentials + endpoint list
CPO -> IOP: PUT /ocpi/cpo/2.2.1/locations/FR/ABC/LOC1 (push Location + EVSE)
IOP -> eMSP: routed Location update
eMSP -> IOP: POST /ocpi/emsp/2.2.1/commands/START_SESSION (with response_url)
IOP -> CPO: routed START_SESSION command
CPO -> IOP: POST <response_url> (CommandResult: ACCEPTED)
CPO -> IOP: POST /ocpi/cpo/2.2.1/cdrs (push CDR)
IOP -> eMSP: routed CDR for settlementGIREVE readiness proof points
GIREVE validation proves your stack can complete the IOP credentials handshake and survive hub-routed module exchange and CDR settlement before you start live onboarding.
| Area | Coverage | Typical validation |
|---|---|---|
| Credentials and discovery | Versions endpoint, Token A/Token C exchange, and endpoint registration | Validate the IOP handshake every routed module depends on. |
| Operational roaming exchange | Locations, EVSEs, Sessions, Tariffs, Tokens, Commands, and CDRs | Check the full CPO and eMSP data path the hub routes before live partner traffic exists. |
| Version coverage | OCPI 2.1.1 and 2.2.1 | Register and test the exact version IOP expects for your party. |
Common scenarios
Pre-onboarding readiness
Validate your CPO or eMSP flows before you request IOP onboarding from GIREVE.
Version migration
Test OCPI 2.1.1 and 2.2.1 side by side when moving your IOP party registration to the newer version.
Operational regression testing
Re-run Locations, Sessions, Tariffs, Tokens, Commands, and CDR scenarios whenever your roaming backend changes.
Related resources
Validate GIREVE hub routing before you onboard to IOP
Simulate the IOP credentials handshake and CPO/eMSP module routing so you find interoperability issues before live onboarding or CDR settlement.