NexTool Solutions

GLPI 11 hat einen nativen Webhook: Bei jedem erstellten, geänderten oder gelöschten Ticket benachrichtigt er ein anderes System per HTTP, mit Signatur und Wiederholungsversuchen. Wir haben ihn in unserem Support-GLPI getestet, und die erste Konfiguration hat nichts zugestellt. Der Grund stand auf keinem Bildschirm: GLPI lehnt jede URL mit Port ab, etwa :8080 oder den Standardport :5678 von n8n. Diese Anleitung zeigt, wie Sie ihn konfigurieren, was der Test gemessen hat und welche drei Details die Integration blockieren.

Sie brauchen mehr als einen ausgehenden Webhook, mit Bedingungen, mehreren Schritten oder dem Empfang von Daten von außen? Siehe Automatisierungen und Webhooks im GLPI mit NexTool.

Was der native Webhook tut (und was nicht)

Der Webhook von GLPI 11 ist ausgehend: Wenn bei einem Element etwas passiert, erstellt GLPI eine Nachricht und sendet sie an eine URL. Damit können Sie ein ERP benachrichtigen, eine Karte in Teams öffnen, ein Dashboard speisen oder einen Flow in n8n auslösen.

• Ereignisse: neu, Aktualisierung und Löschung.
• Elemente: dieselben wie in der neuen API von GLPI 11, etwa Tickets, Probleme, Änderungen, Assets und Benutzer.
• Nachricht: standardmäßig ein Element im API-Format (Status, Anforderer, Team, Einheit, Datumsangaben), mit Variablen bearbeitbar.

Er empfängt nichts. Damit ein anderes System Tickets im GLPI erstellt oder ändert, führt der Weg über die API.

Wo Sie ihn konfigurieren

Unter Einrichtung > Webhooks > Hinzufügen:

Und in den Registerkarten:

• Kriterien: filtert, welche Elemente auslösen, mit denselben Kriterien wie die Suche. Z. B. nur Tickets der Kategorie „Einkauf“.
• Payload-Editor: ersetzt die Standardnachricht durch Ihre eigene Vorlage, mit Vorschau.
• Sicherheit: Geheimnis für die Signatur, Validierungs-Challenge der URL und OAuth-Authentifizierung.
• Benutzerdefinierte Header: etwa Authorization oder Content-Type.

Der Test: was wir gemessen haben

Wir haben zwei Webhooks in der Testeinheit unseres Support-GLPI angelegt (fiktives Unternehmen Acme) und Tickets erstellt. Einer zeigte auf ein Ziel, das mit 200 antwortet; der andere auf ein Ziel, das mit Fehler 500 antwortet.

Die drei Details, die die Integration blockieren

1. Eine URL mit Port wird abgelehnt

GLPI 11 ruft nur URLs auf, die eine Zulassungsliste passieren (Schutz vor Missbrauch des Servers). Die Standardregel akzeptiert Domain, IP und Pfad, aber keinen Port. Der Fehler erscheint nicht auf dem Bildschirm: Er steht in webhook.log, als „Webhook target URL ... is unsafe“.

Wir haben die Funktion von GLPI selbst getestet:

Lösung: Veröffentlichen Sie ein Ziel auf dem Standardport (443 oder 80), in der Regel hinter einem Reverse Proxy. So lösen Sie auch HTTPS. Die Liste lässt sich mit der Konstante GLPI_SERVERSIDE_URL_ALLOWLIST erweitern, aber sie gilt für jeden Zugriff des Servers auf externe URLs, ändern Sie sie also mit Bedacht.

2. Ohne Content-Type versteht ein Ziel JSON möglicherweise nicht

GLPI sendet den Body als JSON, aber ohne den Header Content-Type. Werkzeuge wie n8n und viele Frameworks lesen den Body nur dann als JSON, wenn der Header dies angibt.

Lösung: Fügen Sie unter Benutzerdefinierte Header Content-Type: application/json hinzu.

3. Ohne Cron geht nichts raus

Der Webhook wird nicht sofort gesendet: Er kommt in eine Warteschlange, und die automatische Aktion queuedwebhook sendet jede Minute, bis zu 50 auf einmal. Läuft der GLPI-Cron nicht, wächst die Warteschlange nur.

Lösung: Cron über die Kommandozeile jede Minute (siehe Schritt 6 in So installieren Sie GLPI 11) und ab und zu ein Blick auf Einrichtung > Webhooks > Webhook-Warteschlange (Webhook queue auf dem Bildschirm).

So validieren Sie die Signatur beim Ziel

Jede Sendung enthält zwei Header: X-GLPI-timestamp (Zeitpunkt des Ereignisses) und X-GLPI-signature. Die Signatur ist der HMAC-SHA256 des Body, gefolgt vom Timestamp, mit dem Geheimnis des Webhooks. In 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)

Zwei Vorsichtsmaßnahmen: - Der Timestamp stammt vom Ereignis, nicht vom Versand. Bei Wiederholungsversuchen bleibt er gleich. Wenn Sie „alte“ Nachrichten ablehnen, lassen Sie ein Zeitfenster, das die Versuche abdeckt (einige Minuten). - Verwenden Sie den rohen Body, so wie er angekommen ist. Wenn Ihr Code JSON dekodiert und erneut kodiert, stimmt die Signatur nicht.

Wer mehr Sicherheit braucht, findet in der Registerkarte Sicherheit die Validierungs-Challenge: Vor dem Versand ruft GLPI die URL mit einem crc_token auf, und ein Ziel muss mit dem HMAC dieses Tokens antworten. Außerdem gibt es OAuth (client credentials): GLPI holt sich einen Token beim Autorisierungsserver und sendet ihn als Bearer.

Wann der native Webhook nicht ausreicht

• Daten empfangen von einem anderen System: Dafür brauchen Sie die API.
• Logik mit mehreren Bedingungen und Schritten, etwa „wenn die Kategorie X ist und der Anforderer zur Geschäftsleitung gehört, einen Kanal benachrichtigen und eine Aufgabe anlegen“: Die Kriterien filtern, verketten aber keine Aktionen.
• Auf einem einzigen Bildschirm sehen, was fehlgeschlagen ist, und mit einem Klick erneut senden. Die Warteschlange zeigt den Status, aber die Diagnose steht in webhook.log.

In diesen Fällen kommen ein Orchestrator wie n8n oder ein Modul wie Automations von NexTool ins Spiel.

Checkliste vor dem Einschalten in der Produktion

1. Ziel über HTTPS, auf dem Standardport, ohne :porta in der URL.
2. Header Content-Type: application/json.
3. Signatur beim Ziel validiert, mit rohem Body und Zeitfenster für die Versuche.
4. Kriterien, damit nicht bei allem ausgelöst wird.
5. „Anzahl der Versuche“ je nach Wichtigkeit (3 ist ein guter Anfang).
6. GLPI-Cron läuft jede Minute.
7. „Protokoll in der Historie des Elements“ aktiviert, damit der Techniker sieht, was gesendet wurde.
8. Test mit einem fiktiven Ticket, bevor Sie es für alle freigeben.

NexTool-Test vom 3. Oktober 2026, in GLPI 11.0.7 unseres Supports, Testeinheit mit fiktiven Daten. Die Webhooks und Testtickets wurden anschließend gelöscht. Das Verhalten wurde zusätzlich im Quellcode von GLPI 11 überprüft.