Api Submit
Fire a workflow at a remote ComfyUI and keep your local queue moving
- image
- job_id
ApiSubmit is the fire-and-forget version of Api Generate: it takes the same workflow JSON and the same injection settings, submits the job to a remote ComfyUI, and returns immediately with a job_id instead of blocking until the render finishes. The idea is that your local ComfyUI queue doesn't hold a socket open for five minutes while a RunPod churns - it gets the job registered and moves on, then Api Collect picks up the result on a later pass.
It's the node that makes "render on the cloud, keep my graph responsive" actually feel like a queue rather than a phone call on hold.
How it works
Everything about the workflow building is identical to Api Generate - prompt injection, seed override, image upload, the whole overrides mechanism - so if you've read that node's article, the inputs are old friends. The differences are all in the scheduling behavior.
ApiSubmit is an output node, which means it runs even when nothing consumes its job_id output. Every time you queue, it re-runs (IS_CHANGED returns the current time), rebuilds the workflow, and submits. If no job is already in flight, it writes a record into the shared jobs.lock file - job id, remote prompt id, api_url, the output node id, and your label - then hands back the job_id string.
If a job is already in flight, it skips the submit and returns an empty job_id. That's the one-at-a-time queue discipline: one API job per slot, so you can't accidentally stack a dozen renders on a pod that will throttle you. The lock also records a timestamp, and a stale lock older than the pack's threshold gets overridden rather than deadlocking your workflow forever.
That label input is genuinely useful. It's recorded with the job and returned by Api Collect later, so when you're collecting in a loop you can tell which job you just grabbed - handy when you've got a few of these running.
Inputs that matter
Same required set as Api Generate minus timeout_sec (there's nothing to wait for): workflow, positive_prompt, positive_prompt_id, api_url, output_id, plus negative_prompt_id, seed, seed_id, image_node_id. The optional extras are negative_prompt, image, overrides, and the label mentioned above.
The one output, job_id, is a STRING - empty when a job is already in progress.
Install
Part of ComfyUI-Alchemine-Pack:
cd ComfyUI/custom_nodes
git clone https://github.com/alchemine/comfyui-alchemine-pack
pip install -r requirements.txt
Or via ComfyUI Manager (search "ComfyUI-Alchemine-Pack"). No model downloads; the models live on the remote instance.
Common issues
The trap people hit first: you submit, and the job_id output is empty, and you think it's broken. It's not - it means a job is already queued. That's the intended behavior, and it's also why you don't fire ApiSubmit in a tight loop expecting multiple concurrent renders. It'll never happen; the lock is the point.
Second, the same API-format requirement as its sibling: UI-format workflows fail on the remote. And remember that nothing happens until you run the graph again to collect - if you submit and never queue a second pass with Api Collect downstream, the render finishes on the pod and just sits there in history.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| workflow | STRING | — | |
| positive_prompt | STRING | — | |
| positive_prompt_id | STRING | — | |
| negative_prompt_id | STRING | — | |
| output_id | STRING | — | |
| seed | INT | -1-1–2147483647 | — |
| seed_id | STRING | — | |
| api_url | STRING | — | |
| image_node_id | STRING | — | |
| negative_promptopt | STRING | — | |
| imageopt | IMAGE | — | |
| overridesopt | STRING | — | |
| labelopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| job_id | STRING | — |