Make's webhook queue holds 667 items per 10,000 credits: plan for Sume

Make's webhook queue is smaller than most people expect: 667 items for every 10,000 credits you license per month, and never more than 10,000. When it is full, Make answers 400, and Sume retries a job webhook that gets a non-2xx up to 10 times, 30 seconds apart. So a queue that stays full for about four and a half minutes costs you the automatic delivery.

Below are the Make limits, the sums, and what to do on the Sume side.

Make's documented limits

Sizing arithmetic

Queue capacity scales in steps of 667 per 10,000 credits, so 20,000 credits gives 1,334 items and 30,000 gives 2,001. The cap binds at 15 steps: 15 x 667 = 10,005, which Make limits to 10,000, so you reach it at about 150,000 licensed credits per month. These are my sums from the documented ratio.

Why this matters for Sume

Sume sends only terminal job events (job.completed, job.failed, job.canceled), so each job produces one callback, not a stream. The risk is a burst: many jobs finishing together while the scenario is slow.

What to do

• Make acknowledges at queueing time, so Sume sees a fast 200 as long as the queue has room. Watch the queue, not the response time.
• If you turn on sequential processing, expect the queue to grow because items wait for the previous run (see the sibling post on ordered processing).
• Keep a reconcile job that finds jobs whose callback never arrived and calls redeliver for them, or reads GET /v1/jobs/{id}/result. Never resubmit the paid job.
• Store job_id on every execution and skip duplicates, because retried deliveries carry the same job.