Vier Oberflächen
API, Webhook, Widget-SDK und Workflow sind nicht dasselbe
Beginnen Sie mit einem konkreten Geschäftsvorgang: etwa Kontakt im CRM anlegen, Ticketstatus zurückschreiben oder eine Nachricht revisionsfähig archivieren. Schreiben Sie dafür Sender, Empfänger, Trigger, Datenfelder, Latenz, Fehlerpfad und verantwortliches System auf.
Ein Marketingbegriff wie API-fähig reicht nicht. Fordern Sie Basis-URL, Version, Authentifizierungsart, Scopes, Endpunkte, Eventkatalog, Beispieldaten, Pagination, Rate Limits, Changelog, Deprecation-Frist und Supportmodell für genau Ihren Use Case.
| Oberfläche | Typischer Zweck | Nicht automatisch enthalten |
|---|---|---|
| Produkt-API | Datensätze lesen, schreiben oder Aktionen auslösen | Ereignisse in Echtzeit oder Benutzeroberfläche |
| Webhook | bei ausgewählten Ereignissen einen Endpoint benachrichtigen | Abfrage beliebiger Daten, vollständige Historie oder Exactly-once |
| Widget-SDK | Browserverhalten, Identität, Darstellung oder Tracking steuern | serverseitige Agenten-, Export- oder Compliance-API |
| Power Platform | Teams, Connectoren und Zielsysteme in einem Flow orchestrieren | allgemeine native Produkt-API oder fertiger Connector für jedes CRM |
Evidenzmatrix
Was die offiziellen Quellen tatsächlich belegen
| Produkt | Belegt | Grenze vor Kauf |
|---|---|---|
| WebChat | kanalbezogenes Triggerwort, Teams-Connector, Power Automate und optionale Zielsysteme | keine allgemeine Produkt-API, Webhook-Oberfläche oder Widget-SDK in den geprüften öffentlichen Quellen belegt |
| Chatwoot | Application-, Client- und Platform-APIs; auswählbare Konto-Webhooks mit HMAC-Signatur | Tokenrechte, API-Klasse, Cloud/Self-hosted-Grenze und Zustellsemantik je Release prüfen |
| Tidio | OpenAPI, Widget SDK und signierte Webhooks; Topics, Version und Webhook-ID | Webhooks laut Doku nur Plus/Premium und für Owner/Admin; API-Änderungen erzeugen keine Webhooks |
| LiveChat | Agent-/Customer-Chat-APIs, Web/RTM, registrierbare Webhooks und granulare Scopes | App, OAuth/PAT, Rollen, Eventfilter, Tarif und Versionsstatus konkret abnehmen |
Betrieb
At-least-once verlangt Idempotenz und Abgleich
Tidio dokumentiert ausdrücklich mögliche Duplikate, nicht garantierte Reihenfolge, eine eindeutige Webhook-ID und dass OpenAPI-Änderungen keine Webhooks auslösen. LiveChat nennt einen kurzen Bestätigungszeitraum und begrenzte Wiederholungen. Chatwoot dokumentiert Signatur-, Zeitstempel- und Delivery-Header, aber die für Ihren Release nötige Retry- und Reihenfolgelogik muss der PoC beweisen.
Ein Dashboard mit grünen HTTP-Codes genügt nicht. Messen Sie empfangene, verifizierte, deduplizierte, verarbeitete, fehlgeschlagene und abgeglichene Events getrennt und korrelieren Sie sie mit einer fachlichen Objekt-ID.
- Antworten Sie dem Webhook schnell mit 2xx und verarbeiten Sie Nutzlasten danach asynchron in einer Queue.
- Prüfen Sie Signatur gegen den unveränderten Rohbody, Zeitstempel und erlaubtes Zeitfenster; rotieren Sie Secrets kontrolliert.
- Nutzen Sie Delivery-/Webhook- oder Event-ID als Deduplizierungsschlüssel und machen Sie jede Seitwirkung retry-sicher.
- Sortieren Sie nach fachlicher Eventzeit und stabiler ID; Empfangsreihenfolge darf keine Geschäftslogik bestimmen.
- Speichern Sie Quarantäne und Dead-letter-Fälle, alarmieren Sie und ermöglichen Sie einen kontrollierten Replay.
- Führen Sie regelmäßig API-Reconciliation durch, weil Webhooks verzögert, doppelt, gefiltert oder nicht erzeugt sein können.
- Versionieren Sie Payloadschema und Consumer; unbekannte Felder tolerieren, fehlende Pflichtfelder stoppen und Deprecations überwachen.
Security & Datenschutz
Token, Payload und Rückschreibrechte minimieren
Ein korrekt signierter Webhook beweist nur Herkunft und Integrität unter dem geteilten Geheimnis. Er beweist nicht, dass der Absender fachlich berechtigt war oder dass Ihr Empfänger den Vorgang ausführen darf.
Bei einem Teams-/Power-Platform-Weg gehören zusätzlich Flow-Owner, Verbindungskonten, DLP-Richtlinien, Umgebungen, Connector-Lizenzen und der externe Rückkanal in dasselbe Kontrollmodell.
- Trennen Sie Test und Produktion, ausgehende Webhook-Secrets, API-Tokens und interaktive Benutzeridentitäten.
- Vergeben Sie nur nötige Read-/Write-Scopes; globale Chat-, Kontakt- oder Adminrechte brauchen begründete Freigabe.
- Nehmen Sie Name, E-Mail, Telefonnummer, Nachrichtentext, Anhänge, IP-/Browserdaten und interne Notizen ins Datenflussregister auf.
- Verschlüsseln Sie Queue, Logs, Replay-Speicher und Secrets; maskieren Sie personenbezogene Inhalte in Telemetrie.
- Schützen Sie Rückschreibaktionen mit Zustandsprüfung, Allowlist, Vier-Augen-Freigabe für riskante Aktionen und Auditlog.
- Definieren Sie Retention, Auskunft und Löschung auch für Eventkopien, Fehlerqueues, Exporte und Backups.
Abnahme
Acht Tests vor der Integrationsentscheidung
- 01
Vertrag einfrieren
Use Case, System of Record, API-Version, Endpunkte, Events, Felder und erwartete Latenz festhalten.
- 02
Rechte negativ testen
Abgelaufener, falscher und zu schwacher Token sowie fremdes Konto müssen sicher scheitern.
- 03
Signatur prüfen
Manipulierte Nutzlast, alter Zeitstempel, falsches Secret und Replay dürfen keine Aktion auslösen.
- 04
Duplikate senden
Dasselbe Event mehrfach und parallel zustellen; Ergebnis darf nur einmal fachlich wirksam werden.
- 05
Reihenfolge brechen
Update vor Create, verspätetes Close und gleichzeitige Nachrichten kontrolliert verarbeiten.
- 06
Ausfall erzwingen
Timeout, 500, Queue-Stopp, Zielsystemfehler und Rate Limit mit Retry, Alarm und Recovery testen.
- 07
Lücke abgleichen
Webhook absichtlich verlieren oder API-Ursprung verwenden und den Datensatz per Reconciliation finden.
- 08
Exit beweisen
Secret rotieren, App entziehen, Webhook löschen, Delta exportieren und gespeicherte Eventkopien fristgerecht entfernen.