ComfyUI Node

HTTP Form Data Item

The simplest form field you'll ever build

By wawahuy·Created about a year ago·Updated 11 months ago· 14
HTTP Form Data Item
    • form_item
    namefield_name
    valuefield_value

    Some nodes do clever things. This one does the most boring, essential thing in the pack: it makes a single text field for a multipart form. HTTP Form Data Item takes a name and a value, wraps them in a little form_item object, and lets the HTTP Form Data container bundle them into the body of a POST.

    That's the whole job, and that's fine. Multipart forms are just lists of named fields, and this is how you declare "here's a field called title with this text."

    How it works

    Two required inputs, both plain text:

    • name - the field name the API expects (defaults to field_name).
    • value - the field's content (defaults to field_value).

    One output: form_item (HTTP_FORM_ITEM). Wire it into any itemN slot on HTTP Form Data. That's it - no optional inputs, no knobs.

    Internally it marks the item as type text, and the form container routes it into the data part of the multipart body rather than the files part. If you're following along in the pack, note this is the plain sibling of HTTP Form Text Item, which exists to also let you set a content_type per field. For 99% of text fields you don't need that, so this one is the one you'll actually use.

    When it matters

    Anytime a multipart endpoint wants a text field alongside a file - a caption, a title, a tag, an instruction. It's the standard companion to HTTP Form Image Item / HTTP Form File Item in an upload form. Keep a few on the canvas, type values or wire them from other string-producing nodes, and you're done.

    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, no dependencies beyond the pack itself.

    Where people get burned

    Two classic mistakes, both simple. First, the name must match what the API's docs say - the server couldn't care less what you named the widget, only what's in the name field. Second, an item that's not plugged into an HTTP Form Data node does nothing. The form_item output is only meaningful once it's inside a form container, so if your POST looks empty, check that the item actually reached HTTPPost's form-data path through HTTP Form Data rather than floating disconnected on the canvas.

    CategoryHTTP/Form Data

    Inputs (2)

    NameTypeDefaultDescription
    nameSTRINGfield_name
    valueSTRINGfield_value

    Outputs (1)

    NameTypeDescription
    form_itemHTTP_FORM_ITEM