Webhook not fired when a job is canceled? Jobs vs runs in Sume
A canceled Sume job sends job.canceled, but a canceled run sends no webhook at all. Which surface you called decides it; how to detect a cancel by polling.
It depends on what you started. A generation job that is canceled does send a webhook, job.canceled. A run, meaning an Action, Format or Agent Completion, does not: a canceled run delivers no webhook at all, so after you call cancel you poll status_url until payload.status is canceled.
Both come from Sume's docs, read 2026-09-29. Sume has two webhook surfaces with separate event sets, so check which endpoint created the thing you canceled before you debug your receiver.
Which surface delivers a webhook for a cancel?
A job comes from POST /v1/models/... or a model endpoint such as /v1/avatar-1.0/generate; a run comes from an Action, Format or Agent Completion endpoint. The event sets do not overlap.
| Outcome | Job webhook | Run webhook |
|---|---|---|
| Completed | job.completed | Terminal event, status: OK |
| Failed | job.failed | Terminal event, status: ERROR |
| Canceled | job.canceled | No webhook |
| Skipped | Not applicable | No webhook |
Why does a canceled run skip the webhook?
Run delivery is for runs that complete or fail; the envelope status is OK or ERROR for those outcomes, not for cancel. The docs describe cancel as a separate API path with no cancel webhook status, and say to trust the cancel response. A skipped run, one recorded terminal without starting because another run was active, never delivers either; the create response already told you.
How do I detect the cancel instead?
Request the cancel, then read the receipt. Cancel on an action run needs actions:write and is idempotent; canceling an already-terminal run returns that terminal receipt with 200. The cancelable field is true only while the run is queued or processing.
curl -sS -X POST "https://api.sume.com/v1/action-runs/$RUN_ID/cancel" \
-H "Authorization: Bearer $SUME_API_KEY"
curl -sS "https://api.sume.com/v1/action-runs/$RUN_ID/status" \
-H "Authorization: Bearer $SUME_API_KEY"What should my receiver do with cancels?
Do not start a timer that waits for a run POST after you cancel; mark the run canceled from the poll. Keep the status spelling in mind: Action runs use canceled with one l and remap cancelled, so do not assume job-side status strings transfer. Full lifecycle notes are in Runs and results.
What does a job.canceled delivery look like?
Failed and canceled job webhooks use status: "ERROR" and include an error object, so a receiver that only checks for OK will file a cancel with failures. Key your handler on event, and use job_id as the idempotency key on your side.
Job webhooks are terminal events only; there are no progress or partial deliveries. Keep polling available anyway: the docs call delivery an optimization and never the only recovery path.
Does a skipped run behave the same way?
Yes, and it is easy to confuse with a cancel. With on_active_run: "skip" a run is recorded terminal immediately, without ever starting work, so no completion exists to notify you about. Defaults differ by surface: Format defaults to allow, while Action defaults to skip. Read status on the create response you got back rather than waiting for a POST that will not arrive.
Sources
Related posts
More in Developers
- Webhook payload too large (1 MiB)? Fetch the result URL
A Sume run receipt over 1 MiB arrives with payload null and a payload_too_large error. The run did not fail; fetch the receipt from result_url. Handler steps.
- Webhook endpoint redirect 301 not followed: what Sume does
Sume does not follow redirects on webhook deliveries: a 3xx is a failed attempt, not a delivery. Point webhook_url at the final URL, not a hop.
- Webhook dedupe id stable across retries: request_id and created_at
On Sume run webhooks, dedupe on the envelope request_id, which equals run_id and repeats on every retry. Order by created_at; request_id cannot.
- Webhook retry: fixed delay vs exponential backoff, with numbers
Fixed delay retries at even gaps; exponential backoff doubles them. Sume uses fixed for job webhooks and backoff for run webhooks: how long each keeps trying.
Written by Sume