Rate limit testing in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the expected HTTP status code after exceeding the rate limit?

You send 101 requests in 1 minute to an API with a rate limit of 100 requests per minute. What HTTP status code should you expect on the 101st request?

A 403 Forbidden

B 200 OK

C 500 Internal Server Error

D 429 Too Many Requests

💡 Hint

Think about the standard HTTP response for rate limiting.

The HTTP status code 429 indicates the client has sent too many requests in a given amount of time, which matches the rate limit scenario.

❓ assertion

intermediate

Which Postman test script correctly asserts the rate limit reset header?

You want to verify that the response header X-RateLimit-Reset exists and is a valid UNIX timestamp in your Postman test script. Which option is correct?

A pm.test('Rate limit reset header exists', () => { pm.response.to.have.header('X-RateLimit-Reset'); const reset = parseInt(pm.response.headers.get('X-RateLimit-Reset')); pm.expect(reset).to.be.a('number'); });

B pm.test('Rate limit reset header exists', () => { pm.response.to.have.header('X-RateLimit-Reset'); const reset = pm.response.headers.get('X-RateLimit-Reset'); pm.expect(reset).to.be.a('string'); });

C pm.test('Rate limit reset header exists', () => { pm.response.to.have.header('X-RateLimit-Reset'); const reset = pm.response.headers.get('X-RateLimit-Reset'); pm.expect(reset).to.be.above(0); });

D pm.test('Rate limit reset header exists', () => { pm.response.to.have.header('X-RateLimit-Reset'); const reset = pm.response.headers.get('X-RateLimit-Reset'); pm.expect(reset).to.equal('number'); });

💡 Hint

Check that the header exists and is parsed as a number.

Option A correctly checks the header exists, parses it as an integer, and asserts it is a number type.

🔧 Debug

advanced

Why does this Postman test script fail to detect rate limit exceeded?

Given this Postman test script:

pm.test('Detect rate limit exceeded', () => {
  pm.expect(pm.response.code).to.equal(429);
  pm.expect(pm.response.json().message).to.equal('Rate limit exceeded');
});

But the test always fails even when the API returns 429 with message 'Rate limit exceeded'. What is the likely cause?

A The test script syntax is invalid and causes a runtime error.

B The response body is empty or not JSON, so pm.response.json() throws an error.

C The status code 429 is not the correct code for rate limiting.

D The message string is case sensitive and should be 'rate limit exceeded'.

💡 Hint

Consider what happens if pm.response.json() is called on a non-JSON response.

If the response body is empty or not JSON, pm.response.json() throws an error causing the test to fail even if status code is 429.

🧠 Conceptual

advanced

What is the main purpose of rate limit testing in API QA?

Choose the best description of why rate limit testing is important in API quality assurance.

A To verify the API can handle unlimited requests without failure.

B To check if the API returns correct data formats under heavy load.

C To ensure the API enforces usage limits to protect resources and maintain performance.

D To test the API's authentication mechanisms under multiple requests.

💡 Hint

Think about why APIs limit the number of requests per user.

Rate limit testing ensures the API enforces limits to prevent overload and protect backend resources.

❓ framework

expert

Which Postman collection runner setting helps simulate rate limit testing effectively?

You want to simulate sending 150 requests quickly to test rate limiting in Postman. Which collection runner setting is best to achieve this?

A Set delay between requests to 0 ms and run all iterations immediately.

B Set delay between requests to 1000 ms to avoid hitting rate limits.

C Run requests sequentially with a delay of 5000 ms to simulate user behavior.

D Use the 'Save responses' option to store all responses for later analysis.

💡 Hint

To test rate limits, you want to send requests as fast as possible.

Setting delay to 0 ms sends requests rapidly to trigger rate limits effectively.

Practice

1. What is the main purpose of rate limit testing in Postman?

easy

A. To validate user input forms

B. To verify the UI layout of the application

C. To test database connection speed

D. To check if the system blocks too many requests in a short time

Solution

1. Step 1: Understand rate limit testing goal

   Rate limit testing checks if the system prevents too many requests sent quickly.

2. Step 2: Match purpose with options

   Only To check if the system blocks too many requests in a short time describes blocking too many requests, which is the goal of rate limit testing.

3. Final Answer:

   To check if the system blocks too many requests in a short time -> Option D

4. Quick Check:

   Rate limit testing = block too many requests [OK]

Hint: Rate limit testing checks request blocking speed [OK]

Common Mistakes:

• Confusing rate limit testing with UI or database testing
• Thinking it tests input validation
• Ignoring the request frequency aspect

2. Which Postman feature helps simulate multiple rapid requests for rate limit testing?

easy

A. Collection Runner

B. Monitor Scheduler

C. Environment Variables

D. Pre-request Script Editor

Solution

1. Step 1: Identify features for sending multiple requests

   Collection Runner allows running a set of requests repeatedly and quickly.

2. Step 2: Compare with other options

   Monitor Scheduler runs tests on schedule, Environment Variables store data, Pre-request Script Editor runs scripts before requests. Only Collection Runner sends many requests fast.

3. Final Answer:

   Collection Runner -> Option A

4. Quick Check:

   Multiple rapid requests = Collection Runner [OK]

Hint: Use Collection Runner to send many requests fast [OK]

Common Mistakes:

• Choosing Monitor Scheduler which runs slower
• Confusing environment variables with request sending
• Thinking pre-request scripts send requests

3. In Postman, you send 10 requests quickly to an API with a rate limit of 5 requests per minute. What status code do you expect for the 6th request?

medium

A. 200 OK

B. 429 Too Many Requests

C. 404 Not Found

D. 500 Internal Server Error

Solution

1. Step 1: Understand API rate limit behavior

   The API allows only 5 requests per minute; requests beyond that get blocked.

2. Step 2: Identify expected status code for blocked requests

   HTTP status 429 means "Too Many Requests", used when rate limit is exceeded.

3. Final Answer:

   429 Too Many Requests -> Option B

4. Quick Check:

   Exceeded requests = 429 status [OK]

Hint: 429 means rate limit exceeded [OK]

Common Mistakes:

• Expecting 200 OK for all requests
• Confusing 404 with rate limit errors
• Thinking server error 500 means rate limit

4. You wrote a Postman test script to check for status 429 after rapid requests but it always passes even when the server returns 200. What is the likely error?

medium

A. Checking 'pm.response.code' but comparing with string '429' instead of number 429

B. Using 'pm.response.status' but comparing with number 429 instead of string '429 Too Many Requests'

C. Not sending enough requests to exceed the rate limit

D. Using 'pm.response.code' instead of 'pm.response.status'

Solution

1. Step 1: Understand Postman response code type

   pm.response.code returns a number, so comparisons must be with numbers, not strings.

2. Step 2: Identify comparison mistake

   Comparing pm.response.code (number) with string '429' always fails, so test passes incorrectly.

3. Final Answer:

   Checking 'pm.response.code' but comparing with string '429' instead of number 429 -> Option A

4. Quick Check:

   Compare status code as number, not string [OK]

Hint: Compare status codes as numbers, not strings [OK]

Common Mistakes:

• Comparing number with string in assertions
• Not sending enough requests to trigger rate limit
• Confusing pm.response.code and pm.response.status

5. You want to test an API's rate limit of 10 requests per minute using Postman. Which approach best ensures you detect the limit accurately?

hard

A. Send 10 requests slowly over 2 minutes and check for status 429

B. Send 5 requests spaced 10 seconds apart and check for status 200

C. Send 20 requests rapidly using Collection Runner and check for status 429 after 10th request

D. Send 1 request and check if status is 429

Solution

1. Step 1: Understand rate limit testing requirements

   To detect rate limit, send more requests than allowed quickly to trigger limit.

2. Step 2: Evaluate options for detecting limit

   Send 20 requests rapidly using Collection Runner and check for status 429 after 10th request sends 20 rapid requests exceeding 10 limit, so status 429 should appear after 10th request. Others send fewer or slower requests, unlikely to trigger limit.

3. Final Answer:

   Send 20 requests rapidly using Collection Runner and check for status 429 after 10th request -> Option C

4. Quick Check:

   Exceed limit quickly to detect 429 [OK]

Hint: Send more than limit requests fast to catch 429 [OK]

Common Mistakes:

• Sending requests too slowly to trigger limit
• Sending fewer requests than limit
• Checking wrong status codes