429 Too Many Requests in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the HTTP status code returned?

You have a REST API that limits clients to 5 requests per minute. If a client sends 6 requests quickly, what HTTP status code will the server return for the 6th request?

A 429 Too Many Requests

B 200 OK

C 500 Internal Server Error

D 403 Forbidden

💡 Hint

Think about what status code means the client sent too many requests in a short time.

The 429 status code means the client has sent too many requests in a given amount of time, triggering rate limiting.

🧠 Conceptual

intermediate

Why use 429 Too Many Requests status code?

Which reason best explains why an API uses the 429 Too Many Requests status code?

A To confirm the request was successful

B To show the server encountered an unexpected error

C To indicate the client is not authorized

D To tell the client to slow down because it exceeded request limits

💡 Hint

Think about what happens when a client sends too many requests too fast.

429 status code tells the client to slow down because it has sent too many requests in a short time.

🔧 Debug

advanced

Identify the cause of unexpected 429 errors

A client reports receiving 429 Too Many Requests errors even though they send only 1 request per minute. What is the most likely cause?

A The client is not authorized to access the API

B The client is sending requests too slowly

C The server's rate limit is set too low or misconfigured

D The server is down and returning 429 by mistake

💡 Hint

Consider server settings that control request limits.

If the server's rate limit is too low or misconfigured, it may block even low-frequency requests with 429 errors.

🚀 Application

advanced

How to handle 429 errors in client code?

You receive a 429 Too Many Requests response from an API. What is the best way for your client application to handle this?

A Wait for the time specified in the Retry-After header before retrying

B Stop sending requests permanently

C Immediately retry the request without delay

D Ignore the error and continue sending requests

💡 Hint

Look for a header that tells you when to try again.

The Retry-After header tells the client how long to wait before retrying after a 429 response.

❓ Predict Output

expert

What is the output of this rate limiting code snippet?

Consider this Python Flask snippet implementing simple rate limiting. What will be the output on the 4th request from the same IP within 10 seconds?

Rest API

from flask import Flask, request, jsonify
import time

app = Flask(__name__)

request_times = {}

@app.route('/api')
def api():
    ip = request.remote_addr
    now = time.time()
    times = request_times.get(ip, [])
    # Remove timestamps older than 10 seconds
    times = [t for t in times if now - t < 10]
    if len(times) >= 3:
        return jsonify({'error': 'Too many requests'}), 429
    times.append(now)
    request_times[ip] = times
    return jsonify({'message': 'Success'})

# Simulate 4 requests from same IP quickly
ip = '192.168.1.1'
for i in range(4):
    request_times[ip] = [time.time() - 1, time.time() - 2, time.time() - 3]
    now = time.time()
    times = request_times.get(ip, [])
    times = [t for t in times if now - t < 10]
    if len(times) >= 3:
        print(429)
    else:
        times.append(now)
        request_times[ip] = times
        print(200)

A

200
200
200
200

B

200
200
200
429

C

429
429
429
429

D

200
429
429
429

💡 Hint

Check how many timestamps are kept and when 429 is returned.

The code allows 3 requests within 10 seconds. The 4th request triggers 429.

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