Donut Image Reporter (HTTP)

Donut Prompt Receiver gives ComfyUI a front door - an app POSTs a prompt to a local HTTP port and your workflow runs. But a door is only half of a conversation. Someone has to send the image back. That's this node's job: it sits after your final image output, and when a run was triggered over HTTP it saves the result so the receiver's GET /result/{id} endpoint can serve it back to whatever asked. Use it as the bookend to the receiver and you get a genuine request/response loop - prompt in, PNG out - with no ComfyUI API knowledge required.

It's from the same pack as Donut Prompt Receiver and carries the same assumptions: loopback-only, desktop ComfyUI, local companion app. Standalone it does nothing interesting; paired with the receiver it completes the round trip.

How it works

The node is an output node that passes its images through untouched and does its real work as a side effect. When a run carries a prompt ID (the receiver injects it into the _api_prompt_id input, with a fallback to the last-known ID), the reporter saves the first image in the batch - images[0] - as api_result_{prompt_id}.{file_format} and registers it with the receiver's server. From then on, GET http://localhost:8001/result/{prompt_id} returns that file with an X-Prompt-Id header, or a 202 "still processing" if it isn't ready yet.

If no prompt ID is present - a normal manual run from the canvas - the node does nothing except pass the image through. That's fine: it's an output node, so it costs you nothing to leave inline.

The inputs that matter

• images - your final IMAGE tensor, straight from the last node in the chain.
• file_format - png, jpg, webp (default), tiff, or bmp. WebP is the sensible default: small and fast for an app to fetch.
• quality (1–100, default 90) - applies to jpg/webp/tiff. Leave it unless the app on the other end cares about bytes.
• lossless_webp and optimize - only matter for webp/png; flip them if size or fidelity beats speed.

The _api_prompt_id input is internal plumbing (the extension hides it) - you don't set it, the receiver does.

The only output is images, a straight pass-through of what you fed in. Don't expect the node to transform anything; it's a checkpoint, not a processor.

Install

Same as its sibling: install the pack via ComfyUI Manager (search "ComfyUI-DonutLocalAutomation"), or

cd ComfyUI/custom_nodes
git clone https://github.com/DonutsDelivery/ComfyUI-DonutLocalAutomation

then restart ComfyUI. The only runtime dependency is requests (and Pillow, which ComfyUI bundles) - no models, no downloads.

The gotcha that will bite you

Here's the thing nobody tells you: the reporter writes to a hardcoded path - /home/user/Programs/ComfyUI-new/ComfyUI/temp/, straight out of the author's own machine. Not the temp dir ComfyUI actually uses, not a configurable field. If that directory doesn't exist on your system, the save fails silently - the exception is caught, a [DonutImageReporter] Error saving result line lands in your console, the image still passes through, and GET /result/{id} just stays "pending" forever while you wonder what's wrong.

If the reporter seems to do nothing, check two things: that the workflow run was actually API-triggered (a manual run won't save anything), and that that exact directory exists on your machine. Creating it is the crude fix:

mkdir -p /home/user/Programs/ComfyUI-new/ComfyUI/temp/

It's ugly, but it's what the shipped code expects. Don't rely on this node for production-grade result delivery until the path becomes configurable - for anything beyond a quick local script, you may want to save images with a proper output node and hand the file path back to your app yourself. Within those limits, though, it's exactly the reply button the receiver needs.