What API should alternative frontends use?

[jerkstorecaller]

There's three options available in Comfy:

1. "API" workflow file sent with every prompt to the classic /prompt endpoint
2. App Mode workflow, alternative to the above which lets you reduce it to the fields the caller usually wants to edit
3. Comfy API v2. Repos available as of two weeks ago, but I couldn't find meaningful doc about on the website. Like, what makes this better? It seems to support caching bytes attached to the workflow, such as images for i2i or i2v presumably.

What does ComfyOrg suggest people be using going forward?

[jestiawasim-star]

DOSSIER MAÎTRE DU MANGA
Compilation de référence — Univers, narration, pouvoir, personnages, lieux et bible visuelle
Projet : ECLIPSE NOIRE / univers de Tetta Shirah
Ce document rassemble les fondations les plus importantes établies jusqu’ici afin de pouvoir
les conserver, les copier et les réutiliser pour la production du manga.

[Shyboy0499]

For an alternative frontend, the practical answer is: use the classic /prompt workflow API unless you specifically need the newer features.

• Classic /prompt (serialized workflow from "Save (API Format)") is the stable, documented, widely-implemented surface — every existing frontend uses it. Maximum compatibility and predictable behavior: you POST a prompt, then consume executed events and grab outputs from /history / /view. If you want your frontend to just work, this is the safe default.
• App Mode is a wrapper around that same workflow that reduces what the caller must send — you expose only the fields you want edited. Great for a "let a non-technical user tweak a couple of knobs and run" UI, but it's still the same execution underneath.
• API v2 is the newer protocol, and as you noticed, documentation is thin and it's early — I'd treat it as "evaluate for new builds, don't bet a frontend on it yet." Expect churn while it settles.

Decision guide:

• Third-party or your own frontend that needs to just work → classic /prompt.
• A simple "tweak and run" UI for other users → App Mode on top of a /prompt backend.
• Greenfield and comfortable tracking a moving spec → peek at API v2, but budget for changes.

The classic endpoint won't go away (it's the compat surface), so defaulting to /prompt is safe.

[perfectmodelslab]

There is a fourth architecture the three options above skip, and it is the one we shipped: do not build an external frontend, build an extension panel inside the official one.

Context: we ship PerfectLab Studio, a node pack whose entire UI is a custom panel (625 tile pickers, a live prompt preview, session controls). No separate process, no serialized workflow in sight.

How it works:

• the pack registers through app.registerExtension, and the UI is a custom widget chain attached to our node. State lives in widgets_values, so the official frontend persists it for free: save, reload, refresh the browser, the panel comes back exactly as left.
• backend calls that do not fit the graph go through server routes shipped by the same pack. We serve our own read/write endpoint for panel state, no CORS to think about, no auth story to build, no second server to deploy.

Why this beats the external-frontend framings for a product use case:

• No workflow drift. An external frontend POSTs serialized graphs and owns the impedance mismatch forever. The panel edits the real node widgets, so "what the user picked" and "what the graph holds" are the same bytes.
• No API version coupling. We do not care whether /prompt, App Mode or API v2 wins. The extension API of the official frontend moves slower than API v2, and it is the same surface every custom node already depends on.
• Distribution is one install. Users get nodes and UI together through the Manager and the Registry, and the whole thing works offline: tiles, fonts, state, all inside the package.

Trade-offs, so this does not read as an ad: you are bound to the official frontend's extension API (fine for us, it churns far less than API v2), you live inside the browser session rather than a standalone app, and headless/batch use still wants /prompt on top.

So the decision guide gets one more line: building a product UI on top of ComfyUI itself, where users already have the official frontend -> extension panel plus custom server routes. For standalone apps, the guide above stands.

[evachxji]

For a new standalone or alternative frontend, the current documentation recommends Comfy API v2, preferably through the official Python or TypeScript SDKs, unless you specifically need low-level local-server controls.

That recommendation is now explicit in Running Workflows, and v2 has a real compatibility policy: changes within v2 are additive; breaking changes ship as v3. So I would not treat it as merely an experimental protocol anymore.

The main advantages over building a new integration directly on /prompt are:

• durable, pollable and cancelable jobs, with idempotent submission;
• authoritative status/output retrieval by job ID, with SSE as an optional live channel rather than the source of truth;
• content-addressed assets: the server computes BLAKE3 hashes and deduplicates blobs, so identical i2i/i2v inputs do not need to be uploaded repeatedly;
• the same client model works with Comfy Cloud, Comfy API deployments, and self-hosted ComfyUI.

For self-hosted ComfyUI, run the API Proxy:

pip install comfy-api-proxy, then comfy-api-proxy.

It defaults to http://127.0.0.1:8189 and proxies the classic ComfyUI server at 127.0.0.1:8188. Submit a workflow in API format (File → Export Workflow (API)), not the editor/UI JSON format.

The classic /prompt + /ws + /history//view route still makes sense for existing integrations, or when you need raw local details such as queue and node internals. However, the current Server API documentation explicitly says there is no compatibility guarantee across releases, so I would not make it the default for a new portable frontend. Also, the deprecated “v1” in the new docs refers to the v1 Cloud API, not the classic local /prompt endpoint.

App Mode belongs to a different layer: it is an authoring/presentation mechanism for exposing selected workflow inputs and outputs as a simplified app, not a separate versioned execution API. You can use it to decide which fields your UI should expose, but execution should still go through API v2 or the classic Server API.