HTTP 429 — Too Many Requests
HTTP 429 is the rate limiter’s verdict: too many requests in the window. A Retry-After header — seconds or a date — says when the client may return, and respecting it is the difference between a blip and a ban.
When 429 shows up
- Public APIs enforcing per-key or per-IP request budgets.
- Backoff tests where clients must prove they honour Retry-After.
Mocking a 429 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/search",
"status": 429,
"delay": 100,
"enabled": true,
"body": {
"error": "rate_limited",
"retryAfter": 30
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 429 mean?
The client exceeded its request allowance. Wait for the interval in Retry-After, then resume — ideally with exponential backoff.
How can I test a 429 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 429. The example configuration above returns this response after the listed delay, so the client exercises its 429 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.