WebSocket
Open a WebSocket and your agent streams its response back over the same socket as it is generated. Sessions persist across turns, so multi-step conversations remember context. No SSE plumbing, no keepalive logic to write.
Overview
The WebSocket connector holds a persistent, full-duplex connection between your client and an agent. The client authenticates once, then sends JSON messages; each message triggers a run, and the response streams back as it is generated: a stream_start event, stream_chunk events with partial text, and a stream_end carrying the full response and token usage. Turn streaming off and you get one complete response event instead.
Each connection is a session with its own conversation history, so multi-turn chat works without a session store on your side. You skip the streaming plumbing too: no SSE endpoints, no chunk buffering, no keepalive logic to write; the connector handles ping/pong and graceful close.
How it works
Create the connector
Add a WebSocket connector from your agent's Connector Flow. WebSocket connectors run in sync mode: the connection stays open and responses come back on the same socket.
Copy the URL and secret
The connector detail drawer opens with the WebSocket URL and secret. Authentication is enabled by default; pass the secret via the X-Connic-Secret query parameter or header, and disable Require Authentication only when middleware validates clients first.
Connect and chat
Open the socket from any WebSocket client, send a JSON message, and receive streamed chunks or a complete response. Messages on the same connection share a session, so the agent remembers earlier turns.
What you can build
Patterns teams ship in production. No queues, workers, or schedulers to run.
User sends a message
ws://your-app/chatAgent streams the reply as it is generated, holds context across the session, and pulls answers from your product data — a chat UI your users actually trust.
User sends a message
ws://your-app/chatAgent streams the reply as it is generated, holds context across the session, and pulls answers from your product data — a chat UI your users actually trust.
Streaming, sessions, and limits
With streaming on (the default), each message is acknowledged with an ack, then the response arrives as stream_chunk events followed by a stream_end with the full text and token usage. An optional id on each message correlates responses to requests. Sessions expire after inactivity (1 hour by default) and cap the number of messages per session (100 by default); closing the connection ends the session.
Every message is a normal agent run underneath, with full traces, token and cost tracking, and the same guardrails and approval rules as any other trigger. A chat UI in production stays as debuggable as a batch job.
Authentication and file input
Secret-key authentication is on by default and can be turned off when middleware validates connections before they reach Connic. Clients can also send documents, images, or audio to a multimodal model by including a base64-encoded files array in the payload; it follows the same convention as multipart webhook uploads, with each file becoming a binary part of the model input. See the full message and event formats in the WebSocket docs.
Information
- Publisher
- By Connic
- Category
- Connectors
- Modes
- Sync
- Documentation
- WebSocket docs
Frequently Asked Questions
How do I stream AI agent responses to the browser?
stream_chunk events with partial text as it is generated, ending with a stream_end that includes the full text and token usage.Does the connector keep conversation history across messages?
Should I use WebSocket or a sync webhook for chat?
Bring the event source, payload shape, result destination, and any private-network or approval requirements. We will map WebSocket to the right Connic connector mode, deployment path, and observability setup.
Talk to Sales