Make webhook 429 at 300 requests per 10 seconds and Sume retries

If a Make custom webhook returns 429 to Sume, that is Make's documented limit: more than 300 incoming webhook requests in a 10-second interval. Sume treats the 429 like any non-2xx answer and retries the same job event, so one short burst usually clears on its own. A loop that you write to replay events can keep the limit tripped, so pace it.

What Make documents

The numbers below come from Make's own webhook page. The page does not state a payload size cap or a request timeout, so this post makes no claim about either.

What Sume does with a 429

A Sume generation job that you start with mode: "webhook" and a public HTTPS webhook_url sends one signed POST per terminal event (job.completed, job.failed, job.canceled). Success is any 2xx. Network errors and non-2xx answers are retried, up to 10 attempts in total, with a fixed delay (30 s by default) and a 10 s timeout per attempt.

The arithmetic: 10 attempts have 9 gaps of 30 s, so Sume keeps trying for about 4.5 minutes after the first failure. A burst that Make clears inside that window costs you nothing. Use job_id as your idempotency key, because a retried delivery carries the same job.

When you really hit 300 in 10 seconds

Sume starts paid jobs according to your plan's concurrency, so finished jobs normally reach your URL spread over time. The realistic ways to hit the limit are your own code and fan-in:

• A script that calls Redeliver for hundreds of old jobs in a tight loop.
• Several Sume workspaces or several scenario branches that all post to one Make webhook URL.
• A test harness that sends signed bursts to the same URL as production.

Pace a replay

Redeliver (POST /v1/jobs/{job_id}/webhook/redeliver, key scope jobs:write) re-sends the real terminal event with a fresh timestamp and signature. It does not use one of the automatic 10 attempts, so it is the right tool after Sume has given up. One request per second is far below Make's limit:

#!/usr/bin/env bash
set -euo pipefail
: "${SUME_API_KEY:?set SUME_API_KEY}"
while read -r job_id; do
  curl -fsS -X POST "https://api.sume.com/v1/jobs/${job_id}/webhook/redeliver" \
    -H "Authorization: Bearer ${SUME_API_KEY}" > /dev/null
  sleep 1
done < job_ids.txt

Limits and when not to bother

If a scenario receives a few events an hour, ignore all of this. Do not rely on webhook delivery as your only record: after 10 refused attempts you have a failed delivery but a job that still finished, and the result stays readable from GET /v1/jobs/{id}/result. Keep the status_url poll as a backup, and read the delivery state on the job (webhook_delivery) when you need to know which events never arrived.