Make webhook response module placement and Sume's 10 retries

Put Make's Webhook response module at the end of a Sume receiver scenario, or answer immediately and do the work later, because a response module placed mid-scenario means you do not get error notifications for what runs after it. Sume then sees a 2xx, stops retrying and treats the event as delivered.

Make's webhooks page (read 2026-10-10) lists three default answers: 200 when accepted, 400 when the queue is full, and 429 when the rate limit is hit. Sume's webhook docs say it retries network errors and non-2xx answers until it uses all attempts, so those defaults decide whether a callback is retried.

Default answers and what Sume does with them

Sume's webhook page says to return a 2xx after you store the event. Up to 10 attempts are made in total, with a fixed delay of 30 seconds by default (not exponential backoff) and a 10 second timeout per attempt. The 10 attempts leave nine gaps, so the retry window is about 270 seconds of spacing plus up to 10 seconds for each try.

Make's queue limits matter at that pace. The page says that for every 10,000 credits licensed per month you can have 667 items in each webhook's queue, up to 10,000 items, and that over the limit Make rejects data with a 400 and Queue is full. It also says Make processes up to 300 incoming webhook requests per 10 seconds and returns 429 above that.

Why response module placement matters

The page says that if the Webhook response module sits mid-scenario, before errors occur, you will not get error notifications. For a receiver, that is a trap: Sume gets its 2xx the moment the module runs, and a failure in a later module is never retried by Sume.

A safe layout keeps the response module last, or answers fast and then writes the event to a data store before any slow work. If you must answer early, store job_id and the payload first. Then a failed later step can be replayed from your own record, and Sume's job redeliver (POST /v1/jobs/{job_id}/webhook/redeliver) stays available as a second chance.

• Store the event, then respond, then process.
• Use job_id as the dedupe key in the Make data store.
• Do not rely on Sume retrying after you returned a 200.
• Keep status_url polls as the recovery path.

Sizing a wave against Make's limits

Sume's job webhooks are terminal-only, one per job. A wave of 100 jobs finishing close together would send about 100 events, below Make's 300 per 10 seconds. Two or three waves finishing in the same ten seconds would not be. Then Make answers 429 and Sume retries on its 30 second cadence.

Make also keeps webhook logs for 3 days on standard plans and 30 days on Enterprise, per the same page. Do not treat Make's log as your ledger; keep the job_id and artifact URL in your own table, since Sume's own job read stays the authority for a result.

One more detail: the run webhooks page says Sume does not follow redirects and counts a 3xx as a failed attempt, so publish the exact Make webhook address Make gives you and do not put a shortener or a redirecting proxy in front of it. If you ever pause the scenario, expect missed deliveries and recover through the status poll or a redeliver call.