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.