Continue Workflow Run

Continue a paused workflow

Use the workflow HITL example, which provides a complete function-only workflow_hitl.py server and client for step confirmation, user input and output review. It stores the run in SQLite and uses workflow ID release-review-workflow.

Start a run and keep its returned run_id, session_id and step_requirements array. Save that array as step-requirements.json. After the appropriate human decision, update the requirement's confirmed value, user_input or review result and retain the issued identities. For nested executor pauses, preserve the executor run/session IDs and nested requirements too.

RUN_ID="returned-paused-run-id"
SESSION_ID="returned-session-id"
curl --fail-with-body \
  "http://127.0.0.1:7777/workflows/release-review-workflow/runs/$RUN_ID/continue" \
  -H "Authorization: Bearer $OS_SECURITY_KEY" \
  -F "session_id=$SESSION_ID" -F 'stream=false' \
  -F 'step_requirements=<step-requirements.json'

For a shared-key server, set OS_SECURITY_KEY before starting the linked example and in the client's shell. The request field is step_requirements; Team requirements and Agent tools are different contracts.

The run must currently be PAUSED. Completed, pending, running, cancelled or errored runs return 409; this endpoint does not create a completed-run follow-up. A continued run can pause again, so inspect each result and resolve its newly returned requirements. Remote workflows are unsupported (400).

Background continuation needs a paused ticket

background=true requires an eligible existing paused durable queue ticket, not merely a workflow database. A run that started outside the durable queue returns 409 through this background path. Continue it with background=false instead. See durable HITL continuation.

Use stream=false to poll a queued continuation after 202. A ticket originally submitted without streaming cannot later attach a continuation stream (409); use polling. Ordinary non-background streaming returns Workflow events and can report a failure after HTTP 200 has begun.

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.

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

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"}