Automatisering
Webhookar
Webhook-åtgärden skickar ett signerat HTTP-anrop till ett annat system i samma stund något händer i Gfacility, med egna headers, egen payload och ett läsbart exempel på vad mottagaren får.
Uppdaterad 25. Juli 2026
Konfiguration · Automatisering · 9.4
En webhook är den utgående halvan av er integration: i samma stund ett ärende, en bokning, en tillgång eller en besökare ändras i Gfacility går ett HTTP-anrop ut till en URL som ni äger. Ingen polling, ingen nattlig export, ingen mellanprogramvara att passa. Det är en av de sju åtgärderna i 9.2 Automationer, så den ärver samma triggar, villkor och körhistorik som varje annan åtgärd.
Använd den när det andra systemet måste reagera. Vill du i stället läsa data i din egen takt passar API:et och Power BI-kopplingen bättre.
Varför det här spelar roll för verksamheten
"Ekonomi knappar in varje debitering för hand"
Bokning stängd, skicka debiteringsraderna direkt in i ekonomisystemet.
"Vår statussida ligger efter verkligheten"
En större incident byter status och den publika sidan uppdateras inom sekunder.
"Passerkort beställs för sent"
Besökare godkänd, meddela passersystemet innan hen kommer.
"Revisorerna vill ha ett externt spår"
Borttagna poster går ut till er egen loggagring, utanför Gfacility.
Vad du ställer in
| Inställning | Vad den gör |
|---|---|
| Webhook-URL | Den HTTPS-endpoint som tar emot anropet. |
| Tillämpa på | Vilken posts data som följer med. En underliggande omfattning, till exempel en boknings besökare, skickar ett anrop per träff i stället för ett anrop med en lista. |
| Skicka ändringar av dessa fält | Mottagaren får det gamla och det nya värdet på varje fält du väljer. Lämna tomt för att skicka alla ändrade fält. |
| Egna headers | För mottagarens egen autentisering, till exempel Authorization eller X-Api-Key. Följer med vid varje anrop. |
| Extra payload | Valfri JSON som läggs in i anropet under "extra", så att du kan skicka med ett tenant-id eller en routningsnyckel som mottagaren behöver. |
| Egen request body | För en mottagare som kräver sin exakta struktur: din JSON blir hela request body och standardpayloaden för posten följer inte med. |
Tokens, så att payloaden bär verkliga värden
Värden i den extra payloaden och i en egen request body stöder tokens, skrivna som dubbla klamrar runt en fältsökväg. Redigeraren har en väljare Infoga token med sökning, så att du inte behöver kunna fältnamnen utantill: välj fältet och tokenen skrivs åt dig. Vid körning byts varje token mot postens värde.
Det är just detta som gör en fast body användbar: mottagaren får ärendenummer, plats och beställarens e-post i stället för ett fast exempelvärde.
Säkerhet
Signerade anrop
Varje anrop bär en HMAC-signaturheader. Verifiera den på er sida innan ni litar på innehållet, så att en tredje part inte kan förfalska ett anrop till er endpoint.
Krypterade headers
Headervärden lagras krypterade och visas maskerade efter att de sparats. Låt masken vara för att behålla det nuvarande värdet; ingen läser tillbaka er API-nyckel ur formuläret.
Bygg, titta, och aktivera först sedan
Redigeraren validerar din JSON medan du skriver, säger till när den inte är giltig och visar ett exempel på en giltig struktur. Intill visar Vad mottagaren får den verkliga payloaden, så att du kan jämföra den med det andra systemets dokumentation innan ett enda anrop går ut.
Sedan gäller det vanliga automationsflödet: testkör regeln mot en verklig post, kontrollera posten i körhistoriken och aktivera.
Vilka beslut tar du?
Standardpayload eller egen body?
Standard plus extra payload är lättare att underhålla. Välj egen body bara när mottagaren inte kan ändras.
Vilka fält behöver mottagaren egentligen?
Att skicka alla ändrade fält är bekvämt men stökigt, och lämnar ut mer än mottagaren behöver.
Vem äger endpointen?
Utse en ansvarig på mottagarsidan. En webhook som ingen underhåller misslyckas tyst i månader.
Vad händer vid fel?
Bestäm med "stoppa vid första misslyckade åtgärden" om resten av regeln ändå ska köras.