The ENAPI platform has implemented OCPI version 2.1.1-d2. It serves as a intermediate between CPOs and eMSPs brokering OCPI requests. OCPI 2.1.1-d2 is a protocol designed for point-to-point communication between eMSPs and CPOs. ENAPI has adapted the protocol to work for an intermediate connecting CPOs and eMSP by implementing both interfaces.

Full list of additions to OCPI 2.1.1 made by ENAPI.

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.

Note that there must be a valid roaming agreement in place between sender and receiver on the ENAPI platform for any data to be exchanged.

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.

ENAPI implements common hub behaviour outlined in OCPI 2.2.1. This includes message broadcasting and open routing requests.

ENAPI also accepts additional HTTP headers that were introduced in OCPI 2.2 to support intermediaries ("hub" in OCPI terminology):

These headers are typically not required because ENAPI can normally infer the sender and receiver from the request context.

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

ENAPI has also added the country_code and party_id of the data object owner for locations and tariffs. These are 2.2 properties that help the receiver of data to determine the roaming partners that own the objects received from the transaction broker.

The ENAPI Transaction Broker adds another HTTP header from OCPI 2.2 to make request tracing easier.

The X-Request-ID header can be attached to an OCPI request to trace it through the ENAPI system.

This is optional. If no header is supplied, ENAPI will generate one and attach it as a header with the same name to the response.

The rest of the OCPI 2.1.1 specification is currently implemented as-is. The following updates are planned to add value to the protocol: