🔗 OCPI 2.2.1

The ENAPI Transaction Broker supports OCPI 2.2.1. Note that the following modules are not yet implemented:

We plan on supporting them soon, but please let us know if you have an urgent need for these modules.

OCPI 2.2 introduced base64 token encoding of authorization tokens. However, not all platforms support token encoding. ENAPI provides configuration to each platform, allowing you to define whether tokens should be encoded or not.

ENAPI performs regular synchronisation with roaming partners to ensure it has the most up-to-date data. By attaching appropriate time interval query parameters, ENAPI ensures it does not request more data than necessary.

ENAPI also fully supports the PUSH model in OCPI, so that data owners can send their roaming partners the latest data updates in real-time. ENAPI performs validation on the incoming data and broadcasts it to all relevant roaming partners.

Since ENAPI strives to have the latest data, requests made by roaming partners to the ENAPI platform do not incur a round-trip to the owner of the data.

For the remote authorisation of charging sessions, ENAPI routes the message to the appropriate recipient (commands receiver, typically a CPO or CPMS).

For the authorisation of RFID cards (tokens), if ENAPI does not have prior knowledge of the token (an eMSP has not shared the token with ENAPI), it must broadcast the authorisation request to all eMSPs with which the CPO has a valid roaming agreement with.

As part of the Credentials handshake, ENAPI will provide your system with only a single

Credentials Role - ENAPI's own, with the HUB market role.

Data received from roaming partners via ENAPI will have the country_code and party_id of the roaming partner in the data object.

HubClientInfo is partially implemented as a means of discovering OCPI parties that you have a roaming agreement with. ENAPI sends a request to both sides when an agreement is made. Currently ENAPI only tracks CONNECTED and SUSPENDED statuses.

ENAPI supports OCPI routing and tracing headers in requests, as described in the OCPI 2.2.1 specification.

OCPI 2.2.1 made it easier and more explicit to combine operations of multiple "parties" under the same "platform" connection.

Routing headers are not required when sending an OCPI request to ENAPI from a platform with a single party (Credentials Roles). However, currently if a platform has multiple parties, they will need to append the OCPI-from-country-code and OCPI-from-party-id headers in order for the ENAPI platform to correctly discern the sending party. This is important because roaming agreements on the ENAPI platform are between parties, not platforms.

ENAPI also supports OCPI-to-country-code and OCPI-to-party-id headers. There are performance benefits to providing these headers, since ENAPI does not have to infer the recipient from the request context.

There are cases where the OCPI-to-country-code and OCPI-to-party-id request headers are required:

If ENAPI receives it's own country code and party ID (DE*ENA) in the routing headers, it will treat the request as an open routing request.