Success Callback

SuccessCallback is the exit door of a workflow that isn't being watched by a human. If you're building anything around ComfyUI's API - a bot, a small SaaS wrapper, a Discord command that queues a render and needs to know when it's ready - this node is the piece that tells your backend "this job finished, here's the result."

What it's actually for

Run ComfyUI through its API instead of the browser and you lose something the UI gives you for free: a person watching the queue. Nothing tells your code a generation finished - you either poll /history on a loop, or you build something to push a notification out the moment it's done. SuccessCallback is the author's answer to the second option: it takes the ID of the job, the location of the image it produced, and an address to report to, and fires a request over. The author's own framing in the README - "callback for successful image generation, in conjunction with the back-end" - says plainly that this only makes sense if you've got a backend of your own listening on the other end. If you're a solo hobbyist working entirely inside the ComfyUI UI, there's nothing here for you; this is glue for people running their own service on top of ComfyUI.

Inputs and outputs

All three inputs are required - there's no optional configuration here, just the three pieces of information the callback needs to be meaningful:

• request_url (STRING, default http://localhost:8196) - the endpoint on your own backend that's listening for a "job done" ping. The default is obviously a placeholder; point it at wherever your service actually runs.
• image_url (STRING, default http://localhost:8196) - where the finished image lives. This node doesn't generate or upload anything itself, so you'll be wiring this in from whatever step in your workflow actually saved or uploaded the output.
• prompt_id (STRING, default "example") - which job this callback is about. This is exactly what the companion node in this pack, GetPromptId, produces - wire its promt_id output straight into this field, and your backend can match the callback to the specific job it queued.

The output is text (STRING) - the response your callback produced. Treat it as a debug string: route it into a display node while you're setting this up so you can actually see what came back, rather than firing requests blind.

Installing it

It ships in the same tiny repo as GetPromptId, so one install gets you both nodes:

• ComfyUI Manager - search "Comfyui_Get_promptId," install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/xs315431/Comfyui_Get_promptId.git, restart.

No extra dependencies or model files in the README - it's a plain Python node making a network call, nothing heavier than that.

Common issues

The defaults are the first trap: both request_url and image_url default to the exact same placeholder address. Forget to change either one and the node will happily fire a request at localhost:8196 with nothing there to receive it - no crash in the UI, just a call that goes nowhere and a backend that never hears from ComfyUI. Change both before you trust this in a real pipeline.

The second trap is the same one that catches GetPromptId: the schema marks this node is_output_node: false, which means ComfyUI's executor only runs it if something downstream actually depends on it. Drop SuccessCallback at the very end of a graph, don't connect its text output to anything, and there's a real chance ComfyUI prunes it out of execution entirely - the callback that's supposed to be the whole point of the node just never fires. Wire text into even a basic display/preview node so the executor has a reason to run this branch at all.

Beyond that, remember this node makes an outbound network call from inside your workflow - a genuinely arbitrary one, since it's just Python hitting whatever URL you give it. That's worth keeping in mind for the same reason the wider ComfyUI custom-node ecosystem gets flagged for security concerns generally: nodes execute with full access and no sandboxing, so make sure request_url points somewhere you actually trust, especially if the machine running ComfyUI can reach anything sensitive on your network. And sanity-check reachability first - if ComfyUI is running on a remote box or inside a container, "localhost" in the default won't mean what you think it means once you swap in a real address; confirm the target is actually reachable from wherever the executor is running, not just from your own laptop.