Runs

A single execution of a flow. Identical conceptually to Orchestration's executions; this page focuses on the differences.

Read

{
  "data": {
    "flow": { "id": "flw_01HXY...", "name": "Ticket triage", "slug": "ticket-triage-v1", "spec": { ... } },
    "run": {
      "id": "run_01HXY...",
      "flowId": "flw_01HXY...",
      "flowVersion": 3,
      "status": "succeeded",
      "trigger": "manual | webhook | cron",
      "input": { ... },
      "steps": [ ... ],
      "finishedAt": "..."
    }
  }
}

Note the response wraps both the run AND the flow snapshot — convenient when an analyst is investigating a run weeks later and the flow has since changed.

Status lifecycle

running may instead transition to failed (uncaught error), awaiting_approval (the DAG hit a human_approval node), or cancelled (POST /runs/{id}/cancel). From awaiting_approval the run resumes back into running after a reviewer acts.

List runs for a flow

curl ".../api/flows/ticket-triage-v1/runs?status=succeeded&limit=50" \
  -H "Authorization: Bearer $QE_API_KEY"

Filters: status, trigger, from, to, plus standard pagination.

Approve (human_approval)

{
  "proposedActionOverride": { "amount": 5500000 },
  "note": "LLM proposed 5M but transaction was actually 5.5M — corrected"
}

A key difference from Orchestration: proposedActionOverride lets the approver edit the LLM-proposed action before executing it. The downstream node receives the overridden value via step.<approval_node>.output.proposedAction.

This is the canonical pattern for "LLM drafts, human signs off, possibly with edits":

[llm_step] drafts an action
    ↓
[human_approval] surfaces to analyst with proposed action
    ↓ analyst edits or accepts
[service_call] executes the (possibly edited) action

Reject

{ "note": "LLM hallucinated a fee that doesn't apply; rejecting." }

Flow's onReject policy determines whether the run fails or routes to recovery.

Cancel

POST /api/runs/{runId}/cancel — same as Orchestration. Sets status to cancelled and prevents downstream nodes from firing.

Trace ID

Like Orchestration, every service_call and http_request step sends an X-Quantum-Trace-Id header. The trace ID is also on the run row. Use it to correlate AI Automation runs with downstream service logs.

Retention

Runs are retained for 180 days by default. Step outputs >100 KB are stored in object storage and linked from the step record. After 180 days, the run row stays but step outputs are purged unless your org has long-retention enabled (compliance tier).