A 429 means "too many requests." The API is telling you to slow down, so it returns 429 instead of your data. This shows up the moment a workflow fans out. You trigger on 500 records, the workflow fires a request per record, and 500 requests reach the API at once. Under a per-second limit, most of those come back as 429 and the run fails partway through. Many APIs send a Retry-After header that says how many seconds to wait before the next try, and some also send headers for the limit, the remaining count, and the reset time.

The built-in options I know of

I want to compare how people actually hold requests under the limit, so here is a starting point from n8n's own docs.

• Batching in the HTTP Request node. Add Option, then Batching, then set Items per Batch and a Batch Interval in milliseconds to pace the requests. For an API that allows one request per second, a batch interval of 1000 ms keeps you at that rate (per n8n docs).
• Retry On Fail on the node. It tries again after a failure, and if you use it for rate limits, n8n's docs say to set Wait Between Tries above the limit window so the retry does not hit the same wall (per n8n docs).

Both are on-platform. The gap I run into is that a fixed retry delay ignores the Retry-After value the API already sent, so you either wait longer than needed or not long enough.

Do you pace requests up front with batching and delays, retry after the failure, or do both? Does anyone read the Retry-After header and wait exactly that long, and if so, how do you pull it from the response? .