Zum Hauptinhalt springen
Alert-Webhooks senden die Alerts Ihres Teams an einen HTTPS-Endpoint, den Sie betreiben. Nutzen Sie sie, um ein Bereitschaftstool, eine Ticket-Warteschlange oder Ihr eigenes Operations-Dashboard zu speisen. Alert-Webhooks sind von Verifizierungs-Webhooks getrennt. Verifizierungs-Webhooks senden Sitzungs-, Entitäts- und Transaktionsergebnisse an Ihre Anwendung. Alert-Webhooks benachrichtigen Ihr Team, wenn etwas Aufmerksamkeit erfordert: eine Verifizierung, die auf eine manuelle Prüfung wartet, eine fehlgeschlagene Zahlung oder ein Dienstvorfall. Sie haben ihre eigene Payload, ihr eigenes Signaturgeheimnis, ihre eigene Signatur und einen eigenen Wiederholungszeitplan.

Ziel einrichten

Sie konfigurieren Alert-Webhooks in der Business Console, nicht über die API. Mitglieder, die die Organisationseinstellungen verwalten können, können Ziele hinzufügen, ändern und testen.
1

Ziel hinzufügen

Fügen Sie unter Organisationseinstellungen > Team-Benachrichtigungen ein Alert-Webhook-Ziel mit der URL Ihres Endpoints hinzu. Die URL muss https:// verwenden und zu einer öffentlichen Adresse auflösen.
2

Signaturgeheimnis speichern

Didit zeigt das vollständige Signaturgeheimnis, das mit whsec_ beginnt, nur einmal an. Speichern Sie es jetzt: Danach zeigt die Konsole nur noch die letzten vier Zeichen an.
3

Alerts an das Ziel weiterleiten

Das Hinzufügen eines Ziels sendet noch nichts an dieses. Fügen Sie das Ziel den Routing-Regeln der Alerts hinzu, die es empfangen soll.
4

Test senden

Klicken Sie auf Test senden, um einen alert.test-Alert zu senden, und prüfen Sie, ob Ihr Endpoint diesen akzeptiert.
Eine Organisation kann bis zu 25 Ziele in Team-Benachrichtigungen haben. Nur Live-Aktivitäten erreichen ein Ziel. Alerts zu Sandbox-Verifizierungen, Unternehmensverifizierungen, Transaktionen und AML-Treffern werden niemals an dieses gesendet.

Alert-Typen

Payload

Jeder Alert ist ein POST-Aufruf mit einem JSON-Body. Didit sendet den Body als kompaktes JSON mit sortierten Schlüsseln. Dieses Beispiel ist zur besseren Lesbarkeit formatiert:
data enthält immer:
  • event: der Ereignisschlüssel, zum Beispiel session_in_review.
  • label und value: worauf sich der Alert bezieht, zum Beispiel Session und #1042.
Einige Alert-Typen fügen data weitere Schlüssel hinzu:
  • alert.billing.autorefill_failed fügt paused hinzu, einen booleschen Wert, der true ist, wenn die automatische Aufladung jetzt pausiert wurde, bis Sie die Karte aktualisieren.
  • alert.service.degraded und alert.service.recovered fügen service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title und body hinzu. status ist bei alert.service.degraded entweder degraded oder down und bei alert.service.recovered entsprechend recovered. service verwendet die Dienstschlüssel aus GET /v3/status/, und incident_id der id eines Vorfalls dort entspricht.
Alerts enthalten niemals personenbezogene Daten von Endbenutzern oder Dokumentdaten. Sie identifizieren eine Sitzung, eine Transaktion oder ein anderes Element anhand seiner Nummer und verlinken darauf in der Konsole. Ignorieren Sie unbekannte webhook_type-Werte und data-Schlüssel, damit neue Werte Ihren Endpoint nicht beeinträchtigen.

Anfrage-Header

Signatur prüfen

X-Signature-V2 ist der hex-codierte HMAC-SHA256 des Strings <X-Timestamp>.<raw body>, berechnet mit dem Signiergeheimnis Ihres Ziels als Schlüssel.
  • Verwenden Sie das vollständige Geheimnis genau so, wie Didit es angezeigt hat, einschließlich des Präfixes whsec_.
  • Signieren Sie die rohen Anfrage-Bytes genau so, wie Sie sie empfangen haben. Das Parsen und erneute Serialisieren des JSON kann die Bytes verändern und die Überprüfung fehlschlagen lassen.
  • Vergleichen Sie die Signaturen in konstanter Zeit.
  • Weisen Sie Anfragen ab, deren X-Timestamp um mehr als 5 Minuten von Ihrer Systemzeit abweicht. Didit signiert jeden Versuch, einschließlich jedes Wiederholungsversuchs, mit einem neuen Zeitstempel, sodass dieses Zeitfenster niemals einen echten Wiederholungsversuch abweist.
  • Beantworten Sie eine fehlgeschlagene Prüfung mit 400. Eine Antwort mit 401, 403, 404 oder 410 markiert das Ziel für eine erneute Verbindung (siehe Wiederholungsversuche).
Alert-Webhooks werden nicht wie Verifizierungs-Webhooks signiert. Der Header heißt zwar ebenfalls X-Signature-V2, aber der signierte String ist ein anderer, und Alert-Webhooks senden weder X-Signature noch X-Signature-Simple. Verwenden Sie Ihren Verifizierer für Verifizierungs-Webhooks nicht wieder.

Node.js (Express)

Python (Flask)

Signiergeheimnis rotieren

Sie rotieren das Geheimnis auf dem Ziel unter Team-Benachrichtigungen. Didit zeigt das neue Geheimnis einmalig an und signiert jeden späteren Versuch damit, einschließlich Wiederholungsversuchen von Alerts, die vor der Rotation erstellt wurden. Das alte Geheimnis verliert sofort seine Gültigkeit. Es gibt keinen Übergangszeitraum, und kein Header enthält eine mit dem vorherigen Geheimnis erstellte Signatur. Deployen Sie das neue Geheimnis auf Ihrem Endpoint, sobald Sie es rotiert haben.

Wiederholungsversuche

Didit behandelt jede 2xx-Antwort als zugestellt. Jeder Versuch wartet bis zu 5 Sekunden auf Ihre Antwort und folgt keinen Weiterleitungen. Didit wiederholt einen Alert nach einem Timeout, einem Verbindungsfehler, einer 5xx-Antwort oder einer 408-, 425- bzw. 429-Antwort. Die Wiederholung erfolgt bis zu 5-mal über einen Zeitraum von etwa 24 Stunden: Jede andere Antwort ist endgültig, einschließlich 3xx und aller anderen 4xx. Ein über Test senden versendeter Test wird nur einmal gesendet und niemals wiederholt. Eine Antwort mit 401, 403, 404 oder 410 markiert das Ziel außerdem für eine erneute Verbindung: Die Konsole zeigt es mit dem Status Erneut verbinden an. Dasselbe gilt für eine URL, die beim Senden durch Didit zu einer privaten oder anderweitig blockierten Adresse aufgelöst wird. Didit sendet weiterhin neue Alerts an das Ziel, und es wird nach der nächsten erfolgreichen Zustellung oder bei einer Aktualisierung seiner URL wieder aktiv. Unter Letzte Benachrichtigungen in Team-Benachrichtigungen wird jede Zustellung mit ihrem Ergebnis aufgeführt, und Sie können eine fehlgeschlagene Zustellung von dort aus wiederholen.

Verwandte Themen

  • Verifizierungs-Webhooks: Sitzungs-, Entitäts- und Transaktionsergebnisse für Ihre Anwendung.
  • Dienststatus: Der öffentliche Feed hinter alert.service.degraded und alert.service.recovered.
  • Manuelle Prüfung: Vorgehensweise bei einer Verifizierung in Prüfung.
Zuletzt geändert am 7. November 2026