Webhook endpoint redirect 301 not followed: what Sume does
Sume does not follow redirects on webhook deliveries: a 3xx is a failed attempt, not a delivery. Point webhook_url at the final URL, not a hop.
Sume does not follow redirects on webhook deliveries. A 301 or 302 (any 3xx) is a failed attempt, not a delivery, so it burns one of the ten attempts and the redirect target never receives the event. Point webhook_url at the final URL, the one that answers 2xx directly.
What does Sume count as delivered?
The URL is also re-validated as a public HTTPS URL at delivery time, not only when you submit.
| Your endpoint answers | Result |
|---|---|
Any 2xx | Success |
A 3xx redirect | A failed attempt; not followed |
| No answer within 10 seconds | Attempt times out and is retried |
| Ten failed attempts | webhook_delivery.status is exhausted |
Did my run fail when the redirect broke delivery?
No. 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. For generation jobs, keep status_url polling available for events that never arrive.
Where do redirects usually come from?
The docs do not list causes, but the shape is common: an http to https hop, a trailing-slash rule, or a proxy that sends a bare host to another host. Since the webhook URL must be public HTTPS already, check the exact string you registered with a plain curl -i and confirm it returns a 2xx and not a Location header.
How do I recover deliveries that already failed?
Redeliver re-posts the real terminal event, but it never changes the destination URL, and a new URL is a new job. So the fix belongs on your side: make the original URL answer 2xx without redirecting, then Redeliver. It works after the automatic attempts are exhausted because it does not consume one of the automatic 10.
How long does Sume keep trying?
Run webhook retries follow min(max(30s × 2^(attempt−1) with jitter, Retry-After), 1h), and Sume honours Retry-After on 429 and 503. Generation job webhooks use a fixed spacing (30 seconds by default) with the same 10-attempt cap. Either way, an endpoint that only ever redirects will use all ten attempts before the delivery is marked exhausted.
Return 2xx quickly, after durably recording the event, and do your processing afterward.
What if I need to move the endpoint?
Do not rely on a redirect to carry deliveries across. Register the new URL on new work, and keep the old URL answering 2xx directly for jobs and runs already in flight, since redeliver targets the original destination. Non-HTTPS, localhost and private-network URLs are rejected with 400 invalid_request when you submit, so the new URL has to be public HTTPS from the start.
Sources
Related posts
More in Developers
- Webhook dedupe id stable across retries: request_id and created_at
On Sume run webhooks, dedupe on the envelope request_id, which equals run_id and repeats on every retry. Order by created_at; request_id cannot.
- Webhook retry: fixed delay vs exponential backoff, with numbers
Fixed delay retries at even gaps; exponential backoff doubles them. Sume uses fixed for job webhooks and backoff for run webhooks: how long each keeps trying.
- Webhook unknown event type: return 204, not a 500
One Sume verifier covers run and job webhooks. Route on event and answer 204 for unknown types so a new event never becomes a 500 and a retry storm.
- Webhook signature mismatch: compare the secret fingerprint first
When a Sume webhook signature will not verify, compare x-sume-webhook-secret-fingerprint with the dashboard fingerprint. It is safe to paste into a ticket.
Written by Sume