Sume schedule run: communication.mode webhook alone sends nothing
On a Sume schedule run, communication.mode is descriptive only. Delivery starts when communication.webhook_url is set, an HTTPS URL up to 2,048 characters.
Setting communication.mode to webhook on a schedule run does not by itself send a webhook. The Sume docs describe mode as descriptive only: it takes async (the default) or webhook, and it is communication.webhook_url that arms delivery. The URL must be HTTPS and at most 2,048 characters. Without it, the run behaves as async and you read the receipt by polling.
Request fields that touch delivery
The API silently drops unknown top-level properties instead of returning a 400. A misspelled communication key therefore looks accepted and then does nothing, which is the usual way a webhook run ends up silent.
Sume also accepts communication.callback_url as an alias for webhook_url; send one or the other. Top-level webhook_url, callback_url and mode are fal-shaped aliases that Sume normalizes into communication.*, and values that disagree between the two layers return 400 invalid_request.
| Field | Type | Default | Effect |
|---|---|---|---|
| communication.mode | async or webhook | async | Descriptive only |
| communication.webhook_url | HTTPS URI, up to 2048 | none | Terminal delivery target; arms delivery |
| on_active_run | skip or reject | skip | What to do if a run is already active |
| input | object | {} | Up to 64 properties and 2 MiB |
Test it in the right order
Start a run with a public HTTPS URL and a fresh Idempotency-Key. Sume rejects localhost, private-network and non-HTTPS URLs with 400 invalid_request, so test against a tunnel or a staging host, not http://localhost. Read the receipt: it should return 202 with status queued and a next_action of poll_status. Then poll status_url until the run reaches a terminal status; polling always works whether or not a webhook is armed.
The run webhook docs describe the delivery contract, including what is sent and when. Read them before you write a receiver, and make the receiver refuse requests when its signing secret is empty rather than skipping verification.
What a webhook does not replace
Poll as a backstop. A run that has not reported within your own deadline should be read from status_url, and you can cancel it with cancel_url while it is queued or processing.
- The receipt and the result route stay the source of truth; use them if a delivery is missed.
- events_url on a receipt is always null, because there is no public run events route.
- Canceled runs do not send a webhook; the status route still shows canceled.
One more check before production
Run the same request twice with the same Idempotency-Key. The second response should be an idempotency replay (idempotency_hit true) rather than a new run, which tells you your retry logic cannot double-start the schedule.
Sources
Related posts
More in Agents
- Scheduled run spend cap: a request can lower it, never raise it
A Sume schedule's per-run cap is min(request, schedule cap). A $3 request on a $1 schedule runs at $1; null removes the ceiling; 0 is a 400.
- script_run limits: timeout 5-55 s, max_calls and max_paid_calls
Sume's script_run runs a short script of MCP tool calls with a 5 to 55 second timeout and caps on calls and paid calls. What it returns and cannot call.
- Seedance 2.5's 4-second minimum costs $1.07 at 480p 9:16
Seedance 2.5 accepts 4 to 30 seconds, and the shortest 480p 9:16 clip is $1.074709, over the $1.00 default schedule cap. Price points and what to do.
- Six locales, six Agent Completions at $2 each: a $12 worst case
One Agent Completion per locale, each with its own spend cap and Idempotency-Key. Six runs at $2 bound generation to $12, and a retry cannot start a seventh.
Written by Sume