Um canal de notificação de webhook no Document360 é um método automatizado de enviar dados de eventos em tempo real da sua base de conhecimento para um aplicativo externo sempre que ocorre uma ação específica. Webhooks eliminam a necessidade de monitoramento manual ao enviar cargas JSON estruturadas diretamente para uma URL de sua escolha — como um canal Slack, uma integração personalizada ou uma plataforma de automação. Você pode configurar múltiplos canais de webhook e mapear cada um para eventos específicos da base de conhecimento por meio das configurações de mapeamento de notificações .
Quando usar canais de notificação por webhook
Use notificações do webhook quando quiser automatizar como sua equipe ou sistemas externos respondem a mudanças na base de conhecimento.
- Alertas de equipe: Notifique uma equipe de suporte ou documentação no Slack ou Microsoft Teams no momento em que um artigo for publicado, atualizado ou excluído — sem que ninguém precise verificar o portal manualmente.
- Invalidação do cache: Detecte eventos de exclusão de artigos (que incluem slugs para todos os idiomas) e remova automaticamente as entradas correspondentes do seu cache de conteúdo.
- Automação de fluxos de trabalho: Acione processos posteriores em ferramentas como Make ou Zapier quando eventos específicos ocorrem, como a publicação de um novo artigo ou a exclusão de um token de extensão.
- Auditoria e conformidade: Transmita a atividade da base de conhecimento para um serviço de registro para manter um registro em tempo real de quem mudou o quê e quando.
- Automação de workflows personalizados: Mapeie o evento atualizado do status do fluxo de trabalho do artigo para um canal de webhook, de modo que mover um artigo para um status específico de fluxo de trabalho personalizado (por exemplo, um status usado para transferir conteúdo para uma etapa externa de revisão) possa acionar uma plataforma de automação downstream como n8n, Make ou Zapier.
Antes de começar
- Tenha a URL do webhook de destino pronta — esse é o endpoint fornecido pelo aplicativo receptor (por exemplo, uma URL de webhook recebida do Slack, um webhook de cenário Make ou seu próprio endpoint de servidor).
- Se a aplicação receptora exigir autenticação, obtenha a chave de autorização antes de começar.
Como configurar um canal de notificação de webhook
-
Navegue até Configurações () > portal da base de conhecimento na barra de navegação esquerda.
-
No painel de navegação à esquerda, selecione Notificações.
A aba Canais está selecionada por padrão. -
Clique em Novo canal.
-
No painel de Canais Disponíveis , selecione Webhook.

Configurar as opções de canal aparece no mesmo painel assim que você clica no tipo de canal.
-
No campo de nome Friendly , insira um nome único para este canal webhook.
-
No menu suspenso do método de Solicitação , selecione POST ou PUT dependendo do que a solicitação receptora espera.
-
No campo URL do Webhook , insira a URL de destino onde as notificações devem ser enviadas.
-
No menu suspenso Solicitar conteúdo , escolha o formato da mensagem para a carga útil.
-
Se o aplicativo receptor precisar de cabeçalhos HTTP adicionais, clique em Adicionar () na chave de Autorização e adicione cada cabeçalho como um par chave-valor.
-
Se for necessária autenticação, insira a chave de Autorização no campo correspondente.
-
Clique em Salvar.

O canal do webhook é criado e listado em Canais de Notificações. Para ativá-lo, vá na aba de mapeamento de notificações e mapeie o canal para os eventos que você deseja acompanhar.
Para detalhes sobre cabeçalhos de requisição HTTP suportados e seus formatos esperados, consulte a referência do cabeçalho MDN Request.
Melhores práticas
- Use nomes amigáveis descritivos que identifiquem tanto o destino quanto o escopo do evento — por exemplo,
Slack-ArticlePublishouMake-AllEvents— para que os canais fiquem fáceis de distinguir ao mapear notificações. - Escopar cada canal para um conjunto focado de eventos , em vez de rotear todos os eventos por um único webhook. Isso facilita o gerenciamento de falhas e a tentativa de tipos específicos de eventos de forma independente.
- Proteja seu endpoint com uma chave de autorização sempre que o aplicativo receptor a suportar, para evitar que cargas úteis não autorizadas cheguem aos seus sistemas.
- Use o campo Slugs nos eventos de exclusão para identificar e eliminar imediatamente as entradas corretas de cache em todos os idiomas quando um artigo for removido, evitando conteúdo obsoleto.
FAQ
Quais informações estão incluídas em uma notificação de webhook?
Quando um webhook é ativado, o Document360 envia uma carga útil JSON estruturada para a URL configurada. A carga útil inclui o tipo de evento, o usuário que realizou a ação, o carimbo de data UTC e metadados sobre o artigo ou projeto afetado. Os campos exatos variam conforme o evento — veja os exemplos de payload abaixo para detalhes.
Posso acionar uma ferramenta externa de automação quando o status do fluxo de trabalho de um artigo muda?
Sim. Mapeie o evento atualizado do status do fluxo de trabalho do artigo para um canal de webhook em Mapeamento de Notificações. Sempre que um artigo ou categoria de página entra ou sai de um status de fluxo de trabalho, o Document360 envia um webhook para sua URL configurada, que sua plataforma de automação (como n8n, Make ou Zapier) pode usar como gatilho. Verifique o payload que sua plataforma de automação recebe para confirmar quais campos pode usar para identificar o artigo específico, já que os campos do payload variam conforme o tipo de evento.
Como é uma carga útil de webhook de exemplo?
Abaixo está um exemplo de carga útil para o evento salvo de configurações do artigo :
{
"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"
}
Os campos de carga útil são:
| Campo | Descrição |
|---|---|
| Nome da base de conhecimento | O nome do projeto da base de conhecimento. |
| Evento | A ação que desencadeou o webhook (por exemplo, artigo publicado). |
| Usuário / Usuário eletrônico | O membro da equipe que realizou a ação. |
| Logado (UTC) | Data e hora da ação no UTC. |
| Nome do artigo / ID do artigo | Detalhes do artigo afetado. |
| Idioma / Código de idioma | A linguagem do artigo. |
| ID da versão do projeto | Identificador único da versão da base de conhecimento associada ao artigo. |
| Nome da versão do projeto | Nome exibido da versão da base de conhecimento associada ao artigo. |
Os campos ID de versão do Projeto e nome da versão do Projeto agora são padrão em todos os eventos webhook relacionados a artigos, incluindo: Configurações de Artigo Salvas, Regra de Redirecionamento de Artigo Adicionada, Regra de Redirecionamento de Artigos Atualizada e Regra de Redirecionamento de Artigo Deletada. Isso permite que você identifique de forma confiável a versão associada para cada ação de artigo sem chamadas adicionais de API.
O payload do evento de exclusão inclui o slug do artigo?
Sim. Quando um artigo é excluído, o payload inclui um campo Slugs que retorna o slug do artigo excluído em todos os idiomas em que estava disponível. Isso permite identificar e remover as entradas corretas do cache imediatamente quando o webhook é executado, sem fazer chamadas adicionais de API.
{
"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" }
]
}
As estruturas de carga útil diferem para eventos que não sejam artigos?
Sim. A estrutura do payload varia dependendo do tipo de evento. O campo Evento sempre reflete a ação que disparou, e os demais campos são específicos para o objeto envolvido. Por exemplo, um evento de exclusão de token de extensão inclui um campo Extensão , um evento de configuração de widget inclui um campo de nome de configuração de widget, e um evento de pasta Drive inclui um campo de nome de pasta . Campos que não se aplicam a um determinado evento são omitidos do 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"
}