OCPI commands (START_SESSION)

The Commands module is how an eMSP asks a CPO to act on a charger: start, stop, reserve, unlock. Defined in OCPI 2.2.1. It never goes to the EVSE itself.

Index of other modules: OCPI sample messages. Why this is not OCPP: OCPI vs OCPP.

When each command is sent

START_SESSION — driver (or partner app) wants energy on a given EVSE
STOP_SESSION — same party wants that session ended
RESERVE_NOW / CANCEL_RESERVATION — hold or release a connector
UNLOCK_CONNECTOR — cable stuck

START_SESSION sample

POST /ocpi/2.2.1/commands/START_SESSION

JSON{
  "response_url": "https://emsp.example.com/ocpi/2.2.1/commands/START_SESSION/abc",
  "token": {
    "country_code": "NL",
    "party_id": "EMS",
    "uid": "TAG-1001",
    "type": "RFID",
    "contract_id": "NL-EMS-C0001",
    "issuer": "Demo eMSP",
    "valid": true,
    "whitelist": "ALWAYS",
    "last_updated": "2026-08-14T09:00:00Z"
  },
  "location_id": "LOC1",
  "evse_uid": "NL-CFL-E1"
}

The CPO answers quickly with ACCEPTED or REJECTED, then later POSTs the real result to response_url. Meanwhile it should send OCPP RemoteStart (1.6) or RequestStart (2.0.1) to the station that owns that EVSE.

What you can test in Chargeflux today

We do not expose an OCPI endpoint. You can still prove the charger half: launch the simulator, connect your CSMS, and send RemoteStartTransaction (or RequestStartTransaction) as if the OCPI command already succeeded.

Spec PDFs: 2.2.1-d2, 2.3.0. EVRoaming downloads.

FAQ

When is OCPI START_SESSION sent?

When an eMSP (driver app or roaming partner) asks a CPO to start a session on a specific EVSE, usually after the token is already known.

Does START_SESSION replace OCPP RemoteStartTransaction?

No. START_SESSION is eMSP → CPO over HTTP. The CPO then sends OCPP RemoteStartTransaction (1.6) or RequestStartTransaction (2.0.1) to the charger.

Last reviewed August 2026 · Chargeflux.io