OCPP Integration Services
Two systems can both be OCPP compliant and still fail to work together. Compliance is measured against a specification. Interoperability is measured against another implementation.
The specification leaves room for interpretation, and implementers use it. One backend expects a configuration key another does not send. One charger reconnects with a different transaction state than the platform assumed. Neither party is wrong by the document, and sessions still fail.
Send us the failing caseFor Charger OEM, CMS platform, CPO
Where integrations actually break
Swipe to compare
| Area | Typical failure |
|---|---|
| Boot and registration | Charger registers but the platform rejects the identity or configuration set |
| Heartbeat and connection | Reconnection behaviour after network loss differs from what the platform tracks |
| Transaction lifecycle | Start and stop accepted, but transaction state diverges between the two sides |
| Meter values | Sampled data present but with a unit, context or interval the platform will not bill from |
| Remote commands | Command accepted at the protocol layer, not executed at the charger |
| Firmware management | Update accepted, status reporting incomplete, platform cannot confirm the outcome |
| Configuration keys | Key supported by one side and unknown to the other |
Diagnosis is message level
An integration problem is not resolved by comparing feature lists. It is resolved by reading the message exchange, in order, with timestamps, from both ends. Most disputes between a charger vendor and a platform vendor end when someone produces the trace.
Because we build both chargers and backends, that trace can be read from either side rather than requested from a third party who has no incentive to produce it.
Transaction integrity
Billing depends on transactions surviving conditions the happy path does not cover: connection loss mid-session, charger restart, platform restart, and clock differences between the two. A charger that handles those cleanly and a platform that reconciles them are different requirements, and both have to hold.
What an integration engagement produces
- A tested integration against the specific platform and firmware versions in question
- A documented list of behaviours where the two implementations differ, and how each is handled
- Message traces for the cases that failed, retained as evidence
- Configuration and version constraints, so a later update does not silently break it
- A regression position: what to retest when either side releases
Version support
OCPP 1.6J and 2.0.1 are both in shipping firmware, with 2.1 in development. Version support is a starting point rather than an answer: an integration is verified against the platform and release you will actually run, because that is where the differences live.
A version number is not an integration
The most common integration problem we are called into is not a bug. It is a charger that genuinely supports the OCPP version on its datasheet and still will not work with the platform the customer has chosen.
One customer came to us having bought exactly that. The unit was sold as an OCPP charger. Nothing on the datasheet was untrue. Its OCPP was not interoperable with the backend they needed it on, because a version is a claim about a protocol and their problem was about a specific platform, at a specific release, exchanging a specific set of messages.
So an integration is verified against what you will actually run, not against what the datasheet claims. Anything short of this is a compatibility assumption wearing an integration's clothes.
- The platform, named, at the release you will be on
- The message set your operation depends on, including the failure paths
- Behaviour on reconnect, on backend loss, and on a transaction interrupted part way through
- Firmware update over the air, demonstrated end to end
How we work with you on this
We work with your platform team rather than around them. Your engineers know what your operation actually depends on, and an integration built without that knowledge passes its tests and fails in service.
Where the finding is that your existing charger or platform is the wrong one, you will hear it. That is an uncomfortable message to deliver to someone who has already bought, and it is more useful than an integration that papers over it.
Want this applied to your own site?
Send us the failing caseRelated
Technically reviewed by Akhil Joy, CEO. Last reviewed 2026-08-29.
Frequently asked questions
Our charger is OCPP compliant. Why does it not work with our CMS?
Compliance is measured against the specification, interoperability against another implementation. The specification leaves room for interpretation, so two compliant systems can disagree on configuration keys, reconnection state or meter value context.
Can you integrate our chargers with a third-party CMS?
Yes. The engagement is the same whether the platform is ours or not, though a platform that will share message traces makes it faster.
Which OCPP versions do you work with?
OCPP 1.6J and 2.0.1 are both in shipping firmware. Integration is verified against the specific platform and release you will run.
What do you need from us to start?
Charger firmware version, platform and its version, the failing behaviour, and message traces from either side if you have them.
How do we stop it breaking again after an update?
The engagement documents the version constraints and the regression set, so you know what to retest when either side releases.
Send us the failing case
Give us the charger firmware version, the platform and what fails. Message traces from either end make it faster.
Send us the failing case