Rate-limits de l'API#
Certains endpoints sont soumis à une rate-limit par projet, afin que la charge d'un client ne dégrade pas les temps de réponse des autres. Les limites s'appliquent à l'ensemble des tokens d'un même projet, quel que soit le compte de service utilisé.
Endpoints limités#
| Endpoint | Limite par projet |
|---|---|
GET/integration/enedis/search_contract (et sa variante POST) | 2 appels / seconde |
GET/integration/enedis/request/{requestId}/data | 5 appels / seconde et 120 / minute |
Les endpoints non listés ici ne sont pas limités par projet.
Quelques précisions sur la restitution des données :
- les deux fenêtres se cumulent : le budget à la seconde autorise une rafale courte, celui à la minute plafonne le régime soutenu à 2 appels/seconde en moyenne ;
- les fenêtres sont glissantes : elles sont évaluées sur les N dernières secondes, pas sur des tranches horaires fixes ;
- ce budget est commun à toutes les routes qui restituent une courbe de charge, y compris les endpoints équivalents de l'ancienne API enedis-v2 : alterner entre les deux ne double pas le budget.
Des plafonds globaux, communs à l'ensemble de nos clients, s'ajoutent à ces limites par projet. En pratique vous ne les atteindrez pas avant votre propre budget.
Ce qui se passe au-delà#
L'appel est rejeté avec un statut 429 Too Many Requests — la donnée n'est pas lue, rien n'est facturé :
{
"_tag": "RateLimited",
"message": "Rate limit exceeded for key 'loadcurveData.org:mon-projet' (window=1s, limit=5)"
}
Sur les anciennes routes /enedis/v2/*, le même statut 429 est renvoyé avec le corps { "error": "Too many requests, please try again later." }.
Un appel rejeté ne consomme pas de budget : dès que la fenêtre glisse, l'appel suivant passe.
Conduite à tenir#
Un 429 n'est pas une erreur définitive : c'est une invitation à ralentir. Réessayez, mais pas immédiatement.
- Réessayez avec un backoff exponentiel (par exemple 1 s, 2 s, 4 s…) plutôt qu'en boucle serrée : une boucle de retry sans attente reste bloquée à la limite et n'avance pas.
- Lissez vos exports. La restitution de données est l'appel le plus coûteux de l'API ; paralléliser massivement la récupération d'un lot de requêtes est contre-productif. Une file avec quelques appels concurrents au plus donne un débit total supérieur.
- Ne relancez pas un appel qui a réussi. Si vous avez déjà les données d'un
requestIdpour une période, inutile de les redemander : mettez-les en cache de votre côté.
Besoin d'un budget plus élevé ?#
Ces limites sont configurables projet par projet. Si votre usage légitime les dépasse, contactez-nous en décrivant le débit dont vous avez besoin et nous les ajusterons.