What to expect when connecting to the ENAPI platform

The ENAPI platform serves as a intermediate between CPOs and eMSPs brokering OCPI requests. The following OCPI versions are supported:

• 2.1.1-d2*

• 2.2.1

• 2.3.0

The following versions are not currently supported:

• 2.2

Interoperability

ENAPI has implemented OCPI version interoperability to support connections between eMSPs and CPOs using different OCPI versions.

Some use cases introduced in later OCPI versions are not available to partners on earlier OCPI versions. Where possible, ENAPI can back-port functionality to unlock use cases between partners upon request.

🚴‍♂ Request Lifecycles

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.

ENAPI Pull Behavior

ENAPI performs regular synchronization with roaming partners to ensure it has the most up-to-date data. There are two sync types:

Full sync

• Performed every Saturday at 01:00 UTC

• Query parameter date_to is the datetime at the start of the sync.

• Query parameter limit defaults to 1000 but is configurable depending on your system characteristics.

Delta sync

• Performed every day (excluding Saturday) at 01:00 UTC

• Query parameter date_from is the datetime of the last successful sync.

• Query parameter date_to is the datetime at the start of the sync.

• Query parameter limit defaults to 1000 but is configurable depending on your system characteristics.

ENAPI Push Behavior

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.

Charging Authorizations

ENAPI does not perform any authorization of charging sessions itself.

ENAPI forwards RFID authorization requests to the appropriate MSP (the token owner), and remote start/stop commands to the appropriate CPO (the location owner).

For efficiency of authorization, ENAPI requires prior knowledge of the token or location, in order to route the request to the correct MSP or CPO. This means that ENAPI does not broadcast authorization requests to every MSP or CPO in the event that it does not know a token or location.

🚦 Routing

ENAPI implements common hub behavior introduced in recent versions of OCPI and applies this behavior to all OCPI versions. Examples of hub routing functionality include 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. However, there are some caveats.

• There are performance benefits to providing these headers, since ENAPI does not have to infer the recipient from the request context.

• If a platform has multiple parties with the same role (2.2.1+ only), they must append the OCPI-from-country-code and OCPI-from-party-id headers in order for the ENAPI platform to correctly discern the sending party.

• Locations Module: GET object (single location, EVSE or connector) from CPO interface. As identifiers are not globally unique, context about the owning party is needed. Therefore OCPI-to-country-code and OCPI-to-party-id 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.

🕵 Request Tracing

The ENAPI Transaction Broker adds HTTP headers introduced in OCPI 2.2 to make request tracing easier.

The X-Request-ID and X-Correlation-ID headers can be attached to an OCPI request to trace a request through the ENAPI system and beyond.

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.

ℹ Fetching OCPI Data from ENAPI

By default, ENAPI does not return the X-Total-Count HTTP response header when making paginated requests. This feature is opt-in. If you need this functionality in order to process pages, please contact us.