When a driver pulls into a charging station on a network they don't belong to and plugs in, they probably don't think much about what happens behind the scenes. For the CPO running that station, however, the roaming session is a multi-party data exchange that crosses at least three systems before the driver's home network gets billed. OCPI — the Open Charge Point Interface — is the protocol that makes this work, and understanding its data model is essential for any CPO building interoperability into their network.
This post is a technical walkthrough of how OCPI 2.2.1 roaming actually functions: the party roles, the data flows, and where the complexity concentrates for CPOs who are either enabling their stations for roaming or consuming roaming capabilities from other networks.
The Three-Party Architecture
OCPI roaming involves three logical parties: the eMSP (e-Mobility Service Provider — the driver's home network, which holds their account and payment credentials), the CPO (Charge Point Operator — the party operating the physical station being used), and optionally a roaming hub (an intermediary that aggregates multiple CPO and eMSP connections so each party doesn't need a direct integration with every other party).
The direct-connect model (CPO ↔ eMSP without a hub) makes sense for bilateral agreements between major networks. At scale, direct connections become untenable — a CPO with roaming agreements with 30 different eMSPs needs 30 separate OCPI connections to maintain. Roaming hubs like Gireve, e-clearing.net, and Hubject provide the aggregation layer: the CPO connects once to the hub, and the hub routes sessions to and from all connected eMSPs. The tradeoff is hub fees and the hub's data routing policies, which some CPOs prefer to avoid for their largest bilateral relationships.
What OCPI 2.2.1 Actually Carries
OCPI is a REST-based protocol organized into functional modules. Each module handles a different aspect of the roaming session lifecycle:
Locations. The CPO publishes its station data — location, available connectors, pricing, real-time availability status — to the eMSP via the Locations module. The eMSP uses this data to tell drivers where they can charge. OCPI location data must be kept current: a connector shown as available that's actually out of order creates driver frustration and disputes.
Tokens. The eMSP shares its driver tokens (RFID credentials, app-generated tokens, or Plug&Charge certificates) with the CPO's token whitelist. When a driver presents their credential at a roaming station, the CPO's OCPP authorization logic checks the local token whitelist before the session starts. Without pre-loaded tokens, the CPO has to make a real-time authorization request to the eMSP's OCPI endpoint during the driver's plug-in sequence — which adds latency and creates a failure mode if the network call doesn't complete.
Sessions. Once a session starts, the CPO sends real-time session updates to the eMSP via the Sessions module: session start, intermediate energy readings, and session stop with final metered totals. The eMSP uses this data to show the driver their active session status in their app.
CDRs (Charge Detail Records). At session end, the CPO generates a CDR — the formal billing record — and sends it to the eMSP. The CDR contains the session's total energy, duration, applicable tariff, and calculated cost. The eMSP uses the CDR to bill their customer. The CPO uses the CDR aggregate to settle with the eMSP according to their bilateral tariff agreement.
Tariffs. CPOs publish their pricing structures for roaming sessions via the Tariffs module. eMSPs display these tariffs to drivers before they start a session. Tariff structures in OCPI 2.2.1 support multiple pricing dimensions — energy (per kWh), time (per minute), flat session fee, and minimum charge — which allows CPOs to replicate their full retail pricing logic for roaming sessions.
The Token Synchronization Problem
Token synchronization is one of the higher-friction operational areas in OCPI deployments. Consider a scenario: a mid-size eMSP with 80,000 active driver tokens connecting to a CPO's OCPI endpoint for the first time. The initial token sync — where the eMSP pushes its full token list to the CPO — can involve tens of thousands of records. OCPI handles this via pagination, but the initial sync can still take significant time depending on the OCPI implementation's throughput limits on both sides.
After initial sync, tokens are updated incrementally: the eMSP pushes delta updates when tokens are added, updated, or revoked. The CPO's OCPI implementation needs to process these updates promptly and reflect them in the OCPP authorization whitelist used by the charge points. There's a propagation delay between when the eMSP updates a token and when that change is reflected on every charge point in the CPO's network. For token revocations (e.g., a driver cancels their account), this delay matters — a revoked token should not continue authorizing sessions at roaming stations.
We're not saying real-time revocation is always operationally critical — for most session types, a 15-minute propagation window is acceptable. But for high-value accounts or networks with specific fraud risk profiles, the propagation latency is a real operational parameter worth understanding and configuring.
CDR Disputes and Settlement
CDRs are the revenue document for roaming sessions, and CDR disputes are a normal part of operating a roaming-capable network. Disputes arise when the eMSP's calculated cost (from CDR data) doesn't match what the driver's vehicle reported (from their onboard energy meter), when a session ended abnormally and the CDR doesn't reflect the actual energy delivered, or when tariff interpretation differs between the CPO and eMSP systems.
OCPI 2.2.1 includes a CDR correction mechanism — the CPO can push a corrected CDR if the original contained errors, and the eMSP can flag a CDR for dispute. But the resolution process is bilateral — OCPI defines the messaging, not the commercial resolution procedure. Most roaming agreements include dispute resolution clauses specifying timelines and escalation paths. From an operational standpoint, the key is ensuring CDRs are generated promptly and accurately: metered energy from the OCPP session should match the CDR energy total without rounding errors or timezone conversion issues in the timestamp fields.
OCPI Implementation Maturity: What to Verify
Not all OCPI implementations are equivalent. OCPI 2.2.1 has mandatory and optional modules, and the optional modules cover important functionality for full roaming interoperability — including the Commands module (for remote start/stop of sessions by the eMSP) and the Credentials module for connection management. Before signing a roaming agreement or connecting to a new party via a hub, it's worth verifying which OCPI modules the counterparty has implemented and which OCPI version they're running. OCPI 2.1.1 and 2.2.1 have meaningful differences in CDR structure, tariff model, and token handling; interoperability testing against a specific version matters.
Many roaming hubs provide conformance testing tools that let CPOs and eMSPs validate their OCPI implementation against the hub's expected behavior before go-live. Using these tools before connecting to a production hub prevents session failures and CDR errors that are much more time-consuming to debug after drivers are affected.
Roaming interoperability is increasingly a baseline expectation for CPOs, not an advanced feature. Drivers expect their credentials to work across networks without friction. The CPOs who build clean OCPI implementations — accurate locations, reliable token sync, prompt CDR generation — provide the roaming experience that builds driver trust in their network, which ultimately drives repeat utilization at their stations.