API-Rate-Limit-Rechner

Wer mehr Verkehr senden muss, als ein einzelnes Fenster zulässt, muss die Arbeit in Batches teilen und dazwischen warten, damit der Anbieter nicht HTTP 429 liefert oder Zugangsdaten widerruft. Dieser API-Rate-Limit-Budgetrechner nimmt die maximalen Anfragen pro Fenster, die geplante Gesamtzahl der Anfragen und optional die Fensterlänge in Sekunden entgegen. Nicht positive Rate-Limits scheitern mit invalid_input und werden nicht berechnet.

Wie Fenster, Batches und Wartezeit Sie unter dem Limit halten

Der Rechner ruft die entfernte API nicht auf; er dimensioniert nur Ihren Zeitplan, damit Ihr eigener Client zwischen Batches schlafen kann.

Eingabevertrag, Antwortfelder und Validierungsregeln

Senden Sie per POST einen JSON-Body mit rate_limit, einer positiven ganzen Zahl erlaubter Anfragen pro Fenster; desired_requests, einer nicht negativen ganzen Zahl geplanter Aufrufe; und optional window_seconds, einer positiven endlichen Länge dieses Fensters in Sekunden, die standardmäßig sechzig beträgt, wenn sie weggelassen wird. Jedes Feld darf als JSON-Zahl oder als numerische Zeichenkette ankommen. Fehlende Felder, nicht endliche Werte, gebrochenes desired_requests, gebrochenes rate_limit und jedes rate_limit, das nicht streng positiv ist, scheitern mit invalid_input und einer Meldung, die das Feld benennt. Bei Erfolg spiegelt der Body rate_limit, desired_requests und window_seconds und liefert windows_needed, batch_size (Maximum an Anfragen pro vollem Batch, gleich rate_limit solange Arbeit übrig ist), last_batch_size (den abschließenden Teil-Batch oder einen vollen Batch, wenn D glatt teilt), full_batches (wie viele Batches die Maximalgröße vor dem Rest nutzen), delay_between_batches_seconds, min_elapsed_seconds, max_requests_per_second als rate_limit geteilt durch window_seconds sowie eine kurze Formelzeichenkette, die die Aufrundungsregel wiederholt. Beispiel: rate_limit hundert, desired_requests dreihundertfünfzig, window_seconds sechzig ergibt vier Fenster, Batch-Größe hundert, letzter Batch fünfzig, Wartezeit sechzig Sekunden und minimale Dauer hundertachtzig Sekunden. Null desired_requests liefert null Fenster und null Wartezeit ohne Fehler, was für Dry-Run-Planer nützlich ist.

Wo ein API-Rate-Limit-Budgetrechner sich lohnt

Produktverantwortliche, die abschätzen, wie lange ein Masseneexport dauert, können eine Dokumentanzahl in Wanduhrzeit umrechnen, bevor sie dem Kunden ein Fenster am selben Tag versprechen. Fehlgeschlagene Validierung wird nicht berechnet. Integrationsskripte, die Webhooks nachfüllen, Suchdokumente neu indexieren oder Mandanten migrieren, kennen oft die Gesamtzahl der Elemente vor dem Start. Diese Zahl plus das Rate-Limit des Anbieters in diesen Rechner zu geben erzeugt einen Sleep-Zeitplan, den Sie in eine Worker-Schleife legen können, ohne 429-Stürme durch Ausprobieren. Observability- und Chaos-Werkzeuge können prüfen, dass ein synthetischer Lastgenerator max_requests_per_second aus dem veröffentlichten Limit nie überschreitet. Weil die Implementierung reines Parse-Tier-A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz. Halten Sie die Zeitplanlogik in Ihrem Client; nutzen Sie diesen Endpoint als einzige Wahrheitsquelle der Arithmetik, damit Mobile, Edge-Worker und CI-Jobs gleich planen.