ComfyUI API Nodes Say ‘Sign In Required’ When You Run Workflows via Python — Here’s the Real Fix

You have a workflow that runs perfectly when you click Queue Prompt in the ComfyUI browser UI. It uses a built-in Partner Node — a paid, cloud-backed integration such as BRIA, Seedance, or a hosted image model. The minute you submit that same workflow programmatically with a Python script hitting /prompt, the job dies with a popup that reads “Sign In Required to Use API Nodes”.

The first assumption everyone makes is that something is wrong with the script. It isn’t. You are logged in to the web UI. The workflow runs fine manually. The failure only appears in the programmatic path, and that asymmetry is the entire clue. In this guide I’ll walk through the exact root cause, the documented authentication fix, and how to verify your batch jobs actually execute.

Why the Error Mentions a ‘Browser Login’ That Your Script Can’t See

The confusion comes from a deep difference between how local models and Partner Nodes authenticate. A local checkpoint, LoRA, or VAE never checks who you are — it runs on your GPU and that’s the end of it. Partner Nodes are different: they are thin clients that call out to Comfy’s hosted backend, and they are billed against your ComfyUI account, not against your local server.

When you open the browser UI and are signed in, that account session lives in your browser. The frontend carries it into every request, so the Partner Node in your manual run can resolve “who is paying for this.” A Python script calling POST /prompt over raw HTTP has no such session. There is no browser, no cookie, no account context — only a JSON payload. The node therefore cannot authenticate against your account and correctly refuses with a sign-in error.

Key point: this is not an issue with your server’s API key, your firewall, or your script’s HTTP handling. The Partner Node authenticates against a ComfyUI platform account, which is conceptually separate from the ComfyUI server itself. That’s why “I’m already logged in in the browser” does not help — the credential simply never makes it into the programmatic request.

Diagnosing It: Confirm It’s the Account-Key Gap, Not a JSON Bug

Before you reach for the fix, rule out the more common JSON mistakes so you don’t chase the wrong problem. Run this quick triage:

• Does the node work manually in the UI? If yes, the workflow structure is valid. The failure is authentication, not node wiring.
• Does the error appear only in the API path? This is the signature of the account-session gap. If the node also fails manually, you likely have a missing model or a malformed input instead.
• Are you submitting API-format JSON, not UI-format? Quick sanity check: your payload should be the flat prompt object keyed by node ID, not the nested workflow export. Sending UI-format JSON causes a completely different error (“does not appear to be an API workflow JSON”), so if you see the sign-in message specifically, you’re past that hurdle.
• Does the console stop at the “preprocessing” stage? In the common report, the job posts, returns a prompt_id, enters preprocessing, then fails. That timing — accepted, then rejected right before execution — is consistent with an auth check inside the node.

If all four point the same direction, you’re dealing with the account-key gap and can move straight to the fix.

The Fix: Put Your ComfyUI Account API Key in the Prompt Payload

Since mid-2025 ComfyUI has supported running paid Partner Nodes headlessly by passing your ComfyUI Account API Key inside the request itself. You no longer need a browser session. The key travels in the extra_data field of the /prompt payload, under the key api_key_comfy_org.

First, generate the key. Create an account on the ComfyUI Platform, then create an API key. It looks like comfyui-87d01e.... This is not the same as any token you use to authenticate your own script against your own server — it’s the account credential that Partner Nodes use to bill cloud calls.

Here is the exact request shape. Notice the key goes inside extra_data, sitting alongside (not inside) the prompt object:

import json, urllib.request

SERVER_URL = "http://127.0.0.1:8188"

prompt = json.loads(workflow_with_api_nodes)  # your API-format prompt dict
payload = {
    "prompt": prompt,
    "extra_data": {
        "api_key_comfy_org": "comfyui-87d01e28d***********************"  # your real key
    },
}
data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(f"{SERVER_URL}/prompt", data=data)
urllib.request.urlopen(req)

For a requests-based harness, wrap the same structure with the key included:

import requests

resp = requests.post(
    f"{SERVER_URL}/prompt",
    json={
        "prompt": prompt,
        "extra_data": {"api_key_comfy_org": "comfyui-..."},
    },
)
resp.raise_for_status()

Prerequisites to keep in mind: the key must be valid, and your account must hold sufficient credits for the Partner Node you’re calling. A valid key with an empty credit balance fails differently — the call is authorized but execution errors out on billing. If you’re handling multiple clients, you can read the key from the associated user rather than hard-coding one, but the per-request extra_data placement is the same regardless.

Common Traps That Make the Fix Look Like It Didn’t Work

• Putting the key in the wrong level. The field must be a sibling of prompt inside extra_data. Nesting it inside the prompt object or sending it as a raw header does not authenticate the Partner Node.
• Confusing the account key with your server API key. A ComfyUI account key is comfyui-... and is tied to platform billing. An unrelated auth token for your own instance won’t satisfy the node’s account check.
• Reusing a UI-exported workflow untouched. The prompt you POST must be in API format. If you’re exporting from the UI, generate the API prompt via app.graphToPrompt() in the browser console rather than hand-converting.
• Empty credits. Authentication succeeds but execution still errors. Verify your platform credit balance before blaming the key.
• Assuming the old browser-login requirement still applies. The headless-key support landed in a specific PR; if you’re on a very old ComfyUI build, update before expecting extra_data.api_key_comfy_org to be honored.

Verifying the Batch Actually Ran

Once you inject the key, don’t assume success from the HTTP 200 on POST /prompt — that only confirms the job was accepted, not that it finished. Confirm the full lifecycle:

• Read the prompt_id from the response body.
• Poll /history/{prompt_id} until the job leaves the queue and runs.
• Check the node outputs in the history payload — a Partner Node that completed will return its actual artifacts.
• Purge any hard-coded key from logs or committed scripts before you share the harness.

A working call produces a history entry with non-empty outputs for the Partner Node. If you instead see a status still stuck at preprocessing or an auth message echoed back, re-check the key placement and your account credit balance — those two, in that order, resolve nearly every remaining failure.

Conclusion

“Sign In Required to Use API Nodes” is not a bug in your script and not a sign that Partner Nodes can’t be automated. It’s the gap between your browser’s account session and a headless HTTP request. Close that gap by embedding your ComfyUI Account API Key in the extra_data.api_key_comfy_org field of every /prompt payload, keep your key at the right nesting level, and verify execution through /history. With that in place, you can run paid, cloud-backed nodes in fully automated batch pipelines alongside your local models — no manual login required.

For the current, authoritative reference on the key itself and the exact Python shape, see the official ComfyUI API Key Integration documentation. If your broader pain is submitting the right JSON in the first place, that’s a separate root cause, and the difference between UI-format and API-format workflows trips up a lot of people — see my guide on why your workflow nodes vanish when you switch from UI JSON to API JSON, written for the same local-AI automation audience.