HTTP Display Result

Here's the thing nobody warns you about when you build your first API workflow: an HTTP node's string outputs don't show up anywhere you can actually read them. You wire HTTPGet's content into the next node and just have to trust it. HTTP Display Result is the pack's answer to that - a proper output node that takes a response and renders it in the UI so you can see what the hell the server actually said.

It's the debugging node you leave permanently attached to any API call while you're building, and the reason this pack is workable at all for beginners.

How it works

Three required inputs, which map exactly to a method node's outputs: status_code (INT), headers (STRING), and content (STRING). Feed them straight from HTTPGet/Post/Put/Patch/Delete.

Then the display controls:

• display_mode - formatted (default), raw, or summary. Formatted pretty-prints JSON bodies, separates headers and cookies, and adds a ✓/✗ success marker. Raw shows things closer to the wire. Summary collapses everything to a few lines.
• max_content_length (default 1000) - anything longer gets truncated with a note. Bump it if you're reading big responses.
• show_headers and show_cookies - toggle the sections. show_cookies is handy when an API hands you a Set-Cookie and you want to see it.
• json_indent - indentation for JSON bodies (default 2).

Four outputs: display_text (the human-readable rendering), summary (the one-liner version), status_text (like HTTP 200 OK - it has a small table of common status messages), and success (a BOOLEAN: true for 2xx statuses).

The success output is quietly the most useful one in the pack for branching. Wire it to a switch and you can route on "did this call actually work" instead of string-matching status codes.

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, nothing heavy - pure standard-library json.

Where people get burned

Two small traps. First, this is an output node - its job is displaying, so if you wire display_text into something downstream, you're feeding it formatted text with === HTTP Response === banners, not raw content. Grab content from the request node itself for that. Second, the truncation: with the default 1000-character cap, a long JSON response looks "cut off mid-object" in the UI. That's the node working as designed - raise max_content_length (up to 10000) rather than assuming the API sent broken JSON.