Chat-API-Referenz

POST, GET und SSE-Endpunkte für Chat-Integrationen.

Wenn du eigene Clients baust (Website-Widget, Slack-Bot, interne App), sprichst du direkt mit der Chat-API.

#Authentifizierung

Zwei Wege:

• Session-Cookie (für eingeloggte Weboberfläche)
• JWT Bearer-Token (für Mobile / externe Integrationen)

Authorization: Bearer <token>

JWT-Tokens erzeugt der Login-Endpunkt. Frage deinen Betreiber nach der Ausstellungsprozedur für Service-Tokens.

#Endpunkte

#POST /chat/index

Sendet eine Nachricht und wartet auf die komplette Antwort.

Request-Body (JSON oder multipart/form-data):

{
  "chat_id": "unified_42",
  "tenant": "mecomedia",
  "message": "Was stand heute in meinen Mails?",
  "test_mode": false
}

Bei Datei-Uploads: multipart/form-data mit zusätzlichem file-Feld.

Response:

{
  "reply": "<p>Heute stand …</p>"
}

Für Klick-Vorschläge nutze /chat/stream — sie kommen dort als eigenes suggestions-Event.

#GET /chat/stream

Wie oben, aber mit SSE-Streaming. Details: Streaming & SSE.

#GET /chat/resume

Replayed persistierte Messages seit since-Zeitstempel als SSE-Stream. KEIN neuer User-Turn, kein LLM-Call. Use case: App-Resume nach Hintergrund.

GET /chat/resume?chat_id=unified_42&tenant=mecomedia&since=2026-05-17T22:30:00Z

Optional Header: Last-Event-ID: 42 (oder ?last_event_id=42) — Backend übernimmt den Counter.

Emittiert: message, tool_start/tool_complete (replayed), dann done mit {resumed: true, count: N}. Siehe Streaming & SSE.

#GET /chat/history

Liefert den Verlauf einer Chat-Session.

GET /chat/history?chat_id=unified_42&tenant=mecomedia

Response:

{
  "messages": [
    { "role": "user", "content": "...", "created": "..." },
    { "role": "assistant", "content": "...", "created": "..." }
  ]
}

#POST /chat/reset

Leert den Verlauf einer Chat-Session, ohne die ID zu ändern.

{ "chat_id": "unified_42", "tenant": "mecomedia" }

#Parameter im Detail

#Status-Codes

#Limits

• Upload-Größe: siehe Datei-Uploads
• Verlauf: das Modell sieht jeweils die letzten 50 Nachrichten der Session

Weitere Limits (z. B. Nachrichten pro Minute) richtet die Betriebsseite bei Bedarf ein — frage deinen Betreiber.

#Fehlerformat

{ "error": { "code": "TOOL_FAILED", "message": "getOrders: 502 Bad Gateway" } }

Bei SSE-Streams kommt dieselbe Struktur als error-Event vor dem done.