Webhook returns a 301: Stripe, OpenAI and Sume count it as failed

If the webhook URL you gave answers with a 301 or 302, the event is not delivered. Stripe says it considers redirect responses to webhook requests as failures. OpenAI says 3xx redirects will not be followed and are treated as failures. Sume's run webhooks page says redirects are not followed and a 3xx is a failed attempt. The fix is the same everywhere: register the URL the redirect resolves to.

What each page says

The last row matters. The job webhooks page says non-2xx responses are retried, but it does not mention redirects by name. Assume the stricter behaviour, since a 3xx is not a 2xx.

The usual causes

The last cause is easy to miss. Your browser test passes because you are signed in, while the sender gets a 302 to a login page on every attempt.

• A trailing slash: the route is /hooks/sume/ and you registered /hooks/sume, or the other way round.
• http to https: a proxy upgrades the scheme with a 301. Sume rejects non-HTTPS URLs at submit, so this shows up on a domain that moved.
• www to apex, or an old hostname that now redirects.
• A login or auth middleware that redirects unsigned requests to a sign-in page with a 302.

How to check before you submit

Send a bare POST with no cookies to the exact URL and read the status line. You want a 4xx for a missing signature or a 2xx, never a 3xx. Sume's Send test button on the webhooks dashboard fires a dummy webhook.test payload, and a failed test delivery tells you the URL is wrong before a paid run does.

On Sume run webhooks, a failed delivery never changes the run. If ten attempts hit a redirect, the run is still completed and you fetch it from result_url. Fix the URL, then use Redeliver on the run, which does not use up one of the automatic ten. The destination stays the same URL, so for a job whose URL was wrong, you need a new job.

A quick checklist

Before any production run, confirm four things for the URL you submit: it is HTTPS, it has the exact path and trailing slash your router serves, it answers POST without any cookie, and it returns a 2xx or a 4xx but never a 3xx. Repeat the check after a domain move, a CDN change or a framework upgrade, since each of those can add a redirect that browsers hide.

Remember that Sume re-validates the URL as public HTTPS at delivery time for run webhooks, not only at submit. A URL that was fine last month can fail now if DNS changed to a private address or the scheme was downgraded. The delivery status and attempt count on the job page, or webhook_delivery on a run, are the quickest way to notice that deliveries are failing.