Sume run webhook behind a redirect: a 3xx counts as a failed attempt

Sume does not follow redirects when it delivers a run webhook, so an endpoint that answers 301 or 302 is a failed attempt, not a delivery. Register the final public HTTPS URL, with the hostname that actually serves the request. Sume also re-validates the URL at delivery time, not only when you submit the run.

From Run webhooks, read on 2026-10-03.

What counts as a delivery

Success is any 2xx. Anything else, including a 3xx, is a failed attempt and is retried. The docs give up to 10 attempts in total, then the delivery status becomes exhausted, with a 10 second timeout per attempt and a backoff that grows from 30 seconds and caps at one hour. Honour Retry-After on 429 and 503.

Common ways to end up behind a redirect

A bare hostname that redirects to the www form, an http address that upgrades to https, and a trailing-slash rule on a framework route are typical. Each looks fine in a browser, which follows redirects. Test with a client that does not follow them and check that you get a 2xx directly.

Send test, on the webhooks page of the dashboard, fires a dummy webhook.test payload, so it is a cheap way to check an endpoint before a real run. It is not a replay of a real run; use Redeliver on a delivery row for that.

The run is unaffected

A delivery outcome never changes the run itself. An endpoint that refuses all ten attempts leaves a failed delivery and a run that is still completed; fetch it from result_url. So a redirect problem costs you the push notification, not the result or the money.

Return 2xx quickly after durably recording the event, and dedupe on request_id, which is the same on every retry of one run. Remember that canceled and skipped runs send no webhook at all.

Reading a failed delivery

Each run's receipt carries a webhook_delivery block with a status. An exhausted status means all ten attempts have been used. If the status shows failure, check the endpoint first for a redirect, then for a slow handler that exceeds the 10 second timeout, and test it with a client that does not follow redirects.

After fixing the endpoint, use Redeliver on the delivery row. The docs say it re-sends the current terminal receipt with a fresh timestamp and signature, signed with the same secret as the original, so your verifier needs no change, and it does not consume one of the ten automatic attempts.