API Rate Limit Planner
Met de API Rate Limit Planner bereken je hoeveel API-requests je kunt versturen binnen de limieten van een API. Vul de rate limit in (requests per seconde of minuut), de burst-limiet en de gewenste gebruiksduur, en zie direct hoeveel requests je per dag, week of maand kunt maken. Onmisbaar voor developers die werken met externe API's zoals Stripe, Google Maps, Twitter of andere services met rate limiting. Voorkom HTTP 429 fouten en plan je API-integratie optimaal.
API Rate Limit Planner
Hoe werkt de berekening?
- Reken de rate limit om naar requests per seconde (RPS).
- Deel de RPS door het aantal clients voor de per-client limiet.
- Bereken het interval: 1000 / RPS per client = milliseconden tussen requests.
- Vermenigvuldig RPS met het aantal actieve seconden voor dagelijkse totalen.
- Bereken de burst hersteltijd: burst limit / RPS.
- Pas een veiligheidsmarge van 80% toe om throttling te voorkomen.
Voorbeeldberekening
Je gebruikt een API met een limiet van 100 requests per minuut, een burst van 20, en je hebt 3 workers die de API aanroepen.
- Rate limit: 100/minuut = 1,667 requests per seconde
- Per worker: 1,667 / 3 = 0,556 requests per seconde
- Interval per worker: 1000 / 0,556 = 1.800 ms (1,8 seconden)
- Per uur: 1,667 × 3600 = 6.000 requests
- Per dag (24 uur): 6.000 × 24 = 144.000 requests
- Burst hersteltijd: 20 / 1,667 = 12 seconden
- Veilige limiet (80%): 115.200 requests per dag
Resultaat:
Met 3 workers en een limiet van 100/minuut kun je maximaal 144.000 requests per dag maken. Elke worker moet minimaal 1,8 seconden wachten tussen requests.
Resultaat interpreteren
Het interval per client geeft aan hoe lang elke worker minimaal moet wachten tussen requests om binnen de limiet te blijven. De burst hersteltijd toont hoe lang het duurt voordat de volledige burst-capaciteit weer beschikbaar is na een burst. De veilige limiet (80%) biedt een buffer voor onverwachte pieken en vertraagde responses. Plan altijd met deze marge om HTTP 429 (Too Many Requests) fouten te voorkomen.
Tips
Implementeer exponential backoff: bij een 429-fout wacht je steeds langer (1s, 2s, 4s, 8s) voordat je opnieuw probeert.
Gebruik een request queue met een rate limiter library om gelijkmatig verdeelde requests te garanderen.
Cache API-responses lokaal om onnodige herhaalde requests te voorkomen.
Monitor je API-gebruik via headers als X-RateLimit-Remaining en X-RateLimit-Reset.
Plan batch-operaties tijdens daluren als de API een dagelijkse limiet heeft.
Overweeg een hogere API-tier als je regelmatig tegen limieten aanloopt.
Veelgemaakte fouten
Rate limits per API-key delen over meerdere servers zonder het totaal bij te houden.
Geen rekening houden met retry-requests die meetellen voor de rate limit.
Burst-limiet uitputten aan het begin van een periode, waardoor er daarna gewacht moet worden.
Aannemen dat rate limits per endpoint gelden terwijl ze vaak per API-key gelden.
Geen exponential backoff implementeren bij 429-fouten, waardoor je nog sneller geblokkeerd wordt.
Vergeten dat sommige API's onderscheid maken tussen lees- en schrijf-limieten.
Veelgestelde vragen
Een rate limit is een beperking op het aantal API-verzoeken dat je binnen een bepaalde tijdsperiode mag maken. Het beschermt de API-server tegen overbelasting en zorgt voor eerlijk gebruik door alle clients. Overschrijding resulteert meestal in een HTTP 429 (Too Many Requests) foutcode.
De rate limit is het gemiddelde aantal requests dat je per tijdseenheid mag maken. De burst limit is het maximum aantal requests dat je in een zeer korte piek tegelijk mag versturen. Na een burst moet je wachten tot de "emmer" (token bucket) weer is aangevuld met het reguliere tempo van de rate limit.
HTTP 429 Too Many Requests betekent dat je de rate limit van de API hebt overschreden. De server weigert tijdelijk je verzoeken. Check de Retry-After header voor informatie over wanneer je weer requests mag sturen. Implementeer altijd error handling voor deze statuscode.
Een token bucket wordt gevuld met tokens in een vast tempo (bijv. 10 per seconde). Elke request verbruikt een token. Als de bucket leeg is, worden requests geweigerd. De maximale capaciteit van de bucket is de burst limit. Dit systeem staat korte pieken toe terwijl het gemiddelde gebruik beperkt blijft.
Bij de meeste API's tellen alle requests mee, ongeacht of ze succesvol zijn. Zelfs fouten (4xx, 5xx) verbruiken een token. Dit maakt het extra belangrijk om fouten in je requests te minimaliseren en niet blindelings te retrien, omdat retries ook meetellen.
Gebruik een rate limiter library voor je programmeertaal (bijv. Bottleneck voor Node.js, ratelimit voor Python). Sla het laatste request-tijdstip op, bereken het benodigde interval en wacht indien nodig. Lees de X-RateLimit headers uit API-responses om dynamisch bij te sturen. Implementeer een queue voor meerdere workers.
Over deze berekening
Auteur
Mastercalc Redactie
Financieel en technisch redactieteam
Laatst bijgewerkt
2026-08-24
Aannames bij deze berekening:
- De berekening gaat uit van een gelijkmatige verdeling van requests over de actieve uren.
- De burst limit wordt als token bucket model berekend (tokens worden continu aangevuld).
- Alle clients/workers delen dezelfde rate limit (per API-key).
- Er wordt geen rekening gehouden met netwerklatentie of serverresponstijd.
- De veiligheidsmarge van 80% is een aanbeveling; sommige API's vereisen een grotere marge.
Deze calculator geeft een theoretische schatting van je API-budget. Werkelijke limieten worden bepaald door de API-provider en kunnen variëren per endpoint, plan of gebruiker. Raadpleeg altijd de officiële API-documentatie voor de exacte rate limits en implementeer robuuste foutafhandeling.