Ratenbegrenzungen
Die programmatische API wendet zusätzlich zur monatlichen Gutschriftquote eine einfache Ratenbegrenzung pro Konto an. Auf dieser Seite werden die Begrenzung, ihre Ermittlung und die ordnungsgemäße Rücknahme erläutert.
Die
| Einstellung | Wert |
|---|---|
| Fenster | Gleitender 60-Sekunden-Durchschnitt |
| Maximale Anzahl von Anfragen | 60 pro Abrechnungskonto (gleitendes Zeitfenster) |
| gezählt | Aktuell erfolgreich Anrufe nach Verbrauch, 429sund 500s nachdem die Authentifizierung/Planung erfolgreich war (gleitendes Zeitfenster auf dem Server). 401 / 403 werden bei dieser Obergrenze nicht berücksichtigt. |
| Quelle | Standardwert: 60 Anfragen pro Minute und Konto. |
Konkret bedeutet dies: durchschnittlich eine Anfrage pro Sekunde, wobei innerhalb eines Zeitfensters von 60 Sekunden bis zu 60 Anfragen zulässig sind.
Wenn du das Limit überschreitest, gibt die nächste Anfrage Folgendes zurück:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
{
"success": false,
"error": "Rate limit exceeded. Max 60 requests per minute."
}
Die Anfrage 429 selbst wird protokolliert, was in Ordnung ist – sie fällt wie jede andere Anfrage aus dem 60-Sekunden-Fenster heraus.
So funktioniert das Fenster
Der Limiter ist ein gleitendes Fenster, kein fester Bereich:
- Bei jeder Anfrage zählt der Server, wie viele deiner Anfragen in den letzten 60 Sekunden eingegangen sind.
- Wenn dieser Wert bereits ≥ 60 ist, wird die Anfrage mit
429. - Ansonsten wird der Vorgang fortgesetzt, protokolliert und fließt in zukünftige Fenster ein.
Also eine Abfolge von 60 Anfragen bei t=0 klart auf bei t=60, nicht zu Beginn der nächsten Minute. Es gibt keine Wiederholungsversuch Kopfzeile – Warte etwa 1 Sekunde und versuche es erneut oder gehe wie unten beschrieben vor.
Backoff
Eine pragmatische Schleife:
async function withRetry(fn, { maxAttempts = 6, baseMs = 1000 } = {}) {
for (let attempt = 1; ; attempt++) {
try {
return await fn();
} catch (err) {
const isRateLimited =
/Rate limit exceeded/.test(err.message);
const isUpstream5xx =
/Upstream error/.test(err.message);
if (!isRateLimited && !isUpstream5xx) throw err;
if (attempt >= maxAttempts) throw err;
const delay = baseMs * Math.pow(2, attempt - 1) + Math.random() * 250;
await new Promise((r) => setTimeout(r, delay));
}
}
}
Anmerkungen:
- Verwende exponentielles Backoff mit Jitter. Eine Wohnung
setTimeout(1000)bei jedem erneuten Versuch zu einer Kollision mit sich selbst führen, wenn du parallel arbeitest. - Nicht erneut versuchen
403,404,401oder die Erschöpfung des Kredits429. Die werden sich nicht innerhalb einer Minute erholen. - Versuche, die Obergrenze zu erreichen. Sechs Wiederholungsversuche mit
baseMs=1000Das deckt bereits eine Wartezeit von etwa einer Minute ab – wenn du danach immer noch einer Ratenbegrenzung unterliegst, liegst du bei über 60 Anfragen pro Minute und benötigst weniger gleichzeitig aktive Worker, nicht mehr Wiederholungsversuche.
Entwerfen unter bestimmten
| Arbeitsbelastung | Parallelität für mehr Sicherheit |
|---|---|
| Schnellskripte / einmalige Nachträge | 1 Mitarbeiter, keine besondere Arbeitsrhythmusregelung. Du wirst die Quote schon lange vor Erreichen der Obergrenze erfüllen. |
| Stetiger ETL | 1 Worker, ~1 Sekunde Pause zwischen den Anfragen. Vorhersehbar, keine Spitzenlasten. |
| Crawler mit hoher Burst-Rate | 2–4 Worker mit einem Token-Bucket, der auf insgesamt 60/min für alle Worker ausgelegt ist. Zentralisieren Sie den Bucket. |
| Live-Dashboards / Abrufe pro Benutzer | Caching am Netzwerkrand; niemals mehr als 60 Anfragen pro Minute und Benutzer an den Upstream-Server weiterleiten. |
Das Limit gilt pro Benutzer, nicht pro IP-Adresse oder pro Schlüssel – die Erstellung mehrerer Schlüssel erhöht es nicht.
Ratenlimit vs.
| Sorge | Grenzwert | Zurücksetzen |
|---|---|---|
| Salve | 60 / 60er-Jahre-Stil | Fortlaufend |
| Umfang | 20.000 pro Kalendermonat | Erste gebührenpflichtige Anfrage im neuen Monat (Server Y-m) |
In der Praxis stoßen anhaltende Rechenlasten schon lange vor Erreichen des Ratenlimits an die Kreditquote. Das Ratenlimit dient in erster Linie dazu, außer Kontrolle geratene Schleifen zu stoppen.
Ermittlung der Ursache eines 429
Sowohl das Minutenlimit als auch das monatliche Guthabenlimit geben einen 429 Statuscode. Sie können sie anhand des Antworttextes unterscheiden:
if (res.status === 429) {
const body = await res.json();
if (body && body.credits) {
// Monthly credit limit reached.
// Do not retry until next month or you upgrade your plan.
} else {
// Per-minute rate limit reached.
// Implement a backoff strategy and retry.
}
}
Die vollständige Übersicht über die Statuscodes finden Sie unter „Fehler “.
Häufige
- Enge Schleifen ohne Schlaf. A
fürSchleife ohneerwartenDie Wartezeit zwischen den Anfragen verbraucht innerhalb von Millisekunden 60 Aufrufe und führt zu einem Stillstand. - Parallelisierung ohne gemeinsamen Begrenzer. Zwei Worker, die jeweils 40 pro Minute verarbeiten, lösen die Begrenzung aus, obwohl jeder einzelne „sicher“ erscheint.
- Erneuter Versuch
403/404als wären es Ratenbegrenzungen. Das bedeutet „Zugriff verweigert“ oder „falscher Pfad“; ohne eine Änderung der Anfrage oder des Kontos werden sie keinen Erfolg haben. - Umfrage
/Impressumum eine Geschwindigkeitsbegrenzung zu erkennen. Dieser Endpunkt wird auf das Ratenlimit angerechnet (und kostet ein Guthaben). Sehen Sie sich die tatsächlichen429stattdessen.