How to integrate a ComfyUI workflow API into a website: frontend, backend, queue, and results

Fri, 10 Jul 2026 06:24:49 +0800

Integrating a ComfyUI workflow into a website is not just about calling one API endpoint. A production-ready flow needs a frontend form, a backend task API, parameter mapping, file upload, queue control, status polling, result storage, and user-friendly errors.

The safest pattern is: the website never lets users submit arbitrary workflow JSON. The backend owns the workflow template, exposes only safe parameters, submits jobs to ComfyUI, then stores and returns results.

Separate the Two API Layers

There are usually two layers:

Your website API: what the browser calls.
The ComfyUI API: what your backend calls.

Do not expose the ComfyUI API directly to the public internet. It is an internal rendering service, not a user-facing API gateway.

Minimal Website Loop

User fills form
  -> backend creates task
  -> backend maps parameters into workflow JSON
  -> backend submits to ComfyUI
  -> frontend polls task status
  -> backend fetches generated file
  -> result is displayed or stored

This loop is enough for a first version.

Backend API Design

A simple backend can provide:

1
2
3

POST /api/generate
GET  /api/tasks/{taskId}
GET  /api/tasks/{taskId}/result

POST /api/generate creates a task and returns taskId. The frontend should not wait on this request until image generation finishes.

Maintain Task Status Yourself

Track states such as:

queued
running
succeeded
failed
expired

ComfyUI may expose queue and history data, but your product still needs its own task state so the frontend has stable semantics.

Do Not Let Users Submit Workflow JSON

Treat workflow JSON as backend-owned configuration. Users should only control safe fields:

prompt;
negative prompt;
style;
size;
seed;
uploaded image;
strength or steps within limits.

Letting users upload arbitrary workflow JSON can expose models, nodes, file paths, or expensive operations.

Keep Parameter Mapping Separate

Maintain a mapping layer:

form.prompt -> workflow node text
form.seed -> sampler seed
form.width -> latent width
form.height -> latent height

This makes it easier to change the workflow without rewriting the frontend.

Image Upload Handling

For image-to-image or reference-image workflows:

Upload the image to your backend.
Validate type and size.
Store it temporarily.
Pass the file to ComfyUI or place it where ComfyUI can read it.
Delete temporary files after expiration.

Do not trust the browser-provided filename or MIME type alone.

Frontend Interaction

The frontend should show:

form validation;
upload progress;
queued or running state;
estimated wait message;
result preview;
retry button;
clear failure reason.

Do not leave the user staring at a spinner with no task state.

Backend Pseudocode for Submitting to ComfyUI

receive request
validate user input
create task record
load workflow template
patch safe parameters into workflow
submit prompt to ComfyUI
save prompt_id and task status
return taskId

Then a worker or polling process updates the task until the output is ready.

Where to Store Result Files

Option 1: Proxy Downloads Through the Backend

This is simple for small internal apps. The backend downloads from ComfyUI and returns the file to the browser.

Option 2: Upload to Object Storage

For public websites, upload results to S3, R2, OSS, or another object storage service. Store only the result URL and metadata in your database.

Why You Need a Queue

Image workflows are slow and GPU resources are limited. Without a queue, users can overload the service with repeated clicks.

Use a queue to control:

concurrency;
per-user rate limits;
retry behavior;
timeout;
priority;
GPU utilization.

User-Friendly Error Handling

Translate internal failures into messages users can understand:

invalid prompt;
uploaded file too large;
generation timed out;
model temporarily unavailable;
queue is full;
result expired.

Keep detailed stack traces in logs, not in the browser.

Production Safeguards

Before launch, add:

authentication or quota;
upload limits;
prompt and content policy checks;
workflow parameter limits;
queue concurrency control;
timeout and cancellation;
result expiration;
cost monitoring;
model and node allowlist;
internal API protection.

RunningHub or Self-Hosted ComfyUI?

Hosted platforms such as RunningHub reduce infrastructure work and are easier for quick product validation. Self-hosted ComfyUI gives more control over models, nodes, GPU cost, data handling, and custom workflows.

Use hosted services for fast trials. Use self-hosting when you need strict control, private models, or deep customization.

Recommended Rollout Order

Run the workflow manually in ComfyUI.
Freeze one workflow template.
Expose only a few safe parameters.
Build backend task API.
Add frontend polling.
Store results.
Add queue and limits.
Add monitoring and cleanup.
Expand to more workflows.

FAQ

Can the frontend call ComfyUI directly?

It is not recommended for public sites. Use your backend as the boundary.

Does the website need WebSocket?

Not necessarily. Polling is enough for a first version. WebSocket can improve real-time progress later.

Can users upload workflow JSON?

Usually no. Keep workflows on the backend and expose safe parameters only.

Where should generated results be stored?

For production, object storage is usually better than keeping files on the ComfyUI machine.

Can one website connect multiple workflows?

Yes. Use workflow IDs and separate parameter mappings.

Are video workflows the same as image workflows?

The structure is similar, but video jobs need longer timeouts, larger storage, stricter queues, and better progress feedback.

Summary

The reliable way to integrate ComfyUI into a website is to treat it as an internal rendering engine. Your backend owns the workflow, queue, task state, storage, and safety limits. The frontend only collects safe inputs and displays progress and results.

Website Development on KnightLi Blog