HTTP Request Sender

There's a whole category of ComfyUI nodes built to call a specific cloud API - Veo, Nano Banana, the whole "paste your key here" family. HTTP Request Sender is the opposite thing and honestly more useful in its way: a plain, fully generic HTTP client as a node. You bring the URL, the method, and the body. It does not call any API on its own, holds no keys, and needs no account. Wire it to a Discord webhook, a local inference server, an image-classification endpoint, or any REST service you can reach from your machine, and your workflow becomes able to phone home.

How it works

Underneath it's httpx with http2=True and redirects followed, so it's a real, modern HTTP client - not a toy. It builds headers from header_json, cookies from cookies_json (also folded into a Cookie header), and a body from body_json. Then it picks one of two transport modes:

• JSON mode (when send_image_enabled is off, or no image is connected): the JSON body is sent as an application/json payload.
• Multipart mode (when send_image_enabled is on and an image is wired in): the image is converted to RGB(A), encoded as WEBP (or PNG via send_image_format), and sent as a file part under multipart_field_name_in_image (default upload_image), while the JSON body goes in as a second part under multipart_field_name_in_body (default metadata). That's the shape a lot of image-uploading APIs expect.

Every request carries the default user agent python-httpx/0.28.1 comfy-nekonote-extensions/0.4.7 - change it in user_agent if the endpoint is picky about unknown agents.

The inputs that matter

The required trio: request_url, request_method (GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS), and timeout (1–60s, default 10). Then the useful optional set: header_json, body_json, send_image, and the multipart field names. That's most of what a beginner will ever set - everything else has sane defaults.

Outputs are the three things you care about after a request: HTTP Status Code (INT), Response Text (STRING), and Response Cookies (STRING). Wire Response Text into the pack's DisplayStringData to read what came back, and route the status code into a switch to branch on success vs failure.

Where people get burned

The failure mode here is silence by design. Rather than raising on bad input, the node returns synthetic status codes - 400 for a missing/invalid URL or malformed JSON, 408 on timeout, 500 on connection errors - with the error message in the response text. Your workflow won't crash, but a failed webhook will look like a "200" if you're only watching the image output. Check the status code; that's why it's an output.

The second trap: send_image_enabled defaults to on, but if no image is actually connected, it quietly falls back to JSON mode. Want image upload and think you have it wired? Make sure the image socket is actually populated, or you'll be sending JSON to an endpoint waiting for a file.

Security, briefly

It's a plain HTTP client - the URL you type is where your prompt and image go, full stop. That's the same rule as every API node, minus the credential: no keys to leak, and the pack is small and MIT-licensed so you can read exactly what it sends. Just know your endpoint.

Install

ComfyUI Manager → search "comfy-nekonote-extensions", or:

cd ComfyUI/custom_nodes
git clone https://github.com/0nyx-networks/comfy-nekonote-extensions

Restart ComfyUI; it's under NEKONOTE → HTTP. This is the one node in the pack whose dependency (httpx) genuinely might not already be in your environment - let Manager install requirements if the node errors on first use. The pack (MINETA "m10i" Hiroki, MIT, v0.4.7) has no model files; it's built on the newer comfy_api.latest backend API, so keep ComfyUI current.