OCPI 2.1.1 vs 2.2.1: Differences, Features & Upgrade Guide

Quick answer: OCPI 2.2.1 is a superset of OCPI 2.1.1 with three structural changes that matter most. (1) Roles: 2.1.1 has no role field (a party acts as CPO or eMSP); 2.2.1 adds an explicit role list (CPO, EMSP, HUB, NAP, NSP, SCSP, OTHER). (2) Modules: 2.2.1 adds ChargingProfiles (smart charging through the roaming chain) and HubClientInfo (hub-aware participant discovery). (3) Credentials: both versions identify a party by an alpha-2 country_code (FR, NL) plus a 3-character party_id; 2.2.1 moves them into a roles[] array so one platform can register several roles. OCPI 2.2.1 also adds four 4xxx Hub-error status codes (4000-4003). Both versions use the same Token A, B and C credentials handshake.

OCPI 2.1.1 and OCPI 2.2.1 are the two versions most EV charging teams evaluate when they build roaming integrations, both published by the EVRoaming Foundation. The specifications and reference schemas are hosted on GitHub at ocpi/ocpi. OCPI 2.1.1 remains a common baseline for partner interoperability, while OCPI 2.2.1 expands the protocol for hubs, smarter tariff handling, and charging-profile workflows.

If you need version-specific validation, start with OCPI 2.1.1 testing and OCPI 2.2.1 testing.

If you are preparing for roaming rollout or partner onboarding, continue with OCPI roaming testing or book an OCPI demo.

What Are the Key Differences Between OCPI 2.1.1 and 2.2.1?

The Short Answer

Choose OCPI 2.1.1 when you need the fastest path to stable roaming interoperability with the core modules: credentials, locations, sessions, CDRs, tariffs, tokens, and commands.

Choose OCPI 2.2.1 when you need hub-oriented behavior, smarter charging workflows, or a broader protocol surface for future roaming requirements.

In practice, many teams still need to support both: 2.1.1 for existing partner compatibility and 2.2.1 for newer integrations.

By the numbers — as of 2025, per the EVRoaming Foundation and the published OCPI specifications:

• OCPI 2.1.1 defines 6 modules (Locations, Sessions, CDRs, Tariffs, Tokens, Commands) plus Credentials and Versions. There is no role field; a party acts as CPO or eMSP.
• OCPI 2.2.1 defines 8 modules — the same 6 plus ChargingProfiles and HubClientInfo. An explicit role list adds HUB, NSP, NAP, SCSP next to CPO, EMSP and OTHER.
• Party identifiers: both versions use an ISO 3166-1 alpha-2 country_code plus a party_id in credentials; 2.2.1 puts them in a roles[] array with one entry per role. Location.country is alpha-3 (FRA, NLD) in both versions.
• Status codes: 2.1.1 uses ranges 1xxx / 2xxx / 3xxx; 2.2.1 adds a 4xxx Hub-error class with four codes: 4000 generic, 4001 unknown receiver, 4002 timeout on forwarded request, 4003 connection problem (4900-4999 reserved for custom hub codes).
• Credentials handshake: both versions use Token A → Token B → Token C. Token A is shared out-of-band, the sender generates Token B and sends it in POST /credentials, and the receiver returns Token C, which the sender uses from then on.

What Stays the Same Between the Two Versions?

The good news is that the two versions share the same core model:

• REST APIs over HTTPS
• credentials handshake and token exchange
• version discovery through /versions
• core roaming entities such as locations, EVSEs, sessions, CDRs, tariffs, and tokens
• CPO and eMSP role separation

That means an upgrade from 2.1.1 to 2.2.1 is usually not a full rewrite. It is more often an expansion of your existing roaming implementation.

Where Does OCPI 2.2.1 Add Real Value?

1. Hub-Centric Integrations

OCPI 2.2.1 is a better fit for hub-connected ecosystems because it adds structures that are more practical for multi-party roaming environments. The most visible example is HubClientInfo, which helps systems exchange participant information in hub-based topologies.

If your roadmap includes hub onboarding, version 2.2.1 is usually the safer long-term choice.

2. ChargingProfiles

OCPI 2.2.1 introduces ChargingProfiles, which matters when smart charging needs to pass through the roaming chain instead of staying entirely inside the local CPO backend.

This becomes relevant when:

• an eMSP wants to influence charging behavior
• a roaming workflow needs schedule-aware energy management
• the backend stack must coordinate with OCPP 2.0.1 smart charging flows, the charger-side protocol maintained by the Open Charge Alliance

3. Richer Tariff and Field Coverage

OCPI 2.2.1 gives teams more expressive tariff and metadata structures. That matters when pricing presentation, settlement clarity, or country-specific compliance expectations become stricter.

How Do the Modules Compare?

Credentials and Version Discovery

No major conceptual change here. Both versions rely on the same practical sequence:

1. GET /versions
2. GET /versions/{version}
3. POST /credentials
4. token exchange and endpoint discovery

This is why many teams can run both versions side by side without changing the whole architecture.

Locations, Sessions, and CDRs

Both versions support the core data flows roaming teams need every day:

• publish charger locations and EVSE data
• exchange live or near-real-time session updates
• submit CDRs for settlement and invoicing

For many operators, this is enough to ship a production roaming connection on 2.1.1.

Tokens and Commands

Again, both versions cover the main operational paths:

• driver token synchronization
• remote start and stop behavior
• reservation and unlock style command flows

If your product only needs baseline roaming enablement, 2.1.1 can remain perfectly serviceable.

ChargingProfiles

This is one of the clearest reasons to move to 2.2.1. When your roaming program needs charging control beyond static authorization and billing, 2.2.1 gives you the protocol surface to model it.

HubClientInfo

This is the other major differentiator. Hub-oriented roaming is easier to reason about in 2.2.1 because the protocol acknowledges those integration patterns more explicitly.

When Should You Choose OCPI 2.1.1?

Choose OCPI 2.1.1 if:

• you need fast partner onboarding with the core roaming modules
• your partners already standardize on 2.1.1
• you do not need ChargingProfiles right now
• your current architecture is direct CPO-to-eMSP interoperability rather than hub-heavy orchestration
• you want a narrower implementation scope for the first production release

For many teams, 2.1.1 is the right operational baseline and remains worth supporting for years.

When Should You Choose OCPI 2.2.1?

Choose OCPI 2.2.1 if:

• you need hub integration workflows
• you need HubClientInfo
• you need ChargingProfiles
• your tariff and metadata requirements are growing
• you want to reduce the risk of building against an older functional baseline while your product roadmap expands

If you are building a newer roaming platform from scratch, 2.2.1 is often the better strategic default.

Should You Support Both OCPI Versions?

The safest commercial approach is often:

• support OCPI 2.1.1 for baseline compatibility
• support OCPI 2.2.1 for advanced and future-facing integrations

This mirrors what many backend teams already do on the charger side with OCPP 1.6 testing and OCPP 2.0.1 testing.

How Do You Migrate from OCPI 2.1.1 to 2.2.1?

Step 1: Keep Your Core Modules Stable

Before adding 2.2.1-only features, make sure your 2.1.1 baseline is fully reliable:

• credentials lifecycle
• locations synchronization
• sessions and CDR exchange
• token authorization
• command callbacks and error handling

Step 2: Add Version-Aware Routing

Make sure your implementation can distinguish version-specific endpoints and payload handling cleanly. This reduces regression risk and lets you run 2.1.1 and 2.2.1 side by side.

Step 3: Add 2.2.1-Only Modules Deliberately

Treat ChargingProfiles and HubClientInfo as explicit additions, not incidental changes. They usually need:

• new payload validation
• new persistence models
• new async workflow handling
• new interoperability tests

Step 4: Test with Simulated Counterparties

Do not wait for a live roaming partner or hub to discover payload mismatches. Simulate the opposite party and test the full flow before launch with OCPI roaming testing.

Step 5: Validate Mixed-Version Behavior

If your platform will support both versions, test:

• 2.1.1-only partner flows
• 2.2.1-only partner flows
• shared core modules across both versions
• error handling when payload expectations diverge

Example Decision Framework

Frequently Asked Questions

Is OCPI 2.2.1 backward compatible with 2.1.1?

Not automatically in the sense of using identical endpoints and payload expectations everywhere. The versions are closely related, but your implementation still needs explicit version-aware handling.

Should I skip OCPI 2.1.1 and only implement 2.2.1?

Only if you are certain your target partners and hubs do not require 2.1.1. Many teams still need 2.1.1 for practical interoperability.

Is ChargingProfiles the main reason to adopt 2.2.1?

It is one of the strongest reasons, especially for smart charging and advanced roaming workflows. Hub support is the other big reason.

What is the safest production strategy?

Support the 2.1.1 baseline cleanly, then expand to 2.2.1 where partner demand or product scope requires it.

Further Reading

• OCPI 2.1.1 testing
• OCPI 2.2.1 testing
• What is OCPI?
• OCPI endpoints complete reference
• How to implement OCPI roaming
• OCPI roaming testing