NexTool Solutions

O GLPI 11 tem webhook nativo: a cada chamado aberto, alterado ou excluído, ele avisa outro sistema por HTTP, com assinatura e novas tentativas. Testamos no nosso GLPI de suporte e a primeira configuração não entregou nada. O motivo não estava em nenhuma tela: o GLPI recusa qualquer URL com porta, como :8080 ou a :5678 padrão do n8n. Este guia mostra como configurar, o que o teste mediu e os três detalhes que travam a integração.

Precisa ir além do webhook de saída, com condições, várias etapas ou receber dados de fora? Veja Automações e webhooks no GLPI com o NexTool.

O que o webhook nativo faz (e o que não faz)

O webhook do GLPI 11 é de saída: quando algo acontece num item, o GLPI monta uma mensagem e envia para uma URL. Serve para avisar um ERP, abrir um card no Teams, alimentar um painel ou disparar um fluxo no n8n.

• Eventos: novo, atualização e exclusão.
• Itens: os mesmos da API nova do GLPI 11, como chamados, problemas, mudanças, ativos e usuários.
• Mensagem: por padrão, o item no formato da API (status, solicitante, equipe, entidade, datas), editável com variáveis.

Ele não recebe nada. Para outro sistema criar ou alterar chamados no GLPI, o caminho é a API.

Onde configurar

Em Configurar > Webhooks > Adicionar:

E nas abas:

• Critérios: filtra quais itens disparam, com os mesmos critérios da busca. Ex.: só chamados da categoria "Compras".
• Editor de carga: troca a mensagem padrão por um modelo seu, com pré-visualização.
• Segurança: segredo da assinatura, desafio de validação da URL e autenticação OAuth.
• Cabeçalhos personalizados: como Authorization ou Content-Type.

O teste: o que medimos

Criamos dois webhooks na entidade de testes do nosso GLPI de suporte (empresa fictícia Acme) e abrimos chamados. Um apontava para um destino que responde 200; o outro, para um destino que responde erro 500.

Os três detalhes que travam a integração

1. URL com porta é recusada

O GLPI 11 só chama URLs que passam numa lista de permissão (proteção contra uso indevido do servidor). A regra padrão aceita domínio, IP e caminho, mas não aceita porta. O erro não aparece na tela: fica no webhook.log, como "Webhook target URL ... is unsafe".

Testamos a função do próprio GLPI:

Solução: publique o destino na porta padrão (443 ou 80), normalmente atrás de um proxy reverso. Isso também resolve o HTTPS. Dá para ampliar a lista com a constante GLPI_SERVERSIDE_URL_ALLOWLIST, mas ela vale para todo acesso do servidor a URLs externas, então mexa com cuidado.

2. Sem Content-Type, o destino pode não entender o JSON

O GLPI envia o corpo em JSON, mas sem o cabeçalho Content-Type. Ferramentas como o n8n e muitos frameworks só leem o corpo como JSON quando o cabeçalho diz isso.

Solução: em Cabeçalhos personalizados, adicione Content-Type: application/json.

3. Sem cron, nada sai

O webhook não é enviado na hora: vai para uma fila, e a ação automática queuedwebhook envia a cada minuto, até 50 por vez. Se o cron do GLPI não estiver rodando, a fila só cresce.

Solução: cron por linha de comando a cada minuto (veja o passo 6 de como instalar o GLPI 11) e, de vez em quando, um olho em Configurar > Webhooks > Fila de webhooks (Webhook queue, na tela).

Como validar a assinatura no destino

Cada envio traz dois cabeçalhos: X-GLPI-timestamp (momento do evento) e X-GLPI-signature. A assinatura é o HMAC-SHA256 do corpo seguido do timestamp, com o segredo do webhook. Em Python:

import hmac, hashlib

def assinatura_valida(corpo: bytes, timestamp: str, assinatura: str, segredo: str) -> bool:
    calc = hmac.new(segredo.encode(), corpo + timestamp.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(calc, assinatura)

Dois cuidados: - O timestamp é do evento, não do envio. Nas novas tentativas ele se repete. Se você recusar mensagens "velhas", deixe uma janela que cubra as tentativas (alguns minutos). - Use o corpo bruto, do jeito que chegou. Se o seu código decodificar e codificar o JSON de novo, a assinatura não bate.

Para quem precisa de mais garantia, a aba Segurança tem o desafio de validação: antes de enviar, o GLPI chama a URL com um crc_token, e o destino precisa responder com o HMAC desse token. Também há OAuth (client credentials): o GLPI pega um token no servidor de autorização e envia como Bearer.

Quando o webhook nativo não basta

• Receber dados de outro sistema: precisa da API.
• Lógica com várias condições e etapas, como "se a categoria for X e o solicitante for da diretoria, avisa um canal e abre uma tarefa": os Critérios filtram, mas não encadeiam ações.
• Ver numa tela só o que falhou e reenviar com um clique. A fila mostra o status, mas o diagnóstico está no webhook.log.

Nesses casos, entram um orquestrador como o n8n ou o módulo Automações do NexTool.

Checklist antes de ligar em produção

1. Destino em HTTPS, na porta padrão, sem :porta na URL.
2. Cabeçalho Content-Type: application/json.
3. Assinatura validada no destino, com o corpo bruto e janela de tempo para as tentativas.
4. Critérios para não disparar em tudo.
5. "Número de tentativas" de acordo com a importância (3 é um bom começo).
6. Cron do GLPI rodando a cada minuto.
7. "Log no histórico do item" ligado, para o técnico ver o que foi enviado.
8. Teste com um chamado fictício antes de abrir para todos.

Teste da NexTool em 3 de outubro de 2026, no GLPI 11.0.7 do nosso suporte, entidade de testes com dados fictícios. Os webhooks e chamados de teste foram apagados depois. Comportamentos conferidos também no código-fonte do GLPI 11.