A run is one execution of a model. You create runs withDocumentation Index
Fetch the complete documentation index at: https://docs.runflow.io/llms.txt
Use this file to discover all available pages before exploring further.
POST /v1/models/{model_id}/runs. The model_id segment is the model’s provider/slug and may be more than two segments deep (e.g. bytedance/seedance/2.0/fast/text-to-video). Each run has an id, a status_code, optional logs, and optional node-runs (steps inside a multi-step model).
Create a run
id and status_code: queued. Save the id; that’s what every other run endpoint takes.
Lifecycle
status_code | Meaning |
|---|---|
queued | Accepted, waiting for compute. |
dispatching | Being submitted to the execution provider. |
running | Executing. |
succeeded | Finished, outputs ready. |
failed | Error during execution. See failure_message. |
cancelled | You cancelled it. |
partial_succeeded | Batch-only terminal status. Individual runs do not use it. |
GET /v1/runs/statuses.
Get the result
Runs are asynchronous by default. Decide per request whether to receive the final payload by callback or by polling.- Callback (recommended). Provide
callback_urlon the create-run request. Runflow POSTs the event envelope there when the run reaches a terminal state. See Callbacks. - Polling. Omit
callback_url. PollGET /v1/runs/{id}untilstatus_codeis terminal.
sync_mode input for inline output. Use it only when the individual model page documents sync_mode and you intentionally want the response body to carry media data. It is per-model, not platform-wide.
Inspect a run
GET /v1/runs/{id}/logs- structured log lines.GET /v1/runs/{id}/node-runs- per-step records for multi-step models.GET /v1/runs/{id}/callback- the event-envelope payload Runflow delivered (or attempted to deliver) to yourcallback_url. Same shape documented under Callbacks.
Related
Callbacks
Async result delivery.
Batches
Run a model on many inputs in one request.
Errors
Failed run shape.