Migrer votre application sur la nouvelle plateforme d’API Management d’Enedis
Dès le mois de Novembre 2021, nous avons mis en service la nouvelle plateforme d’API management d’Enedis.
Dans ce contexte, de nouvelles versions des API Authorize, Grid_connection_simulation, Metering et Customers ont vu le jour au fur et à mesure de la migration des API sur cette nouvelle plateforme. Les impacts utilisateurs ont été limités au maximum, mais certaines modifications seront nécessaires pour consommer ces nouvelles APIs dont vous trouverez les détails ci-dessous.
Les versions précédentes des API restent bien sûr fonctionnelles sur l’ancienne plateforme jusqu’au mois de Mars 2023. Passé cette date, seules les API de la nouvelle plateforme seront maintenues.
Basculer sur la nouvelle plateforme
Afin de cibler la nouvelle plateforme d’API Management, il faut modifier l’url de l’environnement ciblé :
- Ancienne plateforme : https://gw.prd.api.enedis.fr
- Nouvelle plateforme : https://ext.prod.api.enedis.fr
Les identifiants de vos applications seront conservés sur tous les environnements (bac à sable et production), il ne sera donc pas nécessaire de les changer.
Appeler les nouvelles API
API d’Authentification
Afin de cibler la nouvelle API d’authentification, il faut modifier la version de l’API ciblée et le path technique d’appel dans l’URL :
- Ancienne plateforme : /v1/oauth2/…
- Nouvelle plateforme : /oauth2/v3/…
L’ancienne API d’authentification fonctionnait par le biais d’un stockage du consentement utilisateur au sein même du jeton d’accès. Cela nécessitait de toujours conserver son jeton d’accès et de le renouveler fréquemment.
Avec la nouvelle API, cela évolue et cette action n’est plus nécessaire : après avoir récupéré le consentement du client, une génération simple de jeton sera suffisante pour pouvoir avoir accès aux données. La vérification du consentement est conservée : c’est une autre brique du SI qui s’en chargera.
En conséquence, l’obtention d’un jeton d’accès par une simple requête, avec la méthode d’authentification « Client Credential » accompagnée des identifiants de l’application, suffira pour faire des appels à une API. Sur la nouvelle plateforme, votre application, ses identifiants et ses souscriptions seront reportées : il n’y a pas d’action nécessaire pour pouvoir appeler cette API. Seuls l’environnement ciblé et le path d’appel de l’API nous permettront d’identifier si vous appelez l’ancienne plateforme ou la nouvelle.
API Grid_connection_simulation
Afin de cibler la nouvelle API Metering, il faut modifier le nom et la version de l’API ciblée ainsi que le path technique d’appel dans l’URL.
- Ancienne plateforme : /v2/grid_connection_simulation/…
- Nouvelle plateforme : /grid_connection_simulation/v4/…
L’API sur la nouvelle plateforme s’appelle suite à une authentification sur cette nouvelle plateforme (/oauth2/v3/).
API Metering v4
Afin de cibler la nouvelle API Metering, il faut modifier le nom et la version de l’API ciblée ainsi que le path technique d’appel dans l’URL. Afin de respecter les souscriptions identifiées dans les contrats, il a fallu diviser l’API en plusieurs petites API. Vous trouverez ci-dessous les nouveaux noms des API sur la nouvelle plateforme :
|
Données souhaitée |
Path API Ancienne Plateforme |
Path API Nouvelle Plateforme |
|
Consommation quotidienne |
GET /v4/metering_data/daily_consumption |
GET /metering_data_dc/v5/daily_consumption |
|
Puissance maximum de consommation quotidienne |
GET /v4/metering_data/daily_consumption_max_power |
GET /metering_data_dcmp/v5/daily_consumption_max_power |
|
Consommation par demi-heure |
GET /v4/metering_data/consumption_load_curve |
GET /metering_data_clc/v5/consumption_load_curve |
|
Production quotidienne |
GET /v4/metering_data/daily_production |
GET /metering_data_dp/v5/daily_production |
|
Production par demi-heure |
GET /v4/metering_data/production_load_curve |
GET /metering_data_plc/v5/production_load_curve |
Fonctionnellement, l’API ne change pas : le contrat d’interface reste le même que sur l’ancienne plateforme. Un seul élément évolue : lors des appels, il faut envoyer un header « Accept » valorisé à « Application/json ».
Sur la nouvelle plateforme, votre application, ses identifiants et ses souscriptions seront reportées : il n’y a pas d’action nécessaire pour pouvoir appeler cette API. Seuls l’environnement ciblé et le path d’appel de l’API nous permettront d’identifier si vous appeler l’ancienne plateforme ou la nouvelle.
API Customers v3
Afin de cibler la nouvelle API Customers, il faut modifier le nom et la version de l’API ciblée ainsi que le path technique d’appel dans l’URL. Afin de respecter les souscriptions identifiées dans les contrats, il a fallu diviser l’API. Vous trouverez ci-dessous les nouveaux noms des API sur la nouvelle plateforme :
|
Données souhaitée |
Path API Ancienne Plateforme |
Path API Nouvelle Plateforme |
|
Identité |
GET /v3/customers/identity |
GET /customers_i/v5/identity |
|
Données de contact |
GET /v3/customers/contact_data |
GET /customers_cd/v5/contact_data |
|
Données contractuelles |
GET /v3/customers/usage_points/contracts |
GET /customers_upc/v5/usage_points/contracts |
|
Adresse |
GET /v3/customers/usage_points/addresses |
GET /customers_upa/v5/usage_points/addresses |
Fonctionnellement, l’API ne change pas : le contrat d’interface reste le même que sur l’ancienne plateforme. Un seul élément évolue : lors des appels, il faut envoyer un header « Accept » valorisé à « Application/json ».
Sur la nouvelle plateforme, votre application, ses identifiants et ses souscriptions seront reportées : il n’y a pas d’action nécessaire pour pouvoir consommer cette API. Seuls l’environnement ciblé et le path d’appel de l’API nous permettront d’identifier si vous appeler l’ancienne plateforme ou la nouvelle.
Abonnement aux nouvelles API
Sur la nouvelle plateforme, votre application, ses identifiants et ses souscriptions seront reportées : il n’y a pas d’action nécessaire pour pouvoir vous abonner aux nouvelles API.