START_SESSION: remote start over OCPI

The three-step async flow

Three parties, three hops, and every one can fail on its own:

1. eMSP to CPO — the OCPI command, answered immediately with a CommandResponse.
2. CPO to charger — an OCPP RemoteStartTransaction (1.6J) or RequestStartTransaction (2.0.1) over the charger's live WebSocket.
3. Back up the chain — the charger answers, the CPO POSTs a CommandResult to your response_url, and a Session object appears separately.

The Session is what actually confirms charging. The CommandResult confirms the charger accepted the instruction; the Session confirms a charge exists. They are different facts and they arrive separately.

The fields

Sending the whole Token object rather than a reference is deliberate: the CPO may need to authorise without being able to reach you, so it needs the token's valid and whitelist state in hand.

On EVSE targeting: omitting evse_uid lets the CPO pick, which raises success rates. But drivers are standing at a specific charger, so in practice you almost always want to name it — a driver at bay A2 does not want the CPO starting bay A7.

Example: the full exchange

POST /ocpi/2.2.1/commands/START_SESSION
Authorization: Token <base64 token>
OCPI-from-country-code: IN
OCPI-from-party-id: EMS
OCPI-to-country-code: IN
OCPI-to-party-id: EFI
X-Request-ID: 7c1a4e90
X-Correlation-ID: booking-88231

{
  "response_url": "https://emsp.example.com/ocpi/2.2.1/commands/START_SESSION/7c1a4e90",
  "token": {
    "country_code": "IN", "party_id": "EMS",
    "uid": "DR-88231", "type": "APP_USER",
    "contract_id": "IN-EMS-C0142",
    "issuer": "Example Mobility Services",
    "valid": true, "whitelist": "ALLOWED",
    "last_updated": "2026-08-11T08:55:00Z"
  },
  "location_id": "LOC-ND-014",
  "evse_uid": "EVSE-014-02",
  "authorization_reference": "auth-4471"
}

The immediate answer — queued, not started:

HTTP/1.1 200 OK

{
  "data": { "result": "ACCEPTED", "timeout": 30 },
  "status_code": 1000,
  "timestamp": "2026-08-11T09:11:59Z"
}

Then, once the charger has responded over OCPP:

POST /ocpi/2.2.1/commands/START_SESSION/7c1a4e90
X-Correlation-ID: booking-88231

{ "result": "ACCEPTED" }

And separately, through the Sessions module, the object that actually proves a charge exists:

PUT /ocpi/2.2.1/sessions/IN/EMS/sess-77c1

{
  "id": "sess-77c1",
  "start_date_time": "2026-08-11T09:12:00Z",
  "kwh": 0.000,
  "auth_method": "COMMAND",
  "authorization_reference": "auth-4471",
  "location_id": "LOC-ND-014",
  "evse_uid": "EVSE-014-02",
  "connector_id": "1",
  "status": "ACTIVE",
  "last_updated": "2026-08-11T09:12:00Z"
}

Reading the failure modes

FAILED is worth special handling. The most common physical cause is a cable that is not seated properly, and a message telling the driver to reseat it resolves a meaningful share of these without any support contact.

Where implementations go wrong

• Showing success on the CommandResponse. ACCEPTED at phase one means queued. Showing “charging started” there produces a support ticket every time the charger then reports EVSE_OCCUPIED. Wait for the Session.
• Retrying on timeout. The charger may be mid-start. A retry can produce two sessions and a double charge. Reconcile against Sessions instead.
• Non-idempotent callback handlers. Duplicate results are normal. Key on the request ID and ignore repeats.
• Omitting authorization_reference. Without it, matching this command to its Session and CDR becomes timestamp guesswork.
• Not checking capabilities first. The Locations module tells you whether an EVSE is REMOTE_START_STOP_CAPABLE. Checking saves a guaranteed failure.
• Ignoring stale EVSE status. Starting against an EVSE your map last saw an hour ago is how EVSE_OCCUPIED rates climb.

A flow that holds up in production

1. Check the EVSE is AVAILABLE and REMOTE_START_STOP_CAPABLE.
2. Send the command with authorization_reference set.
3. On ACCEPTED, show starting — never started.
4. Wait for whichever arrives first: the CommandResult or the Session.
5. Show charging only once a Session exists.
6. On timeout, check Sessions before declaring failure.
7. Never auto-retry; let the driver decide, after you have confirmed no session started.

The whole design principle: the Session is the truth, the command is only a request.