Charger commands and transaction state

Available: tenant fleet API. Send commands through POST /v1/tenants/{tenant_id}/stations/{station_id}/commands with stations:control and a persisted Idempotency-Key.

Example bodies (replace illustrative resource IDs):

{"action":"start","connector_id":14,"token":"authorized-id-tag"}

{"action":"stop","transaction_id":21}

A manual start does not verify or collect payment. The supplied charging token must satisfy the station/core authorization configuration. The public API does not offer arbitrary token registration. Use managed bill start or external charging sessions; both manage their own short-lived token and correlate the resulting transaction.

Diagram source

sequenceDiagram
  participant App as Application backend
  participant API as Ivora API
  participant C as CSMS and charger
  App->>API: Command with persistent idempotency key
  API-->>App: 202 and operation ID
  API->>C: Dispatch protocol command
  C-->>API: Accepted or rejected response
  App->>API: Poll operation and transactions
  API-->>App: Observed physical state

An operation marked succeeded confirms an upstream response, not physical charging or completion. Observe station state and GET /v1/tenants/{tenant_id}/transactions. Stop uses the actual transaction resource ID. Check the completed transaction before finalizing a bill.

A rejected operation carries a stable code in result.error.code, for example station_offline, connector_not_found, transaction_ended or dispatch_unconfirmed. Subscribe to operation.completed webhooks to learn the outcome without polling; the event echoes the operation ID and full record.

Reset, unlock and availability commands use the same route. The API reference defines their allowed fields. In production, commands act on real chargers and drivers; simulate or mock them while developing payment flows.

Charger screen content is not a command. Charger displays are desired state: a synchronous 200 write that Ivora keeps pushing, with no 202 operation to poll.