Order the charging session messages

Intermediate

OCPI 2.1.1

Compare this step across versions

Technical details off

The OCPI messages of one charging session, in the order the CPO sends them to the eMSP.

0 / 5 completed

Who takes part in a charging session

Starting a charging session

Real-time updates during charging

Finishing the charging session

Order the charging session messages

The OCPI messages of one charging session, in order

What You'll Learn:

The order of the OCPI messages in one charging session
Which messages the CPO sends to the eMSP and when

The Players in This Lesson:

CPO

eMSP

EMSP

Message Flow:

Step 0 of 5

CPO

POST /tokens/{token_uid}/authorize

eMSP

Message: Real-time authorization

Details: When the eMSP has its Tokens authorized in real time, the CPO asks the eMSP whether a Token may charge, optionally at a given Location. The eMSP answers with an AuthorizationInfo object, and ALLOWED means the Token may charge.

Response: {"status_code": 1000, "data": {"allowed": "ALLOWED"}, "timestamp": "2026-10-16T09:30:00Z"}

"An eMSP might want their Tokens to be authorizated 'real-time', not white-listed. For this the eMSP has to implement the POST Authorize request and set the Token.whitelist field to `NEVER` for Tokens they want to have authorized 'real-time'."OCPI 2.1.1 Tokens module · #13-real-time-authorization"Do a 'real-time' authorization request to the eMSP system, validating if a Token might be used (at the optionally given Location)."OCPI 2.1.1 Tokens module · #222-post-method"The endpoint response contains a AuthorizationInfo object."OCPI 2.1.1 Tokens module · #222-post-method"|ALLOWED |This Token is allowed to charge at this location."OCPI 2.1.1 Tokens module · #41-allowed-enum"Response code, as listed in Status Codes, indicates how the request was handled. To avoid confusion with HTTP codes, at least four digits are used."OCPI 2.1.1 Transport and format chapter · #response-format"|1000 |Generic success code"OCPI 2.1.1 Status codes chapter · #1xxx-success

CPO

PUT /sessions/{country_code}/{party_id}/{session_id}

eMSP

Message: New Session

Details: The CPO pushes the Session it just created to the eMSP's Sessions endpoint.

Response: {"status_code": 1000, "timestamp": "2026-10-16T09:30:00Z"}

"When the CPO creates a Session object they push it to the eMSPs by calling PUT on the eMSPs Sessions endpoint with the newly created Session object."OCPI 2.1.1 Sessions module · #11-push-model

CPO

PATCH /sessions/{country_code}/{party_id}/{session_id}

eMSP

Message: Session update

Details: In OCPI 2.1.1 the CPO sends every change to a Session it already pushed by calling PATCH on the eMSP's Sessions endpoint. The request carries only the fields that have to be updated; any field it does not specify is considered unchanged.

Response: {"status_code": 1000, "timestamp": "2026-10-16T09:30:00Z"}

"Any changes to a Session in the CPO system are sent to the eMSP system by calling PATCH on the eMSPs Sessions endpoint with the updated Session object."OCPI 2.1.1 Sessions module · #11-push-model"Same as the PUT method, but only the fields/objects that have to be updated have to be present, other fields/objects that are not specified are considered unchanged."OCPI 2.1.1 Sessions module · #223-patch-method

CPO

PATCH /sessions/{country_code}/{party_id}/{session_id}

eMSP

Message: Session update: status COMPLETED

Details: When the Session has finished, the CPO sends the change with PATCH and sets its status to COMPLETED, the final status of a Session. Sessions cannot be deleted.

Response: {"status_code": 1000, "timestamp": "2026-10-16T09:30:00Z"}

"Any changes to a Session in the CPO system are sent to the eMSP system by calling PATCH on the eMSPs Sessions endpoint with the updated Session object."OCPI 2.1.1 Sessions module · #11-push-model"Sessions cannot be deleted, final status of a session is: `COMPLETED`."OCPI 2.1.1 Sessions module · #11-push-model

CPO

POST /cdrs

eMSP

Message: Charge detail record (CDR)

Details: The CPO pushes the new CDR to the eMSP's CDRs endpoint with POST. The eMSP answers with a Location header holding the URL of the new CDR. A CDR cannot be changed once it is sent.

Response: Location: https://www.server.com/ocpi/emsp/2.1.1/cdrs/123456, {"status_code": 1000, "timestamp": "2026-10-16T09:30:00Z"}

"When the CPO creates CDR(s) they push them to the relevant eMSP by calling POST on the eMSPs CDRs endpoint with the newly created CDR(s)."OCPI 2.1.1 CDRs module · #11-push-model"The response should contain the URL to the just created CDR object in the eMSP system."OCPI 2.1.1 CDRs module · #222-post-method"CDRs are created by the CPO. They probably only will be sent to the eMSP that will be paying the bill of a charging session. Because a CDR is for billing purposes, it cannot be changed/replaced, once sent to the eMSP, changes are not allowed in a CDR."OCPI 2.1.1 CDRs module · #1-flow-and-lifecycle

What OCPI 2.1.1 defines for this lesson

Modules in this version

Locations

Sessions

CDRs

Tariffs

Tokens

Commands

Credentials

Hub Client Info

Charging Profiles

Payments

Bookings

No advertised interface-role field

Endpoint descriptions name the module and URL without an interface-role field.

The header carries the token value

The request header carries the shared credentials token value.

Session ID uses case-sensitive text

The Session ID uses text whose letter case matters.