Integration

Hubject OICP Testing

Hubject runs intercharge on OICP. OCPPLab is an OCPP and OCPI simulator — it does not implement OICP 2.3 or a simulated Hubject hub. Use OCPI roaming tests here to prove CPO/eMSP modules before you take a separate Hubject QA onboarding.

What is Hubject OICP testing?

Hubject’s intercharge network uses OICP (currently 2.3). OCPPLab does not speak OICP and does not stand in for Hubject QA. This page is a Hubject-facing briefing: what Hubject expects, and which OCPI 2.1.1 / 2.2.1 modules OCPPLab can exercise so your CSMS is ready before you start Hubject’s own onboarding.

Why this matters

OICP authorization bugs — a malformed eRoamingAuthorizeStart or a dropped SessionID — strand drivers at the charger and are hard to debug once live partner traffic is flowing.
Getting eRoamingPushEvseData and eRoamingPushEvseStatus right before QA onboarding means your charge points show up in partner apps on the first try.
Hubject QA is the place to prove OICP. OCPPLab can only prove the OCPI modules you already run — locations, sessions, CDRs — so those are solid before you book Hubject’s own environment.

What to validate

Partner-readiness checks for hub-oriented roaming flows and operational exchange patterns.
Session, authorization, tariff, and settlement-path validation at the integration boundary.
Failure handling across delayed responses, invalid payloads, and asynchronous operational callbacks.
Cross-checks between your roaming implementation and the underlying CPMS or settlement systems behind it.

Example Hubject OICP roaming validation flow

A practical Hubject readiness test verifies that your backend can exchange the right operational data with a hub-facing integration boundary before any live partner traffic arrives.

CPO -> Hub (QA): eRoamingPushEvseData (publish EVSE static data, EvseID DE*ABC*E1234567)
CPO -> Hub (QA): eRoamingPushEvseStatus (status: Available)
Hub -> CPO: Acknowledgement (Result: true)

# Driver taps a partner RFID at the charger
CPO -> Hub: eRoamingAuthorizeStart (EvseID, Identification: RFID UID)
Hub -> eMSP: forward AuthorizeStart
eMSP -> Hub: Authorized + SessionID
Hub -> CPO: AuthorizationStatus = Authorized

# App-initiated remote start from the eMSP
eMSP -> Hub: eRoamingAuthorizeRemoteStart (EvseID, EvcoID, SessionID)
Hub -> CPO: AuthorizeRemoteStart
CPO -> Hub: Acknowledgement (Result: true)

# Session ends
eMSP -> Hub: eRoamingAuthorizeRemoteStop (SessionID)
CPO -> Hub: eRoamingChargeDetailRecord (SessionID, kWh, start/stop time)
Hub -> eMSP: forward CDR for billing

Hubject readiness proof points

Hubject-facing validation is usually about proving that the backend can survive hub-mediated partner workflows before live onboarding and operational rollout.

Area	Coverage	Typical validation
EVSE data publication	eRoamingPushEvseData and eRoamingPushEvseStatus	Confirm your charge points and live status reach the hub so partner apps can show them.
Authorization	eRoamingAuthorizeStart, eRoamingAuthorizeStop, and remote start/stop	Exercise both RFID and app-initiated sessions, including SessionID handling.
Charge Detail Records	eRoamingChargeDetailRecord exchange	Validate CDR fields and timing so settlement with the eMSP reconciles.

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.

OICP regression after a CPMS change

Re-run the full eRoamingAuthorizeStart-to-eRoamingChargeDetailRecord flow whenever you change authorization, session, or CDR logic in your CPMS.

Running OICP alongside OCPI

Check that your backend keeps OICP roaming with Hubject consistent when it also speaks OCPI to other partners.

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 flows so you can validate EVSE data, token authorization, and CDR reconciliation before starting Hubject intercharge onboarding.
Does OCPPLab simulate Hubject's proprietary OICP protocol?: No. OCPPLab focuses on standard OCPI (2.1.1 and 2.2.1). Hubject uses OICP for its direct intercharge interface; we help teams benchmark and validate their roaming core before entering Hubject's QA environment.

Prove OCPI roaming before you start Hubject onboarding

Simulate the CPO-to-hub-to-eMSP exchange — EVSE pushes, authorization, and Charge Detail Records — so you reach the Hubject QA environment already passing.

Start your testing Book technical demo

What is Hubject OICP testing?

Why this matters

OICP authorization bugs — a malformed eRoamingAuthorizeStart or a dropped SessionID — strand drivers at the charger and are hard to debug once live partner traffic is flowing.

Getting eRoamingPushEvseData and eRoamingPushEvseStatus right before QA onboarding means your charge points show up in partner apps on the first try.

Hubject QA is the place to prove OICP. OCPPLab can only prove the OCPI modules you already run — locations, sessions, CDRs — so those are solid before you book Hubject’s own environment.

What to validate

Partner-readiness checks for hub-oriented roaming flows and operational exchange patterns.

Session, authorization, tariff, and settlement-path validation at the integration boundary.

Failure handling across delayed responses, invalid payloads, and asynchronous operational callbacks.

Cross-checks between your roaming implementation and the underlying CPMS or settlement systems behind it.