Webhook non ricevuti
Procedura diagnostica per gli eventi webhook non consegnati — sottoscrizione, log, raggiungibilità, TLS, timeout, firma e ripetizione.
Il tuo sistema non riceve gli eventi attesi. Segui la procedura nell'ordine: i primi tre passaggi individuano la causa in oltre l'80% dei casi.
Il log di consegna è la fonte di verità
Prima di indagare sul tuo endpoint, guarda cosa dice Blu Pantheon: il log di consegna distingue subito fra “evento mai generato”, “evento non sottoscritto”, “consegna tentata e fallita” e “consegna riuscita”. Sono quattro problemi completamente diversi.
Procedura diagnostica
Verifica che l'evento sia sottoscritto
Apri l'endpoint e controlla l'elenco degli eventi selezionati. Un endpoint attivo che non sottoscrive l'evento non riceve nulla e non registra alcun errore: è la causa più frequente e la più facile da trascurare.
Verifica anche che l'endpoint sia in stato Attivo e non Sospeso: dopo troppi fallimenti consecutivi la piattaforma sospende automaticamente l'endpoint.
Controlla i log di consegna in Console
Il registro conserva 30 giorni di tentativi. Per ogni consegna trovi identificativo, evento, esito, codice HTTP restituito, durata, numero del tentativo e corpo della risposta del tuo server (troncato).
| Cosa vedi | Significato | Dove intervenire |
|---|---|---|
| Nessuna riga per quell'evento | L'evento non è stato generato o non è sottoscritto | Verifica la condizione che genera l'evento e la sottoscrizione |
| Righe con esito Consegnato e codice 200 | Blu Pantheon ha consegnato correttamente | Il problema è nella tua elaborazione a valle |
| Codice 4xx | Il tuo endpoint ha rifiutato la richiesta | Il tuo codice o la verifica della firma |
| Codice 5xx | Errore nella tua applicazione | Log applicativi del tuo sistema |
| Esito Timeout | Nessuna risposta entro 10 secondi | Rendi asincrona l'elaborazione |
| Esito Errore di connessione | Endpoint irraggiungibile | Rete, DNS, firewall |
| Esito Errore TLS | Problema di certificato | Certificato del tuo endpoint |
Verifica la raggiungibilità dell'endpoint
L'endpoint deve essere raggiungibile da Internet, non solo dalla tua rete aziendale. Prova da una rete esterna, per esempio dalla connessione dati del telefono:
curl -i -X POST "https://integrazioni.acme.it/blupantheon/eventi" \
-H "Content-Type: application/json" \
-H "X-BP-Event: session.ended" \
-H "X-BP-Delivery: dlv_test_0001" \
-H "X-BP-Signature: sha256=firma-di-prova" \
-H "X-BP-Timestamp: 1788258000" \
-d '{"event":"session.ended","data":{"sessionId":"ses_test"}}' \
--max-time 15Che cosa osservare:
- Codice HTTP restituito: deve essere un 2xx. Un 401 o 403 indica che la verifica della firma fallisce o che c'è un livello di autenticazione non previsto.
- Tempo totale: se supera i 10 secondi, la consegna andrà in timeout.
- Nessuna risposta: DNS non risolto, porta chiusa, firewall.
curl -o /dev/null -s -w "codice: %{http_code} tempo: %{time_total}s\n" \
-X POST "https://integrazioni.acme.it/blupantheon/eventi" \
-H "Content-Type: application/json" -d '{}'Endpoint dietro VPN o rete privata
Un endpoint raggiungibile solo dalla rete interna non può ricevere webhook. Esponi un gateway pubblico, usa un servizio di inoltro, oppure passa al polling delle API. Vedi Integrazioni CRM ed ERP.
Verifica il certificato TLS
L'endpoint deve essere in HTTPS con certificato valido. Non sono accettati certificati autofirmati, scaduti, con nome host non corrispondente o con catena incompleta.
echo | openssl s_client -connect integrazioni.acme.it:443 -servername integrazioni.acme.it 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesLa catena incompleta è il caso più insidioso
Un certificato con catena intermedia mancante funziona nel browser (che completa la catena da solo) ma fallisce dai client applicativi. Se il sito si apre correttamente ma i webhook danno errore TLS, questa è quasi sempre la causa. Verifica la catena con uno strumento di analisi SSL online.
Verifica di rispondere entro 10 secondi
Il timeout di consegna è di 10 secondi. Se il tuo endpoint elabora l'evento in modo sincrono (scrittura su CRM, invio email, elaborazioni pesanti) supererà facilmente il limite.
Il pattern corretto:
1. Ricevi la richiesta
2. Verifica la firma HMAC
3. Metti il payload in una coda o su una tabella di staging
4. Rispondi 200 immediatamente
5. Elabora in un processo separatoTimeout e duplicati
Se rispondi dopo il timeout, la consegna è marcata come fallita e viene ritentata: il tuo sistema riceverà lo stesso evento più volte e potrebbe creare record duplicati. Rispondere subito non è solo una questione di prestazioni.
Verifica di restituire un codice 2xx
Qualsiasi codice diverso da 2xx è considerato un fallimento e attiva i ritentativi.
| Codice restituito | Interpretazione | Comportamento |
|---|---|---|
| 200, 201, 202, 204 | Consegna riuscita | Nessun ritentativo |
| 301, 302, 307, 308 | Reindirizzamento | Non seguito: considerato fallimento |
| 400, 422 | Richiesta rifiutata | Ritentativo |
| 401, 403 | Autenticazione fallita | Ritentativo |
| 404 | Endpoint inesistente | Ritentativo |
| 410 | Risorsa rimossa definitivamente | Nessun ritentativo, endpoint sospeso |
| 429 | Troppe richieste | Ritentativo con attesa maggiorata |
| 500, 502, 503, 504 | Errore del server | Ritentativo |
Rispondi 200 anche se il payload non ti interessa
Se ricevi un evento che il tuo sistema non gestisce, rispondi comunque 200 e ignoralo. Restituire 400 o 404 attiva i ritentativi e, dopo abbastanza fallimenti, la sospensione dell'endpoint per tutti gli eventi, inclusi quelli che ti servono.
Verifica il calcolo della firma
Se restituisci 401 perché la firma non corrisponde, controlla nell'ordine:
Usa il corpo grezzo, non l'oggetto deserializzato
La firma è calcolata sui byte esatti ricevuti. Se il tuo framework deserializza e riserializza il JSON, l'ordine delle chiavi o la spaziatura cambiano e la firma non corrisponde più. È l'errore numero uno.
Verifica il segreto
Deve essere quello dell'endpoint specifico, non di un altro. Dopo una rotazione, entrambi i segreti sono validi per il periodo di sovrapposizione: accettali entrambi.
Verifica il formato dell'header
L'header X-BP-Signature ha la forma sha256= seguita dalla firma in esadecimale minuscolo.
Rimuovi il prefisso prima del confronto.
Verifica l'inclusione del timestamp
Se la tua implementazione firma anche X-BP-Timestamp, la stringa da firmare deve essere
costruita esattamente come descritto in Firma HMAC.
Verifica l'orologio del server
Le richieste con timestamp che si discosta di oltre 5 minuti dall'ora corrente vanno rifiutate. Se il tuo orologio è sfasato, rifiuterai richieste legittime.
Verifica i reindirizzamenti
I reindirizzamenti non vengono seguiti. Cause tipiche:
- reindirizzamento da
httpahttps: registra direttamente l'URLhttps; - reindirizzamento da dominio senza
wwwa dominio conwwwo viceversa; - barra finale aggiunta o rimossa dal tuo server;
- reindirizzamento verso una pagina di autenticazione.
Verifica con:
curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" \
-X POST "https://integrazioni.acme.it/blupantheon/eventi"Se il codice è 3xx, aggiorna l'URL dell'endpoint in Console con la destinazione finale.
Verifica le liste di indirizzi consentiti
Se il tuo firewall o WAF filtra per indirizzo IP di origine, autorizza gli intervalli di Blu Pantheon.
L'elenco aggiornato è pubblicato in Console. Le variazioni sono comunicate con 30 giorni di preavviso ai contatti tecnici del tenant.
Il WAF può bloccare senza lasciare traccia visibile
Molti WAF rifiutano le richieste con payload JSON contenenti testo libero (i messaggi delle conversazioni) classificandoli come tentativi di injection. Se il log di Blu Pantheon mostra 403 ma la tua applicazione non registra nulla, il blocco è del WAF. Controlla i suoi log e aggiungi un'eccezione per il percorso dell'endpoint.
Ripeti manualmente la consegna
Dopo aver corretto la causa, puoi ritrasmettere le consegne fallite: singolarmente, oppure in
blocco selezionando un intervallo temporale. La ripetizione mantiene lo stesso identificativo
X-BP-Delivery dell'originale, così il tuo sistema può riconoscerla e applicare
l'idempotenza.
Le consegne restano ripetibili per 30 giorni.
Tabella decisionale
| Log di Blu Pantheon | Log del tuo sistema | Causa | Rimedio |
|---|---|---|---|
| Nessuna consegna | — | Evento non sottoscritto | Aggiungi l'evento all'endpoint |
| Nessuna consegna | — | Condizione dell'evento non verificata | Verifica che l'azione generi davvero l'evento |
| Nessuna consegna | — | Endpoint sospeso | Riattivalo dopo aver corretto la causa dei fallimenti |
| Errore di connessione | Nessuna richiesta | DNS o firewall | Verifica la risoluzione DNS e le regole in ingresso |
| Errore TLS | Nessuna richiesta | Certificato non valido | Rinnova il certificato, completa la catena |
| Timeout | Richiesta ricevuta, elaborazione lunga | Elaborazione sincrona | Passa all'elaborazione asincrona |
| 401 o 403 | Richiesta ricevuta, firma rifiutata | Firma calcolata male | Usa il corpo grezzo, verifica il segreto |
| 403 | Nessuna richiesta nell'applicazione | Bloccato dal WAF | Eccezione sul percorso dell'endpoint |
| 404 | Nessuna richiesta | URL errato | Correggi l'URL in Console |
| 3xx | Nessuna richiesta | Reindirizzamento | Registra l'URL finale |
| 500 | Errore applicativo | Difetto nel tuo codice | Correggi e ripeti la consegna |
| 200 | Nessuna traccia dell'elaborazione | Errore nella coda a valle | Verifica il tuo consumatore asincrono |
| 200 | Elaborato più volte | Ritentativi dopo timeout | Implementa l'idempotenza |
Idempotenza
I ritentativi possono causare la ricezione dello stesso evento più volte. Il tuo sistema deve essere in grado di riconoscerlo.
1. Leggi l'header X-BP-Delivery
2. Cerca l'identificativo in una tabella di eventi già elaborati
3. Se presente, rispondi 200 e termina
4. Se assente, elabora e registra l'identificativo nella stessa transazione
5. Conserva gli identificativi per almeno 7 giorniX-BP-Delivery è la chiave
L'identificativo di consegna è stabile fra i ritentativi dello stesso evento e univoco fra eventi diversi. È il valore corretto per la deduplica: non usare il timestamp né un hash del payload.
Header inviati
| Header | Contenuto |
|---|---|
X-BP-Event | Nome dell'evento, es. session.ended |
X-BP-Delivery | Identificativo univoco della consegna, stabile fra i ritentativi |
X-BP-Signature | Firma HMAC SHA-256 nella forma sha256= seguita dall'esadecimale |
X-BP-Timestamp | Momento della generazione dell'evento, in secondi epoch |
X-BP-Attempt | Numero del tentativo, da 1 a 6 |
X-BP-Tenant | Slug del tenant, es. acme-srl |
Content-Type | Sempre application/json |
User-Agent | BluPantheon-Webhook/1 |
Politica di ritentativo
| Tentativo | Attesa dal precedente |
|---|---|
| 1 | Immediato |
| 2 | 30 secondi |
| 3 | 5 minuti |
| 4 | 30 minuti |
| 5 | 2 ore |
| 6 | 6 ore |
Dopo il sesto tentativo fallito l'evento è marcato come non consegnato. Se il numero di fallimenti consecutivi supera 100, l'endpoint viene sospeso automaticamente e viene inviata una notifica ai contatti tecnici del tenant.
Che cosa inviare al supporto
Informazioni da allegare
- Identificativo della consegna (X-BP-Delivery) di almeno tre casi problematici
- URL dell’endpoint e nome dell’evento
- Schermata o esportazione del log di consegna in Console
- Codice HTTP e corpo della risposta restituiti dal tuo endpoint
- Log applicativi del tuo sistema per lo stesso istante, con fuso orario
- Esito del comando curl di prova eseguito da rete esterna
- Indicazione se il problema riguarda tutti gli eventi o solo alcuni
- Data e ora dell’ultima consegna riuscita
Qualità delle risposte AI
Diagnosi e correzione di risposte generiche, errate, inventate, troppo lunghe, in lingua sbagliata o che ignorano la knowledge base.
Codici di errore
Tabella consolidata dei codici di errore di Blu Pantheon con stato HTTP, causa e azione correttiva, e uso di traceId e X-BP-Delivery.