Skip to main content

Executions & Approvals

Routes for inspecting, controlling, and signaling running and completed executions. All routes are under /api/v1 and require a JWT.

List executions

GET /api/v1/executions?limit=50&offset=0

Returns recent executions for the tenant — id, workflow_def_id, status (running/completed/failed/cancelled), trigger_type, timestamps.

GET /api/v1/executions/visibility?query=ExecutionStatus="Running"

Proxies to Temporal's visibility search — supports Temporal's query syntax for filtering by status, workflow type, time range, etc.

Get an execution

GET /api/v1/executions/{id}

Summary view: status, trigger type/data, input, output, start/end timestamps.

Get execution detail

GET /api/v1/executions/{id}/detail

Full Temporal event history rendered as per-step records — config, resolved input, raw output (sensitive fields redacted), duration, status, and AI cost data (input_tokens, output_tokens, cost_usd) where applicable.

Stream live updates

GET /api/v1/executions/{id}/stream

Server-Sent Events stream of status changes for a running execution. Registered outside the 55-second request-timeout middleware so the connection can stay open for the lifetime of the run. Each event is a JSON-encoded status update.

Retry / resume

POST /api/v1/executions/{id}/retry

Starts a new execution that resumes from the point of failure: PreloadedOutputs is populated from the failed run's completed step outputs, so successful steps (including completed approvals) are not re-run.

Response 202 Accepted — the new workflow_executions row.

Cancel

POST /api/v1/executions/{id}/cancel

Cancels the underlying Temporal workflow. Steps in flight are interrupted; if the execution was waiting on an approval, that step is marked cancelled.

Send a signal

POST /api/v1/executions/{id}/signal
{ "signal": "approve-review_email", "data": { "approved": true, "comment": "looks good" } }

Delivers a named Temporal signal to a running execution. The primary use is human-in-the-loop approvals (approve-<step_id>), but any custom signal name can be used to push external events into a workflow that's waiting on it.

GET /api/v1/executions/{id}/approve/{stepId}?decision=approve|reject

Public, no auth required — the execution ID + step ID combination is the security boundary, suitable for embedding as a button URL in a Slack/Telegram approval message. Equivalent to sending {"signal": "approve-<stepId>", "data": {"approved": <bool>}} via the signal endpoint.

Pending approvals

GET /api/v1/approvals

Lists every step currently in the waiting state across the tenant, across all workflows — backs the dashboard's "Pending Approvals" inbox.

Step feedback

POST /api/v1/executions/{id}/steps/{stepId}/feedback
{ "rating": "up", "comment": "Great summary" }

Records feedback on a step's output — useful for building eval datasets from production traffic.

Workspace files

GET /api/v1/workspaces/runs/{exec_id}/files
GET /api/v1/workspaces/runs/{exec_id}/files/*

List/download files an execution wrote to its sandbox workspace (reports, generated images, processed data).

Audit log

GET /api/v1/audit

Requires admin/owner. Returns recent audit_events — workflow CRUD, secret changes, signals, role changes, etc.

Next