Skip to main content
Once you’ve built and saved a workflow (see Building Workflows), you execute it and read its results either from the definition object or through client.runs. This page covers both.

Running a workflow

Two ways to execute: 1. From the definition object → a Run you poll or stream
2. Synchronous one-shot via the runs service
body/input is a dict keyed by the workflow’s input labels.
For input formats (node labels, node IDs, files), streaming, and webhook callbacks, see Running Workflows.

The runs service

The Run object

Fields: id, status, progress, progress_details, workflow_id, input, output, created_at, finished_at.
Methods (each with an a-prefixed async twin):
wait(output_only=True) returns just the output dict; otherwise it returns the refreshed Run. Streaming yields RunEvents as the run progresses.

Deleting runs

Old runs and everything they own (inputs and outputs, logs, progress, traces, files no other run references) can be deleted to free disk space. Usage analytics and billing are unaffected.
Deleting run history is a platform administrator’s action and cannot be undone. The API key must carry the resource:delete_history scope, which only a platform administrator can add when creating a key (Settings → API keys → Restrict permissions → Platform administration). An unrestricted key does not have it; any other key gets HTTP 403.
Only finished runs (completed, failed, stopped) are deleted. A run that is still queued, running or awaiting a human is left alone and listed in RunDeletion.errors with the reason; stop it first if you mean to remove it. RunDeletion fields: matched (finished runs selected), succeeded, failed, errors (run id → reason). Each call has an a-prefixed async twin (adelete, abulk_delete). The REST endpoints behind these are DELETE /v1/runs/{run_id} and POST /v1/runs/bulk/delete (body: run_ids or filters with to_date as the “older than” cut-off plus workflow_id, status, user_id, from_date, tags; expected_count; dry_run).