Retry-After
header to your 429 response, or specify a timed delay in your error response using a special ThrottledError
. Instead of a user’s Zap erroring and halting, the request will be retried at the specified time.
More on the retry here. The user will see a Waiting/Scheduled message in Zap history instead of an error while the limit is still in place.
ThrottledError
, you could consider implementing a jitter for handling 429 errors, that could look something like this to randomize the frequency of the retries as well:
throw new z.errors.ThrottledError('message here', 60 + Math.floor(Math.random() * 60))
Keep in mind that adding custom error handling with ThrottledError
would likely require a new integration version, whereas adding to the headers could be implemented on your API’s end.