Cursor agent subscriptions and scheduled runs calling an API

Yes, a Cursor scheduled run or subscription can call Sume, because Sume lets an outside system start a run of a saved schedule with POST /v1/actions/{action_id}/runs. Three things must be true first: the schedule is active, its api_trigger_enabled is true, and your key carries actions:read and actions:write.

The Cursor side comes from its changelog, read 2026-09-29: cloud agent subscriptions arrived Aug 19, and Cursor Projects on Sep 10 lists subscriptions that monitor Slack channels, scheduled runs and PR tracking. The changelog does not say how those runs call HTTP APIs, so check Cursor's docs for that.

What can the API do with a schedule?

Schedules are authored in the Agents dashboard, or by asking the Agent in chat to set one up. The Developer API can list them, read them, start runs, and monitor runs, but it cannot create or edit them. The wire namespace is still /v1/actions.

What must be true before the call works?

All three prerequisites are needed on every run request. Scopes are fixed when a key is created, so an older key that predates the API-call trigger fails with 403 insufficient_scope; create a new key and rotate to it.

What does the request look like?

Send an Idempotency-Key header on every run request; without one, every request starts a new run. An accepted run returns 202 with a receipt whose status_url, result_url and cancel_url you follow rather than build.

export SUME_API_KEY="sume_live_..."
export ACTION_ID="aut_..."

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 '{}'

What if the previous run is still going?

Only one run of an Action is active at a time, and on_active_run decides what a second request does. The default skip returns 200 with a receipt whose status is skipped; reject returns 409 action_run_in_progress. A 200 does not mean the work finished, so branch on the receipt's status, not the HTTP code. Polling and result shapes are in Runs and results.

What can the calling agent send?

The body accepts input, on_active_run, generation_spend_cap_usd, primary_output_key, output_schema, response_format and the communication object, and nothing else; unknown top-level properties are silently dropped, not rejected, so check field names. input is an object with at most 64 properties and 2 MiB of UTF-8.

A number for generation_spend_cap_usd is clamped to the smaller of the request and the Action's own cap, so a caller can lower the cap but not raise it. input reaches the Agent as data, not instructions, so caller-supplied text stays untrusted and the saved instructions stay in charge.