WebSockets and workflow messages

Use a WebSocket resource and node to push workflow events to connected clients. This is useful for progress updates, live dashboards, and notifications that should arrive without polling.

Create the channel#

Open Workflows → WebSockets and create or select the resource your clients will use. Review its connection details and access configuration. Use the generated or SDK-supported connection method rather than inventing a WebSocket URL from an HTTP action route.

Publish from a workflow#

Add a WebSocket node, select the resource, and configure the message body. Values from earlier nodes can be included with selectors.

Design a stable event contract, for example:

{
  "type": "report.ready",
  "reportId": "example-report",
  "status": "ready"
}

Use an event name and a record identifier so a client can decide whether to refresh its data. Keep private records behind authorized API reads rather than broadcasting an entire sensitive payload.

Connect and verify#

Connect a test client before running the workflow. Check that it receives one correctly shaped message and handles disconnect/reconnect. Test with the same workspace and environment configuration used by the publishing node.

A node can continue to a next step if connected; otherwise it is terminal for that path. Keep your HTTP response contract explicit when publishing events from a request-driven workflow.

Separate acknowledgement from completion#

An asynchronous action may return a receipt while processing continues in the background. Use a durable record or status endpoint to establish completion. A disconnected client can miss a transient event, so the app should be able to refresh its current state after reconnecting.

Use logs to verify the workflow actually reached the publishing node before diagnosing the client connection.