Custom Image Generation API Call Node

Every other image node in this pack is opinionated: it knows the exact shape of the DALL-E request, or the Flux request, or the Ideogram request, and it builds the JSON for you. This one has no opinions at all. You paste a raw JSON payload into it, it POSTs that payload to an endpoint, and it returns whatever image URL comes back. That makes it the node you reach for when the API you're testing doesn't match any of the presets - a custom endpoint, a work-in-progress provider, or just something you want to probe without writing glue code. The pack's README literally frames it as the "test custom image-generation endpoints without writing glue code" node.

How it works

The mechanism is embarrassingly simple, in a good way:

• It takes your payload string, trims it, and if it doesn't start with { and end with }, it wraps it in braces for you - a small kindness when you've pasted a partial JSON fragment.
• It parses it as JSON (and throws a clear "Invalid JSON payload" error if you mangled it).
• It POSTs to api_url with a Bearer header from api_key.
• It expects the response as response_json["data"][0]["url"] - the common OpenAI-style shape where the first generated image is under data[0].url - and returns that as image_url.

Retries on connection errors and timeouts, three attempts, exponential backoff. Nothing clever, nothing that'll surprise you.

The inputs and outputs that matter

Three inputs, one output - this is a short node.

• payload (multiline STRING) - the entire request body. For a typical images endpoint that's something like {"model": "my-model", "prompt": "a lighthouse at dusk", "size": "1024x1024"}.
• api_url - defaults to https://api.hyprlab.io/v1/images/generations. It's a placeholder; your endpoint goes here.
• api_key - the Bearer key.

The output is image_url (STRING) - the URL of the generated image. Feed that into the pack's Load Image from URL (BillBum) node to turn it into an IMAGE tensor. You'll notice the loop: this node returns URLs, so its natural companion is the URL-loading node, not the base64 one.

Installing it

One node in AhBumm/ComfyUI_BillBum_APIset_Nodes. ComfyUI Manager → search "billbum" → install, or:

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

Restart ComfyUI after installing. Only standard deps (requests, pillow, tenacity), no models.

Common issues

• It only handles URL responses. The hardcoded expectation is data[0].url. If your endpoint returns base64 (b64_json) instead, you'll get a KeyError or a "Image URL not found" exception. That's by design - for base64-returning endpoints, use the DALL-E or Flux nodes, which handle that shape.
• Strict response path. Some APIs nest the image differently - data[0].url is the assumption and there's no fallback. If you're hitting a non-standard API, this node will tell you loudly.
• JSON errors are surfaced, not hidden. The error message tells you exactly which character of your payload is invalid, which is genuinely helpful. The node also prints the full response to the console, so when something fails, read the ComfyUI terminal output - the actual server response is sitting right there.
• No auth beyond Bearer. If your endpoint needs query params, extra headers, or a different auth scheme, this node can't express it. That's the trade-off for being this generic.

It's not the node you'll build a permanent workflow around - but when you're reverse-engineering a new image API, being able to paste a raw payload and see the raw response without touching Python is exactly what you want.