Make 'Process data in order': one slow Sume run can block the rest

With Process data in order on, Make completes each execution before starting the next, and new runs are paused until incomplete executions are resolved; this applies to webhooks too (Make scenario settings, read 2026-10-02). If one run is stuck waiting on a Sume video, every later webhook from other jobs queues behind it, so keep the Sume submit and the Sume result in two separate scenarios.

The settings that matter

A scenario that receives Sume webhooks is an instant-trigger scenario, so a single unhandled error turns it off. The webhooks page also says an inactive webhook returns 410 after 5 days.

Why this matters for Sume

Sume sends one terminal event per job and expects a 2xx within 10 seconds per attempt, retrying up to 10 times. A Make webhook without a response module answers 200 once the item is queued, which is fast. The risk is not the acknowledgment; it is the processing behind it. If an ordered scenario hits an error and stores an incomplete execution, the next Sume deliveries pile up in the webhook queue, which has its own size cap.

Two-scenario layout

• Scenario A (submit): receives the request, calls the Sume API with an Idempotency-Key, saves the job_id, and ends. It never waits for the job.
• Scenario B (result): triggered by the signed Sume webhook, verifies the signature, looks up the job_id, writes the result, and ends in a second or two.
• Turn ordering on only where order really matters, and prefer keying on job_id over relying on sequence.

What to avoid

Do not put a sleep-and-poll loop inside an ordered scenario to wait on a video. Sume supports polling status_url with backoff, but run that on a schedule, not inside a run that blocks everything else. Do not retry a failed run by resubmitting the paid request; read the job first.