Two acronyms, one letter apart, doing completely different jobs — OCPP and OCPI confuse almost everyone entering the charging industry, including plenty of people selling into it. The confusion matters, because knowing which protocol does what tells you where the boundaries in your architecture belong.
Here's the working map.
OCPP: the charger's language
OCPP (Open Charge Point Protocol) connects a charge point to the backend that manages it. Boot notifications, heartbeats, status, meter values, remote commands, firmware delivery, smart-charging profiles — the full operational conversation between hardware and its management system travels over OCPP.
It's a device protocol: one charger, one backend, a persistent WebSocket, and a relationship of control. If the question is "how do I monitor, update or command this charger?", the answer involves OCPP. We've written a lot about it — running mixed 1.6/2.x fleets, securing the connection, smart-charging profiles.
OCPI: the market's language
OCPI (Open Charge Point Interface) connects organisations: the charge point operator (CPO) who runs the infrastructure, and e-mobility service providers (eMSPs) who bring drivers. Over OCPI flow the things a market needs — locations and live availability, tariffs, session records for settlement, tokens for authorisation, and commands like "start a session for my customer on your charger".
It's how a driver with one app charges on networks they've never heard of, and how your chargers appear in mapping services and journey planners. In the UK, open availability data is also a regulatory expectation — the feeds that keep public maps accurate are OCPI-shaped. (See our regulations explainer.)
The one-diagram version
Rendering diagram…
The charging platform sits at the junction: south it speaks OCPP to hardware; north it speaks OCPI to the market; east it speaks plain APIs to your own business systems (a boundary we've covered in streaming telemetry into your stack).
The rest of the alphabet, briefly
A few more you'll meet, so they slot into the map:
- ISO 15118 — the vehicle-to-charger protocol underpinning Plug & Charge (the car authenticates itself; no card or app). It complements OCPP: 15118 between car and charger, OCPP carrying the results upstream.
- OpenADR / grid protocols — demand-response signals between energy players and large loads. Relevant when charging fleets participate in flexibility markets; typically terminates at the platform, which translates it into the site limits and charging profiles chargers understand.
- OSCP — capacity forecasting between grid operator and site; narrower adoption, same "grid-facing, platform-terminated" shape.
The pattern worth internalising: specialised protocols at the edges, one platform translating in the middle. Chargers shouldn't know about roaming; roaming partners shouldn't know about firmware. When those concerns leak across the boundary, architectures get brittle.
What this means when you're evaluating platforms
Three practical consequences of the map:
- "OCPP compliant" is table stakes, not an answer. It says a platform can talk to chargers — nothing about market connectivity, and nothing about how well it operates mixed fleets.
- Ask separately about OCPI. If your strategy involves roaming, eMSP partnerships or regulatory data feeds, the platform's OCPI story — versions, roles (CPO side, eMSP side, or both), hub connections — is its own line of due diligence. A vendor fluent in OCPP but vague on OCPI is telling you where their product stops.
- Your own integrations deserve a first-class door. OCPI is for market partners; it's a poor fit for getting your data into your systems. That's what a proper API surface is for — don't let a vendor point you at their OCPI feed as the answer to internal reporting.
The takeaway
OCPP runs the chargers; OCPI runs the marketplace; your platform is the translator between them and your business. Keep each protocol at its own boundary, evaluate them as separate capabilities, and the acronym soup resolves into a rather tidy architecture.
AmpNexus speaks OCPP 1.6–2.1 southbound and exposes everything northbound through documented APIs — see the platform or talk to us about roaming and data-feed requirements.