> ## Documentation Index > Fetch the complete documentation index at: https://evsim.synergyboat.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting > The status codes the API answers, the failures that actually happen in practice, and how to tell a target failure apart from an outage on our side. ## First, separate the two kinds of failure Every problem you will hit falls on one side of a line: * **The target failed.** Your partner's implementation broke a rule. This is always reported inside a finished run: a failed check or verdict with the recorded exchange and the clause attached. It never arrives as an HTTP error from our API. * **We did not get an answer.** Your request to our API was rejected, rate limited, or our runner was unavailable. This arrives as an HTTP status and says nothing about your partner. A CI script that conflates these will tell your partner they are broken when the truth is that your script never got an answer. Keep the exit codes apart, as in the scripts in [Run a suite](/docs/guide/run-a-suite#gate-your-build-on-it) and [Run a charging journey](/docs/guide/run-a-charging-journey#put-it-in-ci). ## Status codes | Status | Meaning | What to do | | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `400` | The request body or a parameter is invalid. The message names the field. | Fix the request. | | `401` | Missing, invalid or revoked API key. | Check the `Authorization: Bearer $EVRT_KEY` header, and that the key has not been revoked in Settings. | | `402` | The operation needs a paid plan. | Programmatic runs are a paid feature. | | `404` | Not found, including resources that exist but belong to another owner. | Check the id. A correct-looking id that answers 404 usually belongs to a different account. | | `409` | Conflict: a journey plan expired or its hash changed, an `Idempotency-Key` was reused with a different body, or a `recoveryVersion` is stale. | Re-read the current state and repeat the step: preview again, use a fresh key, or decide against the run's current `recoveryVersion`. | | `422` | The request is well formed but cannot be processed as sent. | Read the message; it names what to change. | | `429` | A rate or quota ceiling. In-flight journey runs hold a slot each, and a run paused as `recovery_required` keeps holding its slot until you decide. | Honour the `Retry-After` header. Read your ceilings from `GET /api/v1/usage`. | | `503` | **Our runner is unavailable.** Nothing was admitted; nothing reached your partner. | This is our service status, never a verdict about the target. Try again later. A journey start retried with the same `Idempotency-Key` is safe. | A `202` is not an error and not an outcome: the work was accepted and is still going. Poll or wait for the result. ## Registration **Everything returns 401 after a successful registration.** The partner is almost certainly still presenting the registration token (Token A). It was valid until the handshake completed, and then it died. After registration each side authenticates with the token the other side generated during the exchange. **Registration succeeds, then the partner cannot push anything to you.** They probably never fetched your endpoints. A credentials `POST` obliges the server to go and read the client's endpoints for that version. Skipping it registers fine and then fails days later, disguised as "your callbacks are broken". **The first authenticated request fails and the error makes no sense.** Check the version on the connection. OCPI 2.1.1 sends the credentials token raw; from 2.2 onwards it is Base64 encoded. A version mismatch fails at the auth layer and looks nothing like a version problem. **A second registration attempt succeeds.** That is your partner's bug, not yours. The spec requires `405 Method Not Allowed` for a `POST` from an already-registered client. Registration is not idempotent, and a server that quietly re-registers is masking a state-machine bug somewhere. ## Conformance runs **The run refuses a module.** The selected OCPI version does not advertise it. That is not a gap in your setup: a module with no proven suite on that version is not advertised, because a run that reports failures you cannot act on is worse than one that says the module is not covered. See [Run a suite](/docs/guide/run-a-suite). **A scenario fails on a late step but the endpoint looks healthy.** Scenarios chain their own output: each step feeds the next. A red step 6 with a healthy endpoint usually means something upstream returned nothing usable. Read the exchange on the **first** red step, not the last. **My build fails and every failure is a warning.** Then your build is gated wrongly. Gate on `failed`, not on warnings. A warning means a recommendation was declined, and declining a recommendation breaks no rule. See [Read your report](/docs/guide/read-your-report). ## Charging journeys **The run says `recovering`. Do I need to do anything?** No. Our runner is resuming from its checkpoint after a restart on our side. No request is repeated, and the run continues on its own. **The run says `recovery_required`.** The delivery of one mutating action is uncertain and the tester will not resend it automatically, because a replayed mutation could duplicate a session or a CDR on your partner's side. The run is paused for your decision. Read the run, look at the server-offered `recoveryOptions`, and apply one with the current `recoveryVersion`. A stale version answers `409`: re-read and decide again. See [Run a charging journey](/docs/guide/run-a-charging-journey#when-a-run-pauses-for-a-recovery-decision). **`runIntegrity` is `degraded` or `invalid`. Did my partner fail?** No. Run integrity describes how complete **our** evidence is, never your partner's conduct. Target failures appear as failed verdicts with the exchange attached. A degraded run means part of the story is unobservable, usually because a recovery decision chose to continue without replay. **The start returned `503`.** Our journey runner is unavailable. Nothing was admitted and nothing reached your partner. Start again later; with the same `Idempotency-Key`, the retry either returns the original run or admits it fresh, never both. ## Verdicts **The report says "Compliant" but there are warnings. Am I compliant?** Yes. Nothing failed. A partner who ignores a `SHOULD` has broken nothing, and we will not send you to fix code that already works. **A check passed. How do I know it can even fail?** Because we broke our own server on purpose and made sure it did. Every OCPI 2.2.1 conformance check has been proven capable of failing, and that is enforced in our build. The reasoning, and the limits of the claim, are in [Read your report](/docs/guide/read-your-report). ## Still stuck Every check carries the request that was sent and the response that came back. Open the failing check and read the exchange before assuming the verdict is wrong. If the exchange shows the tester doing something the specification does not permit, that is our bug, and we want to know: [ahoy@synergyboat.com](mailto:ahoy@synergyboat.com).