Als je te vaak een verzoek doet naar een server binnen een korte tijd, kan je ineens geconfronteerd worden met een 429 Too Many Requests melding. Je verzoek was op zich geldig, maar de server vindt dat je er (tijdelijk) te veel van doet.
Deze 429 status code is bedoeld om misbruik of overbelasting te voorkomen. Denk aan brute-force pogingen, API-clients zonder throttle of gewoon een script dat iets te enthousiast loops draait. De foutmelding geeft aan dat je moet wachten, of vertragen, voordat je weer verder mag.
Wat zegt de server met een 429?
De foutmelding http error 429 is onderdeel van de HTTP/1.1 specificatie en geeft aan dat de gebruiker te veel verzoeken heeft verzonden in een bepaald tijdsvenster. In de meeste gevallen komt er ook een Retry-After header mee in de response. Daarmee laat de server weten hoe lang je moet wachten voordat je opnieuw mag proberen.
Een typische response kan er zo uitzien:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
En in de body:
{
“error”: “Too many requests”,
“message”: “Please wait 60 seconds before trying again.”
}
Deze status kan worden gegenereerd door reverse proxies, firewalls, load balancers, of de applicatie zelf. Het doel is altijd hetzelfde: de boel even afremmen.
Wanneer kom je een 429 error tegen?
De http 429 foutmelding zie je vooral bij:
- API’s met rate limiting
- Inlogformulieren met brute-force bescherming
- Crawlers of bots zonder vertraging
- Frontend apps die automatisch polls uitvoeren zonder interval
Bijvoorbeeld: je gebruikt een API met een limiet van 100 requests per minuut, en je stuurt er 120. Dan krijg je de 429 error terug. Soms krijg je hem bij de 101e aanvraag, soms net wat eerder, afhankelijk van hoe het limiet wordt gemeten.
Als je een crawler als Screaming Frog of Ahrefs te agressief instelt, kan een server je tijdelijk blokkeren met een 429. De oplossing is dan simpel: throttle je snelheid, of stel een crawl delay in.
Hoe los je een 429 statuscode op?
Er zijn een paar manieren om hiermee om te gaan:
- Wachten: check of er een Retry-After header is en respecteer die.
- Vertragen: pas je requestfrequentie aan. Voeg delays of exponential backoff toe.
- Caching: voorkom onnodige herhaalde verzoeken door resultaten lokaal op te slaan.
- Authenticatie: sommige API’s geven hogere limieten aan geauthenticeerde gebruikers.
- Contact opnemen: als je denkt dat de limiet te laag is voor jouw toepassing, vraag de provider of je limiet omhoog kan.
Als je binnen je eigen applicatie een 429 genereert, zorg dan dat je foutmeldingen duidelijk zijn voor eindgebruikers. En geef altijd mee hoelang ze moeten wachten.
Wat je moet onthouden
De 429 Too Many Requests melding is geen fout in de klassieke zin. Het is een manier van de server om je netjes te vragen om het rustiger aan te doen. Je verzoek is geldig, maar het moment waarop je het doet is ongunstig, of te vaak herhaald.
Of je nu werkt aan een frontend die veel API-calls doet, of een backend die duizenden records moet wegschrijven, het is goed om deze limieten te respecteren. Ze zijn er niet om je tegen te werken, maar om systemen gezond te houden.
En als je 429’s ziet in logbestanden of monitoringtools, is dat een teken om even pas op de plaats te maken, en je verkeer te analyseren voordat je verdergaat.
