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?

[mohammadrezwankhan]

Short version: keep API-format workflow JSON as the interchange format. App Mode is not a third submission API.

• For a frontend that talks directly to a local ComfyUI, use the native Server API: submit { "prompt": graph } to /prompt, follow execution on /ws (or poll /history/{prompt_id}), and fetch outputs through /view. Those remain the documented local routes.
• App Mode is a frontend presentation/configuration layer that exposes selected workflow inputs and outputs plus a Run action. It is useful UX to imitate, but it does not replace /prompt or define a different transport.
• For one client intended to target Cloud/serverless and self-hosted through a common contract, Comfy API v2 is the newer direction. It adds versioned /api/v2/jobs and /api/v2/assets, content-addressed/deduplicated asset references, idempotent job creation, and poll-authoritative resumable state with optional events (v2 spec).

The important current caveat is deployment: self-hosted v2 presently requires comfy-api-proxy, which maps v2 calls to core's native /prompt//history//view/upload/WebSocket routes. ComfyUI core itself still exposes the native API.

So my practical choice would be:

1. local-only alternative frontend: native Server API;
2. cross-surface application: v2, with the proxy for self-hosted instances;
3. either way: store/submit the API-format graph and treat App Mode metadata as optional UI configuration.

I would not claim that /prompt is deprecated or promise a migration date: I could not find an official deprecation notice or core-v2 timeline, and the v2 SDK/proxy surface is still new.