429 Too Many Requests au lieu de
traiter la requête.
Les limites de débit ne sont pas un mode de facturation. Elles protègent
l’infrastructure contre les pics de trafic et les boucles d’appels accidentelles.
Un client bien conçu (backoff + webhooks) ne devrait jamais les atteindre en
fonctionnement normal.
Les trois dimensions de limitation
Le débit est contrôlé sur trois axes complémentaires. Une requête doit passer les trois pour être traitée ; le premier seuil atteint déclenche le429.
Par IP
Protège contre les bursts provenant d’une même adresse source, avant même la
résolution de la clé API. C’est la première barrière, utile contre les boucles
de retry trop agressives.
Par clé
Chaque clé API (
med_live_… / med_test_…) dispose de son propre budget. Une
clé saturée n’impacte pas les autres clés de votre groupe.Globale
Une limite de plateforme, partagée, qui protège le service amont (relai de
création / tarification) contre une surcharge agrégée.
Le
detail du corps d’erreur précise l’axe atteint, par exemple
Rate limit (key) exceeded. ou Rate limit (ip) exceeded.. Comme toujours,
branchez votre logique sur le statut (429) et non sur le texte de detail,
qui peut évoluer.La réponse 429
Quand une limite est franchie, l’API répond429 au format RFC 9457
(application/problem+json) et joint un en-tête Retry-After indiquant le délai
(en secondes) à attendre avant de réessayer.
Nombre de secondes à patienter avant de soumettre une nouvelle requête.
Respectez-le impérativement : réessayer plus tôt sera de nouveau refusé et peut
prolonger la fenêtre de blocage.
Bonnes pratiques
Respecter Retry-After + backoff exponentiel
En réponse à un
429, attendez au minimum la valeur de Retry-After. En
son absence, appliquez un backoff exponentiel avec jitter (aléa) pour éviter
que tous vos clients ne réessaient en même temps.Regrouper les requêtes
Préférez une requête paginée à des centaines d’appels unitaires. Pour
parcourir vos missions, utilisez la pagination par curseur
(
?limit=200&cursor=…) plutôt que d’interroger chaque mission une par une.Préférer les webhooks au polling
Ne sondez pas (
poll) en boucle GET /transports/{id} pour détecter un
changement de statut. Abonnez-vous aux webhooks : MED vous notifie en
push à chaque transition, sans consommer votre budget de requêtes.Polling vs webhooks
- À éviter — polling serré
- Recommandé — webhooks + réconciliation
Interroger le détail d’une mission en boucle consomme votre budget et atteint
vite la limite par clé, pour une information que vous auriez reçue gratuitement
par webhook.
Exemple : retry avec backoff exponentiel (Node.js)
Ce clientfetch (Node.js ≥ 18) réessaie automatiquement sur 429 (et sur les
erreurs amont 5xx/502, sûres à rejouer grâce à l’idempotence). Il respecte
Retry-After quand il est présent, sinon applique un backoff exponentiel borné
avec jitter.
Récapitulatif
Quels statuts faut-il réessayer ?
Quels statuts faut-il réessayer ?
429 (limite de débit) et les erreurs amont 502/5xx (relai de création ou
de tarification). Les 4xx autres que 429 (par ex. 422 validation, 404
introuvable) ne doivent pas être réessayés tels quels : corrigez d’abord la
requête.Comment éviter le 429 en premier lieu ?
Comment éviter le 429 en premier lieu ?
Le 429 consomme-t-il mon idempotence ?
Le 429 consomme-t-il mon idempotence ?
Non. Une requête rejetée en
429 n’a pas été traitée : rejouer la même
Idempotency-Key exécutera l’opération une fois la fenêtre passée, sans
conflit.Étapes suivantes
Gérer les erreurs
Le format RFC 9457, les codes HTTP courants et la bonne façon de brancher votre
logique sur le
status.Idempotence
Rejouer une requête en toute sécurité après un
429 ou une erreur réseau, sans
créer de doublon.Webhooks
Recevoir les changements en push plutôt que de sonder l’API — la meilleure façon
de rester sous les limites.

GET /events?since=…. La grande majorité des429proviennent d’un polling trop fréquent évitable.