Dafne API
*Note: These APIs are still under development and the specifications may change.
Dafne (Dutch Alternative Fuel National Endpoint) is the system that receives and provides real-time data on alternative energy infrastructure for vehicles from suppliers. This system is also known as NAP-EV.
Connecting
To connect to Dafne, you can contact the NDW Servicedesk. Indicate that it is about connecting to Dafne. From there information regarding the connection will be exchanged and connection tests will be carried out.
Supplying using OCPI-2.2.1
OCPI (Open Charge Point Interface) is a protocol that enables communication between charge point operators and service providers and is maintained by the EVRoaming Foundation.
For delivery to Dafne, using OCPI-2.2.1, openapi-specifications have been created for the pull and push functionality (4.1.3 in OCPI-2.2.1), which indicate what information is expected through the endpoints.
In addition to OCPI-2.2.1, the following optional elements have been made mandatory in the openapi specifications due to the AFIR:
| Object | Element |
|---|---|
| Location | opening_times |
| Location | energy_mix |
| EVSE | parking_restrictions |
| Connector | max_electric_power |
| Connector | tariff_ids |
Pull
To know the complete set of objects and the latest status of individual objects, they are periodically retrieved using the pull functionality. For this, a server must be available that delivers the current state as a response to a GET in accordance with the pull-API openapi-spec.
Pull - Locations
To deliver the Locations, an endpoint must be available that listens to requests for both the complete set and specific locations. Retrieving individual EVSE and Connector objects is not used for the time being.
Pull - Tariffs
To deliver the Tariffs, an endpoint must be available that listens to requests for the complete set of tariffs.
Pull - Authentication
The credentials module of OCPI is not used.
To retrieve the current state from the supplier, authentication details must be provided. These are a client-id with client-secret combination when using OAuth2. According to the OAuth2 conventions, the JWT will be passed via an Authorization: Bearer header. When using an agreed token/api-key, the access token/api-key must be included in the Authorization: Token header.
Push
To communicate changes to objects when they occur, there is push functionality. For this, the client must deliver changes in accordance with the push-API openapi-spec. Full objects are updated with PUT, while only provided elements are updated with PATCH. Only for tariffs is it possible to delete objects with a DELETE.
| Method | Description | Location | EVSE | Connector | Tariff |
|---|---|---|---|---|---|
| PUT | Update objects | x | x | x | x |
| PATCH | Update elements of existing objects | x | x | x | |
| DELETE | Delete objects | x |
It is not allowed to change identifiers of objects. For example, a PUT on a location with a parameter location_id with value x, while the id-element of the object is y.
Push - Locations
To update a single location, it is possible to perform a PUT or PATCH on the Locations, EVSE, and Connector objects. Only the last_updated is a mandatory element. If a sub-object is mentioned in an update, this sub-object must be fully present (according to the requirements of a PUT for that type of object).
Push - Tariffs
To update a single tariff, it is possible to perform a PUT on a Tariff object. To delete a tariff, it is possible to perform a DELETE, which returns an HTTP-204 status code upon success (this differs from the OCPI specification).
Push - Authentication
The credentials module of OCPI is not used.
To deliver the updates (push), a client-id and client-secret are provided to authenticate with OAuth2. According to the OAuth2 conventions, the JWT will be passed via an Authorization: Bearer header.
Supplier pull-API
Pull-API according to openapi-spec
Supplier push-API
Push-API according to openapi-spec
Servicedesk
For more information, you can contact the NDW Servicedesk.