Running workflows

There are two ways to run a workflow, and the right choice depends on how long it takes.

	Synchronous	Queued
Endpoint	POST .../runsync	POST .../run
Returns	The workflow's outputs	An invocationId
Blocks	Until the run finishes	No — returns immediately
Best for	Fast runs inside a request	Long runs, batch work

For a queued run, poll GET .../run/{invocationId} until state is completed or failed. Poll on an interval that suits the workload rather than in a tight loop.

Both accept the same body:

Request body

{
  "inputs":   { "anyKey": "any value" },
  "runEvent": "run",
  "version":  null
}

• inputs — passed straight through to the workflow. The shape is whatever your workflow reads.
• runEvent — which entry point to trigger. Defaults to "run".
• version — a published version to pin to. Defaults to the latest.

Runs made here are ephemeral

API runs clean up their runtime data when they finish and are not written to the workflow's stored output. Read what you need from the response.