Zum Hauptinhalt springen
POST
curl
Mit Webhook-Zielen können Sie unterschiedliche Didit-Ereignisse an unterschiedliche URLs senden. Jedes Ziel hat einen eigenen secret_shared_key, eine eigene webhook_version und eine eigene Liste subscribed_events.

So funktioniert subscribed_events

subscribed_events ist ein Pflicht-Array mit exakten Ereignisnamen. Didit liefert einen Webhook nur dann an dieses Ziel aus, wenn der Wert webhook_type im Payload einem der Werte im Array entspricht.
  • Geben Sie mindestens ein Ereignis an.
  • Verwenden Sie ausschließlich die unten aufgeführten unterstützten Ereignisnamen.
  • Fügen Sie jedes Ereignis einzeln hinzu, das Sie zugestellt haben möchten. Es gibt keinen Platzhalterwert wie * oder all.
  • Um verschiedene Produktbereiche an unterschiedliche Systeme weiterzuleiten, legen Sie mehrere Ziele mit jeweils unterschiedlichen Listen subscribed_events an.

Ereigniskatalog

Die Ereignisfamilien investigator.* (Investigator) und auth.* (Authentifizierung) werden ebenfalls akzeptiert. Alle Ereignisse und ihre Payloads finden Sie unter Webhooks. Gängige Abonnementkombinationen:
Beispiele für Payloads und Signaturcode finden Sie im Webhook-Leitfaden.

Autorisierungen

x-api-key
string
header
erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Body

application/json
label
string
erforderlich

Lesbarer Name, der unter Console → Webhooks angezeigt wird. Hilft bei der Unterscheidung von Zielen, wenn Sie mehrere haben (z. B. „Prod“, „Staging mirror“).

Maximum string length: 255
url
string<uri>
erforderlich

HTTPS-URL, die POST-Anfragen empfängt. Muss unter den Zielen der Anwendung eindeutig sein. Verwenden Sie einen stabilen, abgesicherten Endpoint: Didit wiederholt fehlgeschlagene Zustellungen nach einem Backoff-Zeitplan.

Maximum string length: 2000
enabled
boolean
Standard:true

Wenn false, wird das Ziel gespeichert, aber Didit sendet keine Webhooks dorthin. Nützlich für Staging-Konfigurationen, die Sie vorübergehend pausieren möchten.

webhook_version
enum<string>

Payload-Schema-Version, die Didit sendet. v3 ist das aktuelle/empfohlene Format; ältere Versionen werden zur Abwärtskompatibilität mit älteren Integrationen beibehalten.

Verfügbare Optionen:
v1,
v2,
v3
subscribed_events
enum<string>[]

Zuzustellende Ereignisse. Faktisch erforderlich: Ein explizites [] wird mit 400 abgelehnt, und das Weglassen des Felds erstellt ein Ziel ohne Abonnements, das nichts empfängt.

Minimum array length: 1

Name des unterstützten Webhook-Ereignisses. Verwenden Sie genau diese Zeichenfolgen in subscribed_events; nicht unterstützte Werte werden abgelehnt.

Verfügbare Optionen:
status.updated,
data.updated,
user.status.updated,
user.data.updated,
business.status.updated,
business.data.updated,
activity.created,
transaction.created,
transaction.status.updated,
travel_rule.status.updated,
workflow.compliance_changed,
transaction_rule_suggestions.created,
auth.signup,
auth.login,
auth.login_failed,
auth.password_reset_requested,
auth.password_reset_completed,
auth.mfa_changed,
auth.new_device,
auth.account_locked,
investigator.report.ready,
investigator.decision.automated,
investigator.decision.overridden,
investigator.decision.contested,
investigator.question.raised,
investigator.automation.paused,
investigator.rfi.answered,
investigator.rfi.overdue,
investigator.drift.detected,
investigator.sla.breached,
investigator.qa.failed,
investigator.external.report.ready
Beispiel:

Antwort

Ziel erstellt. secret_shared_key ist das HMAC-Signaturgeheimnis – speichern Sie es jetzt.

uuid
string<uuid>

Stabiler Ziel-Identifikator. In nachfolgenden Aufrufen als {destination_uuid} verwenden.

label
string
url
string<uri>
enabled
boolean
webhook_version
enum<string>
Verfügbare Optionen:
v1,
v2,
v3
secret_shared_key
string

Automatisch generiertes HMAC-Signaturgeheimnis, das an dieses Ziel gebunden ist (URL-sicheres Token mit 43 Zeichen). Verwenden Sie es, um die Signatur-Header bei eingehenden Webhooks zu überprüfen. Wird Aufrufern mit API-Schlüssel immer vollständig zurückgegeben; Console-Benutzer benötigen die Berechtigung read:webhooks, andernfalls sehen sie eine leere Zeichenfolge.

secret_last4
string

Die letzten vier Zeichen des aktuellen Signiergeheimnisses des Ziels, damit Sie Geheimnisse voneinander unterscheiden können. Reicht nicht aus, um eine Signatur zu verifizieren.

previous_secret_expires_at
string<date-time> | null

Wird für 24 Stunden gesetzt, nachdem das Signiergeheimnis des Ziels in der Business Console rotiert wurde. Bis zu diesem Zeitpunkt enthält jede Zustellung an das Ziel auch X-Signature-Previous, X-Signature-V2-Previous und X-Signature-Simple-Previous, erstellt mit dem ersetzten Geheimnis (siehe Signaturprüfung). null, wenn in den letzten 24 Stunden keine Rotation stattgefunden hat.

subscribed_events
enum<string>[]

Ereignisfilter für dieses Webhook-Ziel. Didit stellt nur Webhooks zu, deren Ereignistyp exakt mit einem dieser Werte übereinstimmt – es gibt kein Wildcard-Abonnement. Beim Senden muss die Liste mindestens ein gültiges Ereignis enthalten (ein explizites [] wird mit 400 abgelehnt); ein Ziel mit leerer Liste (Feld bei der Erstellung weggelassen) empfängt nichts. Bei einer Aktualisierung wird die Liste vollständig ersetzt, niemals zusammengeführt.

Minimum array length: 1

Name des unterstützten Webhook-Ereignisses. Verwenden Sie genau diese Zeichenfolgen in subscribed_events; nicht unterstützte Werte werden abgelehnt.

Verfügbare Optionen:
status.updated,
data.updated,
user.status.updated,
user.data.updated,
business.status.updated,
business.data.updated,
activity.created,
transaction.created,
transaction.status.updated,
travel_rule.status.updated,
workflow.compliance_changed,
transaction_rule_suggestions.created,
auth.signup,
auth.login,
auth.login_failed,
auth.password_reset_requested,
auth.password_reset_completed,
auth.mfa_changed,
auth.new_device,
auth.account_locked,
investigator.report.ready,
investigator.decision.automated,
investigator.decision.overridden,
investigator.decision.contested,
investigator.question.raised,
investigator.automation.paused,
investigator.rfi.answered,
investigator.rfi.overdue,
investigator.drift.detected,
investigator.sla.breached,
investigator.qa.failed,
investigator.external.report.ready
Beispiel:
created_by_email
string | null

E-Mail des Mitglieds der Business Console, das das Ziel erstellt hat. null für ein mit einem API-Schlüssel erstelltes Ziel.

created_by_name
string | null

Name des Mitglieds der Business Console, das das Ziel erstellt hat. null bei einem Ziel, das mit einem API-Schlüssel erstellt wurde.

created_at
string<date-time>
updated_at
string<date-time>
health_status
enum<string>

Zustellungsstatus. failing: Bei 3 oder mehr aufeinanderfolgenden Ereignissen ist jeweils der erste Zustellversuch fehlgeschlagen, seit das Ziel zuletzt erfolgreich geantwortet hat (siehe failing_streak). degraded: nicht failing, aber in den letzten 24 Stunden ist ein Zustellversuch fehlgeschlagen und kein späterer Versuch hat dieses Ereignis zugestellt; ein Wiederholungsversuch oder ein erneutes Senden, das es zustellt, hebt dies auf. healthy: weder noch. Unabhängig von enabled. Ein fehlgeschlagener Versuch ist ein Versuch, der mit HTTP 400 oder höher beantwortet oder überhaupt nicht beantwortet wurde.

Verfügbare Optionen:
healthy,
degraded,
failing
failing_streak
integer

Wie viele aufeinanderfolgende Ereignisse bei ihrem ersten Zustellversuch fehlgeschlagen sind, seit das Ziel innerhalb der letzten 30 Tage zuletzt erfolgreich geantwortet hat. Wiederholungsversuche werden nicht gezählt, und jeder erfolgreiche Versuch, einschließlich eines Wiederholungsversuchs oder eines erneuten Sendens, beendet die Serie. 0, wenn seit dem letzten Erfolg kein Ereignis fehlgeschlagen ist.

failing_since
string<date-time> | null

Wann der erste fehlgeschlagene Versuch der aktuellen failing_streak unternommen wurde. null, wenn failing_streak den Wert 0 hat.

last_success_at
string<date-time> | null

Wann das Ziel zuletzt innerhalb der letzten 30 Tage auf eine Zustellung mit einem HTTP-Status unter 400 geantwortet hat. null, wenn dies in diesem Zeitfenster nicht der Fall war.

environment
enum<string>

Umgebung der Anwendung, zu der das Ziel gehört.

Verfügbare Optionen:
live,
sandbox
summary
object

Zustellungsmetriken für die letzten metrics_window_days (30) Tage. last_delivery_at ist der letzte Versuch, unabhängig davon, wann er unternommen wurde.

Zuletzt geändert am 7. November 2026