Get 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.

Poll a saved run

Replace these shell values with the IDs returned by Execute Workflow:

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

session_id is required. For a factory, repeat the factory_input JSON query value needed to reconstruct the workflow. Remote workflow polling returns 400.

The response is the stored full run output. For example, a completed echo run contains these fields (additional output fields omitted):

{"workflow_id":"echo","run_id":"returned-run-id","session_id":"returned-session-id","input":"Hello","content":"Hello","status":"COMPLETED"}

During durable acceptance, the endpoint can return a limited queue-ticket view before the stored run row is available. Continue polling until a terminal status, then inspect the output and any error or pause requirements. This endpoint does not return an SSE stream.

curl --request GET 'https://example.com/workflows/string/runs/string?session_id=string'

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