What is an OCPI gateway?
An OCPI gateway is software that implements the Open Charge Point Interface (OCPI) so Charge Point Operators (CPOs) and e-Mobility Service Providers (eMSPs) can exchange roaming data: locations, tokens, sessions, tariffs, and charge detail records (CDRs).
Product path: OCPI gateway for roaming operations. Protocol depth: OCPI complete guide.
OCPI gateway vs OCPP gateway
These two terms are confused constantly—and that confusion shows up in RFPs.
| Layer | Protocol | Connects | Typical product name |
|---|---|---|---|
| Field | OCPP | Charger ↔ central system | OCPP gateway / OCPP proxy |
| Market | OCPI | CPO ↔ eMSP / hub | OCPI gateway |
- OCPP answers: “How do chargers talk to my platform?”
- OCPI answers: “How do my partners authorize drivers, see locations, and settle sessions?”
You can run a world-class OCPP stack and still fail roaming if OCPI is glued into the CPMS as custom code. You can also ship OCPI modules while charger connectivity remains fragile. Production operators usually need both.
Background: OCPI vs OCPP differences.
What an OCPI gateway actually does
A serious OCPI gateway is not a single “enable OCPI” toggle. It owns operational concerns:
- Credentials and versions — who you are to each partner, which OCPI version, which roles
- Module scope — locations, tokens, sessions, tariffs, CDRs, commands, optional modules
- Sync and push/pull behavior — partner-specific realities in production
- Session and CDR integrity — billing and dispute readiness
- Observability — which partner is blocked, late, or misconfigured
If those live only as scripts in a repo, every new roaming partner becomes a release risk. That is why teams search for OCPI gateway software.
When do you need an OCPI gateway?
You need a dedicated OCPI gateway when:
- You are launching more than one roaming partner or hub
- Token or CDR issues already consume ops time
- Partner onboarding takes weeks because scope is unclear
- Billing/finance cannot reconcile CDRs cleanly
- You want roaming outside the critical path of charger OCPP changes
You might delay a standalone gateway only if you have a single bilateral pilot with no scale plan—and even then, design for extraction early.
Related solution: OCPI roaming operations. Checklist: OCPI rollout checklist.
OCPI gateway vs “OCPI proxy”
Some buyers type OCPI proxy. Intent is usually:
- multi-partner routing
- hub + bilateral coexistence
- shielding the core product from partner variance
That is still an OCPI gateway problem: partner policy and module control. EV Cloud uses gateway language for the product; the architecture covers multi-partner operational control rather than a separate consumer “proxy” SKU.
Versions: 2.1.1, 2.2.1, 2.3.0
Do not buy “OCPI support” as a boolean. Ask:
- Which modules are live for which partners?
- How do you handle partner version mismatch?
- What is the path for tariff and CDR edge cases?
- How do hubs differ from bilateral links?
See OCPI 2.1.1 vs 2.2.1 and OCPI CDR billing integration.
How OCPI gateway fits with EV Cloud
EV Cloud is built as the neutral infrastructure layer:
- OCPP gateway / proxy for chargers
- OCPI gateway for partners
- ChargerPilot AI agents for protocol ops on that telemetry
Keep the CPMS for workflows you like; keep the gateway layer for connectivity and roaming exchange that must stay portable.
