Aanvraaglimieten en serverfouten afhandelen

Een 429-respons afhandelen

Een aanvraag die de limiet overschrijdt, retourneert 429 Too Many Requests, waarbij detail.status is ingesteld op rate_limit_exceeded. Lees de responsheaders voordat je het opnieuw probeert:

• Retry-After geeft de minimale wachttijd in seconden voor een afgewezen aanvraag.
• X-RateLimit-Limit geeft de limiet van de bucket aan.
• X-RateLimit-Remaining geeft het aantal resterende aanvragen aan.
• X-RateLimit-Reset geeft aan wanneer de bucket wordt gereset.

Wacht de tijd in Retry-After af en probeer het daarna opnieuw met exponentieel oplopende wachttijden en willekeurige spreiding. Beperk gelijktijdige aanvragen en zet werk in een wachtrij in plaats van direct na het resetten een piek aan aanvragen te versturen.

Serverfouten afhandelen

Bij een 500-respons bevat de openbare body een algemene fout en een request_id. Interne details van de uitzondering worden niet teruggegeven. Een 503 kan betekenen dat een vereiste service tijdelijk niet beschikbaar is.

Probeer alleen-lezenaanvragen opnieuw met begrensde wachttijden. Controleer bij een aanvraag die iets maakt, bijwerkt, betaalt of anderszins de toestand wijzigt eerst of de oorspronkelijke poging is voltooid. Een time-out of 5xx-respons bewijst niet dat de wijziging is mislukt. Onmiddellijk opnieuw proberen kan dubbel werk veroorzaken.

Diagnostische gegevens bewaren

Leg het tijdstip, de methode, het pad, de status, de responsbody en X-Request-Id vast. Log nooit de waarde van x-api-key. Stop automatische herhaalpogingen na een klein, vooraf begrensd aantal pogingen en maak de fout zichtbaar voor beoordeling.