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

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

• 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 requestId pour une période, inutile de les redemander : mettez-les en cache de votre côté.

Volume d'historique commandé à Enedis

Les requêtes de courbe de charge et de données journalières asynchrones (R63, LOADCURVE, R64, R65, R66) sont comptées en points·jours : le nombre de PRM × le nombre de jours de la période demandée. Seuls comptent les PRM effectivement commandés à Enedis : ceux dont nous avons déjà les données, ou qui n'ont pas de consentement valide, ne comptent pas.

Par exemple, 400 PRM sur 24 mois (400 × 730 = 292 000) tiennent dans une requête R63, 500 PRM non.

Une requête qui dépasse l'une de ces limites passe en FAILED, avec un message qui donne le volume demandé et ce qui reste. Rien n'est facturé. Pour la limite par requête, répartissez les PRM sur plusieurs requêtes ; pour la limite quotidienne, relancez la requête le lendemain.

Le budget quotidien est configurable workspace par workspace : avant une reprise d'historique importante, contactez-nous avec le nombre de PRM et la période.

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.