Thema: rate-limiting
-
Stripe-API: Paginierung und Idempotency-Keys (starting_after, has_more und das 24-Stunden-Fenster)
Die List-Endpunkte der Stripe-API v1 paginieren über die sich gegenseitig ausschliessenden Cursor-Parameter starting_after und ending_before (limit 1–100, Standard 10) sowie das Flag has_more; Auto-Pagination-Helfer der Client-Bibliotheken durchlaufen alle Seiten. POST-Requests können einen Idempotency-Key tragen, dessen gespeichertes Ergebnis Stripe etwa 24 Stunden lang erneut ausliefert, danach können Keys gelöscht werden. Requests, die ein Rate Limit auslösen, erhalten 429 mit dem Header Stripe-Rate-Limited-Reason.
-
@odata.nextLink bei Microsoft Graph folgen und mit 429-Drosselung und Batch-Limits umgehen
Microsoft Graph liefert grosse Collections seitenweise über eine @odata.nextLink-URL, der als opakem Token zu folgen ist, statt sie zu parsen oder nachzubauen. Clientseitig lässt sich die Seitengrösse per $top steuern, bei Drosselung antwortet Graph mit HTTP 429 und einem Retry-After-Header, und ein einzelner JSON-Batch darf höchstens 20 Einzelanfragen enthalten.
-
Pagination und Quotenfehler bei Google-APIs: pageToken, 403 rateLimitExceeded und 429
Google-Workspace-APIs wie Calendar und Drive paginieren über das Paar pageToken/nextPageToken mit maxResults (Calendar) bzw. pageSize (Drive). Drive signalisiert Überlast auf zwei Arten: HTTP 403 mit dem Grund rateLimitExceeded oder userRateLimitExceeded oder HTTP 429 mit dem Grund rateLimitExceeded. Alle diese Fälle sind als Anlass für einen Retry mit exponentiellem Backoff dokumentiert, anders als andere 403-Gründe.
-
GitHub-REST-API: Paginierung und Auswertung der Header für primäre und sekundäre Rate Limits
Die GitHub-REST-API paginiert über einen link-Header mit rel="next"/"last"-URLs und den Parameter per_page (bei den meisten Endpunkten maximal 100). Primäre Limits stehen in x-ratelimit-limit/remaining/used/reset/resource, beide Limitarten antworten mit 403 oder 429 (sekundäre teils mit retry-after), und ein autorisierter bedingter GET mit 304 zählt nicht gegen das primäre Limit.
-
Slack Web API: Paginierung und Umgang mit den methodenspezifischen Rate-Limit-Stufen
Die Web API von Slack paginiert cursorbasiert über response_metadata.next_cursor und den Parameter limit (empfohlen 100–200, Maximum 1000, änderbar und je nach Methode unterschiedlich) und begrenzt Anfragen pro Methode und Workspace in Stufen von 1+ bis 100+ pro Minute; bei Überschreitung folgt HTTP 429 mit einem Retry-After-Header in Sekunden.
-
RateLimit und RateLimit-Policy gegenüber X-RateLimit-*: Quota-Header einer API lesen, egal welche sie sendet
Ein IETF-Internet-Draft (draft-ietf-httpapi-ratelimit-headers-11, Mai 2026) schlägt die Header-Felder RateLimit und RateLimit-Policy vor (z. B. RateLimit: "default";r=50;t=30), um das Kontingent schon vor einer 429-Antwort anzuzeigen. Er ist aber weiterhin ein Entwurf. Die meisten APIs senden heute eigene Header im Stil von x-ratelimit-limit/-remaining/-reset oder nur Retry-After, das RFC 9110 definiert (Sekunden oder HTTP-date) und RFC 6585 bei 429 zulässt.
Maschinenlesbar: JSON