A webhook notification channel in Document360 is an automated method of sending real-time event data from your knowledge base to an external application whenever a specified action occurs. Webhooks eliminate the need for manual monitoring by pushing structured JSON payloads directly to a URL of your choice — such as a Slack channel, a custom integration, or an automation platform. You can configure multiple webhook channels and map each one to specific knowledge base events through the Notification mapping settings.
When to use webhook notification channels
Use webhook notifications when you want to automate how your team or external systems respond to changes in the knowledge base.
- Team alerts: Notify a support or documentation team in Slack or Microsoft Teams the moment an article is published, updated, or deleted — without anyone needing to check the portal manually.
- Cache invalidation: Detect article deletion events (which include slugs for all languages) and automatically remove the corresponding entries from your content cache.
- Workflow automation: Trigger downstream processes in tools like Make or Zapier when specific events occur, such as a new article being published or an extension token being deleted.
- Audit and compliance: Stream knowledge base activity to a logging service to maintain a real-time audit trail of who changed what and when.
Before you begin
- Have the destination webhook URL ready — this is the endpoint provided by the receiving application (e.g., a Slack incoming webhook URL, a Make scenario webhook, or your own server endpoint).
- If the receiving application requires authentication, obtain the authorization key before starting.
How to set up a webhook notification channel
-
Navigate to Settings () > Knowledge base portal in the left navigation bar.
-
In the left navigation pane, select Notifications.
The Notification channels tab is selected by default. -
Click New channel.
-
In the Available channels panel, select Webhook and click Next.
The Channel configuration panel appears.
-
In the Friendly name field, enter a unique name for this webhook channel.
-
In the Request method dropdown, select POST or PUT depending on what the receiving application expects.
-
In the Webhook URL field, enter the destination URL where notifications should be sent.
-
In the Request content dropdown, choose the message format for the payload.
-
If the receiving application requires additional HTTP headers, click Add new () under Default headers and add each header as a key-value pair.
-
If authentication is required, enter the Authorization key in the corresponding field.
-
Click Save.
The webhook channel is created and listed under Notification channels. To activate it, go to the Notification mapping tab and map the channel to the events you want to track.
For details on supported HTTP request headers and their expected formats, refer to the MDN Request header reference.
Best practices
- Use descriptive friendly names that identify both the destination and the event scope — for example,
Slack-ArticlePublishorMake-AllEvents— so channels are easy to distinguish when mapping notifications. - Scope each channel to a focused set of events rather than routing all events through a single webhook. This makes it easier to manage failures and retry specific event types independently.
- Secure your endpoint with an authorization key whenever the receiving application supports it, to prevent unauthorised payloads from reaching your systems.
- Use the Slugs field in delete events to immediately identify and purge the correct cache entries across all languages when an article is removed, avoiding stale content.
FAQ
What information is included in a webhook notification?
When a webhook fires, Document360 sends a structured JSON payload to the configured URL. The payload includes the event type, the user who performed the action, the UTC timestamp, and metadata about the affected article or project. The exact fields vary by event — see the payload examples below for details.
What does a sample webhook payload look like?
Below is a sample payload for the Article settings saved event:
{
"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"
}
The payload fields are:
| Field | Description |
|---|---|
| Knowledge base name | The name of the knowledge base project. |
| Event | The action that triggered the webhook (e.g., Article published). |
| User / User email | The team member who performed the action. |
| Logged on (UTC) | Date and time of the action in UTC. |
| Article name / Article id | Details of the affected article. |
| Language / Language code | The language of the article. |
| Project version id | Unique identifier of the knowledge base version associated with the article. |
| Project version name | Display name of the knowledge base version associated with the article. |
The Project version id and Project version name fields are now standard across all article-related webhook events, including: Article Settings Saved, Article Redirection Rule Added, Article Redirection Rule Updated, and Article Redirection Rule Deleted. This allows you to reliably identify the associated version for every article action without additional API calls.
Does the delete event payload include the article slug?
Yes. When an article is deleted, the payload includes a Slugs field that returns the slug of the deleted article across every language it was available in. This lets you identify and remove the correct cache entries immediately when the webhook fires, without making additional API calls.
{
"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" }
]
}
Do payload structures differ for non-article events?
Yes. The payload structure varies depending on the event type. The Event field always reflects the triggering action, and the remaining fields are specific to the object involved. For example, an extension token deletion event includes an Extension field, a widget setting event includes a Widget setting name field, and a Drive folder event includes a Folder name field. Fields that do not apply to a given event are omitted from the payload.
{
"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"
}