Skip to main content
This walks one complete loop against the deployed service: authenticate, pick a target, run the conformance suite, read the verdict. It uses the built-in sandbox target, a working OCPI peer that every account can run against, so you do not need a partner endpoint yet.

Prerequisites

  • An API key in DOJO_KEY. See Create an API key. Keys need a paid plan. The sandbox run below is free at every tier; it is the key that is not, because the whole API sits behind one. Without a key, run the same thing in the browser and see what you can do without paying.
  • curl and jq.

One complete run

The output is the run summary: how many checks passed, failed and warned. The full per-check report, including the recorded request and response behind every check, is at GET /api/v1/testing/runs/:id. Every answer also carries a seed, and sending it back on a later run makes that run send the same requests again. See Run a suite for what a seed does and does not reproduce. Exit 2 means the script never got an answer: the API refused the call, or the run ended without a verdict. It is deliberately not exit 1, which the CI gate keeps for the one thing that is your partner’s fault, a check that failed.
A 202 is active work, not an outcome. The run did not fail and did not pass; it simply outlived your wait. Treat it as “poll again”, never as a red build. The only failure signal for a conformance run is failed checks in the summary of a finished run.

What just happened

The sandbox is a real OCPI peer, not a recording. The run discovered its versions, completed the credentials handshake, and made real HTTP calls to real module endpoints. Every check in the report carries the exchange that produced it. A run against your partner works exactly the same way; the only difference is the connection you pass.

Next

Connect a partner

Point the tester at a real endpoint.

Run a suite in CI

Gate a build on the result, correctly.