Zapier Next Gen Zaps can pause for a reply: approve before Sume

Place the Sume submit after the approval step, never before it. Next Gen Zaps can pause mid-run for a human reply and then resume, which is the natural gate for a paid render. Key the submit from the approved record so a resume or a double click cannot make two.

Zapier facts are from its September 23 announcement; Sume facts from Communication modes and Errors and credits, read 2026-10-01.

What can the Zap do now?

The announcement says a Zap can pause mid-run for a human reply and then resume, with early access on paid plans (Pro, Team and Enterprise). It also lists branches that split and rejoin and error handling that keeps going. It does not say how long a pause may last, so do not design around a particular timeout.

Why submit after the pause?

A Sume generation job costs credits once it is accepted. The submit reserves the estimated cost from your balance and fails with 402 insufficient_credits before provider work starts if it cannot. A job that has started generating cannot be cancelled and still bills. So the cheap place to say no is before the submit.

What if the Zap resumes twice?

Use an Idempotency-Key built from the approved record, such as the row id and revision. An exact retry returns the original job instead of billing twice. A different payload under the same key is 409 idempotency_conflict, so change the revision if the approver edits the prompt.

curl -X POST https://api.sume.com/v1/video-1.0/generate \
  -H "x-api-key: $SUME_API_KEY" \
  -H "content-type: application/json" \
  -H "idempotency-key: approval-4412-r1" \
  -d '{"prompt":"Slow push-in on a ceramic mug","mode":"webhook","webhook_url":"https://example.com/hooks/sume"}'

How does the Zap hear back?

Use mode: "webhook" with a public HTTPS webhook_url; delivery is terminal events only. Keep polling GET /v1/jobs/{id}/status as a backup, because delivery is a convenience. See the Zapier delayed-webhook post.