NexTool Solutions

GLPI 11 tiene webhook nativo: cada vez que se abre, modifica o elimina un ticket, avisa a otro sistema por HTTP, con firma y reintentos. Lo probamos en nuestro GLPI de soporte y la primera configuración no entregó nada. El motivo no aparecía en ninguna pantalla: GLPI rechaza cualquier URL con puerto, como :8080 o el :5678 predeterminado de n8n. Esta guía muestra cómo configurarlo, qué midió la prueba y los tres detalles que bloquean la integración.

¿Necesita ir más allá del webhook de salida, con condiciones, varias etapas o recibir datos de fuera? Consulte Automatizaciones y webhooks en GLPI con NexTool.

Qué hace el webhook nativo (y qué no hace)

El webhook de GLPI 11 es de salida: cuando ocurre algo en un elemento, GLPI arma un mensaje y lo envía a una URL. Sirve para avisar a un ERP, abrir una tarjeta en Teams, alimentar un panel o disparar un flujo en n8n.

• Eventos: nuevo, actualización y eliminación.
• Elementos: los mismos de la nueva API de GLPI 11, como tickets, problemas, cambios, activos y usuarios.
• Mensaje: por defecto, el elemento en el formato de la API (estado, solicitante, equipo, entidad, fechas), editable con variables.

No recibe nada. Para que otro sistema cree o modifique tickets en GLPI, el camino es la API.

Dónde configurarlo

En Configuración > Webhooks > Agregar:

Y en las pestañas:

• Criterios: filtra qué elementos disparan el webhook, con los mismos criterios de la búsqueda. Ej.: solo tickets de la categoría "Compras".
• Editor de carga útil: sustituye el mensaje predeterminado por una plantilla propia, con vista previa.
• Seguridad: secreto de la firma, desafío de validación de la URL y autenticación OAuth.
• Encabezados personalizados: como Authorization o Content-Type.

La prueba: qué medimos

Creamos dos webhooks en la entidad de pruebas de nuestro GLPI de soporte (empresa ficticia Acme) y abrimos tickets. Uno apuntaba a un destino que responde 200; el otro, a un destino que responde error 500.

Los tres detalles que bloquean la integración

1. La URL con puerto se rechaza

GLPI 11 solo llama a URLs que pasan una lista de permitidos (protección contra el uso indebido del servidor). La regla predeterminada acepta dominio, IP y ruta, pero no acepta puerto. El error no aparece en pantalla: queda en webhook.log, como "Webhook target URL ... is unsafe".

Probamos la función del propio GLPI:

Solución: publique el destino en el puerto predeterminado (443 u 80), normalmente detrás de un proxy inverso. Eso también resuelve el HTTPS. Es posible ampliar la lista con la constante GLPI_SERVERSIDE_URL_ALLOWLIST, pero se aplica a todo acceso del servidor a URLs externas, así que modifíquela con cuidado.

2. Sin Content-Type, el destino puede no entender el JSON

GLPI envía el cuerpo en JSON, pero sin el encabezado Content-Type. Herramientas como n8n y muchos frameworks solo leen el cuerpo como JSON cuando el encabezado lo indica.

Solución: en Encabezados personalizados, agregue Content-Type: application/json.

3. Sin cron, no sale nada

El webhook no se envía en el momento: va a una cola, y la acción automática queuedwebhook envía cada minuto, hasta 50 a la vez. Si el cron de GLPI no está en ejecución, la cola no para de crecer.

Solución: cron por línea de comandos cada minuto (vea el paso 6 de cómo instalar GLPI 11) y, de vez en cuando, un vistazo a Configuración > Webhooks > Cola de webhooks.

Cómo validar la firma en el destino

Cada envío trae dos encabezados: X-GLPI-timestamp (momento del evento) y X-GLPI-signature. La firma es el HMAC-SHA256 del cuerpo seguido del timestamp, con el secreto del webhook. En 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)

Dos precauciones: - El timestamp es del evento, no del envío. En los reintentos se repite. Si rechaza mensajes "viejos", deje una ventana que cubra los reintentos (algunos minutos). - Use el cuerpo sin procesar, tal como llegó. Si su código decodifica y vuelve a codificar el JSON, la firma no coincide.

Para quien necesita más garantías, la pestaña Seguridad tiene el desafío de validación: antes de enviar, GLPI llama a la URL con un crc_token, y el destino debe responder con el HMAC de ese token. También está OAuth (client credentials): GLPI obtiene un token en el servidor de autorización y lo envía como Bearer.

Cuándo el webhook nativo no basta

• Recibir datos de otro sistema: se necesita la API.
• Lógica con varias condiciones y etapas, como "si la categoría es X y el solicitante es de la dirección, avisa a un canal y abre una tarea": los Criterios filtran, pero no encadenan acciones.
• Ver en una sola pantalla lo que falló y reenviar con un clic. La cola muestra el estado, pero el diagnóstico está en webhook.log.

En estos casos, entran en juego un orquestador como n8n o el módulo Automatizaciones de NexTool.

Checklist antes de activarlo en producción

1. Destino en HTTPS, en el puerto predeterminado, sin :porta en la URL.
2. Encabezado Content-Type: application/json.
3. Firma validada en el destino, con el cuerpo sin procesar y una ventana de tiempo para los reintentos.
4. Criterios para no dispararlo con todo.
5. "Número de reintentos" según la importancia (3 es un buen comienzo).
6. Cron de GLPI en ejecución cada minuto.
7. "Registrar en el historial del elemento" activado, para que el técnico vea lo que se envió.
8. Prueba con un ticket ficticio antes de abrirlo a todos.

Prueba de NexTool del 3 de octubre de 2026, en el GLPI 11.0.7 de nuestro soporte, entidad de pruebas con datos ficticios. Los webhooks y tickets de prueba se eliminaron después. Comportamientos verificados también en el código fuente de GLPI 11.