/v1/comfyui-workflows/* and is intentionally not in the public OpenAPI bundle (the generated spec under API reference covers the core model + run surface only). The endpoints below are reachable and supported - this page is the canonical inline reference until they ship to the public spec.
For the end-to-end deploy flow, see Deploy a ComfyUI workflow. This page documents the bare API.
All endpoints require
Authorization: Bearer $RUNFLOW_API_KEY. X-Organization-Id is optional and defaults to the key’s org. Reads need the comfyui-workflows:read scope; writes need comfyui-workflows:create, :edit, or :delete respectively.Endpoints
Workflows
Dispatch runs
Inspect a dispatched run via
GET /v1/runs/{id} (same generic run record as model runs).
Inputs and outputs
The Runflow Input / Output nodes in the ComfyUI graph map to first-class resources you can list and manage:Reference and stats
Dispatch a run
POST /v1/comfyui-workflows/{owner}/{slug}/runs takes the same envelope you use for first-party models:
Response is the minimal
{ "run_id": "...", "status": "queued" } envelope, not the full run record. Poll GET /v1/runs/{id}, whose status_code advances to a terminal state, or wait for the callback.
Create a workflow programmatically
Most teams use the ComfyUI-Runflow plugin to create workflows from a live ComfyUI install. For automation or CI, you can POST directly:name and workflow_json are the only required fields. The full create validator accepts nested inputs[], outputs[], gpu_explicit_models[], custom_nodes[], models[], environment, and resources arrays.
Soft delete
DELETE /v1/comfyui-workflows/{id} marks the workflow deleted but preserves it for audit and rollback. Deleted workflows reject new runs (404 on the dispatch endpoint) but keep their historical run records reachable via the generic GET /v1/runs/{id}.
Related
Deploy a ComfyUI workflow
End-to-end plugin walkthrough.
Runs
Run record shape, polling, callbacks.
Webhooks
Org-level event delivery.
API reference
Public model + run surface (OpenAPI).