Skip to navigation

Long-running operations

Calls that return 202 Accepted, and what to poll after each one.

Deploying chargers and sending them commands takes longer than one HTTP request should wait. These calls return 202 Accepted at once and finish in the background. Each operation’s description in the API Reference names what to poll.

You calledThen pollUntil
evcharger.location.create, evcharger.deploymentRuntimeOps.operate with a location_idevcharger.deploymentRuntimeOps.status({ identity: [...] })every stage is online, or an outcome is failed or stuck
any evcharger.commands.*evcharger.commands.getStatus({ command_id }) for each results[].command.idstatus is applied, rejected, expired or failed
emsp.commands.sendemsp.commands.get with the returned tracking idthe command has a final result
proxy.commands.sendOcpp, proxy.commands.sendOcpiproxy.commands.getOcppStatus, proxy.commands.getOcpiResultthe command has a final result

Polling well

  • Poll every 2 to 5 seconds, and stop at a deadline you choose.
  • A 404 from commands.getStatus means the charger has not received the command yet. Keep polling.
  • When a deployment’s outcome is stuck, read its hint, then call evcharger.deploymentRuntimeOps.diagnostics and read verdict and notes.

Prefer events to polling? Register a webhook for the event types you need.

Retries and 202s

The SDKs send a POST that can act twice only once, even after a 503: the first attempt may already have deployed the charger. Check the status before you retry it yourself. See Errors and retries.