WebSocket
Open a WebSocket and the 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 the 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. With streaming off, the client receives one complete response event instead.
Each connection is a session with its own conversation history, so multi-turn chat works without a client-side session store. The connector also replaces the streaming plumbing: 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 the 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.
Production patterns
Patterns teams ship in production, with Connic running the queues, workers, and schedulers.
User sends a message
ws://your-app/chatAgent streams the reply as it is generated, holds context across the session, and pulls answers from connected product data for a trusted chat UI.
User sends a message
ws://your-app/chatAgent streams the reply as it is generated, holds context across the session, and pulls answers from connected product data for a trusted chat UI.
User is editing
ws://your-app/collabAgent watches the document as users edit, suggests rewrites, and flags mistakes inline. Everyone in the room sees each change without a refresh.
User is editing
ws://your-app/collabAgent watches the document as users edit, suggests rewrites, and flags mistakes inline. Everyone in the room sees each change without a refresh.
Customer asks a question
ws://your-app/supportAgent streams an answer from the connected help docs as it is generated. If the question needs a human, the full transcript hands off to a teammate without losing a word.
Customer asks a question
ws://your-app/supportAgent streams an answer from the connected help docs as it is generated. If the question needs a human, the full transcript hands off to a teammate without losing a word.
New user signs up
ws://your-app/onboardAgent walks the user through setup step by step, answers questions as they come up, and skips completed steps. Day-one activation feels like a guided tour instead of a checklist.
New user signs up
ws://your-app/onboardAgent walks the user through setup step by step, answers questions as they come up, and skips completed steps. Day-one activation feels like a guided tour instead of a checklist.
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
- Connectors
- Connectors
- Modes
- Sync
- Documentation
- WebSocket docs
Frequently Asked Questions
stream_chunk events with partial text as it is generated, ending with a stream_end that includes the full text and token usage.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 SalesMore connectors
Browse the marketplaceCron Scheduler
Run an agent on a cron expression
Stripe
Run an agent on payment events
PostgreSQL
React to row inserts via LISTEN/NOTIFY
Twilio Voice
Answer incoming calls with a voice agent
Twilio Messaging
Receive and send SMS, WhatsApp, and RCS messages
Telnyx Messaging
Receive and send SMS/MMS, WhatsApp, and RCS through Telnyx