Automatisierung
Webhooks
Die Webhook-Aktion schickt einen signierten HTTP-Aufruf an ein anderes System, sobald in Gfacility etwas passiert, mit eigenen Headern, eigener Payload und einem lesbaren Beispiel dessen, was der Empfänger bekommt.
Aktualisiert am 25. Juli 2026
Konfiguration · Automatisierung · 9.4
Ein Webhook ist die ausgehende Hälfte Ihrer Integration: Sobald sich ein Ticket, eine Reservierung, ein Asset oder ein Besucher in Gfacility ändert, geht ein HTTP-Aufruf an eine URL, die Ihnen gehört. Kein Polling, kein Nachtexport, keine Middleware zum Beaufsichtigen. Es ist eine der sieben Aktionen in 9.2 Automatisierungen, also erbt er dieselben Trigger, Bedingungen und dieselbe Ausführungshistorie wie jede andere Aktion.
Nutzen Sie ihn, wenn das andere System reagieren muss. Wollen Sie Daten selbst zu Ihrem Zeitpunkt lesen, passen die API und der Power-BI-Connector besser.
Warum das für das Unternehmen zählt
"Finance tippt jede Verrechnung von Hand nach"
Reservierung abgeschlossen, die Verrechnungszeilen direkt ins Finanzsystem schieben.
"Unsere Statusseite hängt hinter der Realität"
Ein Major Incident wechselt den Status, die öffentliche Seite ist in Sekunden aktuell.
"Zugangsausweise werden zu spät bestellt"
Besucher freigegeben, das Zutrittskontrollsystem informieren, bevor er ankommt.
"Prüfer wollen eine externe Spur"
Gelöschte Datensätze gehen in Ihren eigenen Logspeicher, außerhalb von Gfacility.
Was Sie einstellen
| Einstellung | Was sie bewirkt |
|---|---|
| Webhook-URL | Der HTTPS-Endpunkt, der den Aufruf empfängt. |
| Anwenden auf | Von welchem Datensatz die Daten mitgehen. Ein untergeordneter Bereich, etwa die Besucher einer Reservierung, sendet einen Aufruf pro Treffer statt eines Aufrufs mit einer Liste. |
| Änderungen dieser Felder senden | Der Empfänger erhält den alten und den neuen Wert jedes Feldes, das Sie wählen. Leer lassen, um jedes geänderte Feld zu senden. |
| Eigene Header | Für die Authentifizierung des Empfängers, etwa Authorization oder X-Api-Key. Geht bei jedem Aufruf mit. |
| Zusätzliche Payload | Optionales JSON, das unter "extra" in den Aufruf einfließt, damit Sie eine Mandanten-ID oder einen Routing-Schlüssel mitgeben können, den der Empfänger braucht. |
| Eigener Request-Body | Für einen Empfänger, der auf seiner exakten Struktur besteht: Ihr JSON wird der gesamte Request-Body, die Standard-Payload des Datensatzes entfällt. |
Tokens, damit die Payload echte Werte trägt
Werte in der zusätzlichen Payload und in einem eigenen Request-Body unterstützen Tokens, geschrieben als doppelte geschweifte Klammern um einen Feldpfad. Der Editor hat eine Auswahl Token einfügen mit Suche, damit Sie keine Feldnamen auswendig kennen müssen: Feld wählen und das Token wird für Sie geschrieben. Bei der Ausführung wird jedes Token durch den Wert dieses Datensatzes ersetzt.
Genau das macht einen festen Body erst nützlich: Der Empfänger bekommt die Ticketnummer, den Standort und die E-Mail des Anfragenden statt eines fest eingetragenen Platzhalters.
Sicherheit
Signierte Aufrufe
Jeder Aufruf trägt einen HMAC-Signatur-Header. Prüfen Sie ihn auf Ihrer Seite, bevor Sie dem Body vertrauen, damit Dritte keinen Aufruf an Ihren Endpunkt fälschen können.
Verschlüsselte Header
Header-Werte werden verschlüsselt gespeichert und nach dem Speichern maskiert angezeigt. Lassen Sie die Maske stehen, um den aktuellen Wert zu behalten; niemand liest Ihren API-Schlüssel aus dem Formular zurück.
Bauen, hinsehen, erst dann aktivieren
Der Editor prüft Ihr JSON beim Tippen, sagt Ihnen, wenn es nicht gültig ist, und zeigt ein Beispiel einer gültigen Struktur. Daneben zeigt Was der Empfänger bekommt die echte Payload, damit Sie sie mit der Dokumentation des anderen Systems vergleichen können, bevor ein einziger Aufruf hinausgeht.
Danach gilt der normale Automatisierungsweg: Testlauf der Regel an einem echten Datensatz, Eintrag in der Ausführungshistorie prüfen, dann aktivieren.
Welche Entscheidungen treffen Sie?
Standard-Payload oder eigener Body?
Standard plus zusätzliche Payload ist leichter zu pflegen. Wechseln Sie nur dann zum eigenen Body, wenn der Empfänger nicht angepasst werden kann.
Welche Felder braucht der Empfänger wirklich?
Jedes geänderte Feld zu senden ist bequem, aber unruhig, und gibt mehr weiter, als der Empfänger braucht.
Wer ist Eigentümer des Endpunkts?
Benennen Sie einen Eigentümer auf der Empfangsseite. Ein Webhook, den niemand pflegt, scheitert monatelang unbemerkt.
Was passiert bei einem Fehler?
Entscheiden Sie mit "bei erster fehlgeschlagener Aktion stoppen", ob der Rest der Regel dann noch laufen soll.