List scheduled agent runs over the Sume API: audit your schedules

To list scheduled agent runs with the Sume API, call GET /v1/actions to inventory your schedules, filtered by status or trigger_type, then page each schedule's history with GET /v1/actions/{action_id}/runs, passing next_cursor back as cursor until has_more is false.

The details come from Sume's Scheduled, Runs and results, and API reference docs pages and the OpenAPI reference, read on 2026-09-26. Scheduled is the product name; the wire namespace is /v1/actions. Creating and triggering a schedule is covered in Scheduled AI video agent runs.

How do I list my schedules?

GET /v1/actions needs a key with actions:read. It takes limit (1–100, default 50), status (active or inactive), and trigger_type (cron or api), and it pages with the same cursor rules as run lists. GET /v1/actions/{action_id} reads one schedule.

curl -sS "https://api.sume.com/v1/actions?status=active&trigger_type=cron&limit=100" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq '.data[] | {id, title, next: .cron.next_run_at, last_run_at, has_api: .api_trigger_enabled}'

Which schedule fields matter for an audit?

The public shape deliberately leaves out the instructions text; read and edit instructions in the dashboard. Everything else an audit needs is on the object:

How do I page through a schedule's run history?

GET /v1/actions/{action_id}/runs takes limit from 1 to 100, default 50, and returns { data, has_more, next_cursor }. Pass next_cursor back as cursor until has_more is false. The cursor is opaque: a cursor Sume did not mint is 400 invalid_request. A single run is readable under its schedule at GET /v1/actions/{action_id}/runs/{run_id}, or at GET /v1/action-runs/{run_id}.

curl -sS "https://api.sume.com/v1/actions/$ACTION_ID/runs?limit=100" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq '{has_more, next_cursor, runs: [.data[] | {id, status, source: .trigger.source, created_at}]}'

How do I tell cron runs from API runs?

Every fire, whether cron, manual, or API, produces a run with a receipt. Read these receipt fields:

• trigger.source: cron, manual, or api, next to idempotency_key. In the dashboard's run history, API runs are labeled API and scheduled runs Cron.
• status: queued, processing, completed, failed, canceled (one l), or skipped. Do not assume job-side status strings transfer.
• skip_reason: previous_run_active on a skipped run. idempotency_hit is true on an idempotency replay.
• output_schema.source: default, action_default, or request_override.
• request_id: log it for support.

Can I read a schedule by handle and slug?

Yes. GET /v1/actions/{handle}/{slug} and GET /v1/actions/{handle}/{slug}/runs work the same way as the opaque paths, for example /v1/actions/acme/weekly-teaser/runs. Store the opaque aut_… id anyway: renaming a handle or slug changes the vanity path, and a renamed handle keeps resolving for 90 days, which the docs call a migration window, not a guarantee.

Slugs are lowercase alphanumerics with single hyphens, 2–64 characters, unique within your account, and runs is reserved. slug is null on schedules created before slugs existed, and vanity_invoke_url is null when either half is unknown. An unknown handle, an unknown slug, and a handle you do not own all return the same 404 action_not_found.

What can't I monitor over the API?

The Scheduled gaps listed in Scheduled AI video agent runs also bound monitoring: no run events endpoint, no create or edit endpoints, no MCP or CLI access, and no API access to schedules owned by a team workspace. Three more matter for an audit:

• Runs are listed per schedule. The API reference has no route that lists runs across schedules, so loop over GET /v1/actions first.
• The run list takes only limit and cursor. Filter on status or trigger.source in your own code.
• usage.billable_amount_usd_micros on a receipt is the generation spend attributed to that run. It excludes the agent's own LLM turn, so it is not the run's total cost; GET /v1/usage remains the authoritative billing record.