This article describes the endpoints associated with controlling charging sessions with OICP. There are two flows for authorizing drivers to start and stop charging, and some optional extras at the bottom for an improved user experience.
Authorize at the charger (RFID card)
Charger side authorization here is described as a CPO side driver authorization as it is initiated and requested by the CPO. Typically the CPO will get an Authorization request over OCPP from the charging station, check its internal whitelists and if the token does not match, attempt an authorization through Hubject.
The relevant requests for this flow are eRoamingAuthorizeStart and eRoamingAuthorizeStop
Authorize remotely (Mobile app)
Remote authorization is an EMP side driver authorization as it’s initiated and handled by the EMP. Typically the EMP will have a mobile app and their customer will request to start a charge using a button on the app. The EMP will authorize the driver in their own systems, for example by taking a holding fee on their card, and then send the request over Hubject to the CPO to start charging.
The relevant requests for this flow are eRoamingAuthorizeRemoteStart and eRoamingAuthorizeRemoteStop
Authorization endpoints are using for authorizing the driver to start and stop charging sessions. eRoamingAuthorizeStart and eRoamingAuthorizeStop are used for CPO initiated authorization, commonly with an RFID card at the charging station. eRoamingAuthorizeRemoteStart and eRoamingAuthorizeRemoteStop are used for EMP side authorization, commonly through the mobile app of the EMP.
MANDATORYfor CPO & Online EMP
Used for authorizing the start of a charging session from the CPO side. This action would be triggered when the user authorises locally at the charging station, most commonly with an RFID card. The request is then used by the CPO to check whether this is a valid user with the EMP and whether the EMP will authorize them to charge.
Hubject will authorize this driver in a cascade of steps;
CPO -> EMP: POST https://service.hubject.com/api/oicp/charging/v21/operators/{operatorID}/authorize/stop
Request payload
Response payload
OPTIONAL
Used to stop a charging session from the CPO side . The request must contain the SessionID that was provided by Hubject in response to the AuthorizeStart.
If the session was authorized by the offline AuthorizeStart method (number 1 above) then it must be stopped by this method. Otherwise it is optional as the session could be stopped by an eRoamingAuthorizeRemoteStop for example.
CPO -> EMP: POST https://service.hubject.com/api/oicp/charging/v21/operators/{operatorID}/authorize/stop
Request payload
Response payload
MANDATORYfor CPO & EMP
Used for starting a charging session from the EMP side, most commonly when the driver wants to start a charge using an EMP mobile app.
This request comes from the EMP to the CPO and is a command to authorize the user for the upcoming charging session. The EMP and CPO must have a valid contract and the EVSE ID supplied by the EMP must match one of those uploaded by the CPO.
The CPO must return acknowledgement and detail about whether the charging will be started or not
EMP -> CPO: POST https://service.hubject.com/api/oicp/charging/v21/providers/{providerID}/authorize-remote/start
Request payload [Response is eRoamingAcknowledgement]
MANDATORYfor CPO & EMP
Used by the EMP to stop a charging session remotely, for example from a mobile app.
EMP -> CPO: POST https://service.hubject.com/api/oicp/charging/v21/providers/{externalID}/authorize-remote/stop
Request payload [Response is eRoamingAcknowledgement]
Optional but desired by EMP services to supply their applications with up to date data on the progress of a charging session. Some of the events that can be communicated with this service are; charging start, stop, update of a meter value, or an error during charging.
Hubject will forward every notification from CPO to the interested EMP, and expects an acknowledgement in response.
OPTIONAL
CPO → EMP: POST https://service.hubject.com/api/oicp/notificationmgmt/v11/charging-notifications
This message is split into four types, which are selected using the Type field, they are Start, Progress, End, and Error. Each has a variation on the expected payload. All responses are eRoamingAcknowledgement.
eRoamingChargingNotificationStart request payload:
eRoamingChargingNotificationProgress request payload:
eRoamingChargingNotificationEnd request payload:
eRoamingChargingNotificationError request payload:
Allows EMP to push authentication data to Hubject and then act as an offline EMP.
OPTIONALfor EMP
Offline EMP’s must use this service to upload, update, or delete data to allow Hubject to authenticate their drivers while they are offline.
EMP -> Hubject: POST https://service.hubject.com/api/oicp/authdata/v21/providers/{providerID}/push-request
Request payload: [Response is eRoamingAcknowledgement]