OCPI 3.0 is the next major version of the OCPI roaming protocol, under development at the EVRoaming Foundation. The current mainstream release is 2.2.1 (June 2020), with 2.3.0 published in February 2025. Nothing about 3.0 is stable enough to build production code against.
That caveat is worth stating plainly, because 3.0 development happens in a Foundation working repository rather than as public drafts. There is no published field list, no enum set, no module inventory. What follows describes the direction and the structural problem 3.0 exists to solve, not confirmed specification content. Where a specific has not been published, this article says so and points at the official OCPI changelog instead of inventing detail.
It still matters in 2026 for one reason. If you are choosing an internal data model for a CPO, eMSP, or roaming hub that will outlive your current OCPI version, the shape of the next major version tells you which parts of that model to keep loose.
The character of 3.0
OCPI 2.x has been incremental. As the version history shows, 2.2 (March 2020), 2.2.1 (June 2020), and 2.3.0 (February 2025) each added capability inside the same architectural frame, and some implementations are still running 2.2 quite happily. The 2.1.1 to 2.2 step was a different animal: new roles, a Versions module, a reworked credentials handshake. A major version number signals that second kind of step.
The structural problem behind 3.0 is a single assumption baked deep into 2.x: energy moves from the charge point to the vehicle. Sessions count kWh delivered, CDRs bill for them, Tariffs price them. Bidirectional charging (coming soon) breaks all three at once, and an optional field does not fix it, because reversing the sign of the energy also reverses the direction of the money.
The themes that follow from that:
- V2G as a direction, not an extension. Current OCPI can carry bidirectional information by bolting it onto a one-way frame. A restructured model would make direction an explicit property of a session rather than something inferred.
- Grid services in the same frame as charging. The relationship between a charging session and a flexibility or demand-response obligation currently lives outside the protocol entirely.
- A wider energy-services vocabulary. Discharging, balancing, and deferred delivery are all things a connected vehicle can do that “charging” does not describe.
- Tighter ISO 15118-20 alignment. The 2.3.0 ChargingProfile mapping to 15118-20 was a first attempt, and first attempts usually leave a cleaner second attempt visible.
- Cleanups. Backward compatibility constrains every point release. A major version is the only place accumulated data-model warts can be fixed.
The direction is legible. The details are not, and anyone publishing field names for 3.0 today is guessing.
Likely areas of change
These are the areas where structural pressure exists. None of them are confirmed specification details, and they are worth reading as the questions a 3.0 draft will have to answer rather than as answers.
Sessions and energy direction
Current sessions implicitly assume forward flow. A revised model could make direction explicit (forward, reverse, or mixed within one session) with defined semantics for how energy accumulates when it changes sign partway through.
CDRs for bidirectional sessions
A CDR is the billing artefact, so this is where the ambiguity gets expensive. Energy returned to the grid has to be expressed somehow: as separate forward and reverse components, or as a direction-aware field, or as two linked records. Whichever it is, cost calculation stops being a single multiplication, because energy delivered to the driver and energy received from the driver need not carry the same price.
ChargingProfiles and energy schedules
The ChargingProfiles module already carries smart-charging limits across a roaming link. A general energy-schedule concept would extend that to cover discharge windows and holding states, so one object describes what the vehicle should do rather than only how fast it may charge.
Tariffs in both directions
A V2G-capable vehicle can be billed for charging and paid for discharging in the same session. Expressing that means the tariff structure needs per-direction rates, and probably per-direction restrictions too, since the value of returned energy depends heavily on when it arrives.
Grid services integration
Demand response signals, capacity declarations, and frequency regulation participation have historically sat outside OCPI’s scope. They are run by utilities, system operators, and aggregators under their own programme rules and their own APIs, which differ by market. An operator that wants a roaming session to also count toward a flexibility commitment bridges the two worlds with a custom integration, and the roaming partner has no visibility into it. Bringing that context into OCPI would let a session carry its grid-service state directly instead of relying on a side channel only one party can see.
Refined roles
The role landscape (CPO, eMSP, Hub, SCSP, NSP, NAP) has grown with each major version. Grid-services participants and energy aggregators do not map cleanly onto any of them today, which is the usual precondition for a new role appearing.
Authentication
The Credentials handshake works, but it is showing its age. OCPI authenticates each request with a shared token presented as Authorization: Token <token>, and note that the literal scheme word is Token, not Bearer, which trips up more first integrations than any other single detail. Aligning with OAuth 2.0 or OIDC patterns is a plausible direction, though nothing has been published. The current security model is what you implement against in the meantime.
What has the most inertia
Some parts of OCPI are hard to change not because they are perfect but because every existing integration depends on them.
The core architecture. CPOs roaming with eMSPs, through a hub or peer to peer, mirrors how the commercial relationships are actually structured. The protocol would have to change alongside the industry, not ahead of it.
Module names and boundaries. Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Credentials, and Versions map onto how the business actually works. Their contents can change while their names stay.
JSON over HTTPS. Changing the transport would invalidate every client library and every proxy, gateway, and log pipeline built around it, for no gain that anyone has articulated.
Token-based request authentication. Even a modernised handshake still has to leave a working path for partners who cannot rotate their integration on someone else’s schedule.
A major version refreshes the model. It does not restart the protocol.
The shape of the transition
The Foundation has not committed to public dates, and neither will this article. What is predictable is the sequence, because OCPI is bilateral: a version is only worth anything once the party on the other end of the connection speaks it too.
flowchart LR
A[Public drafts] --> B[Stable release]
B --> C[Hubs implement<br/>and bridge 2.x]
C --> D[New integrations<br/>start on 3.0]
D --> E[2.x moves to<br/>legacy support]
style A fill:#e3f2fd,stroke:#1976d2
style E fill:#e8f5e9,stroke:#388e3cEach arrow has a gate, and the gates are what actually take the time:
Drafts to stable release. Working-group review, then implementer feedback from whoever builds against the draft early. Structural changes attract more review than additive ones.
Stable release to hub implementation. Hubs go first because bridging is their function. Until a hub can translate between 2.x and 3.0, a 3.0 implementation can only talk to other 3.0 implementations, which is a small set on day one.
Hub implementation to new integrations. Once bridging exists, a new partner can start on 3.0 without forcing anyone else to move. This is the point where the version stops being a research project.
New integrations to legacy. The slowest gate. Existing 2.x links keep working, and there is rarely a business case to migrate a connection that settles correctly today.
If you want a rule of thumb rather than a date: an OCPI major version transition is paced by contract renewals and platform roadmaps, not by specification releases.
How to think about 3.0 now
Run 2.2.1 in production. Do not try to anticipate 3.0 in current architecture when there is no draft to anticipate. If you are still deciding, the 2.2 vs 2.2.1 comparison covers which to build on.
Treat 2.3.0 as the near-term question, not 3.0. Its additions cover AFIR-driven fields, bidirectional-aware charging profiles, and tax handling. Whether that migration is worth doing depends on whether you need those things, which for AFIR-regulated networks in Europe (coming soon) is a different answer than for a North American operator with no EU footprint.
Keep the internal model independent of the wire model. If your database rows are OCPI objects, every OCPI change is a schema change. If OCPI objects are produced and consumed at the edge by mappers, the same change is a mapping change. This is the single decision that most affects what a major version will cost you.
Read the drafts when they appear. Familiarity costs an afternoon. Surprise on release day costs a quarter.
Version your adapters, not your stack. Serving two OCPI versions at once is normal and permanent. Design for it rather than treating it as a temporary state.
What this means for fleet operators
If you run a fleet that relies on OCPI roaming to charge across networks (coming soon), 3.0 is not your problem to solve. Your CSMS or charging-management provider owns the protocol version. What is worth asking them is whether their platform can serve two OCPI versions simultaneously, because the answer tells you whether a future migration means coordinated downtime for your depots or nothing at all.
What this means for hubs
For roaming hubs, version transitions are the product. Whether it is a North American interoperability hub, a European roaming hub, or a vendor running a protocol layer such as Hubject, the mechanics are the same:
- The hub speaks the new version early, because it cannot bridge what it does not implement.
- Bridging lets a partner on 3.0 exchange sessions with a partner still on 2.2, which removes the need for lockstep migration across an entire partner base.
- The roadmap needs communicating well in advance, since partners plan integration work against their own release cycles.
That bridging role is why the incentive to implement a new version reaches a hub before it reaches the operators the hub connects.
What this means for CSMS vendors
CSMS platforms sit between the charging hardware, which speaks OCPP, and roaming, which speaks OCPI. A major version on either side is a significant engineering event, and the two protocols move on independent schedules.
- Build for parallel version support from day one rather than retrofitting it.
- Expect your customer base to be spread across OCPI versions indefinitely.
- Use the specification development phase to raise the cases that matter to your customers, since it is far cheaper to influence a draft than to work around a published spec.
The honest summary
Every OCPI 3.0 roadmap with dates in it, including the ones in other previews, is guessing. What is not a guess is where the cost lands.
A major version migration is expensive in direct proportion to how closely your database resembles the OCPI object model. Persisting OCPI objects as your domain model makes the first integration fast, and it charges interest on every version bump after that. A major version turns that interest into a schema migration performed with live roaming partners on the other end of the connection.
The second thing worth saying is that the hardest part of bidirectional roaming may not be the protocol. A CDR stating that a driver received 20 kWh and returned 8 kWh at a different price implies a settlement relationship that current roaming agreements were not written to describe, and contracts move considerably slower than JSON schemas. Whatever OCPI 3.0 eventually says about the wire format, working out how a driver gets paid, through their eMSP, for energy their car pushed back through someone else’s grid connection is a separate problem. That is the one more likely to gate real deployment.