The Ultimate Guide to OCPI (Gateway & Roaming)

What is OCPI?

The Open Charge Point Interface (OCPI) is an open, royalty-free protocol for communication between EV charging backends — most commonly between a Charge Point Operator (CPO) and an e-Mobility Service Provider (eMSP). Where OCPP connects a charger to its management system (often via an OCPP gateway), OCPI connects one operator's platform to another—often via an OCPI gateway—so drivers can charge across networks, sessions are reported, and costs are settled. It is maintained by the EV Roaming Foundation and used by roaming Hubs across Europe and beyond.

Product paths: OCPI gateway · What is an OCPI gateway?

In practice, OCPI is the protocol that makes EV roaming work: it lets an eMSP's app authorize a session on a CPO's charger, receive live status, and get a final Charge Detail Record (CDR) for billing — without either side exposing its internal systems.

OCPI vs OCPP in the operator stack

OCPP and OCPI are complementary layers, not competitors: OCPP connects a charger to its management system, while OCPI connects one operator's backend to another for roaming. A full operator stack runs both.

• OCPP is "south-bound": charger ↔ CSMS/CPMS. It carries connector status, transactions, meter values, and remote commands.
• OCPI is "east-west": CPO backend ↔ eMSP backend (or Hub). It carries Locations, Sessions, Tariffs, CDRs, Tokens, and roaming Commands.

A complete operator stack typically runs an OCPP gateway for charger connectivity and an OCPI layer for roaming and partner exchange. For a deeper breakdown, see OCPI vs OCPP: what's the difference and when to use each.

OCPI modules explained

OCPI is organised into modules defined in the official OCPI specification, and a party implements only the modules its role requires. The core set covers Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Credentials, and Versions:

• Locations — the charging sites, EVSEs, and connectors a CPO publishes to partners.
• Sessions — live and historical charging sessions shared during roaming.
• CDRs — the final, billable Charge Detail Record for a completed session. See OCPI CDR and billing integration for how these flow into settlement.
• Tariffs — pricing structures (per kWh, per minute, flat, parking) attached to connectors.
• Tokens — the RFID cards, app IDs, or contract IDs an eMSP issues to drivers.
• Commands — remote actions such as StartSession, StopSession, ReserveNow, and UnlockConnector.
• Credentials — the handshake that registers two parties and exchanges tokens and endpoints.
• Versions — the discovery endpoint that lists which OCPI versions and modules a party supports.

OCPI 2.2.1 adds ChargingProfiles (smart-charging exchange) and HubClientInfo (party presence through a Hub).

What is the difference between OCPI 2.1.1 and 2.2.1?

OCPI 2.2.1 adds first-class Hub support, a ChargingProfiles module, and alpha-2 country codes, while 2.1.1 remains the most widely deployed version with no native Hub role. The headline differences:

OCPI 2.1.1

The most widely deployed version. It uses alpha-3 country codes, identifies parties by party_id, and covers the core roaming modules (Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Credentials, Versions). It has no native Hub role.

OCPI 2.2.1

The current recommended version. Key changes:

• Party identification moves to country_code (alpha-2) + party_id.
• Hubs become a first-class concept (with HubClientInfo and OCPI-from-* / OCPI-to-* routing headers).
• ChargingProfiles module for smart-charging coordination.
• Additional 4xxx status codes for Hub-specific errors.

Choosing a version is usually dictated by your roaming partners and Hubs (Hubject, Gireve, e-Clearing.net). Many CPOs need to speak both versions to different partners at the same time — which is exactly where a gateway layer that normalises versions earns its place.

How OCPI roaming works

OCPI roaming works as a sequence: two backends complete a Credentials handshake, the CPO publishes Locations, the eMSP's Token is authorized in real time, Sessions stream live, and a final CDR closes the session for billing.

1. Credentials handshake — two parties exchange tokens and base URLs via the Versions and Credentials endpoints, establishing a trusted, authenticated connection.
2. Locations push/pull — the CPO publishes its sites, EVSEs, and connectors so the eMSP can show them in its app.
3. Real-time authorization — when a driver starts a session, the CPO checks the eMSP's Token (in real time or against a cached list) before energising the connector.
4. Sessions — the CPO streams session updates so the eMSP can show live charging state.
5. CDR — when the session ends, the CPO sends a final CDR. The eMSP bills the driver; settlement follows commercial agreements.

OCPI supports both push (sender notifies receiver of changes) and pull (receiver fetches with pagination headers), so partners can pick the pattern that fits their volume and freshness needs.

What is the difference between bilateral and Hub-based roaming?

Bilateral roaming is a direct OCPI connection to each partner, while Hub-based roaming connects you once to a Hub to reach many partners. Most operators run a mix of both:

• Bilateral (peer-to-peer) — you run a direct OCPI connection to each partner. Maximum control, but every new partner is another integration to operate.
• Hub-based — you connect once to a Hub (Hubject, Gireve, e-Clearing.net) and reach many partners through it. Faster coverage, less per-partner work, but you inherit the Hub's conventions and a layer of indirection.

Most serious CPOs end up with a mix: a few strategic bilateral links plus Hub coverage for the long tail. Keeping that topology clean — rather than bolting partner logic into your core product — is the operational challenge OCPI infrastructure is meant to solve. See OCPI roaming launch blueprint for a staged approach.

Why does OCPI matter?

OCPI is what turns isolated charging networks into a single, usable experience for drivers. For operators it means:

• Reach — your chargers become visible and usable to every roaming partner's customers.
• Neutrality — an open standard avoids lock-in to a single roaming vendor or Hub.
• Clean settlement — standardised CDRs make cross-network billing auditable.
• Operational separation — roaming, tokens, tariffs, and CDR workflows stay decoupled from charger connectivity.