Quan un webhook no arriba mai

Treballa-ho en ordre: el registre de lliuraments, el nom de l'esdeveniment, el tallafoc, la signatura. La pestanya Deliveries et diu si Didit l'ha enviat, cosa que divideix el problema per la meitat de seguida.

Escrit pel suport de Didit · Actualitzat el 19 d’agost del 2026

Short answer

Comença per la pestanya Deliveries de la destinació. Si Didit mai ha intentat el lliurament, és un problema de subscripció o de destinació. Si ho ha intentat i ha fallat, el codi de resposta et diu de quin es tracta: 404 vol dir que la teva ruta no era accessible en aquella URL, i una discrepància de signatura vol dir que has calculat el hash dels bytes equivocats.

#Pas 1: Didit ha intentat enviar-lo?

Obre la destinació a API & Webhooks i mira la pestanya Deliveries. Cada intent queda registrat individualment, amb la resposta.

La pàgina de webhooks a la consola de Didit mostrant l'estat de lliurament per destinació
  1. Last sent et diu si Didit ho ha intentat.
  2. View stats mostra els intents i les fallades d'aquella destinació.
  3. Un lliurament de prova separa el teu endpoint de l'esdeveniment en si.
  4. Una destinació que segueix fallant es pot desactivar mentre ho arregles.
Tot el que cal per distingir un esdeveniment que falta d'un endpoint que falla és en aquesta pàgina.

Aquesta única comprovació divideix el problema per la meitat:

  • No hi ha cap intent registrat → l'esdeveniment mai s'ha generat per a aquella destinació. Passa al pas 2.
  • Intent registrat, ha fallat → Didit l'ha enviat i el teu costat l'ha rebutjat o no l'ha rebut. Passa al pas 3.
  • Intent registrat, 2xx → s'ha lliurat correctament. El problema és dins del teu handler, no en el lliurament.

#Pas 2: no s'ha registrat cap intent

Per ordre de probabilitat:

  1. L'esdeveniment no està subscrit. No hi ha comodins - cada família d'esdeveniments s'ha de llistar explícitament. I un nom que no existeix (session.status.updated, kyc.completed) no rep res en silenci. Comprova-ho contra la llista d'esdeveniments.
  2. Aplicació equivocada. Les destinacions pertanyen a una aplicació. Si les teves sessions s'executen sota una aplicació diferent de la de la destinació, cap esdeveniment hi arribarà mai. Aquesta és la causa més habitual quan tot sembla configurat correctament.
  3. No ha canviat res realment. Els webhooks es disparen amb els canvis. Una sessió que no s'ha mogut, o un re-cribratge de monitoratge AML que no ha trobat res per sobre del llindar, correctament no produeix cap esdeveniment.
  4. L'estat que estàs esperant encara no ha passat. Una sessió en In Progress encara no ha acabat. Vegeu quan una sessió no acaba mai.

#Pas 3: el lliurament s'ha intentat i ha fallat

Un 404 vol dir que la sol·licitud ha arribat a alguna cosa que no tenia la teva ruta. Comprova:

  • El camí exacte, incloent-hi una barra final. Un framework que redirigeix /hook a /hook/ pot convertir un endpoint que funciona en un 404 o un cos perdut.
  • Si la URL és pública. Un host local o de staging que no és accessible des d'internet falla d'aquesta manera.
  • Si un proxy, un balancejador de càrrega, o un enrutador basat en camins davant de la teva app està enviant aquest camí a un altre lloc.

Un 5xx vol dir que el teu handler ha llançat una excepció. Registra el cos en brut abans de fer el parsing perquè puguis veure què ha rebut realment.

Un timeout vol dir que no has respost prou ràpid. Retorna un 2xx primer, processa després.

Res de res / connexió rebutjada vol dir que el teu edge l'ha bloquejat. Didit fa els lliuraments des de la IP estàtica 18.203.201.92 amb un user agent DiditWebhook/2.0. Si estàs darrere de Cloudflare o d'un WAF amb una postura de denegació per defecte, permet aquesta IP per al nom d'host receptor.

#El clàssic: el lliurament automàtic dona 404 però Resend funciona

Aquest cas apareix prou sovint com per tenir nom propi. El lliurament automatitzat falla amb un 404, i després fer clic a Resend sobre el mateix esdeveniment funciona.

Aquesta combinació vol dir que tant el payload com el teu endpoint estan bé - així que la diferència és de temporització o de camí, no de contingut. Comprova:

  • Un desplegament o reinici en el moment del lliurament original. El Resend funciona més tard perquè l'app ja torna a estar activa.
  • Un cold start que ha superat el timeout de la teva plataforma - habitual en serverless amb una primera invocació lenta.
  • Un enrutament basat en camins que ha canviat entre els dos intents, o una regla que només coincideix amb algunes sol·licituds.
  • Límit de velocitat o protecció antibots al teu edge que ha deixat passar el reenviament manual perquè ha arribat sol en lloc de dins d'una ràfega.

La pestanya Deliveries té els dos intents amb les seves marques de temps - compara-les amb els teus propis registres de desplegament i d'errors d'aquell minut.

#La verificació de signatura falla

Gairebé sempre és una de tres coses:

  1. Has calculat el hash d'un JSON re-serialitzat. Calcula l'HMAC dels bytes en brut de la sol·licitud tal com s'han rebut. Fer el parsing i tornar a convertir-ho a string canvia els espais en blanc i l'ordre de les claus, i la signatura no coincidirà. La majoria de frameworks necessiten una configuració explícita per donar-te el cos en brut.
  2. Secret equivocat. El secret de signatura és per destinació, i no és la teva clau d'API. Dues destinacions tenen dos secrets diferents.
  3. Suposició d'codificació equivocada. Si no estàs segur de si el secret s'utilitza com a string literal o es descodifica primer, no ho endevinis - segueix la referència de verificació de signatura al peu de la lletra, i registra el cos en brut mentre depures per poder comparar.
Important

No "arreglis" mai una discrepància de signatura saltant-te la verificació. Un endpoint de webhook sense verificar acceptarà una aprovació falsificada de qualsevol que trobi la URL, cosa que converteix una drecera de depuració en una via de presa de control de compte.

#Dos reintents no són una cua

Davant d'un 5xx, un 404, un timeout o una fallada de connexió, Didit reintenta dues vegades - aproximadament al cap d'1 minut i després al cap de 4 minuts més - i després descarta el lliurament. Si el teu endpoint ha estat caigut més temps que això, aquells esdeveniments s'han perdut per sempre.

Construeix un camí de reconciliació: en arrencar, fes polling a l'endpoint de decisió per a qualsevol sessió de la qual no tinguis un estat terminal. Tracta els webhooks com el camí ràpid i el polling com a xarxa de seguretat.

#Provar sense executar verificacions

Try Webhook a la pàgina de la destinació envia un esdeveniment completament format del tipus que triïs - aprovat, declinat, en revisió, KYB, entitat, transacció. Fes-lo servir per demostrar que el teu endpoint, la teva verificació de signatura i el teu handler funcionen abans que una sessió real en depengui.

El sandbox és l'altra meitat d'això: una sessió de sandbox emet webhooks reals amb "environment": "sandbox", així que pots exercitar tot el camí de principi a fi sense cap cost. Vegeu com provar en sandbox.