CRM-Ereignisse über Webhooks empfangen

Customermates sendet einen JSON-POST an Ihren Endpunkt, sobald sich abonnierte Daten ändern. Sie wählen die Ereignisse und die URL. Mit einem Secret wird jede Zustellung per HMAC-SHA256 über den rohen Request-Body signiert. Fehlgeschlagene Zustellungen werden automatisch wiederholt und lassen sich von Hand erneut senden. Der Ereigniskatalog steht am Ende dieser Seite.

Wofür sind Webhooks da?

Webhooks lassen andere Systeme auf CRM-Änderungen reagieren, ohne zu pollen, etwa um neue Kontakte an einen E-Mail-Sequencer zu übergeben, ein Support-Ticket zu öffnen, wenn ein Deal seinen Zustand ändert, einen Finance-Workflow beim Abschluss eines Deals zu starten oder Datensätze nahezu in Echtzeit in ein Data Warehouse zu synchronisieren.

Wie lege ich einen Webhook an?

Öffnen Sie Webhooks, klicken Sie auf Hinzufügen, füllen Sie den Dialog Webhook aus, tragen Sie die URL ein und klicken Sie auf Speichern.

Um einen Webhook zu ändern, klicken Sie auf seine Zeile, bearbeiten ihn und klicken auf Speichern. Zum Entfernen klicken Sie oben im Dialog auf Löschen und bestätigen; seine bisherigen Zustellungen bleiben auf der Seite Zustellungen erhalten. Um die Zustellungen eines Webhooks zu sehen, wählen Sie im Menü Weitere Aktionen seiner Zeile Zustellungen anzeigen: Zustellungen öffnet sich gefiltert auf die URL dieses Webhooks, und Sie können den Filter wie jeden anderen entfernen. Die Liste zeigt URL, Beschreibung, Ereignisse, Status (Aktiviert oder Deaktiviert), Erstellt am und Aktualisiert am. Unter Filter durchsucht die Suche die URL, die Filter decken Erstellungs- und Änderungsdatum ab.

Verwenden Sie einen HTTPS-Endpunkt. Reines http:// wird für jeden Host nur akzeptiert, solange der Webhook keine eigenen Header hat. Mit eigenen Headern muss die URL https:// verwenden oder http:// auf localhost, 127.0.0.1 oder ::1, da Header in der Regel ein Credential tragen. Das wird beim Speichern und erneut vor jeder Zustellung geprüft.

Über MCP nutzen Sie manage_webhooks mit action: "create", dazu url, events[] und optional description, secret, headers, bodyTemplate, enabled. Über REST legt POST /api/v1/webhooks einen Webhook mit denselben Feldern an, und GET /api/v1/webhooks listet sie; GET, PATCH und DELETE /api/v1/webhooks/{id} lesen, ändern und löschen einen, und eine Änderung betrifft nur die Felder, die Sie senden. Eine ID, die nicht existiert oder zu einem anderen Workspace gehört, beantwortet die API mit 404 und dem strukturierten Fehler not_found.

Welche Datensätze lösen einen Webhook aus, und mit wessen Zugriff wird zugestellt?

Sobald Sie ein Datensatzereignis wählen, zeigt der Dialog die Datensatzquelle: Wählen Sie unter Datensätze aus die Liste (oder Alle zugänglichen Typen) und bei Bedarf Geänderte Felder, Datensätze suchen sowie Datensatzfilter auf Feldern und Beziehungen. Zugestellt wird mit dem Datensatzzugriff des Mitglieds unter Zugriffsberechtigtes Mitglied, standardmäßig des Mitglieds, das den Webhook anlegt; nur ein Administrator kann ein anderes Mitglied wählen. Ältere migrierte Webhooks können mehrere Quellen behalten, die als Chips erscheinen.

Über MCP benötigen Datensatzabonnements in manage_webhooks außerdem expectedSchemaRevision aus get_record_model. recordTrigger enthält eine Abfrage mit stabilen Typ- und Feld-IDs und optionalen changedFieldIds; null wählt alle zugänglichen Typen. recordOwnerUserId legt optional den Eigentümer für die Zustellung fest. Lassen Sie diese Einstellungen bei einem Update weg, um sie zu behalten; Änderungen an Quelle oder Eigentümer benötigen die aktuelle Schema-Revision. Ein Webhook, der mehreren Listen folgt, nutzt statt recordTrigger die Einstellung recordSources: bis zu 50 Quellen mit jeweils eigener query, eigenen changedFieldIds und events; beide lassen sich nicht kombinieren, und null entfernt die Quellen. Die REST-API nimmt dieselben Einstellungen.

{
  "url": "https://hooks.example.com/customermates",
  "events": ["record.created", "record.updated"],
  "expectedSchemaRevision": 3,
  "recordTrigger": {
    "query": { "typeId": "<project-type-id>" },
    "changedFieldIds": []
  },
  "secret": "nutze-einen-random-string-aus-einem-password-manager",
  "enabled": true
}

Wer kann Webhooks sehen und ändern?

Den Zugriff legt die Zeile API & Webhooks einer Rolle unter Rollen fest.

Dieselbe Zeile steuert auch API-Schlüssel. Eine Rolle, die eigene API-Keys anlegen oder löschen darf, darf also auch jeden Webhook im Workspace anlegen oder löschen. Die Rolle Admin darf alles. Webhooks sind an keinen Tarif gebunden und funktionieren in jedem Cloud-Tarif sowie selbstgehostet. Dieselben Berechtigungen gelten für manage_webhooks über MCP und in Mate; dort fragt das Löschen eines Webhooks oder das erneute Senden einer Zustellung vorher nach Ihrer Freigabe.

Wie sieht der Payload aus?

Jede Zustellung ist ein POST mit Content-Type: application/json und demselben Umschlag:

{
  "event": "<event-name>",
  "id": "<event-id>",
  "timestamp": "<iso-8601>",
  "companyId": "<workspace>",
  "actorId": "<verursacher>",
  "data": {
    /* event-spezifisch */
  }
}

id bezeichnet das Ereignis: Ein erneutes Senden und jeder Wiederholungsversuch tragen dieselbe id, nutzen Sie sie also zum Deduplizieren. actorId ist der User, der den Write verursacht hat, inklusive User, die über einen API-Key handeln, und Routinen, die für ihren Eigentümer laufen. Messaging-Ereignisse entstehen durch eingehende Provider-Aktivität, ihr actorId ist deshalb null.

Bei Datensatzereignissen enthält data.record die Referenz (typeId und recordId, auch nach einer Umbenennung eindeutig) und die Änderungen, data.cause die Ursache des Writes, und data.causeId teilen alle Ereignisse desselben Writes.

Beispiel für record.updated bei einem Kontakt, ohne für die Erklärung unnötige Felder:

{
  "event": "record.updated",
  "id": "<event-id>",
  "timestamp": "2026-04-22T10:00:00.000Z",
  "companyId": "<workspace-id>",
  "actorId": "<ausloesender-user-id>",
  "data": {
    "causeId": "<cause-id>",
    "cause": { "kind": "mutation" },
    "record": {
      "ref": { "typeId": "<kontakt-typ-id>", "recordId": "<record-id>" },
      "schemaRevision": 3,
      "beforeVersion": 1,
      "afterVersion": 2,
      "fields": [
        {
          "fieldId": "<vorname-feld-id>",
          "before": { "value": { "state": "value", "value": { "kind": "text", "value": "Max" } } },
          "after": { "value": { "state": "value", "value": { "kind": "text", "value": "Maximilian" } } }
        }
      ]
    }
  }
}

Eine echte Datensatzänderung enthält außerdem Zuweisungen, Identitäten, Änderungen an Verknüpfungen und verknüpfte Datensätze. Feldeinträge tragen Anzeigedaten und können statt eines Werts missing, restricted oder error enthalten. Die Liste finden Sie mit POST /api/v1/model/discover, ihre stabilen Feld-IDs liefert POST /api/v1/model/read oder das MCP-Tool get_record_model.

Geänderte Felder in data.record.fields

data.record.fields listet geänderte Felder mit Werten für before und after; data.record.links, data.record.assignments und data.record.identities beschreiben weitere geänderte Verbindungen. data.record.beforeVersion und data.record.afterVersion bezeichnen die Datensatzversionen. Ein fehlender oder eingeschränkter Wert ist nicht dasselbe wie 0.

Änderungen ohne Wirkung erzeugen kein record.updated-Ereignis. Änderungen am Datenmodell können gespeicherte Werte vieler Datensätze neu berechnen. Diese Konfigurationsänderungen bleiben im Datensatzverlauf, erzeugen aber keine Webhook-Zustellung je Datensatz und lösen keine Ereignisroutine aus. Eine spätere Änderung durch einen Benutzer oder die API erzeugt ihr übliches Ereignis. Der Payload wird bei der Zustellung gemäß den aktuellen Datensatz- und Berechnungsfeldrechten des Webhook-Eigentümers redigiert.

Eigene Header und Body-Vorlagen

Zwei optionale Einstellungen decken Empfänger ab, die die Standardzustellung nicht akzeptieren. Ein Webhook ohne beide sendet den Standardumschlag.

Eigene Header werden bei jeder Zustellung mitgesendet, für Endpunkte mit eigener Authentifizierung. Tragen Sie sie zeilenweise als Name: Wert ein (eine Zeile ohne Doppelpunkt wird ignoriert, ein leeres Feld entfernt alle Header) oder übergeben Sie über MCP und API ein headers-Objekt. Sieben Namen sind reserviert und werden abgelehnt: Connection, Content-Length, Content-Type, Host, Transfer-Encoding, X-Webhook-Signature und X-Customermates-Delivery-Id. Namen müssen gültige HTTP-Tokens sein, Werte Latin-1-Text ohne Zeilenumbrüche. Ein Webhook darf bis zu 20 Header tragen, mit Namen bis 128 Zeichen, Werten bis 2.048 Zeichen und insgesamt 8.192 Zeichen. Ein Webhook mit Headern muss HTTPS verwenden; reines HTTP wird nur für localhost, 127.0.0.1 und ::1 akzeptiert.

REST-API und MCP geben Header-Werte und das Secret nie zurück; sie liefern headerNames und hasSecret. Der Dialog zeigt die Werte nur der Rolle Admin und Rollen mit Bearbeiten bei API & Webhooks, das Secret maskiert, bis Sie auf das Augensymbol klicken. Eine Aktualisierung über API oder MCP ohne headers behält die gespeicherten Werte, null löscht sie.

Eine Body-Vorlage ersetzt den Standardumschlag für Endpunkte mit fester Struktur. Schreiben Sie ein JSON-Dokument mit Platzhaltern:

{ "text": "{{event}} for {{data.record.ref.recordId}}" }

Platzhalter sind {{event}}, {{id}}, {{timestamp}}, {{companyId}}, {{actorId}} sowie jeder Pfad unterhalb von {{data}}, etwa {{data.record.ref.recordId}} bei einem Datensatzereignis oder {{data.entityId}} bei einem Messaging-Ereignis. Ein Platzhalter muss innerhalb eines JSON-Strings stehen; {"count": {{data.count}}} wird abgelehnt. Ein Objektwert wird als JSON-String eingesetzt, ein fehlender Pfad als leerer String. Eingesetzte Werte werden escaped, sodass Datensatzinhalte die Struktur des Dokuments nicht verändern können.

Die Vorlage darf bis zu 8.192 Zeichen lang sein, muss ein JSON-Objekt ergeben und wird beim Speichern geprüft. Eine Zustellung, deren Vorlage nicht gerendert werden kann oder deren gerenderter Body 131.072 Zeichen überschreitet, wird als fehlgeschlagen erfasst, ohne gesendet zu werden, und nicht wiederholt. Die Signatur wird über den tatsächlich gesendeten Body berechnet, prüfen Sie sie also gegen den gerenderten Body.

Secret oder Vorlage entfernen. Ist Secret oder Body-Vorlage einmal gesetzt, lehnt der Dialog das Speichern mit leerem Feld ab. Aktualisieren Sie den Webhook über manage_webhooks oder PATCH /api/v1/webhooks/{id} mit secret: null oder bodyTemplate: null, oder löschen Sie ihn und legen ihn neu an.

Zustellungen werden mit dem Ereignis-Payload erfasst, nicht mit dem gerenderten Body. Ereignis-Details zeigt also das ausgelöste Ereignis und nicht die exakt gesendeten Bytes.

Wie sende ich an Slack, Discord oder n8n?

Jedes Rezept nennt URL, eigene Header und Body-Vorlage, die Sie nach Hinzufügen in Webhooks eintragen. Setzen Sie in jedem Fall ein Secret; ein Empfänger, der es nicht prüfen kann, ignoriert den Header.

Claude-Code-Routinen

Startet eine Claude-Code-Routine, wenn sich ein Datensatz ändert. Legen Sie die Routine zuerst unter claude.ai/code/routines an.

1. API-Trigger hinzufügen

   Öffnen Sie die Routine, klicken Sie auf Add another trigger, wählen Sie API und dann Generate token. Kopieren Sie URL und Token; das Token wird nur einmal angezeigt und lässt sich später nicht erneut abrufen.

2. Webhook anlegen

   Fügen Sie die URL ein, wählen Sie Ihre Ereignisse und tragen Sie die Header und die Vorlage unten ein.

3. Payload im Routinen-Prompt referenzieren

   Der Text kommt in einem routine-fire-payload-Block an, den die Routine als nicht vertrauenswürdige Daten behandelt. Der Prompt der Routine muss ihn ausdrücklich referenzieren, etwa "handle das im routine-fire-payload-Block beschriebene Ereignis ab", sonst bleibt der Text unbeachtet.

Die URL lautet https://api.anthropic.com/v1/claude_code/routines/<routine-id>/fire, die Routinen-ID beginnt mit trig_.

Authorization: Bearer <routine-token>
anthropic-beta: experimental-cc-routine-2026-04-01
anthropic-version: 2023-06-01

{ "text": "{{event}} for {{data.record.ref.recordId}}" }

Der Endpunkt liest ausschließlich text, die Vorlage ist deshalb zwingend; ohne sie startet die Routine ohne Kontext. Jede Zustellung und jeder Retry startet einen eigenen Lauf auf Ihr Routinen-Kontingent. Abonnieren Sie deshalb nur die Ereignisse, die die Aufgabe braucht.

Slack

Posten Sie über einen Incoming Webhook aus Slack → Apps → Incoming Webhooks in einen Kanal. Die URL trägt die Authentifizierung, eigene Header sind nicht nötig.

{ "text": "{{event}} for {{data.record.ref.recordId}}" }

Discord

Verwenden Sie die Webhook-URL aus Kanal → Kanal bearbeiten → Integrationen → Webhooks. Dieselbe Struktur, anderer Schlüssel:

{ "content": "{{event}} for {{data.record.ref.recordId}}" }

n8n

Ein n8n-Webhook-Node akzeptiert den Standardumschlag. Lassen Sie beide Einstellungen leer, sofern der Node keine Header-Authentifizierung verwendet. Tut er das, tragen Sie den erwarteten Header ein und lassen die Vorlage leer:

X-N8N-Header-Auth: <Wert>

Das vollständige Muster steht unter n8n.

Alles andere

Ein Empfänger, der weder eigene Authentifizierung noch eine feste Body-Struktur braucht, benötigt keine der beiden Einstellungen. Lassen Sie beide leer und prüfen Sie die Signatur.

Wie prüfe ich die Signatur?

Hat der Webhook ein Secret, enthält jede Request:

X-Webhook-Signature: <hex>

<hex> ist HMAC-SHA256(secret, rawRequestBody), Lowercase-Hex, ohne Präfix. Berechnen Sie den Wert auf Ihrer Seite neu und vergleichen Sie in konstanter Zeit.

Node.js-Beispiel:

import crypto from "crypto";

function verify(rawBody: string, received: string, secret: string) {
  const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(received));
}

Wie funktionieren Wiederholungen (Retries) und fehlgeschlagene Zustellungen?

Eine Zustellung schlägt fehl, wenn der HTTP-Status außerhalb von 2xx liegt, die Request nach 5 Sekunden timeoutet oder keine Antwort eintrifft. Customermates wiederholt Timeouts, Netzwerkfehler, 5xx-Responses sowie 408, 425 und 429 automatisch, mit bis zu 10 Versuchen insgesamt. Die erste Wiederholung folgt 10 Sekunden nach dem gescheiterten Versuch, und jede Pause verdoppelt sich (20 Sekunden, 40 Sekunden und so weiter, höchstens eine Stunde), sodass der letzte Versuch etwa 1,5 Stunden nach dem ersten läuft; danach bleibt die Zustellung Fehlgeschlagen, und Sie können sie von Hand erneut senden. Andere 4xx-Responses, etwa 400, 401, 403, 404 und 422, werden nicht wiederholt, weil ein erneuter Versuch genauso scheitern würde. Eine Zustellung schlägt außerdem schon vor dem Senden fehl, mit Status-Code 422, wenn Header an eine Adresse gehen würden, die sie nicht erlaubt, oder die Body-Vorlage nicht gerendert werden kann.

Wiederholungen laufen innerhalb derselben Zustellung und erzeugen keine weiteren Einträge: Jeder Eintrag zeigt das letzte Ergebnis, kann also Fehlgeschlagen zeigen, während noch Wiederholungen ausstehen, und zu Zugestellt wechseln, sobald eine gelingt.

Wo sehe ich vergangene Zustellungen?

Jede Zustellung wird auf der Seite Zustellungen protokolliert, die neueste zuerst, mit URL, Ereignis, Element (dem betroffenen Datensatz), Status, Status-Code und Erstellt am. Unter Filter durchsucht die Suche Ereignis und URL, die Filter decken Ereignis, URL und Erstellungsdatum ab. Über MCP nutzen Sie manage_webhooks mit action: "list_deliveries"; über REST listet GET /api/v1/webhooks/deliveries die Zustellungen aller Webhooks und GET /api/v1/webhooks/{id}/deliveries die eines Webhooks, die neueste zuerst. Zustellungen bleiben erhalten, solange der Workspace besteht.

Ein Klick auf eine Zeile öffnet Ereignis-Details: Status (Ausstehend, Wird gesendet, Zugestellt oder Fehlgeschlagen), URL, Ereignis, Element, Erstellt am, Status-Code, Antwort-Nachricht und Ereignis-Payload. Der Payload eines Messaging-Ereignisses erscheint so, wie er gesendet wurde. Der Payload eines Datensatzereignisses wird mit Ihren aktuellen Rechten neu gelesen: Werte, die Sie nicht lesen dürfen, erscheinen als eingeschränkt, und ohne Zugriff auf den Datensatz bleibt der Payload leer.

Wie sende ich eine Zustellung erneut?

Zum erneuten Senden klicken Sie oben in Ereignis-Details auf Erneut senden. Die Aktion erscheint, sobald die Zustellung Zugestellt oder Fehlgeschlagen ist, für Rollen mit Erstellen bei API & Webhooks; über MCP nutzen Sie manage_webhooks mit action: "resend_delivery" und der Id der Zustellung, über REST POST /api/v1/webhooks/{id}/deliveries/{deliveryId}/resend. Ein erneutes Senden erzeugt einen neuen Zustellungseintrag mit der aktuellen URL, dem aktuellen Secret, den aktuellen Headern und der aktuellen Vorlage des Webhooks; das Original bleibt unverändert. Ein Messaging-Ereignis wird aus seinem gespeicherten Event erneut gesendet. Ein Datensatzereignis wird mit den aktuellen Rechten des Webhook-Eigentümers neu gelesen, nur dieser Eigentümer oder ein Administrator kann es erneut senden, und das erneute Senden wird abgelehnt, wenn sich die Datensatzquellen des Webhooks seit der ursprünglichen Zustellung geändert haben. Der Webhook muss noch existieren, aktiviert sein und das Ereignis abonnieren; Zustellungen stillgelegter typspezifischer Ereignisse lassen sich nicht erneut senden. Die Seiten Webhooks und Zustellungen zeigen ein solches Ereignis mit (veraltet), etwa Kontakt erstellt (veraltet).

Sind Zustellungen geordnet, und kommen Webhooks in der richtigen Reihenfolge an?

Nein. Zwei record.updated-Ereignisse im Millisekundenabstand können in falscher Reihenfolge ankommen. Nutzen Sie timestamp und Datensatzversion zur Reihenfolge oder behandeln Sie Zustellungen als idempotente Nachrichten mit typeId, recordId und Ereignis-ID als Schlüssel.

Warum ist formatierter Text in Payloads Tiptap-JSON?

Der Wert eines Felds vom Typ Formatierter Text ist in Payloads ein richText-Wert, dessen documentJson Tiptap-JSON ist, die Struktur, die der Editor speichert. Ein Tiptap-kompatibler Serializer macht daraus Markdown. Die REST-Routen für Datensätze liefern dasselbe documentJson. Die MCP-Datensatz-Tools liefern Formatierten Text dagegen als Markdown, markiert als nicht vertrauenswürdiger Inhalt; siehe MCP.

Was enthalten Delete-Payloads?

record.deleted wird gesendet, wenn ein Datensatz in den Papierkorb verschoben wird. data.record enthält die eindeutige ref, die zulässigen Vorher-Werte und die Beziehungen, die er verlässt; afterVersion ist null. Quellfilter gelten unmittelbar vor dem Verschieben, der aktuelle Zugriff des Eigentümers wird vor der Zustellung erneut geprüft. record.restored wird gesendet, wenn er aus dem Papierkorb zurückkommt, und enthält wie record.created die Nachher-Werte.

record.deletedPermanently wird gesendet, wenn ein Datensatz endgültig gelöscht wird, von Hand oder 30 Tage nachdem er in den Papierkorb kam. data.record enthält nur die ref: Die Werte werden entfernt, und auch die früheren Ereignisse des Datensatzes verlieren ihre Feldwerte; erhalten bleibt, wer ihn wann geändert hat. Es erreicht jeden Webhook der Liste, der es ausgewählt hat und dessen Eigentümer die Liste lesen darf, ohne Quellfilter.

Wie untersuche ich eine fehlgeschlagene Zustellung?

• Suchen Sie die Zustellung unter Zustellungen und öffnen Sie sie, um die Ereignis-Details zu sehen.
• Nutzen Sie webhook.site beim Testen als Einweg-Empfänger.
• manage_webhooks mit action: "list_deliveries", GET /api/v1/webhooks/deliveries und GET /api/v1/webhooks/{id}/deliveries unterstützen searchTerm auf URL und Ereignisname.
• Customermates speichert nur den HTTP-Status-Code und den Statustext, den Ihr Empfänger zurückgegeben hat (zum Beispiel 404 und Not Found), angezeigt als Status-Code und Antwort-Nachricht in Ereignis-Details. Der Response-Body wird nicht gespeichert, protokollieren Sie ihn also auf der Empfängerseite. Ohne Antwort zeigt Status-Code einen Strich (in der Liste bleibt die Spalte leer) und Antwort-Nachricht nennt die Ursache, etwa den Timeout.

Welche Ereignisse gibt es?

Ein Webhook kann 16 Ereignisse abonnieren: 5 Datensatzereignisse und 11 Messaging-Ereignisse. Für einen CRM-Webhook wählen Sie Datensatz erstellt, Datensatz aktualisiert, Datensatz in den Papierkorb verschoben, Datensatz wiederhergestellt oder Datensatz endgültig gelöscht (record.created, record.updated, record.deleted, record.restored, record.deletedPermanently) und legen die Datensatzquelle fest; das gilt auch für Listen, die Sie selbst angelegt haben. Alle nutzen den Standardumschlag. Routinen können durch dieselben Ereignisse ausgelöst werden, mit Ausnahme von Datensatz endgültig gelöscht (record.deletedPermanently), E-Mail gelöscht (messaging.email.deleted) und Chat gelöscht (messaging.chat.deleted); Nachricht gelöscht (messaging.message.deleted) löst Routinen aus. Siehe Routinen.

Record-Events

Fünfzehn typspezifische Bezeichner sind stillgelegt. Sie bleiben nur erhalten, damit ältere Webhooks und Zustellungseinträge lesbar bleiben: Für Webhooks und Routinen lassen sie sich nicht auswählen, und nichts löst sie aus. Ersetzen Sie sie durch ein generisches Ereignis mit Datensatzquelle.

Messaging-Events

Messaging-Ereignisse feuern bei eingehender Provider-Aktivität auf verbundenen Konten. Ereignisse bietet sie in jedem Workspace an, sie feuern aber nur, wo Kanäle verbunden sind, und das setzt die Cloud und einen Tarif mit Messaging voraus. actorId ist null. data referenziert Provider-Records per id (entityId für die betroffene Nachricht, den Thread, Kalender, Kalendertermin oder die Verbindung, dazu connectedAccountId, provider, providerMessageId, threadId und ähnliche), statt CRM-Datensätze einzubetten. Ein Messaging-Ereignis wird nur gespeichert, solange ein Webhook oder eine Event-Routine es abonniert.

Weiter

• MCP-Tool-Katalog: Webhooks programmatisch verwalten.
• API-Referenz: die REST-Endpunkte für Webhooks und jede Ereignis-Payload.
• n8n-Integration: Webhooks in visuelle Workflows einbinden.