Skip to content

How do I set retries without trashing my quota or the source API?

Default retry settings are often 'every minute, 5x'. Too aggressive for some APIs, too weak for others. Exponential backoff plus dead-letter is the robust setup.

Try this first

  1. 1Per error type: 5xx and timeouts are retryable, 4xx (except 429) is not (input error, retry won't help).
  2. 2Set exponential backoff: 30s, 1m, 5m, 30m, then dead-letter. That gives transient outages room without hammering the source API.
  3. 3On 429 (rate limit): respect the Retry-After header, not your own schedule. That is what the source declares safe.
  4. 4After last retry: write the payload to a dead-letter queue (DB table or Make Data Store or n8n table) plus error context. Don't let it disappear.
  5. 5Daily review on DLQ: manually re-submit or permanently reject. A DLQ no one looks at is not a DLQ.

When to bring us in

Need a DLQ that spans multiple flows and tools, we can set up the table and re-process flow.

See also

None of the above fits?

Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.

Who are you?

For the AI question we need your email and company, so we can follow up if the AI gets stuck, and to prevent abuse.

Limited to 2 questions per hour and 5 per day, kept lean so the AI stays useful. For more, contacting us directly works better for you and us.

Or skip the DIY entirely

Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.