Make webhook queue MCP tools: stuck items and Sume redelivery

If a webhook queue item looks stuck in a Make scenario that waits on Sume, inspect two places: Make's queue, and the delivery status on the Sume job. If Sume's delivery shows exhausted or failed, call POST /v1/jobs/{job_id}/webhook/redeliver and Sume re-sends the real terminal event.

Make's release notes dated September 25, 2026 mention "MCP tools for webhook queues" for queue management; the snapshot read 2026-10-01 is a one-line entry, so this post does not describe those tools. The Sume side is from Webhooks.

Which side holds the item?

Sume sends the callback; Make receives it. An item missing from Make's queue may never have arrived, and an item present in Make may be waiting on your scenario. Sume's job object and job events show the delivery side, including the webhook.delivery event.

What delivery statuses does Sume report?

The documented vocabulary is pending, delivering, delivered, retrying, failed and exhausted. Automatic delivery makes up to 10 attempts. Ten refused attempts leave a failed delivery and a job that still reached its real terminal state, so the work is not lost.

How do I resend the event?

Use Redeliver, either on the delivery row or with POST /v1/jobs/{job_id}/webhook/redeliver (scope jobs:write). Sume re-POSTs the job's real terminal event with a fresh timestamp and signature. It still works after the automatic attempts are exhausted and does not consume one of the 10. It does not change the destination URL; a new URL is a new job.

Do not use Send test for this. It posts a dummy webhook.test payload with no job id, so it proves the URL is reachable but replays nothing.

What if the callback never arrives?

Keep status_url polling available. The docs call delivery an optimization, never the only recovery path. Treat job_id as the idempotency key in your scenario so a redelivered event does not run the downstream steps twice. For the retry-limit side, see Make webhook queue full 400 and Sume's ten attempts.