Can I create a Sume schedule over the API? Not today

No, you cannot create or edit a Sume schedule over the API today. Schedules are made in the dashboard at the scheduled-runs page, with either a five-field cron plus an IANA timezone or an API-only trigger, and there is no MCP tool or CLI command for creating them.

What the API does give you is control of runs: you can fire a schedule that has an API trigger, read its receipts, and see the results. That is enough for many integrations, but the plan has to account for the manual step.

That boundary is worth knowing before you promise a customer self-serve scheduling inside your own product. You can build the timing in your code, but not the Sume schedule object.

What you configure in the dashboard

The Create a scheduled run page covers the form. The trigger type is fixed at create, so decide between a cron trigger and an API trigger up front, because you cannot change it later. A cron schedule uses five fields plus a time zone name such as Asia/Seoul or America/New_York, which keeps fire times steady through daylight saving changes.

The default generation cap is $1.00, and the schedule also carries the on_active_run rule, which defaults to skip.

What the API can do

The wire namespace is /v1/actions. Schedule ids start with aut_, and run receipts are action.run objects at /v1/action-runs/{id}. Scopes are actions:read and actions:write. An API-triggered schedule accepts a call that fires one run, with an optional Idempotency-Key and a per-run cap that can only lower the schedule's cap. See API trigger.

Two quirks to know. The API silently drops unknown top-level fields for scheduled runs, unlike Format runs, which answer 400 unknown_parameter, so a typo in a field name will not warn you. And events_url is always null on these receipts, so there is no phase timeline; poll status instead.

Errors you will see

A schedule that is switched off returns 409 action_inactive. A schedule without an API trigger returns 409 action_api_trigger_disabled. A second fire while one is running returns 200 skipped by default or 409 action_run_in_progress when set to reject. Handle each as a normal outcome, not an outage.

Because the API drops unknown fields rather than rejecting them, test an API trigger once by hand and read the receipt to confirm your field took effect.

A workable pattern for teams

Create one API-trigger schedule per workflow by hand, record its aut_ id in your configuration, and let your own scheduler or workflow tool decide when to fire it. That moves timing into code you can test and version while keeping the schedule object, its cap, and its overlap rule in Sume.

If you want true cron inside Sume, make the schedule a cron trigger and accept that edits are manual. Put the change in a runbook so someone owns it.

Write down who can edit schedules in the dashboard. Since the API cannot do it, the dashboard is the only audit surface for changes, and access to it should be as controlled as access to a production key.