I’ve written a test script that involves making many GET requests to a 3rd party endpoint. However, I am being rate limited, and because of this, the monitor that is supposed to run some other calls ends abruptly. I’ve tried adding recursive logic to continue to call the GET endpoint until the rate limit subsides, but Postman automatically stops making calls the first time it receives a 429.
My question is, is there a way to change the success criteria to allow my script to continue to hit the endpoint until the rate limit subsides, or is there a better, smarter way to approach this?
Can you please try and see if something like below works?
pm.test("Status code is 429 or OK", function () {
if (pm.response.code === 429) {
console.log('Received 429 - ignore and go to the next request')
return true
} else {
return pm.response.to.have.status(200);
}
});
Just to add to @taehoshino’s suggestion above (which will definitely accomplish what you’re asking, in terms of swallowing the 429 status code) but there are certain things to bear in mind when it comes to API rate limits, which will vary according to the 3rd party site which you are trying to access.
#1: Depending on how the rate limit is implemented (e.g. is it X requests per calendar hour, or X requests per rolling hour), and whether they count a rate-limited request as a “valid” request attempt, if you’re repeatedly making requests when you’re already rate-limited then it may not “reset the clock” on your rate limit. Hardcoded delays within scripts are generally a bad idea, but if you’re restricted to e.g. 600 requests per hour, it’s worth making sure that your script isn’t capable of firing in a request more than once every 6 seconds - thereby ensuring that you don’t hit the rate limit in the first place. (Or, potentially, adding a delay into the ‘Received 429’ section of the script above, to give the limit some time to disperse.)
#2: When an API creator implements a rate limit, it tends to serve two purposes: firstly, to help the business to segregate customers between their different plans (free or tiered) and ensure that their higher-tiered companies get preferential terms of service; but secondly, it’s done as a courtesy to the customer. If you’re seen as somebody who is repeatedly generating “rate limit exceeded” messages on their system, there’s a danger that they may have some sort of business process - perhaps even a fully-automated one - which could automatically block your IP range, for instance to prevent security/DDoS attacks. So again, as per point #1, I’d advise an approach which doesn’t rely on generating rate limit errors as part of your “happy path”.
