Gérer les limites de débit et les erreurs serveur

Gérer une réponse 429

Une requête soumise à une limite de débit renvoie 429 Too Many Requests et detail.status vaut rate_limit_exceeded. Lisez les en-têtes avant de réessayer :

• Retry-After donne le délai minimum, en secondes, après le rejet.
• X-RateLimit-Limit indique la limite du groupe.
• X-RateLimit-Remaining indique le nombre de requêtes restantes.
• X-RateLimit-Reset indique quand le groupe se réinitialise.

Attendez Retry-After, puis réessayez avec un délai exponentiel et une part aléatoire. Réduisez les requêtes parallèles et mettez le travail en file d'attente au lieu d'envoyer une rafale dès la réinitialisation.

Gérer les erreurs serveur

Pour une réponse 500, le corps public contient une erreur générique et un request_id, sans détails sur l'exception interne. Une réponse 503 peut signaler l'indisponibilité temporaire d'un service requis.

Réessayez les lectures avec un nombre limité de tentatives et des délais. Avant de répéter une création, une mise à jour, un paiement ou toute autre modification, déterminez si la première tentative a abouti. Un délai dépassé ou un 5xx ne prouve pas l'échec d'une modification; une répétition immédiate peut la dupliquer.

Conserver les éléments de diagnostic

Notez la date et l'heure, la méthode, le chemin, le statut, le corps de réponse et X-Request-Id. Ne journalisez jamais x-api-key. Arrêtez les relances automatiques après quelques tentatives et signalez l'échec pour examen.