Start and stop sessions remotely

Start a charge from your own app instead of an RFID card: one API call to the charger, and the session begins as soon as a car is plugged in. You can start it for a named driver, cap it as it starts, and stop it whenever you like.

Start a session

curl -X POST "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"type": "remoteStartTransaction", "connectorId": 1}'

{
  "id": "1f2e…",
  "commandType": "remoteStartTransaction",
  "chargingStationId": "9a7c…",
  "status": "sent",
  "createdAt": "2026-10-01T07:30:00Z",
  "expiresAt": "2026-10-01T07:45:00Z",
  "request": { "type": "remoteStartTransaction", "connectorId": 1 }
}

connectorId and evseId pick the outlet. Both are optional: leave them out and the charger chooses. connectorId is the charger's own outlet number (1, 2, …), not an id from the API; on a charger with several outlets that each have more than one connector, send evseId too.

The Idempotency-Key header is required. Send the same request with the same key again and you get the original command back, never a second start, so a retry after a network error is always safe.

On a virtual charger, plug a vehicle in first, from the console or with POST /v1/virtual-chargers/{id}/connectors/{connectorId}/plug-in.

Know when charging has started

The answer is a command, created at once. Every command, whatever it does, follows the same lifecycle, described in Sending commands. For a start, it comes down to two steps:

1. The charger accepts. Poll GET /v1/charging-stations/$CHARGER/commands/{id}, or listen for commandStatusChanged on live updates, until status is accepted or rejected.

2. The session appears. accepted means the charger will try: it still needs a car plugged in. The session itself arrives as a new transaction on that outlet, announced by a transactionStarted live event and a transaction.started webhook.

A charger that accepts with nothing plugged in usually waits a short while for a car and then gives up. Treat a new transaction on the outlet, not accepted, as the sign that charging began.

Start a session for a driver

Pass principalId to start the charge on a person's behalf:

curl -X POST "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"type": "remoteStartTransaction",
       "connectorId": 1,
       "principalId": "'$PRINCIPAL'"}'

The charger then decides the start exactly as it would decide that person's own card: their permissions and status apply, and the session is theirs. If they hold a reservation at this charger, the start claims it. A person outside the charger's project answers 404 principalNotFound, and a suspended one 409 principalInactive. People and their permissions are covered in Let drivers charge with RFID cards.

Cap a session as you start it

Two optional fields shape the session you are starting, and they cap different things.

chargingLimit caps the rate: how much current or power the session may draw, as a schedule. It takes the same schedule as a charger's own limits; see Keep a site within its electrical limits.

transactionLimit caps the total: energy, time or state of charge. The session ends as soon as any one is reached.

curl -X POST "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"type": "remoteStartTransaction",
       "connectorId": 1,
       "transactionLimit": {"maxEnergyWh": 30000,
                            "maxTimeSeconds": 7200}}'

Use any combination of maxEnergyWh, maxTimeSeconds and maxSocPercent. Flowion holds the cap and attaches it to the session the start produces. Not supported on every charger. See which.

Raise or set a cap on a session that is already running:

curl -X PUT "$API/transactions/$TRANSACTION/limit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"maxEnergyWh": 20000}'

The answer is 202: the cap is recorded and goes to the charger with the session's next update. A field you leave out keeps its current value, and a body with no cap at all is 422 emptyLimit.

Stop a session

curl -X POST "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"type": "remoteStopTransaction", "transactionId": 90210}'

Name the session the way the charger knows it. Fetch the transaction first and send whichever of its two identifiers is set: numericId as a number (90210) or textId as a string ("tx-abc"). Send the value bare, never wrapped in an object.

The stop resolves like a start: the command reaches accepted or rejected, and the session's end arrives afterwards as a transactionEnded live event and a transaction.ended webhook.

Check what a charger can do

Before you build a button, ask which commands a charger supports:

curl "$API/charging-stations/$CHARGER/commands/capabilities" \
  -H "Authorization: Bearer $TOKEN"

Each command type is supported, notSupported or notYetKnown (the charger has not been connected long enough to tell). The answer comes from what the charger has already reported, so it works while the charger is offline.

When a command does not go through

Creating the command is refused straight away for a request that can never work:

An offline charger is not an error. The command waits with status: "queued" and is delivered when the charger reconnects, until its expiresAt.

Once the command is under way, its final status tells you how it ended:

Send one command at a time

A charger works through its commands one at a time, in order. Ten commands to one charger queue behind each other, and a charger on a slow mobile connection can take tens of seconds to answer, so set your own client timeouts generously. Commands to different chargers run independently.

Review what was sent

Every command is kept, newest first, with who issued it and how it ended:

curl "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN"

A start and the session it produced are separate records: the command history shows what was asked, the transaction shows what happened.

Endpoints

Commands · Transactions · Virtual chargers

For the messages behind these commands, see How Flowion maps onto OCPP.