Chat-Widget
Alle Endpunkte, die das eingebettete Chat-Widget auf Kundenwebsites nutzt.
Diese Gruppe bündelt alle öffentlichen Endpunkte, die das eingebettete Chat-Widget auf Kundenwebsites verwendet: den Erreichbarkeits-Check (`GET /api/public/widget/health`), das Abrufen der öffentlichen Widget-Konfiguration (`GET /api/public/widget/config/:widget_code`) sowie Nachrichtenversand und -verlauf (`POST /api/public/widget/message`, `GET /api/public/widget/history`). Die Domainfreigabe wird bei der Widget-Erstellung durch Zentor gepflegt; dafür gibt es keine Einstellungsoberfläche im Tenant-Dashboard. Bei einer nicht freigegebenen Herkunft kann der Fehlercode `WIDGET_ORIGIN_DENIED` auftreten. Die Widget-Erstellung selbst ist dem Master-Admin vorbehalten, während der Tenant den fertigen Einbettungscode erhält.
Ein allgemeines Entwickler-API-Key-System existiert nicht. `health` und `config` sind ohne Authentifizierung erreichbar, weil sie für die Initialisierung des Widgets im Browser bestimmt sind. `message` und `history` benötigen dagegen den `X-Widget-Token`-Header und werden zusätzlich gegen eine serverseitige Origin-Allowlist geprüft. Der Embed-Token wird bei der Widget-Erstellung einmalig im Klartext angezeigt und darf nicht in öffentlichen Repositories, Support-Screenshots oder Browser-Logs erscheinen.
Jede Detailseite dieser Gruppe beschreibt Methode, Pfad, Authentifizierung, Idempotenz und die dokumentierten Fehlercodes des jeweiligen Endpunkts einzeln. Ein erfolgreicher Aufruf eines Endpunkts belegt nicht automatisch, dass ein anderer Endpunkt derselben Gruppe ebenfalls erfolgreich verlaufen würde — insbesondere bestätigt ein grüner `health`-Check weder ein gültiges Widget noch eine freigegebene Origin oder die Erreichbarkeit eines KI-Providers.
Das bestätigte plattformweite API-Limit beträgt 2.000 Anfragen innerhalb von 15 Minuten. Ein davon abweichendes Limit für einen einzelnen Widget-Endpunkt wird nur genannt, wenn es für diesen Endpunkt ausdrücklich belegt ist. `message` ist nicht idempotent; ein Client darf einen unklar abgebrochenen Sendevorgang nicht automatisch wiederholen, ohne vorher zu prüfen, ob die erste Nachricht bereits verarbeitet wurde.
Die technische Prüfung dieser Gruppe stützt sich auf die Registry unter `app/frontend/src/content/api-reference/groups/widget.ts` und die zugehörigen Backend-Routen. Jede Detailseite kennzeichnet, ob ein Erfolgspfad live, ein Negativpfad oder nur eine Code-Analogie geprüft wurde — diese Unterscheidung gilt für die gesamte Gruppe und darf nicht durch pauschale Erfolgsaussagen ersetzt werden.