Ein Webhook-Benachrichtigungskanal in Document360 ist eine automatisierte Methode, um Echtzeit-Ereignisdaten aus Ihrer Wissensdatenbank an eine externe Anwendung zu senden, wann immer eine bestimmte Aktion stattfindet. Webhooks machen manuelle Überwachung überflüssig, indem strukturierte JSON-Payloads direkt auf eine URL Ihrer Wahl übertragen werden – wie zum Beispiel einen Slack-Kanal, eine benutzerdefinierte Integration oder eine Automatisierungsplattform. Sie können mehrere Webhook-Kanäle konfigurieren und jeden einzelnen über die Benachrichtigungsmapping-Einstellungen bestimmten Ereignissen zuordnen.
Wann sollte man Webhook-Benachrichtigungskanäle verwenden
Nutzen Sie Webhook-Benachrichtigungen, wenn Sie automatisieren möchten, wie Ihr Team oder externe Systeme auf Änderungen in der Wissensdatenbank reagieren.
- Team-Benachrichtigungen: Benachrichtigen Sie ein Support- oder Dokumentationsteam in Slack oder Microsoft Teams sofort, wenn ein Artikel veröffentlicht, aktualisiert oder gelöscht wird – ohne dass jemand das Portal manuell überprüfen muss.
- Cache-Ungültigkeit: Erkennen Sie Artikellöschereignisse (einschließlich Slugs für alle Sprachen) und entfernen Sie automatisch die entsprechenden Einträge aus Ihrem Inhaltscache.
- Workflow-Automatisierung: Lösen Sie nachgelagerte Prozesse in Tools wie Make oder Zapier aus, wenn bestimmte Ereignisse auftreten, wie etwa ein neuer Artikel veröffentlicht wird oder ein Erweiterungstoken gelöscht wird.
- Audit und Compliance: Streamen Sie Aktivitäten der Wissensdatenbank zu einem Logging-Service, um eine Echtzeit-Audit-Spur zu erhalten, wer wann was geändert hat.
- Benutzerdefinierte Workflow-Automatisierung: Weisen Sie das aktualisierte Ereignis des Artikel-Workflows auf einen Webhook-Kanal zu, sodass das Verschieben eines Artikels in einen bestimmten benutzerdefinierten Workflow-Status (zum Beispiel ein Status, der verwendet wird, um Inhalte an einen externen Review-Schritt zu übergeben) eine nachgelagerte Automatisierungsplattform wie n8n, Make oder Zapier auslösen kann.
Bevor du anfängst
- Haben Sie die Ziel-Webhook-URL bereit – dies ist der Endpunkt, der von der empfangenden Anwendung bereitgestellt wird (z. B. eine Slack-Eingehende Webhook-URL, ein Make-Szenario-Webhook oder Ihr eigener Server-Endpunkt).
- Wenn die empfangende Anwendung eine Authentifizierung benötigt, erhalten Sie vor Beginn den Autorisierungsschlüssel .
Wie man einen Webhook-Benachrichtigungskanal einrichtet
-
Navigiere zu Einstellungen () > Knowledge Base-Portal in der linken Navigationsleiste.
-
Wählen Sie im linken Navigationsfeld Benachrichtigungen aus.
Der Reiter Kanäle ist standardmäßig ausgewählt. -
Klicken Sie auf Neuen Kanal.
-
Im Panel Verfügbare Kanäle wählen Sie Webhook aus.

Die Konfiguration der Kanaloptionen erscheint im selben Panel, sobald du auf den Kanaltyp klickst.
-
Im Feld Freundlicher Name geben Sie einen eindeutigen Namen für diesen Webhook-Kanal ein.
-
Im Dropdown-Menü der Anfrage-Methode wählen Sie POST oder PUT, je nachdem, was die empfangende Anwendung erwartet.
-
Im Webhook-URL-Feld geben Sie die Ziel-URL ein, in der Benachrichtigungen gesendet werden sollen.
-
Im Dropdown-Menü "Inhalt anfordern " wählen Sie das Nachrichtenformat für die Nutzlast.
-
Wenn die empfangende Anwendung zusätzliche HTTP-Header benötigt, klicken Sie unter Autorisierungsschlüssel auf Add () und fügen Sie jeden Header als Schlüssel-Wert-Paar hinzu.
-
Wenn eine Authentifizierung erforderlich ist, geben Sie den Autorisierungsschlüssel im entsprechenden Feld ein.
-
Klicken Sie auf Speichern.

Der Webhook-Kanal wird erstellt und unter Benachrichtigungskanälen aufgeführt. Um ihn zu aktivieren, gehe zum Tab Benachrichtigungszuordnung und weise den Kanal den Ereignissen zu, die du verfolgen möchtest.
Für Details zu unterstützten HTTP-Anforderungsheadern und ihren erwarteten Formaten siehe die MDN Request-Header-Referenz.
Best Practices
- Verwenden Sie beschreibende freundliche Namen , die sowohl das Ziel als auch den Ereignisumfang identifizieren – zum Beispiel oder
Slack-ArticlePublishMake-AllEvents–, damit Kanäle bei der Zuordnung von Benachrichtigungen leicht zu unterscheiden sind. - Scopen Sie jeden Kanal auf eine fokussierte Menge von Ereignissen, anstatt alle Ereignisse über einen einzigen Webhook zu leiten. Das erleichtert es, Fehler zu verwalten und bestimmte Ereignistypen unabhängig zu wiederholen.
- Sichern Sie Ihren Endpunkt mit einem Autorisierungsschlüssel, wann immer die empfangende Anwendung ihn unterstützt, um zu verhindern, dass unautorisierte Nutzlasten Ihre Systeme erreichen.
- Verwenden Sie das Slugs-Feld in Delete-Events , um sofort die korrekten Cache-Einträge in allen Sprachen zu identifizieren und zu löschen, wenn ein Artikel entfernt wird, um veralteten Inhalt zu vermeiden.
FAQ
Welche Informationen sind in einer Webhook-Benachrichtigung enthalten?
Wenn ein Webhook ausgelöst wird, sendet Document360 eine strukturierte JSON-Nutzlast an die konfigurierte URL. Die Nutzlast enthält den Ereignistyp, den Benutzer, der die Aktion ausgeführt hat, den UTC-Zeitstempel und Metadaten zum betroffenen Artikel oder Projekt. Die genauen Felder variieren je nach Ereignis – siehe die untenstehenden Nutzlastbeispiele für Details.
Kann ich ein externes Automatisierungstool auslösen, wenn sich der Workflow-Status eines Artikels ändert?
Ja. Weisen Sie das aktualisierte Ereignis des Artikel-Workflows einem Webhook-Kanal unter Benachrichtigungszuordnung zu. Immer wenn ein Artikel oder eine Seitenkategorie in einen Workflow-Status wechselt oder verlässt, sendet Document360 einen Webhook an Ihre konfigurierte URL, den Ihre Automatisierungsplattform (wie n8n, Make oder Zapier) als Auslöser nutzen kann. Überprüfen Sie die Nutzlast, die Ihre Automatisierungsplattform erhält, um zu bestätigen, welche Felder sie zur Identifikation des jeweiligen Artikels verwenden kann, da Nutzlastfelder je nach Ereignistyp variieren.
Wie sieht eine Beispiel-Webhook-Nutzlast aus?
Nachfolgend eine Beispielnutzlast für das gespeicherte Ereignis Artikeleinstellungen :
{
"Knowledge base name": "Document360 2.0",
"Event": "Article settings saved",
"User": "Matt Sterling",
"User email": "matt.sterling@document360.co",
"Logged on (UTC)": "09/12/2025 06:15:00",
"Article name": "Getting Started",
"Article id": "e1444f0x-0xx0-000x-xxx0-0x3f2bc3713c",
"Language": "English",
"Language code": "en",
"Project version id": "55144000-0xxx-000x-0000-0x2346b3bms3",
"Project version name": "1.0"
}
Die Nutzlastfelder sind:
| Spielfeld | Beschreibung |
|---|---|
| Name der Wissensdatenbank | Der Name des Wissensdatenbankprojekts. |
| Veranstaltung | Die Aktion, die den Webhook ausgelöst hat (z. B. Artikel veröffentlicht). |
| Benutzer-/Benutzer-E-Mail | Das Teammitglied, das die Aktion ausgeführt hat. |
| Eingeloggt (UTC) | Datum und Uhrzeit der Aktion in UTC. |
| Artikelname / Artikel-ID | Details des betroffenen Artikels. |
| Sprache / Sprachcode | Die Sprache des Artikels. |
| Projekt-Versions-ID | Eindeutige Identifikator der mit dem Artikel verbundenen Version der Wissensdatenbank. |
| Versionsname des Projekts | Anzeigename der mit dem Artikel verbundenen Version der Wissensdatenbank. |
Die Felder für die Projektversions-ID und den Namen der Projektversion sind nun Standard in allen artikelbezogenen Webhook-Events, einschließlich: Artikeleinstellungen gespeichert, Artikelumleitungsregel hinzugefügt, Artikelumleitungsregel aktualisiert und Artikelumleitungsregel gelöscht. Dadurch können Sie die zugehörige Version für jede Artikelaktion zuverlässig identifizieren, ohne zusätzliche API-Aufrufe.
Enthält die Delete-Event-Payload den Artikel-Slug?
Ja. Wenn ein Artikel gelöscht wird, enthält die Nutzlast ein Slugs-Feld , das den Slug des gelöschten Artikels in jeder verfügbaren Sprache zurückgibt. So können Sie die korrekten Cache-Einträge sofort identifizieren und entfernen, sobald der Webhook ausgelöst wird, ohne zusätzliche API-Aufrufe vornehmen zu müssen.
{
"Knowledge base name": "My Knowledge Base",
"Event": "Article deleted",
"User": "John Doe",
"User email": "johndoe@example.com",
"Logged on (UTC)": "02/13/2026 10:57:16",
"Article name": "Getting Started Guides",
"Article id": "24a4e58a-9d64-453c-8f00-4159eb94b82e",
"Language": "English",
"Project version id": "0644e0fe-2ae1-4d16-a993-98b81524d5c4",
"Language code": "en",
"Slugs": [
{ "language": "en", "slug": "getting-started" },
{ "language": "fr", "slug": "demarrer" },
{ "language": "de", "slug": "erste-schritte" }
]
}
Unterscheiden sich die Nutzlaststrukturen bei Nicht-Artikel-Ereignissen?
Ja. Die Nutzlaststruktur variiert je nach Ereignistyp. Das Ereignisfeld spiegelt immer die auslösende Aktion wider, und die übrigen Felder sind spezifisch für das betroffene Objekt. Zum Beispiel enthält ein Erweiterungs-Token-Löschereignis ein Erweiterungsfeld , ein Widget-Einstellungsereignis ein Widget-Einstellungsnamen-Feld und ein Laufwerkordner-Event ein Ordnernamen-Feld . Felder, die nicht auf ein bestimmtes Ereignis angewendet werden, werden aus der Nutzlast weggelassen.
{
"Knowledge base name": "Document360 2.0",
"Event": "Extension token deleted",
"User": "Matt Sterling",
"User email": "matt.sterling@document360.co",
"Logged on (UTC)": "09/12/2025 06:47:10",
"Extension": "MAKE"
}