Skip to main content
ChargerDojo has one public API. It is the HTTP surface you automate with an API key against the deployed service:
All operations live under /api/v1 and authenticate with a Bearer API key that starts with cdojo_. There is no other supported base URL and no environment selector.

​
What you can automate

Only the operations in the API reference section of this site are public API. Everything else the application does (the interactive simulator, entity editing, account and key management) is browser functionality, not part of this contract.

​
Authentication

Every request sends the key in the Authorization header:
API keys are created and revoked in the app, in Settings, then Security, and require a paid plan. There is no API for managing keys: a key cannot mint, list or revoke other keys. See Create an API key.

​
Response envelope

Every response is JSON, except the journey event stream, which is text/event-stream. Successes wrap their payload:
Errors carry an HTTP 4xx or 5xx status and a message:
Two statuses deserve a special mention because CI scripts get them wrong:
  • A 202 means the work was accepted and is still going. It is not a success verdict and not a failure. Poll or wait for the result instead of gating on it.
  • A 503 on a charging journey start means our runner is unavailable. It is a statement about our service, never a verdict about your partner’s implementation.
The full status-code table is in Troubleshooting.

​
Limits and usage

Plans set ceilings on runs per minute and in flight, and on the connections every self-serve tier buys. Report retention differs between free and paid. The active-key cap is the same for every account. Read your own numbers instead of hardcoding them:
The response reports your tier, active connections against their cap, active keys against their cap, in-flight and per-minute run ceilings, and your report retention window. connections.cap comes back null on a plan priced on a quote, where connections are fair use rather than a rung you are sold. Read that absence as no published ceiling, never as zero. A run over its rate or in-flight ceiling returns 429 with a Retry-After header. A resource cap never does, because waiting will not help. The connection cap answers 402 where your plan publishes a rung, carrying limit with what you hold and what the plan allows, so free a slot or move up. The active-key cap answers 409, and so does the connection cap on a plan priced on a quote, where there is no rung to move to. An in-flight charging journey holds one run slot until it reaches a terminal state, and a run waiting on a recovery decision keeps holding its slot until you decide.

​
Where to go next

Create an API key

Sign in, create the key in Settings, store it once.

Quickstart

A complete conformance run from the command line.

Connect a partner

Register a real partner endpoint and run against it.

Run a charging journey

Drive a full charging story and watch it live.