SendJsonOnWebSocket

Here's the situation: you've got ComfyUI running a workflow, and you want the workflow itself to hand data - a caption, some metadata, a JSON payload - back to your own code. Not saved to a file, not logged to the console, delivered live to whatever client is watching. SendJsonOnWebSocket is that node, and despite the intimidating name it's about as simple as a node gets: two inputs, no outputs, no API key, no external service.

What it actually does

ComfyUI's frontend isn't just a static page. When you run a prompt, the browser keeps a WebSocket open to the backend, and the backend pushes progress updates, previews, and finished images down that same socket. This node hooks into that exact mechanism via ComfyUI's PromptServer.instance.send_sync(event, json, client_id). It takes your data, names it, and fires it over the socket to the connected browser session. No network round-trip, nothing to sign up for, no config - it's using plumbing that already exists. The name "WebSocket" isn't a lie, but "your workflow can broadcast JSON to the UI" is the honest description.

When you'd reach for it

The built-in ComfyUI UI is great, but it's not always the whole product. If you're building a custom frontend around ComfyUI - a client app, a dashboard, an automation harness - or wiring a workflow into a larger pipeline, this is the clean way to get structured data out at a specific point in the graph. It's a sibling of the same pack's SendImageOnWebSocket, which streams images down the same socket; use the two together and a custom UI can show you a live image and its associated JSON (prompt used, seed, whatever) without either of you ever touching a file system.

The honest caveat: this is a plumbing node for people already building on ComfyUI's API. If your "app" is the normal ComfyUI page, you don't need it. Nothing in the stock UI listens for arbitrary event names, so on its own it's invisible.

The two inputs

• event (STRING, single-line): the message type you're inventing. You pick this, and it becomes the event name your listener matches on - something like "my_custom_data".
• json (JSON): the payload. Wire in any JSON output - metadata from a captioner, a settings object, a list, a string - and it gets serialized over the socket as-is.

It's an output node with no outputs, which just means it runs at the end of the graph and reports nothing back to other nodes. Whatever you feed in is the message.

Listening on the other end

This is where you do the work, because the node is only half the conversation. On the client side you connect to ComfyUI's WebSocket (the same ws://your-host:8188/ws?clientId=... endpoint the UI uses) and handle the event you named. The standard ComfyUI frontend already does this internally for its own message types; you're adding yours to the same stream. If nothing is listening, the message doesn't error - it just evaporates.

Installing it

It's part of the un-seen/comfyui-tensorops pack. In ComfyUI Manager, search for comfyui-tensorops and install, or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/un-seen/comfyui-tensorops

then restart ComfyUI. Heads-up: this pack is small in spirit but heavy on dependencies - installing it pulls transformers, boto3, redis, fal-client, replicate, and surrealist even if you only want the WebSocket node. Manager installs the whole requirements.txt, so budget some setup time.

Where people get burned

• Fire-and-forget. If your client isn't connected to that specific ComfyUI instance, or connected to a different client_id, the message goes nowhere and you get zero feedback. It's a broadcast to the current UI session, not a durable queue.
• Don't use a plain REST call. This is the WebSocket channel; an HTTP request to the API won't see these messages. Your listener has to be a WebSocket client.
• The pack has baggage. This repo has a history of registering node names that collide with Kijai's Florence2 nodes (Kijai himself flagged it back in 2024 when ComfyUI Manager's auto-install grabbed the wrong pack). If Manager ever offers this pack when you're trying to install something else, say no and install the other thing explicitly.

Test it small first: feed a tiny JSON, watch your client log, then trust it in the real workflow.