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”.