API Parameter

What it is

API Parameter builds a JSON object out of named fields and hands you back a string. That's all it does. You'd reach for it when you want the API-facing settings of a run - temperature, size, token cap - to be visible, typed widgets on the canvas rather than a blob of JSON you keep hand-editing inside API Text / Vision or API Image. Chain two or three of them and each field gets its own node you can reroute, mute or feed from upstream.

It matters because of how the rest of the pack works: only parameters a request template explicitly references get sent to the provider. This node is the front half of that contract - it assembles the values, and the template decides which of them survive to the wire.

How it works

Each node takes a name, a value, and a value_type of json or string. That distinction is the entire node. With json, the value is parsed before insertion, so 0.7 becomes the number 0.7, true becomes a real boolean, and {"steps": 4} becomes an object. With string, whatever you typed stays a string - the quotes are added for you.

The optional parameters input is the chain. Wire another API Parameter's output into it and this node parses that JSON, adds or overwrites its own key, and outputs the merged object. Downstream instances win a collision, so order matters when two nodes set the same name. You can't type into that input - it's forceInput, socket-only - but it defaults to {} when nothing is connected, which is why a single node works standalone.

The single output is parameters, a STRING. Wire it into the parameters input of an API node. That's the whole graph edge.

The three fields, and what bites

name defaults to temperature and value to 0.7, straight from the pack author's example. They're the right defaults, because both stock templates (Chat Completions, and the image templates' size/n) work this way. Rename it to whatever your template actually references.

• name must be non-empty, and it becomes the literal JSON key.
• value is multiline, so pasting a small JSON object into it is fine - but only when value_type is json.
• value_type decides whether that value is parsed or quoted.

The failure modes are both loud and both easy to hit:

invalid_parameters: Expecting value: line 1 column 1 means you left value_type on json and gave it something that isn't valid JSON. high is not JSON. "high" is, and so is high with value_type set to string. This is the one people trip on: prose fields like a style or a negative caption almost always want string.

invalid_parameters: Expected a parameter name and an object. means the name box is empty, or the incoming parameters wasn't a JSON object.

The quiet failure

Guessing whether your parameter did anything is the real hazard. You can build four lovely typed parameter nodes, wire them all in, run the workflow, and see zero difference - because none of those keys appear in the request template. The engine sends exactly what {{params.your_name}} asks for and nothing else. If a setting seems ignored, open the template editor and check that the key is referenced in the body, headers, query or path. There's a Test API tab that previews the request before it costs you anything.

Install

The node ships with the pack, so there's nothing extra to install. In ComfyUI Manager search comfyui-custom-api; if the catalogue hasn't caught up, clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/Einzieg/ComfyUI-custom-api.git
/path/to/ComfyUI/venv/bin/python -m pip install -r ComfyUI-custom-api/requirements.txt

Dependencies are aiohttp, Pillow and numpy - no model downloads. Restart ComfyUI and refresh the browser. You'll find it under the Model API category, next to the other two nodes.