OCPI has had five named releases since its first public version, and the gaps between them decide what a roaming link can actually express. This is the version-by-version history: what changed in each release, and what problem the change was solving.
The release timeline
| Version | Released | Major theme |
|---|---|---|
| 2.1 | 2016 | First public version |
| 2.1.1 | Oct 2017 | Patch and clarifications on 2.1 |
| 2.2 | Mar 2020 | Hub role, Smart Charging module, refinements |
| 2.2.1 | Jun 2020 | Bugfix and clarification pass over 2.2 |
| 2.3.0 | Feb 2025 | AFIR data duties plus an extensibility framework |
| 3.0 | (in development) | Larger architectural changes |
timeline
title OCPI version evolution
2016 : 2.1 first public version
2017 : 2.1.1 clarifications and fixes
2020 : 2.2 hubs + smart charging
: 2.2.1 bugfix release
2025 : 2.3.0 AFIR data duties
2026+ : 3.0 in developmentOCPI 2.1 / 2.1.1 (2017)
Theme: the first version with enough of the model pinned down to build a production integration against.
What it established:
- The CPO and eMSP role definitions that the rest of the protocol hangs off (the OCPI overview covers how those roles divide the work)
- The six core modules: Locations, Tariffs, Sessions, CDRs, Tokens and Commands
- The Sender and Receiver interface concept. Each module has a side that publishes data and a side that consumes it, and which side you are is a property of the module, not of your company.
- Token-based authentication between parties
- The Versions and Credentials modules for connection setup, walked through in credentials and versions
What was missing or weak:
- No formal hub role. The protocol modeled every link as CPO to eMSP, so anything sitting in the middle had to present itself as one side or the other.
- Smart charging capability was minimal
- Several data fields carried semantics loose enough that two implementers could read them differently and both be defensible
- Module-level versioning was loose
Status in 2026: 2.1.1 is marked deprecated in the specification. Because the version lives in the URL path, a deployed 2.1.1 link keeps answering /ocpi/cpo/2.1.1/ requests regardless, so “deprecated in the spec” and “gone from the wire” are two different events separated by years.
OCPI 2.2 → 2.2.1 (Mar–Jun 2020)
Theme: hubs, smart charging, and the sanding down that a protocol only gets after production use.
Hub role formally defined
OCPI 2.2 made Hub a first-class role: a party that holds OCPI connections with several CPOs and eMSPs and routes messages between them. Roaming hubs already operated commercially before that (Hubject among them), but they had to do it by impersonating a CPO to one side and an eMSP to the other. Naming the role brought its own plumbing, notably the Hub Client Info module, which lets a hub tell every connected party who else is currently reachable. The tradeoff between routing through a hub and wiring partners directly is worked through in hub vs peer-to-peer OCPI.
Smart Charging module
A module for negotiating charging profiles across the roaming boundary: an eMSP can request a delivery schedule, and the CPO answers with the schedule it will actually honor. 2.1.1 had no vocabulary for this at all. The ChargingProfiles module walks through the message flow.
Better session real-time data
Session updates gained finer live data: dynamic current and voltage, status per EVSE rather than per location, and fuller metering information.
Improved authorization flows
The token model picked up clearer rules for whitelist and blacklist handling, and for what a receiver should do with a token it does not recognize. That last case is the one that used to produce two partners behaving differently while both believed they were correct.
CDR clarifications
The Charge Detail Record gained a structured pricing breakdown. Per-kWh, per-minute, idle fees and taxes each get their own dimension instead of being flattened into one total, which is what makes a disputed session reconcilable months later.
2.2 → 2.2.1 patches
2.2.1 is a bugfix and clarification release over 2.2: same module set, same wire format, fewer readings per paragraph. Implementing 2.2 first buys nothing except the ambiguities 2.2.1 already resolved. The 2.2 vs 2.2.1 comparison explains why those minor digits matter in practice.
Status in 2026: OCPI 2.2.1 is the current mainstream release. Absent a specific AFIR requirement, it is the version a fresh implementation should target.
OCPI 2.3.0 (February 2025)
Theme: regulatory compliance and extensibility.
AFIR (Alternative Fuels Infrastructure Regulation) compliance
The EU’s Alternative Fuels Infrastructure Regulation (Regulation (EU) 2023/1804) sets data publication duties for public charge points: availability that reflects reality, ad-hoc payment, and a price the driver can see before plugging in. Those duties land on the protocol as concrete requirements:
- Tariff publication formats that can be rendered into an up-front price
- Status updates timely enough that published availability is not already stale
- A minimum set of Location fields, mandatory rather than optional
2.3.0 carries those fields natively. A 2.2.1 link can be made to satisfy the same duties, but only through bilateral agreement or non-standard fields, which is the exact situation the extensibility framework was added to clean up. AFIR compliance for OCPI in Europe (coming soon) takes the requirements one at a time.
North American tax level support
The earlier CDR pricing model assumed a single national VAT. North American jurisdictions stack taxes (federal, state, county, municipal), and collapsing them into one figure leaves a CDR that cannot be audited against the receipt the driver was shown. 2.3.0 represents several tax levels on a single CDR.
Extensibility framework
A namespaced mechanism for vendor-specific fields and message types. A partner that does not recognize a namespaced extension ignores it rather than rejecting the message. That reverses the earlier stance: previous versions discouraged custom fields, and 2.3.0 instead gives them a place where a strict parser will not choke on them.
Refined module behaviors
- Tariffs module updates for more complex pricing structures
- Sessions module improvements for partial reporting
- Clarifications on what is required versus optional in various flows
Status in 2026: 2.3.0 is the newest published release, and its pull is regulatory rather than technical. Outside the AFIR perimeter, the multi-level tax fields are the part most likely to earn their keep. For a module-by-module breakdown, see what’s new in OCPI 2.3.0.
OCPI 3.0 (in development)
Not released, and the EVRoaming Foundation has published no release date. Treat any timeline you hear as unconfirmed until a release candidate exists.
The gaps 2.x still leaves are a better guide than a rumored date. A major version has room to address:
- Structural changes that 2.x cannot make without breaking compatibility
- Tighter handoffs with ISO 15118, where OCPI tokens and 15118 contract certificates describe the same driver in different vocabularies (see Plug and Charge end to end (coming soon))
- Vehicle-to-grid flows, which need bidirectional energy and settlement concepts the current data model has no room for
- A security model with more in it than bearer tokens over TLS
The version number is the signal worth watching. A 3.0 announces that compatibility is on the table in a way that no 2.x point release does. Our OCPI 3.0 preview tracks the proposals as they firm up.
Migration considerations
From 2.1.1 → 2.2.1
This is the migration with real structural work in it, because 2.2 changed shape rather than adding fields. What moves:
- The hub role, which changes who you talk to and how routing information travels if you go via a hub
- New module endpoints to implement on both interfaces
- CDR pricing structure, where the flat total becomes a set of dimensions
- Token authentication behavior
The 2.1.1 to 2.2 migration guide has the field-level detail.
The workable pattern is to serve both versions from the same backend for a while: keep /ocpi/cpo/2.1.1/ alive, add /ocpi/cpo/2.2.1/, let each partner move when it is ready, and retire the old path once the last one has.
From 2.2.1 → 2.3.0
Smaller, and mostly additive:
- New AFIR-related fields
- Tax level fields, which matter wherever taxes stack rather than only in Europe or only outside it
- Moving any custom fields you previously bolted on into the extensibility framework’s namespace
Backward compatibility
OCPI puts the version in the URL (/ocpi/cpo/2.2.1/...), so one party can serve several versions at once. Partners discover what each other supports through the Versions module and settle on the highest version both sides implement.
That negotiation is what makes a phased migration possible. It is also the reason a unilateral upgrade changes nothing by itself.
Which version to implement today
For a new OCPI implementation in 2026:
- Target 2.2.1 as the floor. It is the current mainstream release, and everything below it is missing structure you will want.
- Add 2.3.0 if AFIR applies to you, or if you bill in jurisdictions with stacked taxes and need the CDR to survive an audit.
- Keep your module boundaries clean. A 3.0 that breaks compatibility will be far cheaper to absorb if your version-specific serialization is not smeared through your business logic.
For an existing 2.1.1 deployment, the deciding factor is not the calendar. It is which 2.2.1 capability you are currently working around: hub routing, smart charging, or CDR pricing detail. If you are working around none of them, the upgrade can wait for a partner to force it. If you are working around two, the workarounds already cost more than the migration.
What actually sets your version
The version you run is not entirely your decision. Because the Versions module settles on the highest version both sides implement, your effective version on any given link is set by whichever partner is furthest behind. Upgrading your own stack to 2.3.0 while your largest counterparties sit on 2.2.1 gets you a set of 2.2.1 links and a second codebase to maintain.
That changes the arithmetic of hub versus direct connections in a way the topology diagrams do not show. One upgrade on a hub link can move every partner behind that hub at once, while a mesh of bilateral connections has to be renegotiated partner by partner. The cost of running a version behind is bounded, but it is not paid once. It is paid on every link you hold, and it is settled on someone else’s schedule.