Zapier Next Gen Zaps: pause for a human reply before a Sume agent run

Next Gen Zaps can pause mid-run for a human reply and then resume, and that pause is the right place to approve a Sume agent run: ask a person to reply with a dollar amount, then send that exact amount as generation_spend_cap_usd in the call to POST /v1/agent/completions. Sume requires that field and has no default, so the approval you collected becomes the ceiling the unattended agent runs under.

Zapier's side comes from its product update The next generation of Zaps is here, read on 2026-10-11. Sume's side comes from Agent Completions and Run webhooks. Sume has no Zapier-specific app in these docs, so the Sume call is a plain HTTPS request.

What does the Zapier update say?

The post lists several features. Relevant here: pausing mid-run for a human reply or scheduled follow-up and then resuming automatically, and processing entire lists with no 500-item loop cap. It says Next Gen Zaps are available on paid plans (Pro, Team, Enterprise), that Team requests must come from account owners or admins, and that the feature is in early access, not yet generally available, with a request form. It also says you can describe a Zap inside MCP-enabled tools such as Claude, ChatGPT or Cursor and deploy it to Zapier.

Because the feature is early access, check that your account has it before you design around the pause.

Why put the approval before the call?

Sume's docs explain the required cap: in the chat product an interactive spend-approval prompt protects you, a backend caller does not get one, and the cap replaces the prompt. An Agent Completion is an unattended agent with tools and access to your generation wallet. A human reply collected before the call turns the cap into a real decision instead of a constant in the Zap.

The order matters. If the Zap called Sume first and asked afterwards, the money would already be committed. Pause, collect the number, then call.

What does the Sume call look like?

The request takes either instruction or messages, never both, plus the required cap. The create call returns 202 and a receipt, not a finished answer, so the Zap should not wait on it. Send an Idempotency-Key so a retried step returns the original receipt with idempotency_hit: true; reusing the key with a different payload returns 409 idempotency_conflict. The Python below shows the shape of the request; it reads the key from SUME_API_KEY and refuses to run without it.

import json, os, urllib.request

def submit(instruction: str, cap_usd: float, idem: str) -> dict:
    key = os.environ.get("SUME_API_KEY", "")
    if not key:
        raise SystemExit("SUME_API_KEY is empty")
    body = json.dumps({"instruction": instruction,
                       "generation_spend_cap_usd": cap_usd}).encode()
    req = urllib.request.Request(
        "https://api.sume.com/v1/agent/completions", data=body, method="POST",
        headers={"Authorization": f"Bearer {key}",
                 "Content-Type": "application/json",
                 "Idempotency-Key": idem})
    with urllib.request.urlopen(req) as r:
        return json.load(r)["data"]

if __name__ == "__main__":
    run = submit("Make a 15 second teaser for the spring sale", 2, "zap-4812-approved")
    print(run["id"], run["status"])

How does the Zap learn the result?

Add communication.webhook_url, a public HTTPS address of at most 2048 characters, to the request and Sume sends one signed POST when the run completes or fails. The event is agent.run.terminal, and you should branch on outcome (ok, degraded or error) rather than on status alone. Sume retries up to 10 times, treats any 2xx as success, and does not follow redirects. Dedupe on request_id. A canceled run sends no webhook, so a Zap that cancels must poll status_url instead.

The signature is HMAC-SHA256 over <timestamp>.<raw_body>, with the timestamp and signature in x-sume-webhook-timestamp and x-sume-webhook-signature. Verify it in a receiver you control and reject an empty secret. Do not hand the signing secret to a general-purpose step that logs its inputs.

What changes with the 500-item cap gone?

A list-processing Zap that once stopped at 500 items could now launch many runs, one per item. Each run carries its own cap, so the worst case is the cap times the item count. Decide that total before the pause, not after: ask the human to approve the total and split it across items. Sume's safe automation page also says to log request ids and statuses, never keys or signed URLs, and that applies to Zap history as much as to code.