Fast jede ernsthafte API begrenzt, wie oft du sie aufrufen darfst. Diese Rate Limits schützen den Anbieter vor Überlastung und Missbrauch – und stolpern lassen sie vor allem Entwickler, die das Limit übersehen oder falsch umrechnen. „1000 Requests pro Minute“ klingt großzügig, ist aber etwas ganz anderes als „1000 pro Tag“. Dieser Ratgeber erklärt, wie Rate Limits funktionieren und wie du sie sauber einplanst.
Die Einheiten umrechnen
Rate Limits werden in verschiedenen Zeitfenstern angegeben: pro Sekunde, pro Minute, pro Stunde oder pro Tag. Um Limits zu vergleichen oder zu prüfen, ob deine Anwendung hineinpasst, musst du sie auf eine gemeinsame Einheit bringen:
- 1 Request/Sekunde = 60/Minute = 3600/Stunde = 86.400/Tag
- 1000 Requests/Minute ≈ 16,7/Sekunde = 1,44 Mio./Tag
- 10.000 Requests/Tag ≈ 0,12/Sekunde – also nur etwa alle 8,6 Sekunden einer
Genau diese Umrechnung erledigt der API Rate Limit Rechner: Du gibst ein Limit in einer beliebigen Einheit ein und siehst sofort die äquivalenten Werte pro Sekunde, Minute, Stunde und Tag. So erkennst du auf einen Blick, ob ein Tageslimit für deinen Anwendungsfall ausreicht.
Burst vs. Sustained
Ein häufiges Missverständnis: Ein Limit von „60 pro Minute“ heißt nicht zwangsläufig, dass du 60 Requests gleichzeitig abfeuern darfst. Viele APIs unterscheiden zwischen:
- Sustained Rate: die durchschnittlich erlaubte Rate über das Zeitfenster – z. B. 60/Minute entspricht 1/Sekunde im Schnitt.
- Burst: wie viele Requests kurzfristig auf einmal erlaubt sind, bevor gedrosselt wird.
Wer das ignoriert und 60 Requests in der ersten Sekunde absetzt, kassiert trotz „60/Minute“-Limit eine Drosselung, weil der Burst überschritten wurde.
Token Bucket und Leaky Bucket
Die meisten APIs setzen Rate Limits mit einem Token-Bucket-Algorithmus um. Stell dir einen Eimer vor, der sich konstant mit Tokens füllt. Jeder Request verbraucht ein Token. Ist der Eimer leer, wird der Request abgelehnt oder verzögert. Das erlaubt kurze Bursts (solange Tokens da sind) und begrenzt gleichzeitig die langfristige Durchschnittsrate.
Das verwandte Leaky-Bucket-Modell glättet die Ausgabe auf eine feste Rate. Beide Verfahren bestimmen, wie „nachsichtig“ eine API auf kurze Lastspitzen reagiert.
Der 429-Fehler und Retry-Strategien
Wird ein Limit überschritten, antwortet die API üblicherweise mit dem HTTP-Status 429 Too Many Requests. Oft liefert sie zusätzlich Header wie Retry-After oder X-RateLimit-Remaining mit, die dir verraten, wann und wie viele Requests wieder erlaubt sind. Eine robuste Anwendung wertet diese Header aus, statt blind weiterzufeuern.
Die beste Strategie bei einem 429 ist Exponential Backoff mit Jitter: Nach jedem Fehlschlag wartest du zunehmend länger (1 s, 2 s, 4 s …) plus einen Zufallsanteil, damit nicht alle Clients gleichzeitig erneut anfragen. Wer einfach in einer Schleife sofort wiederholt, verschärft die Drosselung nur.
Praktische Planung
Bevor du eine fremde API in Produktion einbindest, rechne durch, ob dein erwartetes Volumen ins Limit passt. Multipliziere geplante Nutzer mal Aktionen mal Requests pro Aktion und vergleiche mit dem Tageslimit. Plane Puffer ein – Lastspitzen und Wiederholungen kosten zusätzliche Requests.
Wenn du selbst Hintergrundjobs taktest, hilft beim Festlegen sinnvoller Intervalle der Cron Intervall Rechner, und beim Nachschlagen des passenden Statuscodes der HTTP Status Code Spicker. Weitere Entwickler-Tools findest du in der Webtools-Sammlung.
Auf der anderen Seite: Eigene Limits setzen
Betreibst du selbst eine API, sind Rate Limits dein wichtigstes Schutzwerkzeug gegen Überlastung und Scraping. Staffel sie nach Authentifizierungsstatus: anonyme Aufrufer streng, eingeloggte Nutzer großzügiger, zahlende Kunden am großzügigsten. Kommuniziere die Limits in der Dokumentation und über Response-Header, damit Clients sich anständig verhalten können.
Rate Limits sind kein Hindernis, sondern ein Vertrag zwischen Client und Server. Wer sie versteht, baut Integrationen, die zuverlässig laufen, statt sporadisch an der Drosselung zu scheitern – und der Rechner nimmt dir die lästige Einheiten-Umrechnung dabei ab.