Sume schedule: cron or API call is fixed when you create it

No, you cannot change a Sume schedule between cron and API-only after you create it. trigger_type is fixed at create time: an API-only schedule can never gain a cadence, and a cron schedule can never drop to API-only. The one flexible case goes in a single direction. A cron schedule may also set api_trigger_enabled, so it fires on the clock and accepts POST /v1/actions/{action_id}/runs from your own service.

That means the choice is worth making deliberately before you write the instructions. The wire name is still /v1/actions and ids still start with aut_, but the product is called Scheduled, and everything here follows the Scheduled docs.

The two trigger types

The trigger type is chosen in the dashboard at create time. The default is a cadence: a 5-field cron expression plus an IANA timezone, with hourly, daily and weekly presets that write the expression for you. Under Advanced you can switch to API call, which persists trigger_type: "api" and drops the cadence entirely.

Picking one

If nothing triggers the work except time, such as a weekly product teaser, pick the default cadence. The docs say plainly that a cadence is the whole point of a schedule, and that if you want to call Sume from your backend when your user does something, the Format API is the better fit because it is addressed per call and takes your inputs.

If an external system decides when work happens but you still want saved instructions, a spend cap and a structured output binding, pick API call. Because the choice cannot be reversed, the safe hedge is a cron schedule with api_trigger_enabled turned on: it can do both jobs. The cost of that hedge is that a clock-fired run and an API run share one overlap policy, on_active_run, which defaults to skip for schedules, so a manual run during a cron fire can come back as a skipped receipt.

Spend caps and overlap on either type

The trigger type does not change the cost controls. The generation spend cap bounds what one run may spend on generation, and when unset the effective default is $1.00 per run. A caller can lower it for a single run with generation_spend_cap_usd but never raise it above the schedule's cap; null runs without the automation ceiling while wallet balance and org limits still apply, and 0 is rejected.

Overlap is the other shared control. Only one run of a schedule is active at a time, and on_active_run decides what happens to a second request: skip records a skipped run immediately, while reject returns an error. A skipped run never delivers a webhook, so read the status on the response you got back.

What the API trigger needs

Every API run needs the schedule status to be active, api_trigger_enabled to be true, and a key carrying actions:read and actions:write. An inactive schedule rejects API runs with 409 action_inactive. Keys created before the API trigger shipped lack those scopes and fail with 403 insufficient_scope; scopes cannot be added to an existing key, so create a new one.

``bash curl -sS -X POST "https://api.sume.com/v1/actions/$ACTION_ID/runs" \ -H "Authorization: Bearer $SUME_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{}' ``

If you chose wrong, the fix is to create a second schedule with the other trigger type and copy the instructions over; the Developer API cannot create or edit schedules, so that happens in the dashboard. The create-by-API explainer covers that limit, and the skipped-run guide covers the overlap case.