Calculateur limite de débit API

Les API publiques et privées publient presque toujours une limite de débit, par exemple cent requêtes par minute ou mille par heure. Les ingénieurs qui doivent envoyer plus de trafic qu'une seule fenêtre n'autorise doivent découper le travail en lots et attendre entre eux pour que le fournisseur ne renvoie pas HTTP 429 ni ne révoque les identifiants. Ce calculateur de budget de limite de débit d'API accepte le maximum de requêtes par fenêtre, le nombre total de requêtes que vous prévoyez d'envoyer et, en option, la durée de la fenêtre en secondes. Les limites de débit non positives échouent avec invalid_input et ne sont pas facturées.

Comment fenêtres, lots et délai vous maintiennent sous la limite

Le calculateur n'appelle pas l'API distante ; il dimensionne seulement votre planning pour que votre propre client puisse dormir entre les lots.

Contrat d'entrée, champs de réponse et règles de validation

Envoyez en POST un corps JSON avec rate_limit, un entier positif de requêtes autorisées par fenêtre ; desired_requests, un entier non négatif d'appels que vous comptez faire ; et optionnellement window_seconds, une longueur finie positive de cette fenêtre en secondes qui vaut soixante par défaut si elle est omise. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique. Les champs manquants, les valeurs non finies, desired_requests fractionnaire, rate_limit fractionnaire et tout rate_limit qui n'est pas strictement positif échouent avec invalid_input et un message qui nomme le champ. En cas de succès le corps renvoie rate_limit, desired_requests et window_seconds, puis windows_needed, batch_size (maximum de requêtes par lot complet, égal à rate_limit tant qu'il reste du travail), last_batch_size (le lot partiel final, ou un lot complet lorsque D divise exactement), full_batches (combien de lots utilisent la taille maximale avant le reste), delay_between_batches_seconds, min_elapsed_seconds, max_requests_per_second comme rate_limit divisé par window_seconds, et une courte chaîne de formule qui reformule la règle du plafond. Exemple : rate_limit cent, desired_requests trois cent cinquante, window_seconds soixante donne quatre fenêtres, lot de cent, dernier lot cinquante, délai soixante secondes et minimum écoulé cent quatre-vingts secondes. Zéro desired_requests renvoie zéro fenêtre et zéro délai sans erreur, ce qui est utile pour les planificateurs en dry-run.

Où un calculateur de budget de limite d'API se justifie

Fournir ce total plus la limite de débit du fournisseur à ce calculateur produit un planning de sommeil que vous pouvez insérer dans une boucle de worker sans tempêtes de 429 par essais successifs. Les chefs de produit qui estiment la durée d'un export massif peuvent convertir un nombre de documents en temps d'horloge avant de promettre au client une fenêtre le jour même. Une validation échouée ne consomme pas de solde. Les scripts d'intégration qui remplissent des webhooks, réindexent des documents de recherche ou migrent des tenants connaissent souvent le total d'éléments avant de démarrer. Les outils d'observabilité et de chaos peuvent affirmer qu'un générateur de charge synthétique ne dépasse jamais max_requests_per_second dérivé de la limite publiée. Gardez la logique de planning dans votre client ; utilisez ce endpoint comme source unique de vérité pour l'arithmétique afin que mobiles, edge workers et jobs CI planifient de la même façon.