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.Alert-Typen
Payload
Jeder Alert ist einPOST-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 Beispielsession_in_review.labelundvalue: worauf sich der Alert bezieht, zum BeispielSessionund#1042.
data weitere Schlüssel hinzu:
alert.billing.autorefill_failedfügtpausedhinzu, einen booleschen Wert, dertrueist, wenn die automatische Aufladung jetzt pausiert wurde, bis Sie die Karte aktualisieren.alert.service.degradedundalert.service.recoveredfügenservice,status,incident_id,service_name,state,affected,country_name,started_at,resolved_at,duration_minutes,titleundbodyhinzu.statusist beialert.service.degradedentwederdegradedoderdownund beialert.service.recoveredentsprechendrecovered.serviceverwendet die Dienstschlüssel ausGET /v3/status/, undincident_idderideines Vorfalls dort entspricht.
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-Timestampum 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 mit401,403,404oder410markiert das Ziel für eine erneute Verbindung (siehe Wiederholungsversuche).
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 jede2xx-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.degradedundalert.service.recovered. - Manuelle Prüfung: Vorgehensweise bei einer Verifizierung in Prüfung.