# Quan un webhook no arriba mai Source: https://help.didit.me/ca/integration/webhook-troubleshooting Updated: 2026-10-12 Revisa el registre de lliuraments, el nom de l'esdeveniment, el tallafoc i la signatura en aquest ordre: la pestanya Deliveries et diu si Didit l'ha enviat. 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 Desenvolupadors i Webhooks, selecciona l’endpoint i obre Lliuraments per veure la petició i resposta de cada intent. Reenvia després de corregir el problema. Comprova l’aplicació, l’entorn, les subscripcions i que l’endpoint estigui activat. ![La pàgina de webhooks a la consola de Didit mostrant l'estat de lliurament per destinació](https://help.didit.me/screenshots/webhooks-light.webp) *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](https://help.didit.me/ca/integration/webhooks-basics). 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](https://help.didit.me/ca/verification-sessions/session-not-finished). ## 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](https://docs.didit.me/integration/webhooks#signature-verification) al peu de la lletra, i registra el cos en brut mentre depures per poder comparar. > **Warning:** 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 Amb una resposta 5xx o 404, Didit reintenta dues vegades, al cap d’un minut i després quatre. Un temps d’espera superior a 5 segons o una connexió fallida no es reintenten automàticament. Fes servir Reenvia a Lliuraments després de corregir el problema; un error definitiu genera una alerta. 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 [Video: Configura les claus d'API i prova els teus webhooks - Didit Academy](https://www.youtube.com/watch?v=thOMIGbNLP0&t=140) **Envia un esdeveniment de prova** 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](https://help.didit.me/ca/getting-started/sandbox-and-testing).