Rate limiting voor publieke API's die misbruik stopt zonder echte gebruikers te blokkeren: praktische limieten, per-key quota's, lockouts en uitroltips.
Rate limiting voor publieke API's is niet bedoeld om gebruikers te straffen. Het is een veiligheidsklep die je service beschikbaar houdt wanneer verkeer vreemd wordt — of dat vreemde nu kwaadwillig is of gewoon een fout in een client.
"Misbruik" ziet er vaak eerst normaal uit: een scraper die elke endpoint afloopt om data te kopiëren, brute-force inlogpogingen, token-stuffing tegen auth-routes, of een client die na een timeout in een strakke retry-loop terechtkomt. Soms valt er helemaal niets kwaadachtends te zien: een mobiele app-update komt met een slechte caching-regel en ineens pollt elk toestel je API elke seconde.
De taak is eenvoudig: bescherm uptime en controleer kosten zonder echte gebruikers te blokkeren die normaal werk doen. Als je backend gemeten wordt (compute, database, e-mail/SMS, AI-calls), kan één luidruchtige actor snel voor een hoge rekening zorgen.
Rate limiting alleen is ook niet genoeg. Zonder monitoring en duidelijke foutantwoorden krijg je stille falingen, verwarde klanten en supporttickets die zeggen "jullie API is down" terwijl het in werkelijkheid throttling is.
Een compleet vangnet heeft meestal een paar gescheiden onderdelen:
Als je een API-backend bouwt op een platform zoals AppMaster, blijven deze regels belangrijk. Zelfs met nette, gegenereerde code wil je beschermende defaults zodat één slechte client je hele service niet neerhaalt.
Deze termen lopen door elkaar, maar ze lossen verschillende problemen op en voelen anders voor gebruikers.
Een rate limit is een snelheidslimiet: hoeveel verzoeken een client kan maken in een korte periode (per seconde, per minuut). Een quota is een budget: totaalgebruik over een langere periode (per dag, per maand). Een concurrency limit begrenst hoeveel verzoeken gelijktijdig in behandeling mogen zijn, wat nuttig is voor zware endpoints, zelfs als de request rate normaal lijkt.
Waar je de limiet aan hangt, maakt uit:
Soft throttling vertraagt de client (vertragingen, minder burst-capaciteit) zodat die kan herstellen zonder workflows te breken. Hard blocking wijst verzoeken direct af, meestal met HTTP 429.
Een lockout is sterker dan een normale 429. Een 429 zegt: "probeer het straks opnieuw." Een lockout zegt: "stop totdat aan een voorwaarde is voldaan," zoals een cooldownperiode, een handmatige beoordeling of een sleutel-reset. Reserveer lockouts voor duidelijke misbruiksignalen (credential stuffing, agressief scrapen, herhaalde ongeldige auth), niet voor normale verkeerspieken.
Als je een API bouwt met een tool als AppMaster, behandel deze controles als gescheiden instellingen: korte-window limits voor bursts, langere quota's voor kosten, en lockouts alleen voor herhaald slecht gedrag.
Goede limieten starten met één doel: bescherm de backend terwijl normale gebruikers hun werk kunnen afmaken. Je hoeft op dag één geen perfecte cijfers te hebben. Je hebt een veilige basislijn nodig en een manier om die aan te passen.
Een eenvoudig uitgangspunt is een per-API-sleutel limiet die past bij het soort API dat je runt:
Splits dan limieten per type endpoint. Reads zijn meestal goedkoper en kunnen hogere limieten hebben. Writes veranderen data, triggeren vaak extra logica en verdienen strakkere caps. Een veelgebruikt patroon is bijvoorbeeld 1.000/min voor GET-routes maar 100–300/min voor POST/PUT/DELETE.
Identificeer ook dure endpoints en behandel die apart. Search, rapportagegeneratie, exports, bestandsuploads en alles wat meerdere tabellen raakt of zware businesslogica uitvoert, zou een kleinere bucket moeten hebben, zelfs als de rest van de API ruimhartig is. Als je backend visuele workflows gebruikt (bijvoorbeeld Business Process-flows), telt elke extra stap mee en vermenigvuldigt het werk zich onder load.
Plan voor bursts met twee vensters: een kort venster om snelle pieken op te vangen, plus een langer venster dat duurzaam gebruik in toom houdt. Een veelvoorkomend duo is 10 seconden plus 10 minuten. Dat helpt echte gebruikers die snel klikken, zonder scrapers onbeperkte snelheid te geven.
Bepaal tenslotte wat er gebeurt als de client de limiet overschrijdt. De meeste publieke API's geven HTTP 429 met een duidelijke retry-tijd. Als het werk veilig is om te vertragen (zoals een export), overweeg dan om het te queuen in plaats van hard te blokkeren zodat echte gebruikers alsnog resultaten krijgen.
Per-key quota's zijn meestal de eerlijkste aanpak omdat ze overeenkomen met hoe klanten je service gebruiken: één account, één API-sleutel, duidelijke verantwoordelijkheid. IP-gebaseerde limieten blijven nuttig, maar straffen vaak onschuldigen.
Gedeelde IP's zijn de grote reden. Een heel kantoor kan via één publiek IP naar buiten gaan, en mobiele carriers plaatsen duizenden apparaten achter een kleine pool van IP's. Als je vertrouwt op per-IP caps, kan één luidruchtige gebruiker iedereen vertragen. Een per-key quota voorkomt dat, en je kunt een lichte per-IP limiet als backstop houden voor duidelijke floods.
Om quota's eerlijk te laten aanvoelen, koppel ze aan klantlagen zonder nieuwe gebruikers vast te zetten. Een gratis of trial-sleutel moet echt testen mogelijk maken, maar niet op schaal die jou schaadt. Een simpel patroon is genereuze bursts, een bescheiden duurzaam tarief en een dagelijkse limiet die bij het plan past.
Een per-key beleid dat voorspelbaar blijft:
Om key-sharing en geautomatiseerde aanmeldingen te ontmoedigen, heb je geen zware surveillance nodig. Begin met simpele controles zoals ongewone geografiewijzigingen, te veel verschillende IP's per uur voor één sleutel, of veel nieuwe sleutels die vanaf dezelfde bron worden aangemaakt. Flag en vertraag eerst; lock alleen na herhaalde signalen.
Anoniem verkeer is waar strengere caps zinvol zijn. Als je trial-sleutels aanbiedt, rate-limit die dan strak en vereis een basisverificatiestap voordat je limieten verhoogt. Als je API een openbaar formulier aandrijft, overweeg dan een aparte anonieme endpoint met een eigen quota zodat de rest van je backend beschermd blijft.
Als je je API bouwt met een platform zoals AppMaster, is per-key logica makkelijker consistent te houden omdat auth, businessregels en response handling op één plek leven.
Rate limiting werkt op de lange termijn alleen als clients kunnen begrijpen wat er gebeurde en wat ze daarna moeten doen. Streef naar antwoorden die saai maar voorspelbaar zijn: dezelfde statuscode, dezelfde velden, dezelfde betekenis over endpoints heen.
Als een client een limiet raakt, geef HTTP 429 (Too Many Requests) met een duidelijke boodschap en een concreet wachttijd. De snelste winst is het toevoegen van Retry-After, omdat zelfs simpele clients dan correct kunnen pauzeren.
Een klein setje headers maakt limieten zelfverklarend. Houd namen consistent en voeg ze toe aan zowel succesvolle responses (zodat clients zichzelf kunnen temperen) als aan 429-responses (zodat clients kunnen herstellen):
Retry-After: seconden om te wachten vóór retryX-RateLimit-Limit: huidige toegestane verzoeken per windowX-RateLimit-Remaining: resterende verzoeken in het huidige windowX-RateLimit-Reset: wanneer het window reset (epoch seconds of ISO time)X-RateLimit-Policy: korte tekst zoals "60 requests per 60s"Maak de foutbody net zo gestructureerd als je succesresponses. Eén veelgebruikt patroon is een error-object met een stabiele code, een mensvriendelijk message en herstelhint.
{
\"error\": {
\"code\": \"rate_limit_exceeded\",
\"message\": \"Too many requests. Please retry after 12 seconds.\",
\"retry_after_seconds\": 12,
\"limit\": 60,
\"remaining\": 0,
\"reset_at\": \"2026-01-25T12:34:56Z\"
}
}
Vertel clients hoe ze moeten backoffen wanneer ze 429s zien. Exponentiële backoff is een goede default: wacht 1s, dan 2s, dan 4s, en begrens het (bijvoorbeeld op 30–60 seconden). Wees ook expliciet over wanneer te stoppen met retryen.
Vermijd verrassingen vlak bij quota's. Wanneer een sleutel dicht bij een cap zit (zeg 80–90% gebruikt), voeg dan een waarschuwingsveld of header toe zodat clients kunnen temperen voordat ze gaan falen. Dit is extra belangrijk wanneer één script meerdere routes snel kan raken en budget sneller opbrandt dan verwacht.
Een uitrol werkt het beste wanneer je limieten als productgedrag behandelt, niet als een eenmalige firewallregel. Het doel blijft hetzelfde: bescherm de backend terwijl normale klanten kunnen doorwerken.
Begin met een snelle inventarisatie. Maak een lijst van elke endpoint en markeer ze op kost (CPU, databasewerk, third-party calls) en risico (login, password reset, search, file upload). Zo voorkom je dat je één brute limiet overal toepast.
Een uitrolvolgorde die meestal verrassingen voorkomt:
Houd de eerste release conservatief. Het is gemakkelijker later soepeler te maken dan boze gebruikers te deblokkeren.
Monitor en tune, en versioneer je policy. Houd bij hoeveel verzoeken limieten raken, welke endpoints dat triggeren en hoeveel unieke sleutels betroffen zijn. Wanneer je cijfers aanpast, behandel het als een API-verandering: documenteer het, rol het geleidelijk uit en houd oude en nieuwe regels gescheiden zodat je snel kunt terugdraaien.
Als je je API met AppMaster bouwt, plan deze regels tegelijk met je endpoints en businesslogica zodat limieten overeenkomen met de echte kosten van elke workflow.
Lockouts zijn de veiligheidsgordel. Ze moeten duidelijk misbruik snel stoppen, maar echte gebruikers een helder pad geven om te herstellen wanneer er iets misgaat.
Een kalme aanpak is progressieve straffen. Ga ervan uit dat de client mogelijk misgeconfigureerd is, niet per se kwaadaardig, en escaleer alleen als hetzelfde patroon zich herhaalt.
Gebruik een klein aantal stappen die makkelijk uit te leggen en te implementeren zijn:
Het kiezen wat je lockt, is belangrijk. Per API-sleutel is meestal het eerlijkst omdat het de caller target, niet iedereen achter een gedeeld netwerk. Per account helpt wanneer gebruikers sleutels roteren. Per IP kan helpen bij anoniem verkeer, maar veroorzaakt vals positieven bij NATs, kantoren en mobiele carriers. Bij ernstig misbruik combineer signalen (bijv. lock de sleutel en eis extra checks voor dat IP), maar houd de blast radius klein.
Maak lockouts tijdgebaseerd met eenvoudige regels: "geblokkeerd tot 14:05 UTC" en "herstelt na 30 minuten goed gedrag." Vermijd permanente bans voor geautomatiseerde systemen. Een buggy client kan loopend veel limiet opbranden, dus ontwerp straffen die in de tijd afnemen: een periode met laag, consistent verkeer moet het strafniveau verlagen.
Als je je API in AppMaster bouwt, past deze ladder goed bij opgeslagen counters plus een Business Process die beslist toestaan, vertragen of blokkeren en de unlock-tijd voor de sleutel wegschrijft.
Voor terugkerende overtreders houd een handmatig reviewpad. Ruziën met gebruikers helpt niet. Vraag om request IDs, timestamps en de API-sleutelnaam, en beslis op basis van bewijs.
Vals positieven ontstaan wanneer je verdediging normale gebruikers blokkeert. Ze gebeuren meestal doordat regels te simpel zijn voor hoe mensen je API echt gebruiken.
Een klassieke fout is één globale limiet voor alles. Als je een goedkope read-endpoint en een dure export hetzelfde behandelt, overbescherm je de goedkope (irritant) of onderbescherm je de dure (gevaarlijk). Splits limieten per endpointkost en maak zware paden strikter.
IP-only limiting is een andere valstrik. Veel echte gebruikers delen één publiek IP (kantoren, scholen, mobiele carriers). Eén zware gebruiker kan iedereen blokkeren en het lijkt op willekeurige outages. Geef de voorkeur aan per-API-sleutel limieten eerst, en gebruik IP als secundair signaal voor duidelijk misbruik.
Fouten in de limiter zelf kunnen ook vals positieven veroorzaken. Als je limiter-store down is, kan "fail closed" je hele API neerhalen. "Fail open" kan een spike uitnodigen die je backend alsnog neerhaalt. Kies een duidelijk fallback: houd een kleine noodcap aan de edge en degradeer graceful op niet-kritische endpoints.
Clientafhandeling is belangrijker dan veel teams verwachten. Als je een generieke 429 terugstuurt zonder duidelijke boodschap, proberen gebruikers harder en triggeren ze meer blokken. Stuur altijd Retry-After, en houd de fouttekst specifiek ("Te veel verzoeken voor deze sleutel. Probeer het over 30 seconden opnieuw.").
Het meest vermijdbare probleem is geheimzinnigheid. Verborgen limieten lijken op bugs als klanten voor het eerst onder productiebelasting komen. Deel een simpele policy en houd die stabiel.
Snel checklist om vals positieven te vermijden:
Retry-AfterAls je je API met een tool als AppMaster bouwt, betekent dit vaak het instellen van verschillende caps per endpoint en het teruggeven van consistente foutpayloads zodat clients kunnen backoffen zonder te gokken.
Rate limiting werkt alleen als je ziet wat er gebeurt in realtime. Het doel is niet om elke piek te vangen, maar om patronen te signaleren die tot outages of boze gebruikers leiden.
Begin met een klein aantal signalen die zowel volume als intent uitleggen:
Om "slecht verkeer" te scheiden van "we hebben iets uitgerold", voeg context toe aan dashboards: deploy-tijd, feature-flag veranderingen, marketing-sends. Als verkeer stijgt direct na een release en de 429/5xx-mix gezond blijft, is het meestal groei, geen misbruik. Als de piek geconcentreerd is op één sleutel, één IP-range of één zwaar endpoint, behandel het als verdacht.
Alerts moeten saai zijn. Gebruik drempels plus cooldowns zodat je niet elke minuut gepaged wordt voor hetzelfde event:
Als een alert afgaat, houd een kort incidentnotitie bij: wat veranderde, wat je zag (top sleutels/endpoints) en wat je hebt aangepast (limieten, caches, tijdelijke blocks). Na verloop van tijd worden die notities je echte playbook.
Voorbeeld: je lanceert een nieuwe search-endpoint en verkeer verdubbelt. Als de meeste calls die endpoint raken over veel sleutels, verhoog dan de per-key quota iets en optimaliseer het endpoint. Als één sleutel nonstop exports raakt en de latency omhoog trekt, cap dat endpoint apart en neem contact op met de eigenaar.
Een goede setup is saai wanneer hij werkt. Deze checklist vangt issues die vaak vals positieven veroorzaken of duidelijke gaten laten.
Voer deze checks uit in staging en direct na launch:
Als je op AppMaster bouwt, behandel elk nieuw API-endpoint als een kost-tier beslissing: een simpele lookup mag genereus zijn, alles wat zware businesslogica triggert moet strikter starten.
Bescherm de backend en laat echte gebruikers herstellen:
Voordat je limieten voor een klant verhoogt, controleer hun normale requestpatroon, endpointmix en of ze kunnen batchen of backoffen. Bevestig ook dat ze geen sleutel delen tussen veel apps.
Maandelijks: review top gelimiteerde endpoints, percentage verkeer dat limieten raakt, nieuwe high-cost routes en of je quota's nog aansluiten op echt gebruik.
Stel: je runt een publieke API die door twee apps wordt gebruikt: een customer portal (hoog volume, constant verkeer) en een interne admin-tool (laag volume, maar krachtige acties). Beide gebruiken API-sleutels, en de portal heeft ook een login-endpoint voor eindgebruikers.
Op een middag brengt een partner een buggy integratie uit. Die begint failed requests in een strakke loop te retryen en stuurt 200 verzoeken per seconde vanaf één API-sleutel. Zonder vangrails kan die ene sleutel iedereen wegdrukken.
Per-key limieten beperken de blast radius. De buggy sleutel raakt zijn per-minute cap, krijgt een 429 en de rest van je klanten blijft werken. Je kunt ook een aparte, lagere limiet op dure endpoints hebben (zoals exports) zodat zelfs "toegestaan" verkeer de database niet overbelast.
Tegelijkertijd start een brute-force poging op de auth-endpoint. In plaats van het hele IP-bereik te blokkeren (wat echte gebruikers achter NAT kan raken), vertraag je het eerst en lock je later op basis van gedrag: te veel mislukte pogingen per account plus per IP in een korte window. De aanvaller krijgt progressief langere wachttijden en daarna een tijdelijke lock.
Een echte klant die een paar keer het wachtwoord verkeerd intoetst, kan herstellen omdat je responses duidelijk en voorspelbaar zijn:
Retry-After zodat de client weet wanneer te proberenOm de fix te bevestigen houd je een paar metrics in de gaten:
Dit is hoe beschermende rate limiting eruitziet wanneer het je backend shields zonder normale gebruikers te straffen.
Je hebt geen perfect model nodig op dag één. Begin met een klein, helder beleid en verbeter het terwijl je leert hoe echte gebruikers zich gedragen.
Een degelijke eerste versie heeft meestal drie onderdelen:
Voeg lockouts alleen toe waar het misbruiksrisico hoog is en intentie makkelijk te concluderen valt. Signup, login, password reset en tokencreatie zijn typische kandidaten. Houd lockouts in het begin kort (minuten, geen dagen) en geef de voorkeur aan progressieve friction: eerst vertragen, dan tijdelijk blokkeren, vervolgens een sterkere check.
Schrijf het beleid op in duidelijke taal zodat support het kan uitleggen zonder engineeringhulp. Vermeld wat beperkt wordt (per API-sleutel, per IP, per account), het reset-venster en hoe een klant kan herstellen.
Als je dit implementeert terwijl je een nieuwe backend bouwt, kan AppMaster praktisch zijn: je maakt API's, definieert businessworkflows (inclusief counters en lockout-beslissingen) visueel en deployt naar cloudproviders of exporteert de gegenereerde source code wanneer je volledige controle nodig hebt.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
