---
title: "The Ultimate Guide to OCPI (Gateway & Roaming)"
description: "OCPI explained for CPOs and eMSPs—and when you need an OCPI gateway: modules, 2.1.1 vs 2.2.1, bilateral vs hub roaming for faster cross-network charging."
author: "Yacine El Azrak"
date: "2026-04-05"
updated: "2026-07-23"
tags:
  - "OCPI"
  - "ocpi-gateway"
  - "ev-roaming"
  - "protocol"
  - "cdr"
  - "tariff"
  - "emsp"
  - "cpo"
category: "OCPI"
canonical: "https://gridos.co/ocpi"
---

> OCPI is how CPO and eMSP backends exchange roaming data. An OCPI gateway runs credentials, modules, sessions, and CDRs in production so multi-partner roaming is not custom code per partner.

## 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](/ocpp) connects a charger to its management system (often via an [OCPP gateway](/solutions/ocpp-gateway)), OCPI connects one operator's platform to another—often via an [OCPI gateway](/solutions/ocpi-gateway)—so drivers can charge across networks, sessions are reported, and costs are settled. It is maintained by the [EV Roaming Foundation](https://evroaming.org/) and used by roaming Hubs across Europe and beyond.

**Product paths:** [OCPI gateway](/solutions/ocpi-gateway) · [OCPI roaming operations](/solutions/ocpi-roaming-operations) · [OCPP gateway](/solutions/ocpp-gateway) · [OCPP proxy](/solutions/ocpp-proxy) · [OCPP platform](/solutions/ocpp-platform) · [ChargerPilot AI](/solutions/chargerpilot-ai-agents) · [Solutions hub](/solutions) · [Pricing](/pricing) · [What is an OCPI gateway?](/blog/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](https://openchargealliance.org/protocols/open-charge-point-protocol/) 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](/solutions/ocpp-gateway) (or [OCPP proxy](/solutions/ocpp-proxy) for multi-backend dual-run) for charger connectivity and an [OCPI gateway](/solutions/ocpi-gateway) for roaming and partner exchange. For a deeper breakdown, see [OCPI vs OCPP: what's the difference and when to use each](/blog/ocpi-vs-ocpp-differences) and the full [OCPP guide](/ocpp).

## OCPI modules explained

OCPI is organised into [modules defined in the official OCPI specification](https://github.com/ocpi/ocpi), 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](/blog/ocpi-cdr-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:

| Aspect | OCPI 2.1.1 | OCPI 2.2.1 |
|--------|------------|------------|
| Party identification | `party_id` (with alpha-3 country code) | `country_code` (alpha-2) + `party_id` |
| Hub support | None native | First-class (HubClientInfo, `OCPI-from-*` / `OCPI-to-*` routing headers) |
| Smart charging | Not included | ChargingProfiles module |
| Status codes | Core 1xxx–3xxx | Adds 4xxx Hub-specific errors |
| Typical use | Most widely deployed | Current recommended version |

### 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](/solutions) 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.
## Links
- HTML: https://gridos.co/ocpi
- Markdown: https://gridos.co/ocpi.md