HTTP Session Manager
One login, one base URL, many requests
- session
Hit the same API five times in one workflow and you'll feel the pain this node cures: five nodes each asking for the same token, the same headers, the same cookie. HTTP Session Manager is the pack's "configure once, reuse everywhere" node. It holds your base URL, auth, headers, cookies, and retry settings in one place, then hands out a session object that every method node can share - so those five nodes just take a relative URL and the same session wire.
It's the node you reach for as soon as a workflow makes more than one call to the same API.
How it works
Three required inputs:
session_name- the session's key (defaultdefault_session). Requests share a session by this name.base_url- the API root. When a method node gets a relative URL like/users/meplus this session, the node joins them into the full URL. Big convenience, no string-building.timeout- applied to every request on the session (default 30s).
Then the configuration that replaces per-node setup: headers and cookies as JSON strings, auth_type (none/basic/bearer/api_key/token) with its matching username/password/token/api_key/api_key_header fields, plus verify_ssl, proxy_url, max_retries (default 3), and retry_delay (default 1s, with exponential backoff between retries).
One output: session (HTTP_SESSION). Fan it out to as many request nodes as you like.
The gotcha nobody mentions
Sessions are stored in a class-level dictionary keyed by session_name, and they persist for the life of the ComfyUI process - across runs of the same workflow and even across different graphs. That's usually what you want (cookies survive, so a login handshake in one run carries into the next), but it cuts both ways:
- Change the session's config and rerun: the old client object is reused, so stale headers or auth can linger. The node re-applies settings on every run, but cookies and connection state from previous runs stick around.
- Two workflows using the same
session_nameshare state. Rename sessions per workflow if you want isolation. - There's no UI to close a session -
close_session/close_all_sessionsexist in code but no node exposes them. A restart is the only reset from the graph.
Install
ComfyUI Manager → search "ComfyUI-HTTP" → Install, restart. Manual:
cd ComfyUI/custom_nodes/
git clone https://github.com/wawahuy/ComfyUI-HTTP.git
cd ComfyUI-HTTP
pip install -r requirements.txt
No models; it's a requests.Session wrapper, so no heavy dependencies.
Where people get burned
The "stale state across runs" one is the classic - you change the token in the session manager, rerun, and the old token still goes out because cookies or auth persisted. If an authenticated workflow starts mysteriously failing after an unrelated change, restart ComfyUI or rename the session before you start debugging the API. And remember: a session only exists in memory, so it doesn't survive a ComfyUI restart - re-run the manager node and it rebuilds from scratch.
Inputs (15)
| Name | Type | Default | Description |
|---|---|---|---|
| session_name | STRING | default_session | — |
| base_url | STRING | — | |
| timeout | INT | 301–300 | — |
| headersopt | STRING | {} | — |
| cookiesopt | STRING | {} | — |
| auth_typeopt | COMBO | none | 5 options: none, basic, bearer, api_key, token |
| usernameopt | STRING | — | |
| passwordopt | STRING | — | |
| tokenopt | STRING | — | |
| api_keyopt | STRING | — | |
| api_key_headeropt | STRING | X-API-Key | — |
| verify_sslopt | BOOLEAN | true | — |
| proxy_urlopt | STRING | — | |
| max_retriesopt | INT | 31–10 | — |
| retry_delayopt | FLOAT | 1.000.1–10 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| session | HTTP_SESSION | — |