Skip to content
Integration

Hubject Roaming Readiness

Hubject runs intercharge on OICP. OCPPLab is an OCPP and OCPI simulator: it connects as a CPO or eMSP party over OCPI and does not implement OICP or emulate a Hubject hub. Use the OCPI roaming tests here to prove your CPO or eMSP modules before Hubject QA onboarding.

What is Hubject roaming readiness?

Hubject runs the intercharge roaming network. Partners connect over OICP (currently 2.3), and Hubject also offers an OCPI 2.2.1 interface. OCPPLab does not speak OICP and does not stand in for Hubject QA. This page lists the OCPI 2.1.1 / 2.2.1 modules OCPPLab can exercise, with OCPPLab as the CPO or eMSP party, so your backend is ready before you start Hubject’s own onboarding.

Last reviewed

Why this matters

  • Bugs in your roaming core — location data, token authorization, session state, CDR totals — reach Hubject partners whichever protocol carries them, and they are hard to debug once live partner traffic flows.
  • OICP messages such as eRoamingAuthorizeStart and eRoamingChargeDetailRecord can only be proven in Hubject’s QA environment. OCPPLab does not send or receive them.
  • OCPPLab proves the OCPI modules your backend already runs — credentials, locations, sessions, CDRs, tokens — so that part is solid before you book Hubject’s own environment.

What to validate

  • OCPI 2.1.1 and 2.2.1 credentials handshake with OCPPLab as the CPO or eMSP counterparty.
  • Locations, EVSEs, Sessions, CDRs, Tokens, and Tariffs exchange in push and pull directions.
  • START_SESSION and STOP_SESSION commands with asynchronous CommandResult callbacks.
  • Error handling for malformed payloads, unknown objects, and OCPI status codes.

Example OCPI flow to run before Hubject onboarding

Here OCPPLab is the eMSP counterparty to your CPO backend over OCPI 2.2.1. These are OCPI calls only; the OICP equivalents are tested in Hubject QA.

CPO -> OCPPLab (eMSP): GET /ocpi/versions
CPO -> OCPPLab (eMSP): GET /ocpi/2.2.1                 (version details + endpoints)
CPO -> OCPPLab (eMSP): POST /ocpi/2.2.1/credentials    (Token A in, Token C back)

CPO -> OCPPLab (eMSP): PUT /ocpi/emsp/2.2.1/locations/DE/ABC/LOC1         (Location + EVSE)
CPO -> OCPPLab (eMSP): PATCH /ocpi/emsp/2.2.1/locations/DE/ABC/LOC1/EVSE1  (status: CHARGING)

OCPPLab (eMSP) -> CPO: POST /ocpi/cpo/2.2.1/commands/START_SESSION   (with response_url)
CPO -> OCPPLab (eMSP): POST <response_url>                          (CommandResult: ACCEPTED)
CPO -> OCPPLab (eMSP): PUT /ocpi/emsp/2.2.1/sessions/DE/ABC/SES1     (status: ACTIVE)

CPO -> OCPPLab (eMSP): POST /ocpi/emsp/2.2.1/cdrs                    (CDR for settlement)

Hubject readiness proof points

OCPPLab proves the OCPI side of your roaming backend. OICP operations stay with Hubject QA.

  • Credentials and discovery

    Coverage
    OCPI Versions endpoint and Token A to Token C credentials exchange
    Typical validation
    Proves your party identity (country_code, party_id) and endpoint list.

  • Operational exchange

    Coverage
    Locations, EVSEs, Sessions, Tokens, Tariffs, Commands, and CDRs over OCPI
    Typical validation
    Runs the CPO and eMSP directions against an OCPPLab counterparty.

  • OICP operations

    Coverage
    Not covered: eRoamingPushEvseData, eRoamingAuthorizeStart, eRoamingChargeDetailRecord
    Typical validation
    Prove these in Hubject’s QA environment.

Common scenarios

Before Hubject QA onboarding

OICP messages (eRoamingPushEvseData, AuthorizeStart, ChargeDetailRecord) are Hubject’s protocol. Exercise them in Hubject QA — OCPPLab does not replay those calls.

OCPI regression after a CSMS change

Re-run the OCPI credentials, session, and CDR cases whenever you change authorization, session, or CDR logic, so the roaming core is stable before you repeat Hubject QA.

OCPI partners next to Hubject

If you also roam with partners over OCPI, test those connections in OCPPLab and keep the Hubject OICP connection in Hubject’s own environment.

Related resources

Related resources

Frequently asked questions

How does OCPPLab help EV teams prepare for Hubject roaming?
OCPPLab tests OCPI 2.1.1 and 2.2.1 roaming with OCPPLab as the CPO or eMSP counterparty, so you can check location data, token authorization, sessions, and CDRs before you start Hubject onboarding.
Does OCPPLab simulate Hubject's OICP protocol?
No. OCPPLab does not send or receive OICP messages and does not emulate a Hubject hub. It tests OCPI 2.1.1 and 2.2.1. Prove OICP in Hubject's QA environment.

Prove OCPI roaming before you start Hubject onboarding

Validate the OCPI side of your roaming backend — credentials, locations, sessions, commands, and CDRs — against an OCPPLab CPO or eMSP counterparty before Hubject QA.

Start your testingBook technical demo