Laden...
Webhooks & Events
Überblick
Webhooks sind die Event-Zustellungsschicht von Customermates. Sie sorgen dafür, dass externe Systeme reagieren können, wenn sich Datensätze im CRM verändern. Damit eignen sie sich für Synchronisationen, Benachrichtigungen, Audit-Pipelines und nachgelagerte Automationen.
Die Webhook-Zustellung konzentriert sich auf Lifecycle-Änderungen der wichtigsten CRM-Entitäten. Die Konfiguration liegt im Unternehmensbereich, und Zustellversuche werden gespeichert, damit Teams nachvollziehen können, was gesendet wurde und wie der Ziel-Endpunkt reagiert hat. Diese Seite ist der zentrale Einstieg für Webhook-Setup, Zustellsemantik und belastbare eventgetriebene CRM-Integrationen.
Verfügbare Events
Customermates stellt derzeit genau fünfzehn Webhook-Events bereit:
contact.created,contact.updated,contact.deletedorganization.created,organization.updated,organization.deleteddeal.created,deal.updated,deal.deletedservice.created,service.updated,service.deletedtask.created,task.updated,task.deleted
Damit bezieht sich die Webhook-Ebene auf die fünf zentralen CRM-Entitäten und ihre Lifecycle-Änderungen. Intern existieren zwar noch weitere Domain-Events, aber über Webhooks werden aktuell genau diese fünfzehn Entitäts-Events zugestellt.
Wo Webhooks konfiguriert werden
Die Webhook-Konfiguration liegt in den Unternehmenseinstellungen. Eine Webhook-Subscription definiert:
- die Ziel-URL
- eine optionale Beschreibung
- ein oder mehrere abonnierte Events
- ein optionales Secret
- ob der Webhook aktiv ist
Im selben Bereich gibt es außerdem die Ansicht der letzten Zustellungen. Dadurch eignet sich die Oberfläche nicht nur für das Setup, sondern auch für Betrieb und Fehlersuche.
Zustellformat und Sicherheit
Wenn ein abonniertes Event ausgelöst wird, sendet Customermates einen POST-Request mit einem JSON-Body im Format { event, data, timestamp }. Falls ein Secret hinterlegt ist, enthält der Request zusätzlich einen X-Webhook-Signature-Header. Diese Signatur wird als HMAC-SHA256 über den rohen JSON-Body berechnet.
Damit haben empfangende Systeme zwei stabile Bezugspunkte: den Event-Namen für das Routing und die Signatur für die Verifikation der Anfrage.
Zustellverhalten
Die Webhook-Zustellung läuft asynchron zur eigentlichen Nutzeraktion. Praktisch heißt das: Ein fehlgeschlagener Webhook blockiert die ursprüngliche CRM-Änderung nicht. Jeder Zustellversuch wird mit Erfolgsstatus, Statuscode, Response-Message, Event-Namen, URL und Request-Body gespeichert und kann danach nachvollzogen werden.
Für den Betrieb sind zwei Punkte besonders wichtig:
- Nicht-2xx-Antworten werden als fehlgeschlagene Zustellungen gespeichert.
- Es gibt eine manuelle Resend-Aktion aus der Zustellhistorie heraus.
Customermates bietet aktuell keinen automatischen Retry-Mechanismus und auch keinen Idempotency-Key oder vergleichbaren Zustell-Header. Weil manuelle Wiederholungen möglich sind und externe Systeme eigene Replays erzeugen können, sollten empfangende Endpunkte trotzdem idempotent gebaut werden.
Verarbeitung in externen Systemen
Auf der empfangenden Seite werden Webhook-Payloads typischerweise in ein Workflow-Tool, einen Backend-Service, eine Queue oder eine interne Integrationsschicht geleitet. Der Event-Name entscheidet dort, welcher Handler laufen soll, und das data-Payload enthält den Datensatz-Snapshot oder den Änderungskontext für den nächsten Schritt. Für deterministische Orchestrierung kombinierst du diese Seite mit n8n CRM-Integration. Für die breitere Integrationsstrategie gehst du weiter zu CRM-Integrationen.