HTTP 429 Too Many Requests

Was HTTP 429 bedeutet

HTTP 429 Too Many Requests bedeutet, dass der Client ein Rate-Limit überschritten hat — pro IP, pro API-Key, pro Nutzer oder pro Endpunkt. Wohlerzogene Server senden einen Retry-After-Header (Sekunden oder ein Datum) und oft X-RateLimit-*-Header, die das Kontingent beschreiben.

Für Clients ist die richtige Reaktion immer dieselbe: zurückschalten. Sofortiges erneutes Versuchen macht es schlimmer und kann eine temporäre Drosselung zu einer Sperre eskalieren.

Häufige Ursachen von 429-Fehlern

• Ein API-Client fragt zu häufig ab oder überschreitet sein Kontingent in Schüben.
• Web-Scraping ohne Verzögerungen zwischen Requests.
• Ein Bug: eine Retry-Schleife ohne Backoff, die denselben Endpunkt hämmert.
• Geteilte IP (Büro-NAT, VPN, Serverless-Egress), bei der der kombinierte Traffic das Limit überschreitet.
• Login-Endpunkte, die wiederholte Versuche als Brute-Force-Schutz drosseln.

So behebst du es als Client/Entwickler

• Halte dich exakt an Retry-After; fehlt es, nutze Exponential Backoff mit Jitter (z. B. 1s, 2s, 4s, 8s…).
• Lies die X-RateLimit-Remaining/Zurücksetzen-Header der API und takte Requests proaktiv.
• Bündle Requests und cache Antworten, statt identische Daten erneut abzurufen.
• Verteile die Last über die Zeit, nicht über Wegwerf-IPs — Limits zu umgehen verstößt meist gegen die Nutzungsbedingungen der API.

So behebst du es als API-Betreiber

• Sende immer Retry-After- und Kontingent-Header, damit Clients sich korrekt verhalten können.
• Limitiere die Rate nach Key/Nutzer statt nach bloßer IP, wo möglich, um gemeinsam genutzte Netzwerke nicht zu bestrafen.

Beispielantwort

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0

{"error":"rate_limited","retry_after":30}

FAQ