HTTP PUT Request

PUT is the "replace this entire resource" method. Where POST creates and PATCH tweaks a few fields, PUT says "here is the complete, new version of this thing - overwrite what you had." HTTP PUT Request is the pack's node for it, and honestly it's the one you'll reach for when you're syncing state: uploading a full document, replacing a record, overwriting a config your workflow just regenerated.

How it works

Two required inputs:

• url - the resource to replace, e.g. https://api.example.com/data/1.
• content_type - json (default) or raw. Same split as HTTPPatch: JSON payload goes in json_data, raw bodies go in raw_data. No form or multipart mode here - PUT in this pack is JSON or raw only.

Optional inputs are the standard set: session, auth, headers, cookies, timeout, verify_ssl, allow_redirects, proxy_url.

Four outputs, matching the rest of the method nodes: status_code, headers, content, json.

The mental model that matters

The difference between PUT and PATCH is the one people actually get wrong, and it matters on real APIs. PATCH sends only the fields that changed; PUT sends the complete replacement - on many servers, omitting a field from a PUT body deletes that field on the server. So if your workflow updates one status field, that's a PATCH job. If it regenerates and uploads a full object, that's PUT. Pick wrong and you'll either wipe data or leave stale fields around, both of which are exactly the kind of bug that's invisible until someone notices the server state is wrong.

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; plain requests under the hood.

Where people get burned

Beyond the PUT-vs-PATCH trap: the JSON-input gotcha applies here too. json_data is a text field, malformed JSON is dropped with a console warning, and the request goes out with an empty body - which, for PUT specifically, can clear a resource rather than just fail. If you're building a PUT payload from other nodes, validate it through HTTP Convert JSON first. And remember failures return status_code = 0 with the error in content instead of raising, so check the status before trusting that the resource was replaced.