OCPI has gone through five named releases since its first public version. Each release reflects what the industry learned in production deployments — fixes, additions, and responses to regulation. This is the version-by-version history with a focus on what changed and why it matters.
The release timeline
| Version | Released | Major theme |
|---|---|---|
| 2.1 | 2016 | First public version |
| 2.1.1 | Oct 2017 | Patch + clarifications; first widely-deployed stable |
| 2.2 | Mar 2020 | Hub role, Smart Charging module, refinements |
| 2.2.1 | Jun 2020 | Bugfix on 2.2; what most teams actually implement |
| 2.3.0 | Feb 2025 | AFIR compliance + extensibility framework |
| 3.0 | (in development) | Larger architectural changes |
Visualized as a timeline:
timeline
title OCPI version evolution
2016 : 2.1 first public version
2017 : 2.1.1 first widely-deployed stable
2020 : 2.2 hubs + smart charging
: 2.2.1 production-ready bugfix
2025 : 2.3.0 AFIR compliance
2026+ : 3.0 in developmentOCPI 2.1 / 2.1.1 (2017)
Theme: The first version stable enough for production deployments.
What it established:
- The CPO and eMSP role definitions
- The six core modules (Locations, Tariffs, Sessions, CDRs, Tokens, Commands)
- The “Sender” and “Receiver” interface concept — each module has a side that publishes data and a side that consumes it
- Token-based authentication between parties
- The Versions and Credentials modules for connection setup
What was missing or weak:
- Hub role wasn’t formally defined — hubs existed in practice but the protocol didn’t explicitly model them
- Smart charging capabilities were minimal
- Some data fields had inconsistent semantics across implementations
- Modular versioning was loose
Status in 2026: OCPI 2.1.1 is deprecated but still deployed in legacy systems. Most newer deployments are on 2.2.1 or 2.3.0.
OCPI 2.2 → 2.2.1 (Mar–Jun 2020)
Theme: Hubs, smart charging, and production-readiness.
What changed:
Hub role formally defined
OCPI 2.2 added formal recognition of “Hub” as a role. A Hub is a party that maintains OCPI connections with multiple CPOs and eMSPs and routes messages between them. Before this, hubs existed (Hubject, Gireve) but the protocol didn’t have first-class concepts for hub-to-party communication.
New endpoints like the Hub Client Info module emerged from this addition.
Smart Charging module
A new module for smart charging schedules. CPOs and eMSPs can negotiate energy delivery schedules (e.g., “charge slower during peak grid demand”). This wasn’t usable in 2.1.1.
Better session real-time data
Session module updates added more accurate live data: dynamic current/voltage, status updates per-EVSE, more comprehensive metering information.
Improved authorization flows
The token authentication model got refinements — better support for whitelist/blacklist patterns, clearer behavior when tokens are unknown.
CDR clarifications
The Charge Detail Record (CDR) format got more structured pricing breakdowns. Per-kWh, per-minute, idle fees, taxes — all could be represented cleanly.
2.2 → 2.2.1 patches
2.2.1 was a bugfix and clarification release on 2.2. Most production deployments went directly to 2.2.1, skipping 2.2. 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 mainstream production version. If you’re implementing OCPI today and don’t have specific AFIR compliance needs, this is what you implement.
OCPI 2.3.0 (February 2025)
Theme: Regulatory compliance + extensibility.
What changed:
AFIR (Alternative Fuels Infrastructure Regulation) compliance
The EU’s AFIR regulation (passed in 2023) requires new public DC fast chargers in Europe to meet specific data publication standards — real-time availability, ad-hoc payment support, transparent pricing. OCPI 2.3.0 adds the protocol-level features needed to support this:
- Mandatory tariff publication formats
- Required real-time status updates
- Specific minimum data fields for Locations
If you’re a CPO in Europe deploying new stations, OCPI 2.3.0 (or a compliant 2.2.1 with extensions) is effectively required.
North American tax level support
The previous CDR pricing model assumed European-style VAT (a single national tax). North American jurisdictions often have multiple stacked taxes (federal, state, county, municipal). OCPI 2.3.0 added explicit support for representing multiple tax levels on a single CDR.
Extensibility framework
A formal mechanism for vendor-specific extensions to OCPI without breaking interoperability. Implementations can add custom fields and message types under a namespace; partners that don’t understand them ignore them gracefully.
This is a significant architectural shift. Earlier OCPI versions discouraged custom extensions; 2.3.0 embraces them as long as they’re properly namespaced.
Refined module behaviors
- Updates to the Tariffs module to support more complex pricing structures
- Improvements to the Sessions module for partial reporting
- Clarifications on what’s required vs optional in various flows
Status in 2026: OCPI 2.3.0 is being adopted, especially in Europe under AFIR pressure. Major networks have ongoing migration projects from 2.2.1. For a module-by-module breakdown, see what’s new in OCPI 2.3.0.
OCPI 3.0 (in development)
Not yet released. From public discussions at the EVRoaming Foundation, expected themes:
- Larger architectural restructuring (potentially incompatible breaks from 2.x)
- Better integration with ISO 15118 (Plug & Charge handoffs)
- More explicit support for vehicle-to-grid scenarios
- Enhanced security model
Timeline: likely 2026-2027 for a final release. Our OCPI 3.0 preview tracks the proposed changes as they firm up.
Migration considerations
If you’re upgrading from one version to another, key things to consider:
From 2.1.1 → 2.2.1
This is the most common migration in 2025-2026. Key changes:
- Formal hub role (update integration patterns if you go via a hub)
- New module endpoints (extend your API implementation)
- CDR pricing format changes (be aware of backward compatibility)
- Token authentication updates
Most companies handle this as a “v2 support” alongside their existing v1 endpoints during a transition period, then drop v1 once partners have migrated.
From 2.2.1 → 2.3.0
Smaller migration than 2.1.1 → 2.2.1. Key things:
- New AFIR-related fields (mostly additive)
- North American tax fields (relevant only for NA deployments)
- Adoption of the extensibility framework for any custom fields you previously added in non-standard ways
Backward compatibility
OCPI uses URL versioning (/ocpi/cpo/2.2.1/...). A party can support multiple versions simultaneously. Partners discover each other’s supported versions via the Versions module and negotiate the highest mutually-supported version.
This makes phased migrations possible. Run 2.2.1 and 2.3.0 in parallel for a year, then deprecate the older version.
Which version to implement today
For a new OCPI implementation in 2026:
- Target 2.2.1 as the minimum. This is the baseline for any modern deployment.
- Add 2.3.0 if you operate in Europe. AFIR compliance effectively requires it.
- Plan for 3.0 awareness. Architect your implementation to accommodate larger future changes (clean module boundaries, good versioning hygiene).
For an existing 2.1.1 deployment:
- Migrate to 2.2.1 within 12 months if possible. 2.1.1 partners are dwindling.
- Consider 2.3.0 if you’re in Europe — AFIR enforcement is ramping up.
Three things to take from this
-
2.2.1 is the modern baseline. If you’re starting fresh, this is the floor.
-
2.3.0 is required for AFIR compliance in Europe. North American implementations can target 2.2.1 for now but should monitor 2.3.0 adoption.
-
3.0 will be a bigger break than the 2.x sequence has been. Implementation choices made today should anticipate that future migration.
OCPI versioning is well-managed compared to many industry protocols. Backward compatibility is treated seriously, and the EVRoaming Foundation publishes migration guides. The cost of being a version behind is real but bounded.