HTTP DELETE Request

DELETE is the method you use least and think about last, which is exactly why you'll be glad it's here when you need it. If you're building any kind of automation loop against a real API - clearing a job queue, removing a stale upload, purging an entry your workflow just created - HTTP DELETE Request is the node that does it, with the same shape as the rest of the pack's request nodes so nothing about it feels foreign.

How it works

It's a thin wrapper around requests.delete(). You give it a url, optionally a session (from HTTP Session Manager) and auth (from HTTP Authentication), and it fires the request with retry logic built in. The other request nodes in this pack share the exact same plumbing, so if you've used HTTPGet you already know this one.

The only required input is url. Everything else is optional:

• session / auth - plug in the manager and auth nodes for cookies, base URL, and credentials.
• headers, params, cookies - JSON strings, same gotcha as everywhere else in this pack (see below).
• timeout (default 30s), verify_ssl, allow_redirects, proxy_url.

The outputs that matter

Four outputs: status_code, headers, content, json. For DELETE, status_code is the one that matters - a 200/204 means the thing is gone, and a 404 usually means it was already gone. Wire status_code into a comparison or a display node and branch on it.

Install

ComfyUI Manager → search "ComfyUI-HTTP" → Install, then restart. Manual route:

cd ComfyUI/custom_nodes/
git clone https://github.com/wawahuy/ComfyUI-HTTP.git
cd ComfyUI-HTTP
pip install -r requirements.txt

No models to download; the pack's only genuinely new dependency is jsonpath-ng (needed by the JSON field extractor, not by this node).

Where people get burned

Two things to know. First, headers and params are text fields that must contain valid JSON - {"key": "value"}, not key=value. Malformed JSON gets silently dropped with a console warning, and your request goes out without the header you thought you set.

Second, this node does not throw on failure. If the network dies or the server errors out, it returns status_code = 0 with the error message in content and json. A 404 isn't a failure to the node - it's just a 404. So if you're branching on the result, check the status code explicitly rather than assuming a non-empty response means success.