Skip to main content
Beta: Comfy API v2 is at 0.1.x and the surface may still change. Changes within v2 will be additive; anything breaking would ship as v3.
The official, versioned HTTP API for running ComfyUI workflows from external applications: upload inputs, submit a workflow, observe execution, retrieve results. Most people should start with the Comfy SDKs, which wrap this API in Python and TypeScript. Call these endpoints directly if you are working in another language. The full endpoint documentation is in the API Reference pages of this section, generated from the OpenAPI specification.

Where v2 Runs

The same API is served by three surfaces, so one integration can move between them by changing the base URL. Comfy Cloud. The managed, multi-tenant service at https://cloud.comfy.org. Create an API key and you can submit any workflow. Cloud-specific features such as credits, model browsing, and queue management live on the v1 Cloud API, not on v2. Serverless API (Developer Platform). A workflow you deploy through the Developer Platform gets its own dedicated endpoint at https://{deployment}.run.comfy.app, serving the same v2 API with the same API key. A serverless deployment runs one pinned workflow, so it scales independently and GET /workflow returns the executed graph. See the Serverless API guide for building and deploying. Open-source ComfyUI, via the proxy. During the beta, a self-hosted ComfyUI speaks v2 through comfy-api-proxy, a small open-source service that runs alongside it:
By default it proxies the ComfyUI on 127.0.0.1:8188 and serves the v2 API on 127.0.0.1:8189, binding to loopback only. Authentication is off by default, with an optional static bearer token. The proxy is a stopgap: once v2 stabilizes it moves into ComfyUI core and the proxy is no longer needed. See Your own ComfyUI in the SDK guide for configuration details.

Design Principles

  • Poll first. Every capability is reachable via plain GET polling. The SSE stream is a live enhancement, never the source of truth.
  • Everything is resumable. Submission is idempotent, and job state and outputs are retrievable by ID until expires_at.
  • Content-addressed assets. Assets are UUID-identified records over blobs keyed by a server-computed blake3 hash, so identical inputs are not uploaded twice.
  • Follow links, do not build URLs. Responses embed their follow-up URLs.
See Design Notes for the reasoning behind these.

Base URLs

Endpoint Categories