Sending many requests at once
Your account can have a number of requests in progress at the same time. This page explains what happens when you send more than that, what the 429 response looks like, and how to batch and retry so a large run of invoices goes through without a single failure.
429 was not processed and not billed. Wait the number of seconds in the Retry-After header and send the very same request again.
What happens above the allowance
The number of concurrent requests included in your plan is the number of requests your account can have in progress at the same moment; the current figures are on the pricing page. Requests you send on top of that are not turned away at once. Each one is held for up to a minute until one of your running requests finishes, and is then processed as usual. In a typical run this means every request succeeds; the later ones simply take a little longer.
A request receives 429 in two cases only: when far more requests arrive at the same time than could be handled within that minute, or when a held request could not start within the minute. Either way the request was not processed, and the response tells you when to send it again.
The 429 response
The body is the same error envelope as every other error, with errorCode 4019. The Retry-After header carries the wait in seconds.
HTTP/1.1 429 Too Many Requests Content-Type: application/problem+json Retry-After: 12
{
"title": "Too many requests",
"status": 429,
"errorCode": 4019,
"detail": "Too many requests for this API key are being processed at the moment. Retry after the number of seconds given in the Retry-After header.",
"instance": "/v1/embed/zugferd",
"traceId": "00-2af282af9b150f7fdfceafecd24946f2-671255c289628b1a-00"
}
The value of Retry-After varies a little from response to response on purpose, so that the requests of one run do not all come back in the same second. Always read it rather than assuming a fixed wait.
Send in batches
The simplest way to never see a 429: keep as many requests in flight as your plan allows, and send the next invoice as soon as one response arrives. Your run then finishes as fast as it can without ever exceeding the allowance.
JavaScript
const inFlight = 10; // the concurrent requests of your plan
async function sendAll(invoices) {
const queue = [...invoices];
const workers = Array.from({ length: inFlight }, async () => {
while (queue.length) {
const invoice = queue.shift();
await sendToApi(invoice);
}
});
await Promise.all(workers);
}
C#
await Parallel.ForEachAsync(invoices,
new ParallelOptions { MaxDegreeOfParallelism = 10 },
async (invoice, cancellationToken) => await SendToApiAsync(invoice, cancellationToken));
Python
import asyncio
in_flight = asyncio.Semaphore(10)
async def send(invoice):
async with in_flight:
return await send_to_api(invoice)
await asyncio.gather(*(send(invoice) for invoice in invoices))
n8n, Zapier and Make
| Platform | What to set |
|---|---|
| n8n | The HTTP Request node sends every item of a run at the same time. Open its Options, add Batching and set Items per Batch to the concurrent requests of your plan. Add Retry On Fail on the node's Settings tab with a wait of at least 10 seconds between tries, so an occasional 429 is resent automatically. |
| Zapier | Nothing to set. Zapier recognises a 429 with Retry-After, pauses the step and replays it on its own. |
| Make | Add an error handler to the HTTP module with a Break directive, so a bundle that gets a 429 is stored and retried later instead of stopping the scenario. Keep the scenario's parallel processing within your plan's allowance. |
Retry on 429
Batching avoids almost every 429, but a retry makes your integration complete: wait for Retry-After, resend the same request, and give up after a handful of attempts. Because a rejected request was never processed, resending it can never produce a duplicate.
async function sendWithRetry(request, attempts = 4) {
for (let attempt = 1; ; attempt++) {
const response = await fetch(apiUrl, request);
if (response.status !== 429 || attempt === attempts) return response;
const seconds = Number(response.headers.get('Retry-After')) || 10;
await new Promise(resolve => setTimeout(resolve, seconds * 1000));
}
}
Branch on errorCode 4019 if your error handling is shared with other failures; it is the only code that comes with a 429 status.
Client timeouts
Because a request above the allowance can be held for up to a minute before it is processed, a request in a large run can take about a minute longer than one sent on its own. Set your HTTP client's timeout to at least 120 seconds for calls to the API. On platforms with a fixed shorter timeout, keep the run inside your allowance with batching, so no request has to wait.