Dokumente
Strg+K Suchen Alt+[Alt+] Hilfslinien
API-Schlüssel abrufen

Anleitungen

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:

  1. Bei jeder Anfrage zählt der Server, wie viele deiner Anfragen in den letzten 60 Sekunden eingegangen sind.
  2. Wenn dieser Wert bereits ≥ 60 ist, wird die Anfrage mit 429.
  3. 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 Kredits 429. Die werden sich nicht innerhalb einer Minute erholen.
  • Versuche, die Obergrenze zu erreichen. Sechs Wiederholungsversuche mit baseMs=1000 Das 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ür Schleife ohne erwarten Die 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 / 404 als 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 /Impressum um eine Geschwindigkeitsbegrenzung zu erkennen. Dieser Endpunkt wird auf das Ratenlimit angerechnet (und kostet ein Guthaben). Sehen Sie sich die tatsächlichen 429 stattdessen.