One Make webhook for Sume job.completed and format.run.terminal events

One Make custom webhook URL can receive both kinds of Sume callbacks, because they differ in the event field. Model jobs send job.completed, job.failed or job.canceled. Action, Format and Agent Completion runs send action.run.terminal, format.run.terminal or agent.run.terminal. Branch on event first, then read the outcome field that belongs to that family.

The two payload shapes

Sume documents two webhook surfaces with different event sets and different payloads. The signature scheme is the same (HMAC-SHA256 over <timestamp>.<raw_body>, header x-sume-webhook-signature: sume-v1=<hex>), so one verifier covers both.

Branch order that avoids mistakes

Do the checks in this order in Make, or in any tool that can route:

• Verify the signature against the raw body. If your tool cannot see the raw body, put a small verifier in front of it first.
• Route on event. Anything that is not on your list gets a 2xx and no action, so Sume does not retry events you chose to ignore.
• For runs, route on outcome, not on status. degraded means the run completed and billed, with real media in artifacts[], but no usable structured output.
• For jobs, take the audio, image or video URL from payload.artifacts[] where type matches what you asked for.

Two traps

A run that you cancel sends no webhook, and neither does a run that was skipped by on_active_run: "skip". Poll status_url after a cancel instead of waiting. And a run delivers one terminal event per turn, never one per artifact: if you need progress inside a turn, use the job layer.

Receipts above 1 MiB arrive with payload: null and an error.code of payload_too_large; fetch the receipt from result_url. A job webhook for a music track is tiny by comparison, because it carries only artifact URLs, never audio bytes.

Make's side

Make documents a default reply of 200 with the body Accepted, a rate limit of 300 requests per 10 seconds and a queue per webhook (read 2026-10-05). Those facts matter because Sume stops retrying after the first 2xx. Keep your branch logic idempotent and key it on job_id or request_id.

Do not use this pattern when the two families need different secrets or different retention. The signing secret is per workspace and shared by both surfaces, so a split by URL gives you routing, not isolation.