OCPI: roaming between networks

OCPI (Open Charge Point Interface), from the EVRoaming Foundation, is a widely used open standard between operators. It is not the only roaming protocol (others such as OCHP and eMIP exist), but it is the one these docs focus on. Where OCPP connects a charging station to its own back office, OCPI connects CPOs and eMSPs to each other so a driver on one network can charge on another and everyone gets paid. It is an HTTP REST API exchanging JSON, used peer to peer between two parties or through a roaming hub.

Getting connected: credentials

Two parties start with the Credentials handshake: they exchange tokens and the URL of each other's version and module endpoints, agreeing which OCPI version and which modules they will use. After that, each side calls the other's endpoints directly.

The core modules

OCPI is a set of modules, each a small API. A party implements the ones its role needs.

  • Locations. Where the charging stations are and what they offer: sites, EVSEs, connectors, power, and availability. The CPO publishes; the eMSP consumes to show drivers where they can charge.
  • Tokens. The identifiers that authorise charging (RFID cards, app tokens) and the real-time authorization of them. The eMSP owns its tokens; the CPO checks them.
  • Sessions. Live and completed charging sessions, so the eMSP can follow a session its driver is running on the CPO's network.
  • CDRs. Charge Detail Records, the final billable record of each session, sent from CPO to eMSP. These drive settlement.
  • Tariffs. Pricing information, so a session's cost can be understood and shown.
  • Commands. Remote actions across the roaming link: start, stop, reserve, unlock.
  • Credentials. The registration and handshake described above.
  • Later versions add more: ChargingProfiles and HubClientInfo in 2.2.1, and a Payments module in 2.3.0.

Token authorization

When a driver presents a token on a charging station that belongs to another operator, the CPO authorises it in real time against the token's eMSP over the Tokens module (or a cached, authorised copy). That check returns a yes or no in a few hundred milliseconds, so a driver on another operator's charging station is authorised almost instantly.

CDR reconciliation

Settlement runs on CDRs, so the rules around them are strict. A CDR is immutable once sent: if something was wrong, the fix is a separate credit CDR, never an edit. Parties keep in sync using delta queries driven by a last_updated timestamp, pulling only what changed. Getting CDR exchange right, matching them to sessions, handling corrections, and reconciling what each party owes, is most of the real work of roaming.

Versions

  • 2.1.1. Older but still active across the network. Markdown spec.
  • 2.2.1. The current mainstream version. Adds country_code and party_id on objects, explicit sender and receiver roles per endpoint, the ChargingProfiles and HubClientInfo modules, and session_id on CDRs.
  • 2.3.0. The newest, which adds the Payments module.

A hub such as Gireve or Hubject speaks OCPI to everyone connected, so a party integrates once and reaches the whole network behind the hub.

At Road

Road operates a roaming hub and speaks OCPI as both CPO and eMSP. An operator can connect over OCPI to reach Road's network, take roaming as a managed service, or use the hub purely as OCPI infrastructure while keeping its own agreements. The roaming section of these docs covers Road's implementation; the detail above is the standard itself.