Skip to content
Integration

GIREVE OCPI Testing

Test your CPO or eMSP backend against an OCPPLab OCPI counterparty — the credentials handshake, Locations, Sessions, CDRs, Tokens, Tariffs, and Commands — and run the GIREVE workbook cases 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. OCPPLab does not emulate IOP: it acts as the CPO or eMSP on the other side of your backend.

Last reviewed

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 asynchronous command results.

Example GIREVE OCPI validation flow

This is the flow IOP onboarding checks: the Versions endpoint and credentials handshake, then the modules the hub routes between CPO and eMSP. In OCPPLab you run the same module sequence with OCPPLab as the counterparty CPO or eMSP; routing through IOP itself is proven only on GIREVE’s platform.

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 settlement

GIREVE readiness proof points

OCPPLab validation proves your stack completes the OCPI credentials handshake and the module exchange and CDR settlement IOP expects, before you start live onboarding.

  • Credentials and discovery

    Coverage
    Versions endpoint, Token A/Token C exchange, and endpoint registration
    Typical validation
    Validate the handshake every routed module depends on.

  • Operational roaming exchange

    Coverage
    Locations, EVSEs, Sessions, Tariffs, Tokens, Commands, and CDRs
    Typical validation
    Check the full CPO and eMSP data path the hub routes before live partner traffic exists.

  • Version coverage

    Coverage
    OCPI 2.1.1 and 2.2.1
    Typical validation
    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

Related resources

Frequently asked questions

Does OCPPLab test OCPI 2.1.1 and 2.2.1 roaming for the GIREVE platform?
OCPPLab does not connect to GIREVE or emulate its IOP platform. It validates the OCPI 2.1.1 and 2.2.1 modules and GIREVE workbook cases your IOP onboarding needs — Locations, Sessions, CDRs, Tariffs, and Tokens — with OCPPLab as the CPO or eMSP counterparty.
How are GIREVE platform tokens and command responses validated?
You can test real-time Token authorization pushes, START_SESSION and STOP_SESSION remote commands, and asynchronous command callbacks with automated assertions.

Validate your OCPI modules before you onboard to IOP

Run the OCPI credentials handshake and CPO/eMSP module exchange against an OCPPLab counterparty so you find interoperability issues before IOP onboarding or CDR settlement.

Start your testingBook technical demo