Sume schedule vanity URL: store the aut_ id, not handle/slug

A Sume schedule can be started at a readable path, POST /v1/actions/{handle}/{slug}/runs, as well as at its opaque aut_ id. Both reach the same schedule and run the same pipeline, but only the aut_ id is permanent. Store the id in your integration: renaming your handle or the schedule's slug changes the vanity path, and an old handle keeps resolving for 90 days, which the docs call a migration window, not a guarantee.

From Run a schedule via API, read on 2026-10-03.

What stays the same on the vanity path

Request body, headers, scopes, idempotency, spend caps and the run receipt are identical to the opaque form. The receipt's action.id is always the opaque aut_ id, even when you called by handle and slug. GET /v1/actions/{handle}/{slug} and GET /v1/actions/{handle}/{slug}/runs work the same way.

Slug rules and errors

Slugs are lowercase alphanumerics separated by single hyphens, 2 to 64 characters, unique within your account, and runs is reserved. An unknown handle, an unknown slug, and a handle you do not own all return the same 404 action_not_found, so an error cannot be used to probe whether someone else's handle exists.

That same 404 is what an integration sees after a rename that is past the migration window, with nothing in the message to say a rename happened. If a previously working trigger starts returning action_not_found, check whether the handle or slug changed before checking the key.

A safe way to use both

Use the vanity path in places a human reads, such as a runbook or a chat message, because it shows what the schedule is. Use the aut_ id in code, config and infrastructure, because it never changes. If your tooling lists schedules, read invoke_url from the response and save that, rather than composing a path from pieces.

Remember that schedules owned by a team workspace are not reachable over the public API yet, by either path.

Migrating after a rename

If you must rename a handle or slug, do it in this order. First, change every caller to the aut_ path. Second, confirm each caller got a 202 or an expected 200 on the new path. Third, rename. The 90-day window after a handle rename is a safety net for callers you forgot, and the docs are explicit that it is not a guarantee, so do not plan around using all of it.

Search your repositories and automation tools for the old handle string before the rename, including chat bots, cron jobs and CI files. Those are the places a vanity path tends to hide.