Skip to main content
Most of this documentation is written for someone automating ChargerDojo from a script, and that needs a paid plan. This page is the other half: what you can do today, for nothing, before you decide anything.

​
The line, in one sentence

Running against our sandbox is free. Running against your own or a partner’s endpoint is paid. That is the whole rule, and it holds at every tier including a signed-out browser. One thing about it trips people up. The quickstart drives a free sandbox run through the API, and the API needs a cdojo_ key, which needs a paid plan. So the run is free and the key is not. Without a key, do the same run in the browser.

​
Free, no account at all

The simulator and the learning content. Open chargerdojo.com, pick CPOs, eMSPs and chargers, and watch the OCPI messages move between them. The Learn section explains the protocol itself: what a CPO and an eMSP are, what a CDR is, how a session becomes a bill, and what changed between OCPI versions. If the vocabulary in these guides is unfamiliar, start there, not here. Guided scenarios, which are the fastest way to understand a failure you are actually looking at: a charge billed twice, a session that never closes, a bill higher than the price shown. The MCP server, if you work in a coding agent. Six tools, no key, no signup: which OCPI versions exist, what changed between two of them, how each encodes the credentials token, which suites and journeys can be run. See Connect a coding agent.

​
Free, and better once you sign in

Sandbox runs need no plan at any tier, signed in or not. Signing in is what gives them somewhere to live: your runs are saved, listed and shareable instead of vanishing with the tab. Conformance runs against the built-in sandbox. The sandbox is a real OCPI peer, not a recording: the run discovers its versions and makes real HTTP calls to real module endpoints. You get the same report, with the same per-check evidence, that a paid run produces. Registration is the one shortcut: the sandbox’s credentials are written directly rather than handshaken over loopback, which our own SSRF guard would rightly refuse. Be clear-eyed about what that proves. A sandbox run exercises our client against our server, so a green result tells you the tool works and shows you what a report looks like. It is not evidence about your implementation. For that you need your own endpoint, which is the paid line. Charging journeys against the sandbox, the same way: a full story over time rather than module-by-module checks. Load journeys, which run one at volume, are the exception: those need the Automate plan even against the sandbox.

​
What a plan adds

Connections and run rate differ by plan and are set per deployment. Retention differs between free and paid, not between paid plans. The active-key cap is the same for every account. Read your own rather than trusting a number on a page:
What each plan costs and unlocks is on Plans and pricing.

​
The honest reason the free tier stops where it does

A run against your endpoint costs us minutes of a runner and a real HTTP conversation with a third party. A run against our own sandbox costs us almost nothing. So the line is drawn at whose infrastructure the run touches, not at how good the report is: the free report is the same report.

​
Next