HTTP GET Request
Pull data into your workflow from anywhere
- session
- auth
- status_code
- headers
- content
- json
This is the node the whole pack is built around. HTTP GET Request is how your workflow reads from the outside world: a REST API, a status endpoint, a JSON feed, an LLM's text API, whatever you can reach over HTTP. You give it a URL, it returns the status, headers, and body - and it's the node you'll start with whenever you want ComfyUI to actually talk to something instead of just generating.
It's also the template for the rest of the method nodes in the pack. Learn this one and the other six are free.
How it works
One required input: url. Drop in a full URL, or a relative path like /users/me if you're feeding it a session with a base_url. Then the optional inputs, in rough order of how often you'll touch them:
params- query-string parameters as a JSON object, e.g.{"page": 1, "limit": 10}. Cleaner than hand-building the query string.headers- request headers as a JSON object. This is where you'd normally put anAuthorizationheader if you're not using the auth node.session- from HTTP Session Manager, for cookies, auth, and base URL reuse.auth- from HTTP Authentication, for a reusable credential config.cookies,timeout(default 30s),verify_ssl,allow_redirects,proxy_url.
Four outputs: status_code (INT), headers (JSON string), content (raw body), and json (the body, pretty-printed if it parses as JSON, otherwise identical to content).
The pipeline that makes it useful
GET alone just dumps text. The magic is what you do after:
[HTTPGet] → [HTTPGetJSONField: "$.data.image_url"] → [HTTPImageLoader] → [IMAGE]
Fetch a caption from an API and pipe it into your CLIP text encoder, or pull a reference image URL and load it directly. That's the pattern - and it's why this pack is more than a curiosity.
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 model downloads; it's plain requests under the hood. The only genuinely new dependency in the pack is jsonpath-ng, and this node doesn't even need it.
Where people get burned
The JSON-as-string inputs are the #1 trap. headers and params must be valid JSON - {"key": "value"} - and if they're not, they're silently dropped with a console warning while the request goes out bare. Second: a failed request doesn't error the workflow; it returns status_code = 0 with the error message in content/json. Check the status code before trusting anything downstream, or you'll be debugging phantom issues where a "successful" call actually never happened.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| url | STRING | https://api.example.com/data | — |
| sessionopt | HTTP_SESSION | — | |
| authopt | HTTP_AUTH | — | |
| headersopt | STRING | {} | — |
| paramsopt | STRING | {} | — |
| timeoutopt | INT | 301–300 | — |
| verify_sslopt | BOOLEAN | true | — |
| allow_redirectsopt | BOOLEAN | true | — |
| cookiesopt | STRING | {} | — |
| proxy_urlopt | STRING | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| status_code | INT | — |
| headers | STRING | — |
| content | STRING | — |
| json | STRING | — |