Rate Limits

Standard-Limits

Beide Fenster werden bei jeder Anfrage ausgewertet. Das engere Fenster (60/Minute) steuert kurze Bursts; das Stundenfenster steuert die anhaltende Last. Wenn eines der Fenster überschritten wird, wird die Anfrage mit 429 Too Many Requests abgelehnt — Sie müssen nicht prüfen, welches Fenster ausgelöst hat, nur den Retry-After-Header berücksichtigen.

Antwort bei Ablehnung

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Window: per_minute
X-RateLimit-Limit: 60

{ "error": "rate_limited" }

Retry-After ist immer eine ganzzahlige Anzahl von Sekunden — die kleinste sichere Verzögerung, bevor die nächste Anfrage erfolgreich ist. X-RateLimit-Limit spiegelt die Obergrenze für das ausgelöste Fenster wider.

Gleitende vs. feste Fenster

Das Pro-Minute-Fenster ist auf die Kalenderminute (UTC) festgelegt. Eine Anfrage bei 13:42:59 und eine bei 13:43:01 fallen in verschiedene Buckets. Das Pro-Stunde-Fenster ist ein echtes gleitendes Aggregat über die letzten 60 Minuten. Das bedeutet, dass Sie während der normalen Nutzung niemals die stündliche Obergrenze auslösen, es sei denn, Sie lösen wiederholt die Minutenobergrenze aus.

Empfohlenes Client-Verhalten

• Bei 429 schlafen Sie für mindestens Retry-After Sekunden und wiederholen Sie einmal.
• Verwenden Sie Jitter: retryAfter + random(0, 5) Sekunden, um Thundering Herd zu vermeiden, wenn viele Worker das Limit zusammen erreichen.
• Wenn Sie die Batch-Größe kontrollieren, führen Sie nicht mehr als 50 Anfragen/Minute pro Schlüssel aus — hält Sie sicher unter der Obergrenze.
• Für Hochvolumen-Jobs (Datenexport, Massenbenutzerbereitstellung) stellen Sie einen Schlüssel pro Worker aus, anstatt einen einzigen Schlüssel zu teilen.
• Behandeln Sie 429 nicht als Fehler, auf den Sie alarmieren. Alarmieren Sie nur bei wiederholten Fehlern nach exponentiellem Backoff.

Wiederholungsmuster

Ein minimales Node-Beispiel, das Retry-After mit Jitter respektiert:

async function call(path) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch(`https://api.limeplate.com${path}`, {
      headers: { Authorization: `Bearer ${process.env.SCH_API_KEY}` },
    });
    if (res.status !== 429) return res;
    const wait = parseInt(res.headers.get('Retry-After') || '60', 10);
    const jitter = Math.floor(Math.random() * 5);
    await new Promise(r => setTimeout(r, (wait + jitter) * 1000));
  }
  throw new Error('exhausted retries on 429');
}

Ein höheres Kontingent anfordern

Die meisten Integrationen sitzen komfortabel innerhalb der Standard-Limits. Wenn Ihre Arbeitslast wirklich eine höhere Obergrenze benötigt — zum Beispiel ein nächtliches Looker-Refresh, das Fortschritt für 10.000 Benutzer zieht — schreiben Sie an support@securecodinghub.com mit dem API-Schlüssel-Namen, dem Integrationszweck und den Spitzen-Anfragen/Minute, die Sie erwarten. Wir können die Pro-Schlüssel-Limits anheben, ohne das Token zu rotieren.

Was nicht rate-limited ist

Eingehende Webhook-Zustellungen, die Sie von SecureCodingHub akzeptieren, sind von unserer Seite nicht rate-limited. Ausgehende Webhook-Zustellungen, die wir an Ihren Endpoint senden, folgen einem separaten Wiederholungsplan, der unter Webhooks dokumentiert ist.