WebSocket

Von Connic

Über einen WebSocket streamt der Agent seine Antwort während der Generierung auf derselben Verbindung zurück. Sessions bleiben über mehrere Nachrichten erhalten, sodass Gespräche ihren Kontext behalten. Keine SSE-Infrastruktur und keine eigene Keepalive-Logik.

Sync

Leg los Dokumentation

Überblick

Die WebSocket-Verbindung hält eine persistente Full-Duplex-Verbindung zwischen einem Client und einem Agenten. Der Client authentifiziert sich einmal und sendet dann JSON-Nachrichten. Jede Nachricht löst einen Run aus und die Antwort wird während der Generierung zurückgestreamt: ein stream_start Event, stream_chunk Events mit Textfragmenten und ein stream_end mit vollständiger Antwort und Token-Nutzung. Bei deaktiviertem Streaming kommt stattdessen ein einziges vollständiges Response Event.

Jede Verbindung ist eine Session mit eigenem Gesprächsverlauf, sodass Multi-Turn-Chats ohne eigenen Session Store funktionieren. Auch die Streaming-Infrastruktur entfällt: keine SSE Endpoints, kein Chunk Buffering und keine Keepalive-Logik. Die Verbindung übernimmt Ping/Pong und ein sauberes Schließen.

So funktioniert es

1

Verbindung erstellen

Füge im Verbindungsdiagramm des Agenten eine WebSocket-Verbindung hinzu. WebSocket-Verbindungen laufen im Sync-Modus: Die Verbindung bleibt offen und Antworten kommen über denselben Socket zurück.

2

URL und Secret kopieren

Im Detailbereich stehen WebSocket URL und Secret. Die Authentifizierung ist standardmäßig aktiviert. Übergib das Secret als X-Connic-Secret-Query-Parameter oder Header. Deaktiviere Require Authentication nur, wenn Middleware die Clients vorher validiert.

3

Verbinden und chatten

Öffne den Socket mit einem WebSocket-Client und sende eine JSON-Nachricht. Du erhältst gestreamte Textteile oder eine vollständige Antwort. Nachrichten derselben Verbindung teilen eine Session, sodass sich der Agent an frühere Nachrichten erinnert.

Muster für den Produktivbetrieb

Muster für den Produktivbetrieb, bei denen Connic Queues, Worker und Scheduler betreibt.

Trigger

Nutzer sendet eine Nachricht

ws://your-app/chat

Agent-Aktion

Der Agent streamt die Antwort während der Generierung und lädt Informationen aus verbundenen Produktdaten. Der Session-Kontext bleibt über mehrere Nachrichten erhalten.

Trigger

Nutzer sendet eine Nachricht

ws://your-app/chat

Agent-Aktion

Der Agent streamt die Antwort während der Generierung und lädt Informationen aus verbundenen Produktdaten. Der Session-Kontext bleibt über mehrere Nachrichten erhalten.

Lies die Dokumentation zu WebSocket

Streaming, Sessions und Limits

Bei aktiviertem Streaming (Standard) wird jede Nachricht mit einem ack bestätigt. Danach folgen stream_chunk Events und abschließend ein stream_end mit vollständigem Text und Token-Nutzung. Eine optionale id pro Nachricht ordnet Antworten ihren Anfragen zu. Sessions laufen nach Inaktivität ab (standardmäßig nach 1 Stunde) und sind auf eine festgelegte Anzahl von Nachrichten begrenzt (standardmäßig 100); das Schließen der Verbindung beendet die Session.

Im Hintergrund ist jede Nachricht ein normaler Agent Run mit vollständigen Traces, Token- und Kosten-Tracking sowie denselben Guardrails und Approval-Regeln wie jeder andere Trigger. So lässt sich eine Chat-UI im Produktivbetrieb genauso gut debuggen wie ein Batch Job.

Authentifizierung und Datei-Input

Secret-Key-Authentifizierung ist standardmäßig aktiv und kann deaktiviert werden, wenn Middleware Verbindungen validiert, bevor sie Connic erreichen. Clients können Dokumente, Bilder oder Audio an ein multimodales Modell senden, indem sie ein base64-codiertes files Array in die Payload aufnehmen. Es folgt derselben Konvention wie multipart Webhook Uploads; jede Datei wird zu einem binären Teil des Modell-Inputs. WebSocket-Dokumentation: Nachrichten- und Event-Formate.

Informationen

Publisher: Von Connic
Verbindungen: Verbindungen
Modi: Sync
Dokumentation: WebSocket Docs

Häufig gestellte Fragen

Dazu wird eine WebSocket-Verbindung erstellt, der Socket im Browser geöffnet, die Verbindung mit ihrem Secret authentifiziert und eine JSON-Nachricht gesendet. Die Antwort des Agenten kommt während der Generierung als stream_chunk Events mit Textfragmenten zurück und endet mit einem stream_end inklusive vollständigem Text und Token-Nutzung.

Ja. Jede Verbindung erzeugt eine Session und Nachrichten in derselben Session teilen ihren Gesprächsverlauf, sodass sich der Agent an frühere Nachrichten erinnert. Sessions laufen nach Inaktivität ab (standardmäßig nach 1 Stunde) und sind auf 100 Nachrichten begrenzt. Das Schließen der Verbindung beendet die Session.

WebSocket eignet sich für gestreamte Antworten und Multi-Turn-Kontext: Die Verbindung bleibt offen, Chunks treffen während der Generierung ein und die Session behält den Verlauf. Für einmalige Request-Response-Aufrufe mit einem einfachen HTTP POST bietet sich der Vergleich mit der HTTP-Webhook-Verbindung an.

Plane einen Agenten-Workflow mit WebSocket und Connic

Beschreibe die Event-Quelle, die Struktur der Payload, das Ziel für die Ergebnisse und die Anforderungen an private Netzwerke oder Freigaben. Wir helfen, WebSocket mit dem passenden Verbindungsmodus, Deployment und Monitoring in Connic einzurichten.

Sprich mit Sales

Weitere Verbindungen

Entdecke den Marketplace

E-Mail (SMTP/IMAP)

Postfächer lesen und Antworten senden

Einen Bot mit einem Agenten betreiben

Slack

Agenten auslösen und Ergebnisse in Slack senden

AWS SQS

Eine Queue mit einem Agenten abarbeiten

Apache Kafka

Topics konsumieren und Ergebnisse veröffentlichen

MCP Server

Agenten als MCP Tools bereitstellen