Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.
Part of the lesson OCPI charging session lifecycle
CPO asks the eMSP to authorize the token
Start here
8 min
CPO asks the eMSP to authorize the tokenExplore the tokens module →
The token belongs to a driver of the eMSP. Its whitelist value, ALLOWED_OFFLINE, means real-time authorization is used while the eMSP can be reached, so the CPO asks the eMSP to authorize the token through the Tokens module.
No sandbox run sends this exchange, so there is nothing to run here.
CPO
EMSP
"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"|ALWAYS |Token always has to be whitelisted, realtime authorization is not possible/allowed. CPO shall always allow any use of this Token. |ALLOWED |It is allowed to whitelist the token, realtime authorization is also allowed. The CPO may choose which version of authorization to use. |ALLOWED_OFFLINE |In normal situations realtime authorization shall be used. But when the CPO cannot get a response from the eMSP (communication between CPO and eMSP is offline), the CPO shall allow this Token to be used. |NEVER |Whitelisting is forbidden, only realtime authorization is allowed. CPO shall always send a realtime authorization for any use of this Token to the eMSP."OCPI 2.2.1 Tokens module · #mod_tokens_whitelisttype_enum"|location_id |CiString(36) |1 |Unique identifier for the location. |evse_uids |CiString(36) |* |Unique identifiers for EVSEs within the CPO's platform for the EVSE within the given location."OCPI 2.2.1 Tokens module · #mod_tokens_locationreferences_class
Message FlowStep 3 of 10