Make webhook "Queue is full" 400: what Sume does and how to recover

If your Make webhook returns 400 "Queue is full" to a Sume callback, Sume treats it as any non-2xx: it retries up to 10 attempts total at a fixed delay (30s by default). If all ten are refused, the job is still completed; only the delivery failed, and you can redeliver the terminal event later.

Make facts are from its webhooks help page; Sume facts from Webhooks, both read 2026-09-30.

When does Make return 400 or 429?

The Make page lists status 400 "Queue is full" when the webhook queue is full, and 429 "Too many requests" when the rate limit check fails. The queue holds up to 667 items per 10,000 licensed credits per month, with a maximum of 10,000 items. Make can process up to 300 incoming requests per 10 second interval.

How does Sume respond to a refused delivery?

Sume returns nothing to Make; it just retries. Network errors and non-2xx responses are retried, with up to 10 attempts, a fixed gap rather than exponential backoff, and a 10s timeout per attempt. With the default 30s gap, the ten attempts span about four and a half minutes, so a later attempt can succeed if the queue has drained by then.

What if all ten attempts fail?

Ten refused attempts leave a failed delivery and a job that still reached its real terminal state. Redeliver re-POSTs the job's real terminal event with a fresh timestamp and signature, from the delivery row or POST /v1/jobs/{job_id}/webhook/redeliver. It still works after the automatic attempts are exhausted and does not consume one of the 10.

How do I avoid a full queue?

Keep the scenario draining the queue as jobs finish, or read results by status_url polling, which the docs say to keep available alongside webhooks. Receivers should treat job_id as the idempotency key, since a redelivery can repeat an event. See Make.com webhook scenario for the base setup.