OCPI Conformance Testing Tool
Run OCPI conformance suites against your own endpoint or the built-in sandbox peer. Every check reports the request it sent and the response it received, so a failure tells you which field and which status code, not just that something is wrong.
Loading the tool. The reference below does not need it.
OCPI is the protocol that lets a driver charge on a network that is not their own. When it goes wrong, it goes wrong quietly: a session that never closes, a CDR your partner rejects, a token that authorizes when it should not. The failure usually surfaces as an incident report from the other side, long after the code that caused it shipped.
This tool runs the checks a partner would run, before the partner does. Register an endpoint, pick a version and a module, and the suite issues real requests against it and reports on what came back. Every verdict carries the exchange that produced it, so a failure tells you which request, which field, and what the specification expected instead. That is the difference between knowing something is broken and knowing where.
Simulating and learning are free, with no login, and so is sharing a sandbox report with a partner. Running suites against your own endpoints and wiring them into CI belong to the paid plans, and so do the share links for those reports: a link to a report about your own endpoint stops opening when the plan ends, while a shared sandbox report keeps working.
Where to start
If you are new to the protocol, read what the Open Charge Point Interface is and then follow a real message flow between a CPO and an eMSP. If you would rather see a session end to end before you test one, the EV charging simulator runs the whole exchange in the browser, and the guided scenarios walk through the failures worth recognising.
Common questions
What does a conformance run actually check?
Each suite sends real HTTP requests to the endpoint you register and asserts against what comes back: the OCPI envelope (status_code and status_message), the HTTP status, required fields on every object, pagination headers, and the error paths a partner will eventually hit. A check fails with the assertion that failed, not a score. A Sessions run against OCPI 2.2.1, for example, covers listing, fetching, updating, date filtering, pagination, the not-found and validation errors, and the methods the specification does not allow.
What is in a report?
Every check keeps the exchange behind it: the request method, URL, headers and body it sent, and the status, headers and body it received, with the latency in milliseconds. That is what makes a failure arguable rather than a verdict you have to trust. Runs are durable, can be shared by link, and can be downloaded as JSON.
Which OCPI versions and modules can I test?
OCPI 2.1.1, 2.2.1 and 2.3.0. Suites cover Versions, Credentials, Locations, Sessions, CDRs, Tariffs, Tokens and Commands, with Charging Profiles, Hub Client Info, Payments and Booking on the versions that define them. The coverage table on the home page marks the state of every module against every version, so you can check yours before you start.
Do I need to register anything to try it?
No. A sandbox peer is already registered, so you can run a real suite against it in the browser with no login and no card. Point the suite at your own endpoint when you are ready to test the integration you are actually shipping.
Can I run this in CI?
Yes, with an API key, and an API key needs a paid plan. The same run is available over the REST API (POST /api/v1/testing/runs, with the version and module you want), so a conformance suite can gate a release the way a test suite does.
Is this the same as EVRoaming Foundation certification?
No, and it does not replace it. This is the tool you run while you are building and debugging, as often as you like, against your own endpoints. Formal conformance certification is issued by the EVRoaming Foundation through its own process.