429 Too Many Requests in Rest API - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does the HTTP status code 429 mean?

It means "Too Many Requests". The client has sent too many requests in a given amount of time, and the server is limiting the request rate.

beginner

Why do servers use the 429 Too Many Requests response?

Servers use it to protect themselves from overload and to prevent abuse by limiting how often a client can make requests.

intermediate

What header can a server include to tell the client when to retry after a 429 response?

The server can include the "Retry-After" header with a time in seconds or a date to tell the client when it can try again.

intermediate

How can clients avoid receiving a 429 Too Many Requests response?

Clients can avoid it by slowing down their request rate, respecting server limits, and implementing exponential backoff when retrying.

beginner

Give a real-life example of when a 429 Too Many Requests error might occur.

If you refresh a webpage many times very quickly or send many API requests in a short time, the server might respond with 429 to ask you to wait.

What does HTTP status code 429 indicate?

A Internal Server Error

B Unauthorized Access

C Resource Not Found

D Too Many Requests

429 means the client sent too many requests in a short time.

Which HTTP header tells the client when to retry after a 429 response?

A Content-Type

B Retry-After

C Authorization

D Cache-Control

The Retry-After header specifies how long to wait before retrying.

What is a common reason servers send a 429 response?

A To limit request rate and prevent overload

B To indicate a missing resource

C To require user login

D To signal a server crash

429 is used to protect servers by limiting how often clients can request.

How should a client behave after receiving a 429 response?

A Send a different request

B Immediately retry the request

C Wait and retry after the specified time

D Ignore the response and continue

Clients should wait as instructed before retrying to avoid repeated 429 errors.

Which of these is NOT a way to avoid 429 errors?

A Ignoring server limits

B Sending requests slowly

C Implementing exponential backoff

D Respecting Retry-After header

Ignoring server limits causes 429 errors; respecting limits helps avoid them.

Explain what the 429 Too Many Requests status code means and why it is important.

Think about how servers protect themselves from too many requests.

Describe how a client should handle receiving a 429 response from a server.

Consider polite behavior when a server asks you to wait.

Practice

1.

What does the HTTP status code 429 Too Many Requests mean?

easy

A. Your request is missing required authentication credentials.

B. The server could not find the requested resource.

C. You have sent too many requests in a short time and should wait before retrying.

D. The server encountered an unexpected error.

Solution

1. Step 1: Understand HTTP status codes

   HTTP status codes communicate the result of a request. 429 specifically signals rate limiting.

2. Step 2: Interpret 429 meaning

   429 means the client sent too many requests too quickly and must wait before sending more.

3. Final Answer:

   You have sent too many requests in a short time and should wait before retrying. -> Option C

4. Quick Check:

   429 = Too Many Requests [OK]

Hint: 429 means slow down your requests and try again later [OK]

Common Mistakes:

• Confusing 429 with 404 Not Found
• Thinking 429 means authentication error
• Ignoring the need to wait before retrying

2.

Which HTTP header is commonly used by servers to tell clients how long to wait before retrying after a 429 Too Many Requests response?

easy

A. Content-Type

B. Retry-After

C. Authorization

D. User-Agent

Solution

1. Step 1: Identify headers related to retrying

   When a server limits requests, it often tells clients how long to wait using a specific header.

2. Step 2: Match header to purpose

   The Retry-After header indicates the wait time before retrying after 429.

3. Final Answer:

   Retry-After -> Option B

4. Quick Check:

   Retry-After header = wait time [OK]

Hint: Retry-After tells you when to try again after 429 [OK]

Common Mistakes:

• Choosing Content-Type which describes data format
• Confusing Authorization with retry timing
• Selecting User-Agent which identifies client software

3.

Consider this server response to a client request:

{
  "status": 429,
  "headers": {"Retry-After": "10"},
  "body": "Too many requests, please wait."
}

If the client immediately retries the request after 5 seconds, what is the likely result?

medium

A. The server will respond with another 429 status, indicating to wait longer.

B. The server will accept the request and respond normally.

C. The server will respond with a 404 Not Found error.

D. The server will close the connection without response.

Solution

1. Step 1: Analyze Retry-After header value

   The server asks the client to wait 10 seconds before retrying.

2. Step 2: Evaluate client retry timing

   The client retries after only 5 seconds, which is less than 10 seconds.

3. Step 3: Predict server response

   The server will reject the early retry and respond with 429 again.

4. Final Answer:

   The server will respond with another 429 status, indicating to wait longer. -> Option A

5. Quick Check:

   Retry before 10s = 429 again [OK]

Hint: Retry only after Retry-After seconds to avoid repeated 429 [OK]

Common Mistakes:

• Assuming server accepts early retries
• Confusing 429 with 404 errors
• Thinking server silently drops requests

4.

Given this snippet of server-side pseudocode handling API requests:

if request_count > limit:
    return 429, {"Retry-After": "30"}, "Too many requests"
else:
    process_request()

What is a likely bug if clients keep getting 429 responses even after waiting 30 seconds?

medium

A. The server is processing requests without any limit.

B. The Retry-After header is missing from the response.

C. The server is not checking request_count at all.

D. The server does not reset request_count after the wait period.

Solution

1. Step 1: Understand rate limiting logic

   The server limits requests by counting them and returning 429 if over limit.

2. Step 2: Identify why 429 repeats after wait

   If request_count never resets, the server always thinks limit is exceeded.

3. Step 3: Confirm bug cause

   Not resetting request_count after wait causes repeated 429 responses.

4. Final Answer:

   The server does not reset request_count after the wait period. -> Option D

5. Quick Check:

   Persistent 429 means counter not reset [OK]

Hint: Reset request count after wait to avoid repeated 429 [OK]

Common Mistakes:

• Ignoring the need to reset counters
• Assuming Retry-After header alone fixes issue
• Thinking server ignores request limits

5.

You are designing a client application that calls a public API which may respond with 429 Too Many Requests. How should your client handle this to avoid errors and respect the server?

hard

A. Read the Retry-After header and wait that many seconds before retrying.

B. Stop all requests permanently after the first 429 response.

C. Ignore the 429 response and retry immediately until successful.

D. Send multiple requests in parallel to speed up retries.

Solution

1. Step 1: Understand respectful client behavior

   Clients should avoid overwhelming servers by respecting rate limits.

2. Step 2: Use Retry-After header properly

   The server provides Retry-After to tell clients how long to wait before retrying.

3. Step 3: Implement waiting before retry

   Client should pause for the specified time, then retry to avoid repeated 429 errors.

4. Final Answer:

   Read the Retry-After header and wait that many seconds before retrying. -> Option A

5. Quick Check:

   Respect Retry-After to avoid 429 [OK]

Hint: Always wait Retry-After seconds before retrying after 429 [OK]

Common Mistakes:

• Retrying immediately ignoring Retry-After
• Stopping requests forever after one 429
• Sending many parallel requests causing more 429s