The short answer
If you are starting a new implementation today, target OCPI 2.2.1.
If you are integrating with real roaming partners, expect to support 2.1.1 as well.
That is the practical answer for most teams.
Why 2.2.1 is usually the better target
OCPI 2.2.1 is the more mature version for modern roaming scenarios because it improves:
- Hub-oriented workflows
- Charging profile support
- Platform registration flows
- Tariff and ecosystem modeling
It is the version you would choose if you were designing purely from first principles.
Why 2.1.1 still matters
Because EV charging is not designed from first principles every quarter.
It is shaped by:
- Existing partner deployments
- Legacy bilateral integrations
- Slow-moving operational change
- Commercial constraints
That means many teams still meet 2.1.1 first in production, even if 2.2.1 is the better long-term destination.
What changes in the decision process
The real decision is not:
Which version do we like more?
It is:
Which version do our partners require, and how do we avoid hard-coding that decision into the rest of our platform?
That second question leads to better architecture.
A practical rule of thumb
Choose 2.2.1 as your primary target when:
- You are building a new roaming layer
- You expect hub workflows to matter
- You want a cleaner long-term implementation path
Maintain 2.1.1 compatibility when:
- Existing partners already depend on it
- You are entering mature roaming ecosystems
- Commercial rollout matters more than version purity
The implementation mistake to avoid
Do not let version-specific payload handling leak into every internal service.
Instead:
- Normalize the objects you care about internally
- Handle version translation at the protocol boundary
- Keep partner-specific compatibility logic isolated
This is the same architectural pattern that helps teams survive OCPP 1.6 and 2.0.1 coexistence cleanly.
How this affects CPOs and eMSPs
For CPOs, the biggest issue is usually partner compatibility and operational onboarding.
For eMSPs, the issue is often breadth of interoperability and the operational cost of supporting many counterparties with inconsistent maturity.
In both cases, version flexibility is more useful than version idealism.
Related reading
If you are still mapping how roaming fits into your broader stack, read:
