Webhook in uscita
Mentre il canale webhook in entrata riceve eventi esterni per elaborarli, il nodo webhook_action fa l'inverso: emette una richiesta HTTP verso i tuoi sistemi da qualsiasi punto di una pipeline — l'equivalente dei moduli « HTTP » di Make o « Webhooks » di Zapier.
Perché
Probabilmente disponi già di:
- Un sistema di alerting (PagerDuty, Opsgenie, Slack).
- Uno strumento ITSM (Jira, ServiceNow) per gestire i ticket.
- Una dashboard personalizzata che aggrega il tuo stato operativo.
Anziché chiedere a questi sistemi di interrogare betool tramite polling, falli notificare dalle tue pipeline: posiziona un nodo webhook_action nel punto del grafo in cui si verifica l'evento (un'email qualificata, un filtro superato, un report pianificato…). In combinazione con il canale Pianificazione, è anche la base di un push ricorrente verso i tuoi sistemi.
Configurazione del nodo
| Campo | Ruolo |
|---|---|
url | URL di destinazione (supporta i template) |
method | GET / POST (predefinito) / PUT / PATCH / DELETE |
headers / query | Dizionari {nome: template} |
body_mode | none / json (predefinito) / form / raw / mapper / multipart |
body_template | Template del body (modalità json / form / raw) |
mapping_spec | Costruzione del body tramite il payload mapper (consigliato) — profondità, array, trasformazioni |
auth_mode | none (predefinito) / bearer / basic / api_key_header / oauth2 (client credentials) |
auth_config | Parametri della modalità di autenticazione: {token}, {user, password}, {header, value} o {credential_id} |
timeout_ms | Predefinito 30 000 ms |
retry_count | Numero di nuovi tentativi (predefinito 0, massimo 10), backoff esponenziale |
accepted_statuses | Codici HTTP considerati come successo (predefinito: 200, 201, 202, 204) |
output_key | Chiave del flusso in cui scrivere la risposta (predefinito webhook.response) |
Templating
URL, header, query e body interpolano le chiavi del flusso con la sintassi {percorso}:
{
"event": "order_qualified",
"order_id": "{webhook.payload.order_id}",
"verdict": "{exchange.result}"
}
Autenticazione
- Le credenziali delle modalità
bearer/basic/api_key_headersono archiviate nella configurazione del nodo: restano visibili ai membri che possono aprire questa pipeline. - In modalità
oauth2(client credentials), il nodo contiene solo un riferimento alla credenziale; il segreto risiede nello storage OAuth dell'organizzazione, non viene mai restituito in lettura, e il token viene ottenuto (poi rinnovato) al momento dell'esecuzione. È la modalità da preferire per un segreto sensibile.
Invio di file (multipart)
La modalità multipart (RFC 7578) invia campi di testo e allegati nella stessa richiesta — per i partner che accettano solo multipart/form-data. I file sono referenziati tramite la loro chiave nell'object store e riletti al momento dell'invio (massimo 20 file e 25 MB); una chiave fuori dal perimetro della tua organizzazione viene rifiutata, e un invio in cui manca un allegato viene abbandonato anziché emesso incompleto.
Retry ed errori
- Uno stato fuori da
accepted_statuses, un timeout o un errore di rete innesca un nuovo tentativo con backoff esponenziale (0,5 s, 1 s, 2 s, 4 s…), fino aretry_countnuovi tentativi. - La risposta (
status,headers,body) viene scritta sottooutput_key, con una chiaveerroruna volta esauriti i tentativi: i nodi a valle possono leggere il risultato e avviare un trattamento di riserva in caso di fallimento. Il risultato è visibile nella cronologia. - Nessun doppio invio: se l'esecuzione viene ripetuta (ripresa dopo un redeploy, nuovo tentativo della coda), una chiamata già accettata dal tuo sistema non viene riemessa.
Provare l'origine lato ricevente
Le richieste di webhook_action portano l'autenticazione che configuri tu (auth_mode): è questa che prova l'origine presso il tuo sistema. Per la direzione inversa — verificare la firma di ciò che betool riceve — vedi Webhook in entrata.