Support

Most integration issues fall into one of four buckets: auth, tenant scoping, invalid request bodies, or wrong resource identifiers.

Fast checks

• Call GET /health to verify the API is reachable
• Confirm Authorization: Bearer <jwt> is set and the token has not expired
• Reuse ids returned by previous API calls instead of guessing them
• Internal admin integrators: see Authentication for the X-Organization-Id case

Common error patterns

Retries, timeouts, and transient failures

The official SDKs retry automatically on 408, 429, and 5xx responses with exponential backoff (two attempts by default). Default request timeout is 60 seconds.

If you are calling the API with raw HTTP, you should retry the same status codes:

Long-running operations (bulk provisioning, CPO bundle creation) can take longer than the default SDK timeout. Raise the per-request timeout when you know the call will be slow:

1
client.location_chargers.create(
2
    location_id=LOCATION_ID,
3
    request=[...],
4
    request_options={"timeout_in_seconds": 120},
5
)

Useful debugging endpoints

• GET /health checks API reachability without a token, run this first if nothing seems to work
• GET /catalog/brands checks basic authenticated reads
• GET /locations checks tenant-scoped list access
• GET /chargers/{charger_id}/logs helps confirm whether a command reached the simulator
• POST /chargers/{charger_id}/proxy-message is useful for low-level protocol debugging when you need to inspect raw action handling

When commands appear to do nothing

1. Verify the charger exists in GET /chargers
2. Confirm the charger belongs to the location you are targeting
3. Re-run the command with the exact same ids from the list response
4. Inspect GET /chargers/{charger_id}/logs with an event filter such as Authorize or BootNotification

Documentation issues

If the rendered docs and the API behavior diverge, the source of truth is the checked-in OpenAPI in the SDK repository. Regenerate the OpenAPI contract first, then sync the docs repo if needed.