Make.com error handling: retry a paid API call without duplicates

Make.com handles a failing module with an error route and one of five error handlers: Skip, Retry, Resume, Commit and Rollback. To retry a failed API call, add the Retry handler and turn on incomplete executions; Make stores the failed bundle and reruns it automatically or when you resolve it. For a paid API, that rerun is safe only if the request carries an idempotency key that stays the same on every attempt.

The Make facts come from Make's Help Center (Overview of error handling, Retry error handler, Types of errors, Exponential backoff). The Sume facts come from Errors and rate limits and Create a run. All were read on 2026-09-29. Sume has no official Make app; the call is Make's HTTP module.

What do Make's five error handlers do?

Right-click the module, choose Add error handler, and pick one. Make says an activated error handler doesn't consume operations. With no handler and incomplete executions off, Rollback is the default.

How do I make Make retry a failed HTTP request?

Make already retries some errors on its own, so set up the handler with those in mind:

• In scenario settings, set Store incomplete executions to Yes. The Retry handler requires it.
• Add the Retry handler to the HTTP module. Set Automatically complete execution to Yes for automatic attempts (Make's example: 3 more times, every 15 minutes), or No to leave the run in the Incomplete Executions tab.
• Know what Make already retries. It outputs a RateLimitError for HTTP 429 and a ConnectionError for 502, 503 and 504, and handles both by default when incomplete executions are on.
• Know the clock. A module waits up to 40 seconds for a response before a ModuleTimeoutError, and Make reruns a scenario after ConnectionError or ModuleTimeoutError with exponential backoff.

Can a retry start a second paid job?

Yes, if the key changes. A timeout or a lost response doesn't mean the API refused the request; the job may already exist. Sume's docs say not to retry unsafe submits without an Idempotency-Key. For a Format run create, the docs list what each replay does:

• Same key, same body: 200 with the original and idempotency_hit: true. No second run, no second charge.
• Same key, different body: 409 idempotency_conflict, and nothing runs. Map nothing into the body that changes between attempts, such as the current time.
• Same key, two requests at once: 409 idempotency_key_in_use, which is retryable.
• Build the key from the bundle, for example an order id and a version, never from a random value. Sume's docs call a per-request uuidgen decorative.

POST https://api.sume.com/v1/formats/acme/product-promo/runs
Authorization: Bearer $SUME_API_KEY
Content-Type: application/json
Idempotency-Key: order-123-video-v1

Which API errors should I retry?

Retry what can succeed later; route the rest to a notification or Skip. For Sume's codes:

• 429 rate_limited: retry after the retry-after seconds; Make treats a 429 as a RateLimitError.
• 429 queue_full: the workspace's paid queue is full until an earlier job finishes or is canceled. 503 provider_capacity_exceeded: Sume's provider dispatch queue is full.
• On a job submit, current code replays the stored refusal for those two when you retry with the same key, and Make's default handling can rerun them with the same body. Let them fail to a notification, then resubmit with a new key once the cause clears.
• On a Format run create, the docs say a failed create (402, 503) releases the key, so the same key works once you fix the cause.
• 400 invalid_request, 402 insufficient_credits, 409 idempotency_conflict: a rerun fails the same way. Fix the input or the balance first.

Should the scenario wait for the job to finish?

No. The create answers at once with an id; the result comes later. Make ends a run that lasts over 45 minutes (10 on the Free plan) with an ExecutionInterruptedError. Catch the finished job in a second scenario on a webhook, as Make.com AI video scenario with Sume shows.