Starting a charging session

Intermediate

OCPI 2.2.1

Technical details off

The messages from a card tap to an active Session: the token is authorized, then the CPO pushes the new Session 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

Let's see what happens when you start charging!

What You'll Learn:

How the CPO can ask the eMSP to authorize a Token in real time
What the eMSP answers
How the CPO pushes the new Session to the eMSP

The Players in This Lesson:

CPO

eMSP

EMSP

Message Flow:

Step 0 of 2

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", "token": {…}}, "timestamp": "2026-10-16T09:30:00Z"}

"An eMSP might want their Tokens to be authorized '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.2.1 Tokens module · #mod_tokens_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.2.1 Tokens module · #mod_tokens_post_method"When the token is known by the Sender, the response SHALL contain a AuthorizationInfo object. If the token is not known, the response SHALL contain the status code: `2004: Unknown Token`, and no `data` field."OCPI 2.2.1 Tokens module · #mod_tokens_post_response_data"|ALLOWED |This Token is allowed to charge (at this location)."OCPI 2.2.1 Tokens module · #mod_tokens_allowed_enum"OCPI status code, as listed in Status Codes, indicates how the request was handled. To avoid confusion with HTTP codes, OCPI status codes consist of four digits."OCPI 2.2.1 Transport and format chapter · #transport_and_format_response_format"|1000 |Generic success code"OCPI 2.2.1 Status codes chapter · #status_codes_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 corresponding eMSP by calling PUT on the eMSP's Sessions endpoint with the newly created Session object."OCPI 2.2.1 Sessions module · #mod_sessions_push_model"We also advise that in such cases, platform sending the response leave the `data` field unset in the response format. This applies for example to PUT requests when pushing Session objects, and PATCH requests to add charging periods to Sessions."OCPI 2.2.1 Transport and format chapter · #transport_and_format_response_format

What OCPI 2.2.1 defines for this lesson

Modules in this version

Locations

Sessions

CDRs

Tariffs

Tokens

Commands

Credentials

Hub Client Info

Charging Profiles

Payments

Bookings

Advertised sender and receiver interfaces

An endpoint declares how another platform can pull or push data. Credentials uses the same interface for both roles.

The header token is encoded

The request header carries an encoded token; the Credentials body still carries the raw token.

Billing records name the Token owner

A charge record names the country and company that own the driver's Token.