Sujet : rate-limiting
-
Pagination de l'API Stripe et clés d'idempotence : starting_after, has_more et la fenêtre de 24 heures
Les endpoints de liste v1 de Stripe paginent avec les paramètres de curseur mutuellement exclusifs starting_after/ending_before (limit de 1 à 100, 10 par défaut) et un indicateur has_more, des assistants de pagination automatique des bibliothèques clientes permettant de parcourir toutes les pages. Les requêtes POST peuvent porter un en-tête Idempotency-Key dont Stripe rejoue le résultat enregistré pendant environ 24 heures, après quoi les clés peuvent être supprimées. Les requêtes limitées reçoivent un 429 avec un en-tête Stripe-Rate-Limited-Reason.
-
Suivre @odata.nextLink dans Microsoft Graph et gérer la limitation 429 et les limites du traitement par lots
Microsoft Graph pagine les grandes collections via une URL @odata.nextLink, à suivre telle quelle comme un jeton opaque sans l'analyser ni la reconstruire. Il accepte des tailles de page définies par le client avec $top, limite le débit par un HTTP 429 accompagné d'un en-tête Retry-After, et plafonne une requête batch JSON à 20 sous-requêtes.
-
Pagination et erreurs de quota des API Google : pageToken, 403 rateLimitExceeded et 429
Les API Google Workspace comme Calendar et Drive paginent avec le couple pageToken/nextPageToken et maxResults (Calendar) ou pageSize (Drive). Drive signale une surcharge de deux façons, par un HTTP 403 (reason rateLimitExceeded ou userRateLimitExceeded) ou par un HTTP 429 (reason rateLimitExceeded). Dans les deux cas, la documentation prévoit de réessayer avec un backoff exponentiel, contrairement aux autres motifs de 403.
-
Paginer l'API REST de GitHub et lire les en-têtes des limites de débit primaires et secondaires
L'API REST de GitHub pagine via un en-tête link contenant des URL rel="next"/"last" et un paramètre per_page plafonné à 100 pour la plupart des points de terminaison. Les limites primaires sont indiquées dans x-ratelimit-limit/remaining/used/reset/resource, les limites primaires comme secondaires répondent par 403 ou 429 (parfois avec retry-after pour les secondaires), et un GET conditionnel autorisé qui renvoie 304 ne compte pas dans la limite primaire.
-
Paginer l'API Web de Slack et gérer les paliers de limitation de débit par méthode
L'API Web de Slack pagine par curseur via response_metadata.next_cursor et un paramètre limit (100 à 200 recommandé, maximum 1000, susceptible de changer et variable selon la méthode). Elle applique des paliers de limitation par méthode et par espace de travail, de 1+ à 100+ requêtes par minute, et renvoie un HTTP 429 avec un en-tête Retry-After en secondes en cas de dépassement.
-
RateLimit et RateLimit-Policy face à X-RateLimit-* : lire les en-têtes de quota qu'envoie une API
Un Internet-Draft de l'IETF (draft-ietf-httpapi-ratelimit-headers-11, mai 2026) propose les champs RateLimit et RateLimit-Policy (par exemple RateLimit: "default";r=50;t=30) pour annoncer le quota avant un 429, mais il reste à l'état de brouillon. La plupart des API envoient aujourd'hui leurs propres en-têtes de type x-ratelimit-limit/-remaining/-reset, ou seulement Retry-After, que la RFC 9110 définit (secondes ou HTTP-date) et que la RFC 6585 autorise sur un 429.
Lisible par machine : JSON