OCPI 3.0 is the next major version of the OCPI roaming protocol, in active development at the EVRoaming Foundation. The current released version is 2.3.0 (published in early 2025), and most operators will not touch 3.0 in production until 2028 or later. But the direction the protocol is taking matters now for anyone planning multi-year EV charging architecture — a CPO like EVgo or IONITY, an eMSP, or a roaming hub picking a data model today wants to know what the next major version will demand of it.
There is an important caveat up front: 3.0 development happens in a private EVRoaming Foundation working repository, so no detailed public spec exists yet. This preview describes the direction and themes the Foundation has signalled — not confirmed fields, enums, or modules. Where a specific has not been published, this article says so and points you to the official OCPI changelog rather than inventing detail. High-level and correct beats specific and wrong.
This article covers what is known about OCPI 3.0 as of 2026, what it is positioned to deliver, how it fits alongside the just-released 2.3.0, and how to think about it strategically.
The character of 3.0
OCPI 2.x has been an incremental evolution. As the OCPI version history shows, 2.1.1 → 2.2 → 2.2.1 → 2.3.0 each added capability while staying within the same architectural frame. The jump from 2.1.1 to 2.2, by contrast, was a bigger structural change — new roles, a versioning module, a reworked handshake. A major version number signals that kind of step, not another additive point release.
OCPI 3.0 is positioned as a larger step of that second kind. The motivations the EVRoaming Foundation has signalled:
- V2G integration as a first-class concern. Current OCPI treats bidirectional power as an addition to the existing one-direction frame. 3.0 may restructure the data model to handle bidirectional symmetrically.
- Grid services native integration. The relationship between charging sessions and grid-services participation (demand response, frequency regulation, capacity markets) needs first-class support.
- Energy services framework. Beyond “charging,” the protocol may model a broader range of energy services — discharging, balancing, deferred energy delivery.
- Tighter ISO 15118-20 alignment. Lessons learned from 2.3’s ChargingProfile-to-15118-20 mapping likely inform a cleaner approach in 3.0.
- Cleanups. Years of operational experience reveal data-model warts that 3.0 can fix without backward-compatibility constraints.
The specifics will evolve as drafts mature. The direction is clear; the details are not yet final.
Likely areas of change
Based on the direction of working-group discussion and the trajectory of EV charging needs, these are the areas a 3.0 refresh is positioned to address. None of the following are confirmed spec details — they are the themes to watch as public drafts appear.
Sessions and energy direction
Current OCPI sessions implicitly assume energy flows from charger to vehicle. 3.0 may explicitly model session direction (forward, reverse, bidirectional) with cleaner semantics around energy accounting.
CDRs for bidirectional sessions
A V2G session involves energy flowing back to the grid. The CDR needs to express that — possibly as separate forward/reverse energy components, possibly as a single direction-aware energy field. Cost calculation may diverge (energy delivered to user vs energy received from user at potentially different prices).
ChargingProfiles → broader energy schedules
The 2.3 ChargingProfile module was a meaningful step. 3.0 may evolve this into a more general energy-schedule concept that handles forward charging, reverse discharging, and idle/holding states in a unified way.
Tariffs for bidirectional and grid services
A V2G-capable EV may be billed for charging and paid for discharging. The tariff structure needs to express both directions with potentially different rates, time restrictions, and quality requirements.
Grid services integration
Demand response signals, capacity availability declarations, frequency regulation participation — these have historically been outside OCPI’s scope. They already exist as separate programs on both sides of the Atlantic: utility and ISO demand-response schemes in North America (for example PG&E and ConEdison managed-charging pilots, or ISO-run frequency markets such as PJM and CAISO), and aggregator-run flexibility and balancing services across Europe (national TSO balancing markets, and schemes coordinated through bodies like ENTSO-E). Today an operator bridges those worlds with custom integrations. 3.0 may bring some of that coordination into OCPI as a new module or as extensions to existing ones, so a roaming session can carry grid-service context instead of relying on a side channel.
Refined roles
The role landscape (CPO, eMSP, Hub, SCSP, NSP, NAP) may evolve again. New roles may be introduced for grid-services participants, energy aggregators, etc.
Authentication enhancements
The Credentials handshake works but is showing its age. OCPI today authenticates each request with a shared token presented as Authorization: Token <token> — note the literal scheme word is Token, not Bearer. 3.0 may modernize this, possibly aligning more closely with industry-standard OAuth 2.0 / OIDC patterns. This is speculative direction, not a confirmed change.
Modular evolution
3.0 may make the modular structure of OCPI more explicit — clearer which modules are required vs optional, cleaner extension points for future capabilities.
What stays the same
A short list of things that probably won’t change radically.
The core architecture — CPOs roaming with eMSPs through hubs or P2P — remains.
Most existing modules — Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Credentials, Versions — will continue to exist, possibly with updates but recognizable.
JSON over HTTPS as the transport. No likely change to REST-like patterns.
Token-based request authentication — the shared-token model over HTTPS — with possible enhancements to the handshake.
The protocol is mature and broad. 3.0 will refine, not replace.
Adoption timeline
The Foundation has not committed to public dates. The following is a projection based on how past OCPI versions have travelled from draft to mainstream — treat the years as rough guides, not published milestones, and check the official changelog for real release news.
flowchart LR
A[2026<br/>Drafts published] --> B[2027<br/>Stable release]
B --> C[2028<br/>Adoption broadens]
C --> D[2029-2030<br/>Mainstream]
D --> E[2031+<br/>3.x dominant]
style A fill:#e3f2fd,stroke:#1976d2
style E fill:#e8f5e9,stroke:#388e3c2026: OCPI 3.0 drafts published. Working group review. Some early experimental implementations.
2027: OCPI 3.0 stable release (some projections put it at 2027-2028). First production implementations by hubs and early-adopter operators. Most operators stay on 2.2/2.2.1/2.3.0.
2028: Early adoption broadens. Hubs offer bridging between 2.x and 3.0. New deployments increasingly start on 3.0.
2029-2030: Mainstream adoption. 2.x deployment cohort declines as fleets refresh.
2031+: OCPI 3.0 is dominant. 2.x continues for legacy. OCPI 3.x point releases address gaps.
The pace is set by ecosystem readiness, not just spec readiness. The transition will be gradual.
How to think about 3.0 now
Some practical guidance for 2026 operators.
Stay on 2.2 or 2.2.1 for current production. Don’t try to anticipate 3.0 in current architecture — the details aren’t final. If you’re still deciding, the 2.2 vs 2.2.1 comparison covers which to build on today. A North American CPO with no EU footprint has little reason to move off a solid 2.2.1 deployment yet.
Treat 2.3.0 as the near-term step, not 3.0. OCPI 2.3.0 shipped in early 2025, and its additions — AFIR-driven features, bidirectional-aware charging profiles, tax handling — are the realistic next migration for operators who need them, especially AFIR-regulated networks in Europe (coming soon). That is a far smaller lift than a 3.0 jump.
Design your data model for evolution. If your internal data model maps cleanly to OCPI 2.x but is inflexible to bidirectional and grid-services concepts, you’ll have harder migrations later. Build in some room.
Watch the spec drafts. As OCPI 3.0 drafts emerge, read them. Familiarity costs little; surprise on release day costs a lot.
Build modular code. Your OCPI implementation should be modular enough that you can swap version-specific module implementations without rewriting your whole stack. The pattern: protocol-version-aware adapters around a stable internal model.
What this means for fleet operators
If you operate a fleet that uses OCPI roaming for fleet vehicles (coming soon) to charge across multiple networks:
- You don’t have to think about 3.0 for several years.
- When you do, the migration is your CSMS/charging-management provider’s problem first.
- Your fleet integrations will continue to work via 2.x for years.
What this means for hubs
For roaming hubs, OCPI version transitions are core to the value proposition. Whether it is a North American interoperability hub, a European roaming hub, or a vendor running a protocol layer such as Hubject’s, the pattern is the same:
- Hubs typically adopt new versions early.
- Hubs bridge versions, so a hub on 3.0 can serve partners still on 2.2 — a partner does not have to migrate in lockstep with everyone else.
- Plan the migration roadmap; communicate it to partners well in advance.
For most hub operators, OCPI 3.0 preparation likely starts in 2026-2027 — which is exactly why hubs prepare ahead of the broader operator base.
What this means for CSMS vendors
CSMS vendors are the bridge between the charging hardware (OCPP) and roaming (OCPI). Major version transitions are significant engineering events.
- Build for backward compatibility from day one.
- Expect customers to be on different OCPI versions for years.
- Plan to support 2.x and 3.x in parallel for an extended period.
- Use the spec-development phase to influence the parts that matter for your customers.
The honest summary
OCPI 3.0 is real and in development. A stable release is projected for roughly 2027-2028, with mainstream adoption following across 2028-2030 — though the Foundation has not committed to public dates, so watch the official changelog rather than any single projection. The protocol is positioned to refresh the V2G and grid-services story, restructure some data models, and modernize authentication, but the concrete fields and modules are not public yet. Most current operators should keep 3.0 out of production planning and focus on solid 2.2/2.2.1 implementations, treating 2.3.0 as the near-term migration if AFIR or bidirectional features demand it. Strategic architects should read the drafts as they appear and design an internal model flexible enough to absorb bidirectional and grid-services concepts. The transition will be measured in years, not months — but the direction is clear enough to plan around today.