- Submit a job → get a
request_idimmediately - Poll status (or use webhooks) until the run completes
- Fetch results (hosted URLs) or handle failures
- Optionally cancel a queued/running job
Tip: The Serverless API (LoRA) uses the same request-id pattern—only the request schema differs. See Serverless API (LoRA).Base URL:
https://api.runcomfy.net
Queue endpoints
| Endpoint | Method | Description |
|---|---|---|
/prod/v1/deployments/{deployment_id}/inference | POST | Submit a request |
/prod/v1/deployments/{deployment_id}/requests/{request_id}/status | GET | Check request status |
/prod/v1/deployments/{deployment_id}/requests/{request_id}/result | GET | Retrieve request results |
/prod/v1/deployments/{deployment_id}/requests/{request_id}/cancel | POST | Cancel a queued request |
Common path parameters
deployment_id(string, required): The deployment you want to call.request_id(string, required for status/result/cancel): Returned by the submit call.
Submit a request
- Use the deployment’s cloud-saved workflow (most common): send an
overridesobject to change only specific node inputs. - Send a full workflow at request time (advanced): include
workflow_api_jsoninline to run a different workflow without updating the deployment.
Use cloud-saved workflow
When a workflow is deployed, RunComfy stores itsworkflow_api.json. At request time, you usually send only:
overrides: a partial object keyed by node ID (as strings)- optional webhook fields (
webhook,webhook_intermediate_status)
What overrides reference
Overrides must match the deployedworkflow_api.json:
- node IDs must exist
- input keys must exist under the node’s
inputs - values should match each node’s schema (see
object_info.json)
workflow_api.json, node "6" is a CLIPTextEncode node that has a text input:
workflow_api.json.
Request example (basic)
Request example (image/video via URL)
Use a publicly accessible HTTPS URL that returns the raw file via an unauthenticatedGET request (no cookies, no login pages). Avoid expiring links.
Request example (image/video via Base64)
Request example (API nodes)
If your workflow uses ComfyUI Core API nodes (for example, nodes that require a Comfy API key), include your Comfy Org API key(always starts with ‘comfyui-’) in the request body:Response example
request_id: unique identifier for your jobstatus_url: poll this to track progressresult_url: fetch final outputscancel_url: cancel if still cancellable
Send dynamic workflow (or any workflow_api.json)
Use this when you want to run a different workflow without changing the deployment’s stored workflow. In this mode:- include
workflow_api_jsonin the request body - omit
overrides(or keep it empty) - the job runs the workflow you sent
Response example (dynamic workflow)
Monitor request status
in_queue → in_progress → completed (or cancelled).
Request example
Response example
status:in_queue,in_progress,completed, orcancelledqueue_position: present whilein_queueinstance_id: present once an instance is running your job (useful for the instance proxy)
Want to call ComfyUI backend endpoints on the live instance? See Instance Proxy Endpoints.
Retrieve request results
outputs.
Generated assets (images/videos) are hosted on temporary storage for convenience. Hosted output URLs remain available for up to 7 days after success; after that, they are automatically removed. If you need longer retention, download outputs or copy them into your own storage.
Request example
Response example
- For
succeeded,outputscontains node outputs (usually hosted URLs) - For
failed, you’ll receive anerrorobject describing why the run failed - For
cancelled,finished_atindicates when it was cancelled
Cancel a request
Request example
Response example
outcome(string):cancelledif accepted;not_cancellableif the job is completed or otherwise cannot be cancelled.
