Une API renvoie 429 : reprendre la synchronisation sans perdre de données
Une réponse HTTP 429 indique que le service limite le rythme des requêtes. La reprise doit respecter cette limitation et conserver la progression de la synchronisation. Relancer immédiatement toute la série en boucle peut prolonger le problème et créer des doublons.
Identifier la réponse exacte
Conservez le code, l’heure, l’opération et les informations utiles de la réponse, sans enregistrer les secrets d’authentification. Distinguez la limitation temporaire d’une erreur d’accès ou d’une donnée refusée. Ces situations ne demandent pas la même correction.
La documentation MDN de HTTP 429 précise qu’un en-tête Retry-After peut indiquer le délai à respecter. Les limites peuvent s’appliquer à des périmètres différents selon le service ; consultez aussi sa documentation et votre contrat d’accès.
Conserver un point de reprise
Enregistrez les éléments confirmés et ceux dont le résultat reste inconnu. Un numéro de page ou un curseur ne suffit pas toujours si les données changent pendant la synchronisation. Choisissez un mécanisme adapté à l’API : identifiant stable, date de modification ou autre repère documenté.
Testez le cas où une opération a été exécutée mais où sa confirmation n’a pas été reçue. Avant de la répéter, vérifiez comment l’API permet d’éviter une seconde création. Le guide des commandes en double présente ce risque dans les connexions métier.
Maîtriser les nouvelles tentatives
Préparez une attente croissante et une limite de reprises adaptées au service. Coordonnez les traitements qui partagent le même accès afin qu’ils ne reprennent pas tous simultanément. Une tâche bloquée doit pouvoir passer à un état nécessitant une intervention, avec un diagnostic utile.
Ne contournez pas la limite en multipliant les identités ou les accès. Le problème doit être résolu dans le cadre normal du service : débit autorisé, organisation des appels ou formule d’accès appropriée.
Vérifier les données après rétablissement
Rapprochez le volume attendu des éléments effectivement reçus ou modifiés. Recherchez les trous et les doublons sur la période concernée. Le retour d’un code de succès ne prouve pas que le retard a été entièrement traité.
Documentez l’incident, la progression reprise et les opérations qui restent à examiner. Une synchronisation robuste doit permettre de comprendre où elle s’est arrêtée et ce qui a été confirmé, sans recommencer aveuglément l’ensemble du catalogue.
Questions fréquentes
Que signifie une réponse API HTTP 429 ?
Le service indique que trop de requêtes ont été reçues selon ses limites. Ce statut doit être distingué d’un refus de données ou d’une erreur qui nécessite une autre correction.
Faut-il relancer immédiatement toutes les requêtes après un HTTP 429 ?
Non. Identifiez les indications du service et organisez l’attente ou la reprise prévue. Une relance massive peut prolonger la limitation au lieu de rétablir l’échange.
Que doit conserver un point de reprise de synchronisation ?
Les opérations terminées, celles qui restent à traiter et les informations permettant de les identifier. Il faut pouvoir reprendre sans renvoyer au hasard l’ensemble du catalogue ou des commandes.
Pourquoi prévoir un traitement sans doublon lors des nouvelles tentatives ?
Une requête peut avoir réussi avant qu’une réponse soit perdue ou qu’une autre étape échoue. La reprise doit retrouver le résultat existant plutôt que créer une seconde opération.
Comment confirmer le rétablissement après la fin des erreurs 429 ?
Rapprochez les éléments attendus de ceux réellement reçus par le système destinataire. La disparition du statut d’erreur ne prouve pas que toutes les données en attente ont été synchronisées.
Sources
Documentation consultée le 23 octobre 2026.