Automations
Webhooks
The webhook action pushes a signed HTTP call to another system the moment something happens in Gfacility, with your own headers, your own payload and a readable example of what the receiver gets.
Updated Jul 25, 2026
Configuration · Automation · 9.4
A webhook is the outbound half of your integration story: the moment a ticket, booking, asset or visitor changes in Gfacility, an HTTP call goes out to a URL you own. No polling, no nightly export, no middleware to babysit. It is one of the seven actions in 9.2 Automations, so it inherits the same triggers, conditions and run history as every other action.
Use it when the other system has to react. For reading data on your own schedule, the API and the Power BI connector are the better fit.
Why this matters to the business
"Finance rekeys every charge by hand"
Booking closed, push the chargeback lines straight into the finance system.
"Our status page lags reality"
A major incident changes status, the public page updates within seconds.
"Access badges are ordered too late"
Visitor approved, notify the access control system before they arrive.
"Auditors want an external trail"
Deleted records go out to your own log store, outside Gfacility.
What you configure
| Setting | What it does |
|---|---|
| Webhook URL | The HTTPS endpoint that receives the call. |
| Apply to | Which record's data travels along. A child scope, such as a booking's visitors, sends one call per matched record rather than one call with a list. |
| Send changes of these fields | The receiver gets the old and the new value of each field you pick. Leave it empty to send every changed field. |
| Custom headers | For the receiver's own authentication, such as Authorization or X-Api-Key. Sent with every call. |
| Extra payload | Optional JSON merged into the call under "extra", so you can pass a tenant id or a routing key the receiver needs. |
| Custom request body | For a receiver that insists on its own exact structure: your JSON becomes the entire request body and the standard record payload is left out. |
Tokens, so the payload carries real values
Values in the extra payload and in a custom request body support tokens, written as double curly braces around a field path. The editor has an Insert token picker with search, so you do not have to memorise field names: pick the field and the token is written for you. At run time each token is replaced with that record’s value.
This is what turns a fixed body into a useful one: the receiver gets the ticket number, the location and the requester’s email instead of a hard-coded placeholder.
Security
Signed requests
Every call carries an HMAC signature header. Verify it on your side before you trust the body, so a third party cannot forge a call to your endpoint.
Encrypted headers
Header values are stored encrypted and shown masked after saving. Leave the mask untouched to keep the current value; nobody reads your API key back out of the form.
Build it, then look before you activate
The editor validates your JSON while you type, tells you when it is not valid and shows an example of a valid structure. Next to it, What the receiver gets renders the actual payload, so you can compare it against the other system’s documentation before a single call goes out.
After that, the normal automation flow applies: dry run the rule against a real record, check the entry in run history, then activate.
Which decisions will you make?
Standard payload or custom body?
Standard plus extra payload is easier to maintain. Only go custom when the receiver cannot be changed.
Which fields does the receiver really need?
Sending every changed field is convenient but noisy, and it leaks more than the receiver needs.
Who owns the endpoint?
Name an owner on the receiving side. A webhook nobody maintains fails silently for months.
What happens on failure?
Decide whether the rest of the rule should still run, using "stop on first failed action".