Cron or API call: the trigger type of a Sume schedule is fixed

Choose the trigger type of a Sume schedule carefully, because it cannot be changed later: trigger_type is cron or api, and it is fixed once the schedule is created. An API-only schedule can never gain a cadence, and a cron schedule can never drop to API-only.

This comes from Create a schedule and the Scheduled overview. The product is called Scheduled; the HTTP namespace stays /v1/actions.

What are the two trigger types?

cron is the default. You give it a 5-field cron expression and an IANA timezone, or use the hourly, daily and weekly presets. api is an advanced option under Advanced: it drops the cadence entirely, so the schedule only runs when your service calls POST /v1/actions/{action_id}/runs.

For cron schedules, the cadence is a 5-field expression plus an IANA timezone, so a weekly 09:00 Seoul run and a weekly 09:00 New York run are two different schedules, not one with an offset. The hourly, daily and weekly presets write the expression for you, and the custom option accepts the raw expression. The cron object on the public shape carries the expression, the timezone and next_run_at, which is a handy value to alert on if it ever stops moving.

If you are unsure whether a field is five or six, see cron expressions: 5 vs 6 fields; Sume documents the 5-field form.

Can a cron schedule also accept API calls?

Yes. A cron schedule can set api_trigger_enabled to also accept API runs on top of its cadence. That is the safe default when you are unsure: you keep the clock and gain the option to fire a run on demand. The reverse is not possible, because an API-only schedule has no cadence to add.

Whichever you pick, three things must hold for an API run to start: the schedule's status is active, api_trigger_enabled is true, and the key carries actions:read and actions:write.

How should you decide?

Ask who decides when the work happens. If the answer is a clock (a Monday roundup, a nightly refresh), use cron. If it is an event in your own system (an order shipped, a post approved), use api. If it is both, use cron with the API trigger enabled.

Remember what each fire does: the run executes as an agent in a fresh thread with a structured receipt. If you only want your backend to call Sume per user action with your inputs and no saved schedule at all, the docs point you to the Format API or Agent Completions instead of a schedule.

Overlap is the other design decision that follows from the trigger. Only one run of an Action is active at a time. With the default on_active_run: "skip", a second trigger returns 200 with a receipt whose status is skipped and skip_reason is previous_run_active, and a run row is recorded. With reject you get 409 action_run_in_progress and nothing is recorded. A cron plus API schedule is exactly where both can meet: the clock fires while your service also called, so decide which behavior you want before you enable both.

What if you picked wrong?

There is no edit that flips the type. Create a new schedule with the right trigger, copy the instructions, spend cap and output schema across in the dashboard, and set the old one to Inactive so it stops running. Point your config at the new schedule's aut_... id.

Also note the gaps: the Developer API can list and read schedules and start runs, but it cannot create or edit them, so this migration is a dashboard task.