Hookdeck 15-minute timeout and Sume's 10-second webhook attempt

No. A Hookdeck destination timeout of up to 15 minutes applies to the hop between Hookdeck and your server. Sume's attempt is a separate hop with a fixed 10-second timeout, and a slow answer is retried as a failed attempt.

Hookdeck figures are from its changelog entry; Sume figures from Job webhooks and Run webhooks, read 2026-09-30.

What did Hookdeck change?

Its changelog says custom delivery timeouts can now be extended up to 15 minutes per destination, and that the default is 1 minute. It is set under Advanced configuration in each destination's settings, or through the API with config.delivery_timeout. The entry pitches it at AI tasks and heavy backend work that you want to finish inside one request.

Which timeout does Sume apply?

Sume calls the webhook_url you submitted with the job. Whatever answers at that URL has 10 seconds per attempt, and nothing in the docs makes that value configurable.

Where does a relay fit?

If you put a relay in front of your handler, point webhook_url at the relay's public HTTPS source URL. Sume's 10 seconds then ends where the relay answers, and the relay's own destination timeout is what budgets the work behind it. Check the relay's docs for when its source answers; this page only cites the destination timeout.

Keep the Sume docs' rule in mind either way: return a 2xx after durably storing the event, and process afterward. See how Sume's two retry schedules differ.

What if the handler still runs for minutes?

Treat the webhook as a trigger, not the work. Store job_id, return 2xx, then fetch the result. The docs call delivery an optimization and never the only recovery path, so keep status_url polling available for events that never arrive.