Vai al contenuto principale
I webhook in uscita permettono ai vostri sistemi di reagire agli eventi in Flowella senza interrogare periodicamente l’API. Ogni webhook ha un URL, un segreto di firma e un elenco di tipi di evento. Quando si verifica uno di questi eventi, Flowella invia all’URL una richiesta POST JSON firmata. Potete gestire i webhook nell’app in Settings → Webhooks (vedere Aggiungere e gestire i webhook in uscita) oppure con l’API dei webhook. Questa pagina è il riferimento su ciò che Flowella invia.

Tipi di evento

Selezionate questi eventi quando aggiungete un webhook, oppure passateli in events quando ne create uno con l’API. Gli eventi dei contatti si attivano solo per queste chiamate API su un singolo contatto. Non si attivano per POST /v1/contacts/bulk-upsert, per i contatti creati da messaggi in arrivo, né per le modifiche apportate nell’app o sincronizzate da HubSpot.
Problema noto: optout.created non si attiva per il primo opt-out di un contatto su un numero WhatsApp, sia che il contatto invii una parola chiave sia che chiamiate POST /v1/opt-outs. Al momento si attiva solo quando un contatto che aveva rinnovato il consenso fa di nuovo opt-out. Non fatevi affidamento per intercettare ogni opt-out: elencate gli opt-out con GET /v1/opt-outs (scope contacts:read).
Flowella invia anche webhook.test quando selezionate Send test event nell’app o chiamate POST /v1/webhooks/{id}/test. Non potete abbonarvi a questo evento. Il suo data è { "test": true, "sentAt": "<ISO 8601 time>" }.
Un messaggio in uscita può generare due eventi message.sent: uno quando Flowella lo consegna a Meta e uno quando Meta lo segnala come inviato. I due hanno valori id di primo livello diversi. Usate data.messageId per collegarli allo stesso messaggio.

Formato della richiesta

Flowella invia ogni evento come richiesta HTTP POST con queste intestazioni: Flowella non invia altre intestazioni personalizzate. Il tipo e l’ID dell’evento si trovano nel corpo.

Corpo

Ogni webhook ha una versione del payload, restituita come payloadVersion dall’API dei webhook. La versione 1 è quella predefinita per ogni webhook e non esiste un’impostazione nell’app o nell’API per cambiarla. Le due versioni usano queste strutture:
Flowella non invia un evento il cui data supera i 256 KB.

Verificare le firme

Controllate la firma di ogni richiesta prima di considerarla attendibile. Flowella calcola X-Flowella-Signature in questo modo:
  • Algoritmo: HMAC con SHA-256.
  • Chiave: il segreto di firma come testo UTF-8, esattamente come salvato. Un segreto generato dall’API include il prefisso whsec_.
  • Messaggio: il corpo grezzo della richiesta, byte per byte, così come inviato da Flowella. Nient’altro viene firmato: nella firma non ci sono timestamp né URL.
  • Output: esadecimale minuscolo, 64 caratteri, senza prefisso sha256=.
Per verificare, calcolate lo stesso HMAC sul corpo grezzo e confrontatelo con l’intestazione in tempo costante. Nelle 24 ore successive a una rotazione tramite API, la richiesta contiene entrambe le intestazioni: accettatela se una delle due corrisponde a un segreto in vostro possesso.
Calcolate la firma sul corpo grezzo prima che qualsiasi middleware lo analizzi o lo riformatti. Se il vostro framework analizza il JSON e lo serializzate di nuovo, i byte cambiano e la firma non corrisponde.

Risposte, tentativi e timeout

Flowella consegna più eventi contemporaneamente, quindi possono arrivare in ordine sparso. Usate created_at o occurred_at se l’ordine è importante. Rispondete con uno stato 2xx non appena la firma risulta valida, poi elaborate l’evento in background. Per vedere come appaiono i tentativi nell’app, vedere Tentativi e back-off.

Deduplicare gli eventi

Il vostro endpoint può ricevere lo stesso evento più di una volta: un nuovo tentativo dopo che l’endpoint è andato in timeout ma ha comunque elaborato la richiesta, oppure un replay tramite l’API. Deduplicate in base all’id di primo livello:
  1. Memorizzate l’id di ogni evento che elaborate.
  2. Se un id in arrivo è già memorizzato, rispondete 200 e non fate nient’altro.
  3. Conservate gli ID memorizzati almeno per tutto il tempo in cui potreste ripetere le consegne.
Non deduplicate in base a data.messageId. Eventi diversi relativi allo stesso messaggio, come message.sent e message.delivered, lo condividono.

Feed degli eventi

Il feed degli eventi è un’alternativa pull ai webhook. GET /v1/events restituisce gli eventi degli ultimi 7 giorni, inclusi quelli a cui nessun webhook è abbonato. Richiede lo scope events:read. Filtrate con type (un tipo o un elenco separato da virgole), occurredAfter e occurredBefore, e paginate con limit e cursor. Ogni elemento ha id, type, occurredAt, version, correlationId e data. L’id corrisponde all’id nel corpo del webhook, quindi potete usare il feed per colmare le lacune dopo un’interruzione del vostro endpoint.

Gestire i webhook tramite API

Tutti gli endpoint dei webhook richiedono una chiave API o un token di accesso OAuth con lo scope webhooks:manage. Le chiavi create nell’app lo possiedono. Vedere l’introduzione all’API per l’autenticazione. Gli oggetti webhook contengono id, name, url, events, isActive, consecutiveFailures, signingSecretPrefix (i primi 8 caratteri del segreto attuale), payloadVersion, lastTriggeredAt, disabledAt, createdAt e updatedAt. Ai webhook gestiti tramite l’API si applicano alcune regole:
  • Non potete scegliere il segreto di firma tramite l’API. POST /v1/webhooks ne genera uno che inizia con whsec_ e lo restituisce una sola volta, come signingSecret.
  • I replay non contano ai fini del conteggio dei fallimenti e non lo azzerano. Flowella consegna un replay solo mentre il webhook è attivo e ancora abbonato a quel tipo di evento.
  • L’URL deve rispettare le stesse regole sugli URL dell’app.

Ruotare un segreto di firma

Ruotate un segreto quando pensate che sia stato divulgato, oppure secondo una pianificazione regolare. La rotazione funziona per qualsiasi webhook che abbia un segreto, inclusi i webhook il cui segreto è stato digitato nell’app.
1

Richiedete un nuovo segreto

Chiamate l’endpoint di rotazione e memorizzate il signingSecret della risposta. Flowella lo restituisce una sola volta.
2

Accettate entrambi i segreti per 24 ore

Le nuove consegne sono firmate con il nuovo segreto in X-Flowella-Signature e con il vecchio segreto in X-Flowella-Signature-Previous. Un gestore che usa ancora il vecchio segreto continua a funzionare se controlla entrambe le intestazioni, come nell’esempio in Verificare le firme.
3

Passate al nuovo segreto

Aggiornate il vostro gestore con il nuovo segreto entro 24 ore. Dopodiché, Flowella smette di inviare X-Flowella-Signature-Previous.
Cambiare il segreto nell’app con New signing secret non prevede sovrapposizione: il vecchio segreto smette subito di funzionare.

Test in locale

Per ricevere i webhook sul vostro computer, esponete il server locale tramite un tunnel pubblico, come ngrok o Cloudflare Tunnel. Usate l’URL pubblico del tunnel come endpoint. Poi usate Send test event per inviare richieste quando ne avete bisogno. Flowella rifiuta gli indirizzi locali e privati, quindi un URL localhost non funziona.

Argomenti correlati

Gestire i webhook nell'app

Aggiungete endpoint, inviate eventi di test e consultate il registro delle consegne.

Introduzione all'API

Autenticazione, scope, limiti di frequenza ed errori.

Chiavi API

Create la chiave necessaria per l’API dei webhook.

Developer hub

Richieste API recenti, guide rapide e API sandbox.
Ultima modifica il 24 ottobre 2026