OCPI Is More Important to African EV Charging Than Another Consumer App

The fragmentation problem starts small and becomes expensive

Imagine three charging operators in Lagos, two in Nairobi and one in Kigali. Each has its own backend. Some run different charger vendors. Each has a different API for locations, status and pricing. A mobility platform wants to show all six networks and let a driver start a session.

Without a common interface, the mobility platform builds six adapters. Then every operator changes an endpoint, field name or authentication scheme on its own schedule. Add another aggregator and the integration graph doubles again. Eventually the market is spending engineering time translating the same concepts between proprietary schemas.

OCPI standardizes that business-to-business boundary. The official specification says it enables scalable automated roaming between CPOs and eMSPs and supports authorization, charge-point information, transaction events, charge detail records, remote commands and smart-charging information.²

CPOs own charging operations. eMSPs own the driver relationship.

OCPI is easiest to understand when the roles are clear.

The OCPI 2.3.0 terminology documentation shows the typical module direction for these roles. Locations, sessions, tariffs and CDRs normally originate from CPO-side systems, while tokens normally originate from the eMSP side. Commands usually travel from eMSP toward CPO.³

This division is useful because it creates ownership. One party is authoritative for a particular object and the other party synchronizes it rather than inventing a second truth.

OCPI is not OCPP, and you usually need both boundaries

This is one of the most common architecture confusions in EV software.

The Open Charge Alliance defines OCPP as standardized communication between a charging station and a charging-station management system.⁴ That is the hardware-to-backend boundary. OCPI is the platform-to-platform roaming boundary.

A charger can be perfectly OCPP-compliant and still be commercially isolated from other networks if the operator exposes no roaming layer. Conversely, an eMSP can speak OCPI but still depend on the CPO backend to translate a remote start request into the protocol understood by the physical charger.

What OCPI actually exchanges

OCPI 2.3.0 describes a set of functional modules. Credentials and registration are required; most other modules are optional and can have dependencies.⁵

A roaming charging session is a distributed transaction

From the driver's perspective, a session can feel simple: find charger, tap start, charge, stop, pay. Across systems, it is a sequence of state changes with different owners.

The protocol does not remove distributed-systems problems. It gives those problems a shared language.

How I would architect an OCPI layer

I would keep OCPI outside the core charger-control domain. The internal CPO model should be able to evolve without leaking every internal table into the roaming contract.

The protocol edge should validate country codes, party IDs, object identifiers, timestamps, pagination and version compatibility before domain logic runs. It should also preserve the partner request ID and enough raw context to investigate disputes later.

I would use an internal canonical model and map OCPI objects into it. That prevents the rest of the platform from becoming permanently shaped around one protocol version.

The difficult part is not the happy path

Roaming systems live in partial failure. A remote-start request can be accepted by the CPO backend while the charger is temporarily unreachable. A Session update can arrive late. A tariff can change while a location replica is stale. A CDR can be retried. A partner can time out after the receiving system has committed the request.

The Commands module itself reflects this reality by separating request acceptance from the later command result.¹² That is exactly the right mental model for the rest of the integration: do not collapse "request received," "operation attempted" and "physical action completed" into one boolean.

It is also important to distinguish protocol credentials from driver tokens. OCPI 2.3.0 uses credentials tokens for platform authentication, while the Tokens module deals with credentials used to authorize drivers or charging. The specification explicitly separates those concepts.⁶

Why this matters specifically as African charging networks emerge

The argument is not that Africa should copy Europe's market structure. It is that open interfaces become more valuable before fragmentation hardens.

African EV deployment is likely to remain heterogeneous. Some markets will be bus-heavy. Others will scale motorcycles, ride-hailing or corporate fleets first. Energy companies, property owners, fleet operators and dedicated CPOs may all own charging assets. If each network grows behind a proprietary wall, regional expansion becomes an integration tax.

The IEA expects charging infrastructure to continue expanding rapidly as EV adoption grows, while the World Bank and African Development Bank are already framing charging as part of a broader transport and energy investment problem.¹³¹⁴ In that environment, interoperable software contracts are infrastructure, not a cosmetic developer feature.

OCPI also allows bilateral connections. A market does not need a giant central roaming hub before two networks can interoperate. That is useful for early ecosystems where only a few serious operators exist.

What I would build before another consumer charging app

Consumer experience still matters. But the strongest consumer experience is built on infrastructure that lets the customer move across networks without understanding the commercial boundaries underneath.

The network should be the product. The app should be one client of it.