Cancel Workflow Run

Stored runs and access

Use the database-backed example workflow server and retain the returned workflow, run and session IDs. Configured authorization requires access to run the target workflow.

JWT user isolation is opt-in; non-admin service-account PAT callers always self-scope. Scoped callers can read only their own matching workflow sessions and runs. A wrong owner, missing record or cross-component ID returns 404. Authentication alone does not enable user isolation.

Request cancellation

Using IDs from the linked workflow server:

RUN_ID="returned-run-id"
SESSION_ID="returned-session-id"
curl --fail-with-body -X POST --get \
  "http://127.0.0.1:7777/workflows/echo/runs/$RUN_ID/cancel" \
  -H "Authorization: Bearer $OS_SECURITY_KEY" \
  --data-urlencode "session_id=$SESSION_ID"

Scoped callers require the session ID. 200 with {} acknowledges cancellation intent. Poll Get Workflow Run until a terminal state; the response does not prove the workflow stopped or undo external effects. An unscoped caller can receive this acknowledgement for an unknown run.

curl --request POST 'https://example.com/workflows/string/runs/string/cancel'

null

{  "detail": "string",  "error_id": "string",  "error_type": "string"}

{  "detail": "string",  "error_id": "string",  "error_type": "string"}

{  "detail": "string",  "error_id": "string",  "error_type": "string"}

{  "detail": "string"}

{  "detail": "string",  "error_id": "string",  "error_type": "string"}