It is important to understand how ENAPI treats partners that aggregate operations of multiple eMobility Service Providers (eMSPs) or Charge Point Operators (CPOs).

If you are an aggregator, or if you plan to roam with an eMSP or CPO that is managed by an aggregator, this article contains important information about how your system is treated by ENAPI.

ENAPI strives to accommodate all setups in the EV roaming landscape. Through personalized connection configuration, the most common setups are accounted for. If you think your particular use case is missing, please contact us so we can develop a solution together.

Typically aggregators are platforms that provide services to eMSPs or CPOs to make their lives easier (either technically or administratively). They might be a Charge Point Management System (CPMS) or a white-label eMSP software provider.

ENAPI itself is also an aggregator. When you make an OCPI connection with ENAPI, you are gaining access to a network of partners to roam with.

Since ENAPI is an OCPI-first platform, we have adopted the OCPI nomenclature. This was introduced in OCPI version 2.2 with the definition of platforms and parties.

Platforms are the systems on either end of the OCPI connection. They might be a traditional eMSP or CPO system, or they could be a CPMS or Hub. Parties, meanwhile, are the business entities (think individual eMSPs or CPOs) that are accessible via the platform. They are identifiable by a combination of country code (ISO 3166-1 alpha-2) and party ID. This is a unique combination that is defined in a central registry within the country of operation.

Therefore, an eMSP could be comprised of a single platform with a single party. A dual CPO and eMSP might have a single platform with two parties, or one platform for each party. A CPMS could be comprised of a single platform (its own system) with multiple parties (the CPOs it provides its service to). This topology allows for flexibility in a complex industry.

Depending on the OCPI protocol version used, there are different ways in which aggregators can connect to the ENAPI platform.

This version defined the concept of platforms and parties and therefore has the most flexibility in terms of connections. As an aggregator, you can connect a single platform with multiple parties, or a platform for each party. The former is desired from a maintainability perspective.

OCPI 2.2.1 also introduced the concept of routing headers, where a platform can specify which party is sending the request, and for which party the request is intended for.

This version of OCPI is the preference for new connections to ENAPI (if available). Because of first-class support for multiple parties under a single platform connection, roaming agreements can be defined more granularly in this version than with OCPI 2.1.1. There is also no need for advanced configuration of the platform connection.

OCPI 2.1.1 is limited insofar as only a single "party" can be communicated to ENAPI during the OCPI handshake. As per the OCPI 2.1.1 specification, this is the party that ENAPI will by default expect to be the owner of any data sent over the connection.

This, however, is quite a strict implementation detail which doesn't always suit every platform. With this in mind, ENAPI has developed a configurable system which aims to cater to the multitude of OCPI implementations in the industry. See Configuration Options for more detail on how ENAPI accommodates different platforms.

When performing a 2.2.1 handshake with ENAPI, there will only be a single role communicated: HUB, with the DE*ENA identifier. Discovery of roaming partners (i.e. parties) is available via the hubclientinfo OCPI module. When a new roaming agreement is made, ENAPI will push the new party information with the CONNECTED status.

Platforms can then expect ENAPI to push data belonging to roaming partners using URLs containing the roaming partner party identifier.

ENAPI communicates its own DE*ENA party identifier during the 2.1.1 handshake. ENAPI currently does not have the hubclientinfo module in OCPI 2.1.1 to aid with discovery of roaming partners.

By default, ENAPI will push 2.1.1 data in the same manner as OCPI 2.2.1. That is a divergence from the OCPI 2.1.1 specification where data would be expected to be pushed to URLs containing the connection's party identifier, e.g. /DE/ENA/location_1. The issue with this, with ENAPI as a transaction broker, is that collisions with data identifiers (location ID, token UID, etc.) could occur, because these identifiers are not globally unique: they are only unique per data owner.

There are ways to mitigate this. ENAPI will transform the Location.operator.name and Token.issuer fields to replace the value with the party identifier (country code and party ID). ENAPI also adds OCPI 2.2.1 routing headers in outgoing 2.1.1 requests, to communicate the data owner. Together, these values will allow identification of the roaming partner within the ENAPI platform.

Below are detailed the OCPI 2.1.1 connection configuration options that are available to platforms.

To transmit data belonging to different parties than the one communicated during the OCPI 2.1.1 handshake, ENAPI can configure the connection to bypass this limitation. ENAPI can then receive data on URLs which contain a different party's identifier. For example, if the party registered was DE*ABC, this will allow a location to be sent to ENAPI's location endpoint with the identifier /NL/ABC/location_1. The data will be attached to the DE*ABC party, so any partner with a roaming agreement with DE*ABC will also gain access to the location NL/ABC/location_1.

If ENAPI's divergence from the 2.1.1 specification is not desirable with respect to party identifiers in URL paths, ENAPI can enable "global" data pushes, so that data will always be sent to DE/ENA URL paths.