Automazioni
Webhook
L'azione webhook invia una chiamata HTTP firmata a un altro sistema nel momento in cui qualcosa accade in Gfacility, con intestazioni tue, payload tuo e un esempio leggibile di quello che riceve il destinatario.
Aggiornato il 25 lug 2026
Configurazione · Automazione · 9.4
Un webhook è la metà in uscita della tua integrazione: nel momento in cui un ticket, una prenotazione, un asset o un visitatore cambia in Gfacility, parte una chiamata HTTP verso una URL che è tua. Nessun polling, nessuna esportazione notturna, nessun middleware da sorvegliare. È una delle sette azioni di 9.2 Automazioni, quindi eredita gli stessi trigger, le stesse condizioni e la stessa cronologia di esecuzione di ogni altra azione.
Usalo quando l’altro sistema deve reagire. Se invece vuoi leggere dati con i tuoi tempi, l’API e il connettore Power BI sono più adatti.
Perché questo conta per l’azienda
"L'amministrazione riscrive ogni addebito a mano"
Prenotazione chiusa, spingi le righe di addebito direttamente nel sistema finanziario.
"La nostra pagina di stato è in ritardo sulla realtà"
Un incidente grave cambia stato e la pagina pubblica si aggiorna in pochi secondi.
"I badge di accesso vengono richiesti troppo tardi"
Visitatore approvato, avvisa il sistema di controllo accessi prima che arrivi.
"I revisori vogliono una traccia esterna"
I record eliminati vanno nel tuo archivio di log, fuori da Gfacility.
Cosa configuri
| Impostazione | Cosa fa |
|---|---|
| URL del webhook | L'endpoint HTTPS che riceve la chiamata. |
| Applica a | I dati di quale record viaggiano. Un ambito figlio, come i visitatori di una prenotazione, invia una chiamata per ogni record trovato invece di una chiamata con un elenco. |
| Invia le modifiche di questi campi | Il destinatario riceve il valore vecchio e quello nuovo di ogni campo che scegli. Lascialo vuoto per inviare ogni campo modificato. |
| Intestazioni personalizzate | Per l'autenticazione del destinatario, per esempio Authorization o X-Api-Key. Vengono inviate con ogni chiamata. |
| Payload aggiuntivo | JSON facoltativo che entra nella chiamata sotto "extra", per passare un identificativo di tenant o una chiave di routing che serve al destinatario. |
| Corpo della richiesta personalizzato | Per un destinatario che pretende la sua struttura esatta: il tuo JSON diventa tutto il corpo della richiesta e il payload standard del record non viene incluso. |
Token, perché il payload porti valori reali
I valori del payload aggiuntivo e di un corpo della richiesta personalizzato accettano token, scritti con doppie parentesi graffe attorno a un percorso di campo. L’editor ha un selettore Inserisci token con ricerca, così non devi ricordare i nomi dei campi: scegli il campo e il token viene scritto per te. All’esecuzione ogni token viene sostituito con il valore di quel record.
È questo che rende utile un corpo fisso: il destinatario riceve il numero di ticket, la sede e l’e-mail del richiedente invece di un valore di esempio fisso.
Sicurezza
Chiamate firmate
Ogni chiamata porta un'intestazione di firma HMAC. Verificala dalla tua parte prima di fidarti del corpo, così un terzo non può falsificare una chiamata al tuo endpoint.
Intestazioni cifrate
I valori delle intestazioni sono salvati cifrati e mostrati mascherati dopo il salvataggio. Lascia la maschera com'è per conservare il valore attuale; nessuno rilegge la tua chiave API dal modulo.
Costruiscilo, guardalo e solo poi attivalo
L’editor convalida il tuo JSON mentre scrivi, ti dice quando non è valido e mostra un esempio di struttura valida. Accanto, Quello che riceve il destinatario mostra il payload reale, così lo confronti con la documentazione dell’altro sistema prima che parta una sola chiamata.
Da lì vale il percorso normale dell’automazione: esecuzione di prova della regola su un record reale, controllo della voce nella cronologia, poi attivazione.
Quali decisioni prenderai?
Payload standard o corpo personalizzato?
Standard più payload aggiuntivo è più facile da mantenere. Passa al corpo personalizzato solo se il destinatario non si può modificare.
Di quali campi ha davvero bisogno il destinatario?
Inviare ogni campo modificato è comodo ma rumoroso, e condivide più di quanto serva al destinatario.
Di chi è l'endpoint?
Indica un responsabile dal lato ricevente. Un webhook che nessuno mantiene fallisce in silenzio per mesi.
Cosa succede in caso di errore?
Decidi con "fermati alla prima azione fallita" se il resto della regola deve comunque proseguire.