Rate-Limit-Header auswerten und Rücksetzzeit berechnen
Ein Limit von 100 mit 42 verbleibenden Anfragen und ein Rücksetzwert von 60 um 12:00 UTC bedeuten: Ab 12:01, also in 60 Sekunden, geht es weiter. Fügen Sie die drei Werte und den Empfangszeitpunkt ein, um einen sicheren neuen Versuch zu planen. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Grenzwert
- 100
- Verbleibend
- 42
- Zurücksetzung
- 60
- Aktuelle Zeit
- 2026-07-25T12:00:00Z
- Grenzwert
- 100
- Verbleibend
- 42
- Art der Zurücksetzung
- seconds_offset
- Zurücksetzung (Unix-Zeit)
- 1.784.980.860
Rate-Limit-Header wirken einfach, bis verschiedene Dienste den Rücksetzzeitpunkt unterschiedlich angeben. Dieser Parser übernimmt Limit, Restkontingent, Rücksetzwert und eine ausdrücklich angegebene aktuelle Zeit. Er liefert normalisierte Zahlen sowie volle Sekunden bis zur erneuten Verfügbarkeit von Anfragen. Er erkennt Unix-Zeitstempel in Sekunden oder Millisekunden, strikte UTC-Zeitangaben nach ISO 8601 und kurze numerische Zeitabstände.
Wie der Rücksetzwert gelesen wird
Rate-Limit-Header liefern meist drei Zahlen: das erlaubte Maximum, die noch verbleibenden Anfragen und den Zeitpunkt, an dem das Kontingent zurückkommt. Jeder Dienst schreibt diesen letzten Wert anders. Kleine Zahlen wie 30 oder 900 gelten als Sekunden, die zur angegebenen Uhrzeit addiert werden. Ab einer Milliarde wird der Wert als Unix-Sekunden gelesen, ab hundert Milliarden als Unix-Millisekunden und in Sekunden umgerechnet. Auch ein UTC-Zeitpunkt mit Z am Ende wird akzeptiert. Bei einem Limit von 100, 42 verbleibenden Anfragen und einem Rücksetzwert von 60 um 12:00 UTC kehrt das Kontingent um 12:01 zurück, also in 60 Sekunden.
Typische Fehler und wie Sie das Ergebnis nutzen
Der teuerste Fehler ist, einen unlesbaren Wert als null zu behandeln: Das Programm versucht es sofort erneut, verschärft die Drosselung und verlängert den Ausfall. Hier führt ein unlesbarer Wert zu einem klaren Fehler. Abgelehnt werden auch negative Zahlen, unmögliche Daten und mehr verbleibende Anfragen als das Limit. Die Wartezeit wird auf ganze Sekunden aufgerundet, damit Sie nicht im letzten Sekundenbruchteil erneut senden, und ein bereits vergangener Rücksetzzeitpunkt ergibt null. Danach entscheidet Ihr Programm, ob es wartet, die Arbeit in eine Warteschlange stellt, die Parallelität senkt oder eine Meldung zeigt.
Normalisieren Sie Header vor der Wiederholungsplanung
APIs nennen häufig eine maximale Anfragezahl, das Restkontingent und einen Rücksetzwert. Der Client muss diese Zeichenfolgen jedoch noch in eine sichere Entscheidung umwandeln. Liegt die Rücksetzung in der Vergangenheit, beträgt die Wartezeit null statt eines negativen Werts.
Das Ergebnis eignet sich für Protokolle, Retry-Middleware, Warteschlangenverzögerungen und Testdaten, ohne diese Regeln in jeder Integration neu umzusetzen.
Unterscheiden Sie Zeitstempel und Zeitabstände
Numerische reset-Werte folgen verbreiteten Konventionen. Werte ab einer Milliarde gelten als Unix-Sekunden; ab hundert Milliarden werden sie als Unix-Millisekunden gelesen und umgerechnet. Dadurch sind 30 oder 900 Wartezeiten, während heutige Epoch-Zeitstempel absolut bleiben. reset akzeptiert außerdem strikte UTC-Angaben wie 2026-07-25T12:01:00Z nach ISO 8601, optional mit Millisekunden.
Die Prüfung erkennt unmögliche Daten, ungültige Uhrzeiten, fehlende Werte, negative Zahlen und fremden Text. Ein unlesbarer reset löst einen Eingabefehler aus und wird nicht unbemerkt zu null, denn eine versehentliche sofortige Wiederholung kann die Drosselung verschärfen und einen Ausfall verlängern.
Anwendungsfälle
Sichere Wiederholung planen
Wandeln Sie Header-Zeichenfolgen in eine ganzzahlige Verzögerung um, bevor Arbeit erneut eingereiht wird.
Anbieterdrosselung untersuchen
Normalisieren Sie erfasste Header und vergleichen Sie die Rücksetzung mit dem genauen Antwortzeitpunkt.
Deterministische Retry-Tests erstellen
Geben Sie eine feste Zeit vor und prüfen Sie stabile Berechnungen ohne simulierte Systemuhr.
Häufige Fragen
Welche Rücksetzformate werden unterstützt?
Verwenden Sie nicht negative Sekundenabstände, Unix-Zeitstempel in Sekunden oder Millisekunden oder strikte UTC-Angaben nach ISO 8601 mit Z.
Sendet das Tool eine Anfrage oder wartet es?
Nein. Es prüft und normalisiert nur Ihre Werte; Wiederholungs- und Backoff-Entscheidungen bleiben Aufgabe Ihrer Anwendung.
Was passiert, wenn der Rücksetzzeitpunkt schon vorbei ist?
Die Wartezeit ist dann null, nie negativ. Das hilft bei archivierten Protokollen oder verspätet eingetroffenen Benachrichtigungen, denn das Ergebnis zeigt, dass ein neuer Versuch bereits möglich ist, ohne eine Wartezeit zu erfinden.
Warum muss ich die aktuelle Zeit angeben?
Damit keine Systemuhr die Antwort verändert: Gleiche Eingaben ergeben immer dasselbe Ergebnis. Nutzen Sie den Zeitpunkt, an dem die Antwort eintraf, in Unix-Sekunden, Unix-Millisekunden oder als UTC-Datum; er wird nie als Versatz gedeutet.
Was, wenn mehr Anfragen verbleiben, als das Limit erlaubt?
Die Eingabe wird abgelehnt. Limit und verbleibende Anfragen müssen ganze Zahlen ab null sein, und der Rest darf das Limit nicht übersteigen. Auch ein unlesbarer Rücksetzwert ergibt einen Fehler statt null, damit nicht sofort erneut gesendet wird.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/security/rate-limit-header-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/security/rate-limit-header-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/rate-limit-header-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/rate-limit-header-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/rate-limit-header-parse", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.rate_limit_header_parse",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Da Sie die aktuelle Zeit vorgeben, führt dieselbe Eingabe in Tests, Browsern und API-Integrationen stets zum selben Ergebnis.
Normalisieren Sie Header vor der Wiederholungsplanung
Übergeben Sie die Werte als limit, remaining und reset und tragen Sie in current_time den Empfangszeitpunkt ein. Der Parser prüft, ob limit und remaining nicht negative Ganzzahlen sind, und weist ein Restkontingent oberhalb des Limits zurück. Er bewahrt den ursprünglichen reset-Text, nennt die Interpretation als absoluten Zeitstempel oder Sekundenabstand und erzeugt eine normalisierte Unix-Zeit. seconds_until_reset wird auf volle Sekunden aufgerundet, damit Sie nicht im letzten Sekundenbruchteil erneut anfragen.
Unterscheiden Sie Zeitstempel und Zeitabstände
Kleinere nicht negative Zahlen werden als Abstand zu current_time addiert. Das UTC-Suffix verhindert Zeitzonenannahmen. current_time unterstützt dieselben absoluten Formate, wird aber nie als Abstand behandelt.
Nutzen Sie deterministische Ergebnisse in Clients und Tests
Eine Wiederholungsrichtlinie sollte Auswertung und Entscheidung trennen. Ein Abstand von 60 bei genau zwölf Uhr ergibt stets einen eine Minute späteren Zeitstempel und sechzig verbleibende Sekunden. Es verarbeitet bereits extrahierte Standardwerte. Ermitteln Sie mit dieser Funktion die Kontingentdaten und lassen Sie Ihre Anwendung anschließend warten, Aufgaben einreihen, Parallelität senken oder einen Hinweis anzeigen. current_time wird bewusst vorgegeben: Systemuhr, Netzwerk, Gebietsschema und Zufall können die Antwort nicht verändern. Frühere Rücksetzungen ergeben null, was bei verspäteten Webhooks oder archivierten Protokollen hilft. Das Tool errät keine anbieterspezifischen Header und bestimmt kein exponentielles Backoff. Die Browserversion ist kostenlos; automatisierte API-Aufrufe kosten den angezeigten Grundpreis von $0.002 je Element.
Technische Fragen
Was kostet ein API-Aufruf?
Jedes Element nutzt den angegebenen Grundpreis von $0.002; das Browsertool führt dieselbe Berechnung lokal aus.
Warum muss ich current_time angeben?
Eine ausdrückliche Zeit macht die Berechnung deterministisch und in Clients sowie Tests reproduzierbar.
Was geschieht bei einer vergangenen Rücksetzung?
seconds_until_reset wird auf null begrenzt, während reset_at_unix den ausgewerteten absoluten Zeitpunkt behält.