Sume Action run 409: action_api_trigger_disabled vs action_inactive
Two different 409s stop POST /v1/actions/{id}/runs before any work starts. What each means, the dashboard fix, and how they differ from action_run_in_progress.
409 action_api_trigger_disabled means the schedule's api_trigger_enabled is false; 409 action_inactive means its status is inactive. Both are set in the dashboard, and neither is fixed by retrying.
Both are listed in the error table of Advanced: run a schedule via API. Three prerequisites must all hold for any API run: status active, api_trigger_enabled true, and a key with actions:read and actions:write.
Which 409 am I looking at?
Four 409 codes share one status. Read error.code, not the HTTP status, to decide what to do.
| error.code | Cause | Fix |
|---|---|---|
| action_api_trigger_disabled | api_trigger_enabled is false | Enable the API call trigger on the schedule |
| action_inactive | Schedule status is inactive | Set the schedule Active |
| action_run_in_progress | A run is active and on_active_run was reject | Retry later, or use skip |
| idempotency_conflict | Idempotency-Key reused with a different payload | Use a new key |
How do I fix action_api_trigger_disabled?
Open the schedule at https://www.sume.com/agents/scheduled and enable the API call trigger. If the schedule's trigger type is api, it is already API-only by design. If it is cron, you can enable the API trigger on top of the cadence. The trigger type itself cannot change after creation.
One trap is mixing environments. The invoke endpoint host follows the dashboard you copied it from: a dashboard on a *.dev.sume.com host yields https://api.dev.sume.com, everything else yields https://api.sume.com. Check the host before pasting a copied command into production code.
How do I fix action_inactive?
Set the schedule to Active. While it is Inactive, API runs are rejected with this code. This is useful on purpose: switching a schedule off in the dashboard is a quick way to stop your own integration from starting runs while you edit the instructions.
What should my caller do?
Do not retry the first two in a loop; they are configuration states, not transient errors. Alert a person, and log the request_id from the error envelope. Retrying is reasonable for 429 and for 503 studio_agent_upstream_unavailable, with a bounded count.
A small branch keeps this clear:
For a dashboard of your own, count the two config 409s separately from the busy 409. A rising action_run_in_progress count means your triggers overlap and you should check on_active_run. A single action_inactive after an edit window usually just means someone forgot to switch the schedule back on. Always log the request_id from the error envelope with the code.
case "$CODE" in
action_api_trigger_disabled|action_inactive) echo "config: fix in dashboard" ;;
action_run_in_progress) echo "busy: retry later" ;;
idempotency_conflict) echo "bug: new key needed" ;;
*) echo "other: see request_id" ;;
esacSources
Related posts
More in Agents
- Why a Sume run's billable_amount_usd_micros is not its total cost
usage.billable_amount_usd_micros on a Sume Scheduled run receipt is generation spend only. It leaves out the agent's own LLM turn. Where to read the full bill.
- Agent Completions 403: service_account_agent_completions_unsupported
A Sume service-account key cannot create Agent Completions. It fails with 403 insufficient_scope and a reason code; use another key with the right scopes.
- Claude Code routines API trigger vs the Sume Scheduled run API
Claude Code routines' /fire endpoint and Sume's POST /v1/actions/{id}/runs both start a saved agent over HTTP. Compare payload, limits, receipts and webhooks.
- Which model runs a Sume scheduled agent, and how to choose it
A Sume schedule stores its own model beside its instructions and cap. Where to pick it, what Agent Completions accepts, and what the changelog says on defaults.
Written by Sume