Eine API antwortet mit 429? Du hast das Anfragelimit überschritten. Die Antwort sagt oft, wie lange du warten musst — Geduld und Backoff helfen.
Aufwand:
ca. 25 Min.
Das Symptom
Ein Programm, ein Skript oder eine Webseite, die eine Programmierschnittstelle (API)
nutzt, bekommt plötzlich die Antwort 429 Too Many Requests und funktioniert nicht
mehr richtig. Oft passiert es, wenn viele Anfragen schnell hintereinander gesendet
werden oder ein Skript in einer Schleife läuft.
Die „Layer 8“-Wahrheit
Der Code 429 ist keine Fehlfunktion, sondern eine Grenze, die der Anbieter mit
Absicht zieht. Kein Server verträgt unbegrenzt viele Anfragen, und um sich vor
Überlastung — ob versehentlich oder böswillig — zu schützen, legt fast jede API
fest, wie viele Anfragen in einem Zeitraum erlaubt sind. Wer dieses Limit
überschreitet, bekommt eine höfliche Abfuhr mit der Botschaft: nicht kaputt, nur zu
schnell, bitte kurz warten. Genau deshalb ist die falsche Reaktion, sofort und noch
hektischer erneut anzufragen — das verlängert die Sperre nur.
Die richtige Antwort ist Geduld mit System. Viele Server sagen im Retry-After-Feld
sogar genau, wie lange man warten soll — diesen Hinweis zu befolgen, ist der
kürzeste Weg zurück. Im eigenen Code gehört ein exponentieller Backoff eingebaut, der
nach jedem Fehlschlag länger wartet, statt stur zu hämmern. Und die nachhaltigste
Lösung setzt noch früher an: die Anfragen von vornherein unter dem Limit halten und
wiederkehrende Ergebnisse zwischenspeichern, damit viele Anfragen gar nicht erst
nötig sind. Wer 429 als Aufforderung zum Maßhalten liest statt als Fehler, löst es
zuverlässig.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Meldung verstehen
Der Statuscode 429 bedeutet, dass in zu kurzer Zeit zu viele Anfragen an den Server gingen und er weitere vorübergehend abweist. Das ist keine Störung, sondern ein Schutz des Anbieters vor Überlastung. Wichtig: Es ist kein dauerhafter Fehler, sondern eine Bitte, langsamer zu machen.
2.
Den Retry-After-Hinweis beachten
Viele Server schicken im Kopf der Antwort ein Feld namens Retry-After, das angibt, wie lange man warten soll, bevor man es erneut versucht. Diesen Wert auslesen und respektieren, statt sofort erneut anzufragen — das ist der direkteste Weg aus der Sperre.
3.
Einen exponentiellen Backoff einbauen
Im eigenen Code sollten fehlgeschlagene Anfragen nicht sofort wiederholt werden, sondern mit wachsender Wartezeit (exponentieller Backoff): erst kurz warten, dann länger, dann noch länger. Das entlastet den Server und bringt die eigenen Anfragen zuverlässig durch, statt gegen die Wand zu laufen.
4.
Die Anfragen drosseln
Statt so schnell wie möglich zu feuern, die eigene Anfragerate bewusst unter das erlaubte Limit senken — etwa mit einer kleinen Pause zwischen den Aufrufen oder einer Warteschlange. Das Limit des Anbieters in dessen Dokumentation nachlesen und einhalten.
5.
Ergebnisse zwischenspeichern
Oft werden dieselben Daten unnötig oft abgefragt. Antworten für eine sinnvolle Zeit zwischenspeichern (Cache), damit gar nicht erst so viele Anfragen entstehen. Das ist die nachhaltigste Lösung — sie senkt die Last dauerhaft, statt nur den Fehler zu umgehen.
Häufige Fragen (FAQ)
?Was bedeutet HTTP 429 genau?
Der Server sagt: Ihre Anfragen sind zu häufig, ich lehne sie vorerst ab. Es ist kein Fehler in Ihrem Code und kein Defekt beim Server, sondern eine bewusste Schutzmaßnahme. Der Dienst funktioniert einwandfrei – er schützt sich nur vor Überlastung durch einen einzelnen Aufrufer.
?Was ist ein exponentieller Backoff?
Eine Wartestrategie, bei der die Pause nach jedem Fehlschlag verdoppelt wird: eine Sekunde, zwei, vier, acht. Sie verhindert, dass tausend Clients gleichzeitig im selben Rhythmus erneut anklopfen und den Server ein zweites Mal überrennen. Sendet der Server einen Retry-After-Hinweis, hat dieser immer Vorrang – er nennt die exakte Wartezeit.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Die Konsole meldet einen CORS-Fehler und die Anfrage scheitert? Nicht der Browser ist schuld — der Server muss den Zugriff von deiner Herkunft erlauben.