Saltar al contingut principal
El lliurament de webhooks, que depèn de la versió, es documenta a Esdeveniments d’autenticació i webhooks. Activitat d’autenticació: no registris tipus d’esdeveniment d’autenticació que no hi siguin inclosos amb l’API de destinacions actual.

Visió general

Els webhooks són la manera com Didit envia actualitzacions en temps real al teu backend cada cop que canvia l’estat d’una sessió de verificació, d’una sessió d’empresa, d’un usuari del proveïdor, d’una empresa del proveïdor o d’una transacció. Si subscrius una o diverses destinacions als esdeveniments que t’interessen, pots reaccionar en el moment en què el resultat està a punt, normalment en pocs segons després que l’usuari que fa la verificació acabi el seu flux. Els webhooks són el patró d’integració recomanat. El sondeig de GET /v3/session/{id}/decision/ està disponible com a alternativa, però és més lent, fa més peticions i no rep esdeveniments com data.updated, transaction.status.updated ni els canvis a nivell d’entitat, que només s’emeten amb webhooks. Considera el lliurament de webhooks com la font de veritat i només fes sondejos en arrencar en fred o per a la conciliació. Aquest capítol de la lliçó d’integració de Didit Academy comença a la visió general dels webhooks. La lliçó d’integració d’Academy tracta els webhooks a partir de 3:12: com afegir una destinació, com triar els esdeveniments i el secret de signatura que verificaràs més avall.
Usuaris de Cloudflare / WAF. Didit lliura els webhooks des de la IP estàtica 18.203.201.92 amb User-Agent: DiditWebhook/2.0 +https://didit.me. Si la teva capa perimetral bloqueja clients desconeguts, permet aquesta IP a Security > WAF > Tools > IP Access Rules i tria Permetre per al nom d’amfitrió receptor.

Tipus d’esdeveniments

Utilitza el valor exacte en la matriu subscribed_events d’una destinació. No hi ha comodí: enumera cada família que vols rebre, i pots repartir els esdeveniments entre diverses destinacions. Els valors d’aquesta taula són el conjunt complet d’esdeveniments subscriptibles: no hi ha session.status.updated, kyc.completed ni cap altre de similar. L’única altra entrega que fa Didit és el callback kyb.registry_search.resolved sense signatura, que s’envia a la webhook_url específica de cada sol·licitud que passes a POST /v3/kyb/search/, i mai a una destinació del webhook.
El menú Business Console > API & Webhooks > Try Webhook envia payloads completament formats per a cadascun d’aquests esdeveniments (aprovats, rebutjats, en revisió, noms en Unicode, KYC/KYB, entitat, activitat i transacció). Utilitza’l per validar el teu endpoint abans de posar-lo en producció.

Forma del payload

Embolcall

Tots els webhooks comparteixen el mateix embolcall. Els camps es serialitzen sempre amb sort_keys=True i separadors compactes (, / :), perquè el mateix payload reprodueixi la mateixa signatura en tots dos extrems. Per als esdeveniments de sessió (status.updated, data.updated a les sessions normals i empresarials), l’embolcall inclou a més:

Exemple d’embolcall de sessió

L’objecte decision té el mateix esquema que el retornat per GET /v3/session/{id}/decision/. Per a la referència canònica dels camps de cada funcionalitat (cada propietat de id_verifications[], aml_screenings[], etc.), consulta Models de dades. Deliberadament no dupliquem aquí les taules de camps de cada funcionalitat, perquè el esquema només es trobi en un sol lloc.

Matrius plurals de V3 (important)

Dins de decision, cada resultat per funcionalitat és una matriu amb diversos elements, perquè un mateix flux de treball pugui incloure diverses instàncies de la mateixa funcionalitat (per exemple, diverses comprovacions d’identitat en diversos documents):
Cada element inclou un node_id que coincideix amb el graf del flux de treball, i un status per funcionalitat. No llegeixis els camps singulars heretats de V2 (id_verification, nfc, liveness, face_match, phone, email, poa, aml, ip_analysis, database_validation); només apareixen si una destinació està fixada explícitament a webhook_version: "v2". Els resultats de la Signatura electrònica són a signatures[], només presents quan el flux de treball té un pas de Signatura electrònica: un element per signatari, amb el signatari, la confirmació del codi, el certificat, la marca de temps, els hashes i les rutes de descàrrega de cada document, i el PDF de l’evidència. No hi ha un esdeveniment de signatura independent: status.updated indica quan cal llegir-los. Consulta l’informe de signatura electrònica. Els resultats de la Verificació bancària són a bank_verifications[], un element per cada pas de Verificació bancària. El method de cada element indica com s’ha verificat el compte: open_banking (inici de sessió al banc), account_lookup (comprovació del compte), o bé una alternativa statement o microdeposits, i és null fins que no s’avalua un compte. Quan la persona ha triat Continua sense el teu banc, continued_without_bank és true i continuation indica el motiu. En aquest cas, method és none, tret que abans s’hagi avaluat un intent: consulta Quan la persona no pot verificar el seu banc. Un compte verificat per comprovació del compte no llegeix dades financeres, de manera que financial_data.not_collected enumera els saldos, les transaccions o els ingressos que el pas demanava. Consulta Mètodes de verificació bancària.

Bloc de l’Investigator

Un decision V3 per a una sessió d’usuari o d’empresa també inclou investigator: l’última revisió d’Investigator de la sessió, o null si mai no n’ha tingut cap. Les funcionalitats de recollida de documents, Documents KYB i Document AI, no tenen cap matriu específica per a múltiples elements. Apareixen a la llista features[] de la decisió com a { "feature": "DOCUMENT_AI", "node_id": "…" } (una entrada per node). Consulta Document AI. Les decisions de User Verification també inclouen un únic objecte biometric_consent: si la sessió requeria consentiment biomètric explícit, el trigger, el status de la resposta i la seva evidència. status: "pending" amb reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" vol dir que un SDK natiu anterior a la 4.10.0 ha capturat un rostre sense el pas de consentiment. Consulta Consentiment biomètric.

Claus del mètode de verificació d’identitat

Cada element de id_verifications[] indica quin mètode de verificació d’identitat l’ha produït, perquè un gestor pugui bifurcar segons l’evidència que realment ha rebut: Els gestors existents continuen funcionant sense canvis: una sessió de document defineix verification_method com a document i deixa la resta a null. Els tipus de cada camp es troben a Models de dades.

Sessió de cartera aprovada (status.updated)

Payloads d’esdeveniments d’entitat

Els estats d’entitat són ACTIVE, FLAGGED o BLOCKED. user.data.updated i business.data.updated conserven el camp status i afegeixen una matriu changed_fields i un mapa changes de { field: { previous, current } }. Els esdeveniments business.* usen vendor_business_id en lloc de vendor_user_id.

Payloads d’esdeveniments de transacció

Els webhooks de transacció utilitzen la mateixa infraestructura de distribució i el mateix embolcall, però identifiquen la transacció en lloc d’una sessió:
action_required és null, o l’acció pendent de l’usuari (type wallet_ownership o verification_session, amb la seva url) descrita a Accions requerides de l’usuari. Les transaccions noves tenen APPROVED per defecte. Si una regla, una llista de bloqueig o un flux de treball canvia l’estat durant la creació, el payload inicial de transaction.created reflecteix aquest estat final. transaction.status.updated té la mateixa forma amb el status actualitzat. Els estats de transacció són APPROVED, IN_REVIEW, DECLINED o AWAITING_USER; severity és UNKNOWN / LOW / MEDIUM / HIGH / CRITICAL i direction és INBOUND / OUTBOUND. transaction.created i transaction.status.updated només es lliuren per a aplicacions en producció. Els intercanvis de Travel Rule del sandbox sí que emeten travel_rule.status.updated amb environment: sandbox.

Callback de la cerca de registre KYB

El flux asíncron de POST /v3/kyb/search/ envia un payload extra que no és un esdeveniment de destinació: quan passes un webhook_url a la sol·licitud de cerca, Didit fa un POST d’un callback kyb.registry_search.resolved a aquesta URL quan el registre resol la consulta. Es diferencia dels webhooks de destinació en tres aspectes:
  • És sense signar: no té capçaleres X-Signature*. Didit l’indica amb X-Didit-Unsigned-Callback: true; valida-la fent coincidir request_id amb l’id que ha retornat la sol·licitud de cerca.
  • El nom de l’esdeveniment és a event_type (no a webhook_type), i no hi ha application_id ni environment.
  • timestamp i created_at són enters d’epoch, com altres webhooks, però a diferència del created_at ISO de l’endpoint de cerca.
El callback segueix la mateixa política de reintents que les destinacions de webhook (els reintents tornen a assignar el timestamp i continuen sense signar). Consulta la API de registre KYB per a l’esquema complet de la llista de candidats.

Verificació de la signatura

Cada webhook es signa amb HMAC-SHA256 fent servir el secret_shared_key de la destinació. S’envien tres capçaleres de signatura perquè puguis escollir la que funcioni amb el teu stack: Capçaleres que Didit sempre envia: Durant 24 hores després que es rotí el secret de signatura d’una destinació, els lliuraments també porten X-Signature-Previous, X-Signature-V2-Previous i X-Signature-Simple-Previous (consulta Rotació del secret de signatura).

Rotació del secret de signatura

Pots rotar el secret de signatura d’una destinació a la Business Console. Durant 24 hores després d’una rotació, cada lliurament a aquesta destinació porta tres capçaleres més, fetes amb el secret que s’ha substituït: Un gestor que accepti una coincidència amb una capçalera de signatura o amb la seva capçalera -Previous seguirà verificant mentre desplegues el nou secret: el secret antic coincideix amb la capçalera -Previous, i el nou amb la capçalera habitual. Els exemples de codi de més avall ho fan. Desplega el nou secret dins de les 24 hores, perquè després només es pugui verificar amb el nou secret. previous_secret_expires_at a GET /v3/webhook/destinations/{destination_uuid}/ t’indica quan acaben les 24 hores. Els reintents i els reenviaments es tornen a signar amb el secret actual de la destinació quan s’envien, i només porten les capçaleres -Previous mentre duren les 24 hores. Si tornes a rotar dins de les 24 hores, el secret més antic es retira de seguida: només el secret que era vigent fins a la nova rotació continua verificant a través de les capçaleres -Previous, durant 24 hores des de la nova rotació. Les capçaleres -Previous només existeixen per a les destinacions de webhook. El secret_shared_key a nivell d’aplicació que signa el webhook_url heretat no es solapa: rotar-lo amb rotate_secret_key a PATCH /v3/webhook/ invalida el secret antic de seguida.

X-Signature-Simple està obsoleta

X-Signature-Simple autentica el sobre, no el payload. La seva cadena canònica només cobreix timestamp, session_id, status i webhook_type. No cobreix decision, ni resubmit_info, metadata, vendor_data o event_id. Una sol·licitud amb el camp decision reescrit, però amb aquests quatre camps sense tocar, encara supera la verificació de X-Signature-Simple.És encara més feble en els esdeveniments que no porten cap session_id. Els esdeveniments de transacció (transaction_id, txn_id, amount, score) i d’entitat (vendor_user_id, vendor_business_id) signen "{timestamp}::{status}:{webhook_type}", que no identifica a quina transacció o entitat fa referència l’esdeveniment: dues transaccions diferents informades amb el mateix estat en el mateix segon porten la mateixa X-Signature-Simple. Els esdeveniments travel_rule.status.updated, workflow.compliance_changed i transaction_rule_suggestions.created tampoc porten cap status, així que signen "{timestamp}:::{webhook_type}", per exemple "{timestamp}:::travel_rule.status.updated".Si X-Signature-Simple és l’única capçalera que verifiques, tracta tot el que hi ha fora d’aquests quatre camps com a no fiable i torna a obtenir el registre des de l’API: GET /v3/session/{session_id}/decision/ per a una sessió, o GET /v3/transactions/{transaction_id}/ per a una transacció. L’API és el servidor de referència.
Això és una restricció de compatibilitat, no quelcom que puguem corregir en calent. La cadena canònica de quatre camps és un contracte de format de transmissió: cada receptor que verifica X-Signature-Simple recalcula exactament aquests quatre camps, així que canviar el que signa la capçalera trencaria en silenci tots aquests receptors a la ruta de verificació de la signatura. Cobrir el cos també exigeix una forma canònica del JSON especificada que els dos costats reprodueixin byte a byte, i Didit ja n’ofereix una com a X-Signature-V2. En lloc d’afegir una segona variant que cobreixi el cos amb les seves pròpies regles de canonicalització, la capçalera es manté exactament igual i queda obsoleta a favor de les variants existents que signen tot el payload. Què significa això per a tu:
  • Res no canvia en el canal de transmissió. X-Signature-Simple continua enviant-se a cada lliurament, calculada de la mateixa manera. Els verificadors existents continuen funcionant, i anunciarem amb molta antelació qualsevol eliminació.
  • Les integracions noves han d’usar X-Signature-V2. És segura per al middleware i cobreix tot el payload.
  • Si no pots deixar X-Signature-Simple, verifica-la i després obtén el registre des de l’API en lloc de llegir-lo del cos del webhook.

Per què tres variants?

Alguns frameworks web (els analitzadors de cos d’Express, el middleware de Django, les passarel·les d’API) recodifiquen en silenci el JSON abans que el teu gestor el llegeixi. Si el cos original contenia "José" i el teu middleware el reescriu com a "José", els bytes canvien encara que les dades siguin idèntiques. Aleshores X-Signature falla. X-Signature-V2 es calcula a partir d’una forma canònica del JSON (claus ordenades, separadors compactes, Unicode sense escapar) que gairebé qualsevol middleware reprodueix de manera determinista. La signatura X-Signature-Simple obsoleta, en canvi, recorre a la signatura de només una cadena curta i independent de l’analitzador quan fins i tot això falla. Com que signa només aquesta cadena curta i mai el cos, no pot garantir el cos.

Ordre de verificació recomanat

  1. Prova primer X-Signature-V2. Torna a codificar JSON.parse(body) amb les claus ordenades i Unicode preservat, després HMAC-SHA256(secret, canonical) i timingSafeEqual contra la capçalera.
  2. Si V2 falla i pots llegir els bytes en brut, prova X-Signature contra HMAC-SHA256(secret, rawBody).
  3. Només si fallen els dos, recorre a X-Signature-Simple, obsoleta, contra HMAC-SHA256(secret, "{timestamp}:{session_id}:{status}:{webhook_type}"). Això només autentica el sobre: considera el decision del cos com a no fiable i torna’l a obtenir des de GET /v3/session/{session_id}/decision/ abans d’actuar-hi.
En cada pas, quan hi hagi la capçalera -Previous corresponent, accepta una coincidència amb qualsevol de les dues capçaleres (consulta Rotació del secret de signatura). En tots els casos, rebutja qualsevol sol·licitud amb una diferència respecte de l’hora actual superior a 5 minuts (abs(now - X-Timestamp) > 300) per protegir-te d’atacs de repetició.

Política de reintents

Si el teu endpoint respon amb un 5xx o un 404, Didit reintenta fins a 2 vegades amb una espera exponencial:
  • 1r reintent: aproximadament 1 minut després de la fallada inicial.
  • 2n reintent: aproximadament 4 minuts després del 1r reintent.
Després del segon reintent, el lliurament es descarta. Cada intent de lliurament (l’inicial i els reintents) es registra com una entrada separada a la Business Console, a la pestanya Lliuraments de la destinació, perquè puguis repetir o inspeccionar qualsevol intent. Cada intent del registre de lliuraments d’una destinació porta un número attempt: 1 per al primer lliurament d’un esdeveniment, i un número més que el de l’intent que repeteix, per a cada reintent o reenviament. Els reintents automàtics s’envien a la URL on es va enviar el primer intent, encara que hagis canviat després el url de la destinació. Un reenviament manual s’envia a la URL actual de la destinació, de manera que corregir una URL també corregeix el reenviament. Altres regles de lliurament que has de conèixer:
  • La sol·licitud HTTP de sortida té un temps d’espera de 5 segons.
  • Didit bloqueja els lliuraments a URL privades o a localhost com a mesura de protecció contra SSRF, i mai no segueix redireccions. Utilitza un endpoint HTTPS públic que respongui directament.
  • Una url de destinació que contingui una barra invertida literal, un caràcter de control o més d’una @ a l’autoritat es rebutja com a malformada: aquesta URL no es pot crear i una d’existent no es pot tornar a lliurar ni repetir. Utilitza una URL https://host/path simple, amb com a màxim una secció d’informació d’usuari (per a URL de webhook a l’estil de l’autenticació bàsica).
  • 2xx es considera èxit. Els temps d’espera i els errors de connexió es consideren reintentables (apareixen com a 504/503 al registre de lliuraments); les respostes 3xx i 4xx, excepte 404, no es reintenten.
  • En cada reintent, Didit recalcula les signatures amb un X-Timestamp nou, de manera que el parell de marca de temps i signatura sempre coincideix.
  • Els reintents i els reenviaments es signen amb el secret de signatura actual de la destinació en el moment d’enviar-los.

Ordre de lliurament

Didit no garanteix l’ordre en què et arriben els webhooks. Cada lliurament es posa en cua per separat i un reintent arriba minuts després de l’intent inicial, de manera que un status.updated per a Approved pot arribar-te abans que un anterior per a In Progress. Crea el receptor tenint això en compte:
  • Considera un webhook com un senyal que alguna cosa ha canviat. Quan l’ordre importa, crida GET /v3/session/{session_id}/decision/ i actua segons el status actual.
  • No permetis mai que un esdeveniment més antic sobreescrigui un estat més nou: compara el created_at de l’esdeveniment amb l’últim que hagis desat per a aquest registre i ignora’l si és més antic.
  • Detecta les repeticions per event_id, que es manté igual entre reintents.
Didit posa en cua els esdeveniments d’una transferència Travel Rule en un ordre establert, descrit a Travel Rule exchange status changed, però un reintent pot canviar igualment l’ordre en què arriben.

Configurar una destinació

Pots gestionar les destinacions des de la Business Console > API & Webhooks o mitjançant l’API de gestió.
1

Crea la destinació

Crida POST /v3/webhook/destinations/ (o fes clic a Afegir destinació a la consola) amb un label, una url pública, un webhook_version ("v3") i un array subscribed_events que contingui totes les famílies d’esdeveniments que aquest endpoint ha de rebre. Cal com a mínim un esdeveniment i no existeix cap comodí.
2

Desa el secret_shared_key

La resposta de creació retorna el secret_shared_key de la destinació. Desa’l amb els altres secrets del teu servidor: pertany només a aquesta destinació i és l’entrada de les tres variants de signatura HMAC-SHA256. GET /v3/webhook/destinations/{destination_uuid}/ el torna a retornar als clients amb clau d’API i als usuaris de la consola que poden llegir els webhooks.
3

Implementa l'endpoint

Exposa una ruta POST HTTPS pública, llegeix el cos en brut, verifica la signatura (preferint X-Signature-V2), comprova la finestra de la marca de temps i després distribueix segons el webhook_type. Retorna 2xx tan bon punt hagis posat el treball en cua: fes el processament pesat de manera asíncrona.
4

Confirma les recepcions

Vigila la pestanya Lliuraments de la destinació. Els webhooks que funcionen correctament retornen 200 en un segon o dos. Un 5xx o 404 activa la política de reintents de Didit; les fallades persistents es descarten després del segon reintent.
5

Itera amb Try Webhook

Fes servir els escenaris de Try Webhook de la consola per enviar al teu endpoint payloads d’aprovació, rebuig, revisió, KYB, entitat, activitat i transacció abans d’activar el trànsit de producció.
Funcionalitat de prova de webhooks de Didit a la Business Console

Envia webhooks de prova directament des de la Business Console per validar el teu endpoint abans de posar-lo en producció.

Pots crear tantes destinacions com necessitis. Un patró habitual és una destinació per consumidor: p. ex., esdeveniments KYC → el teu servei d’autenticació, esdeveniments KYB → el teu servei d’operacions de compliment, transaccions → la teva cua de frau. Cada destinació té el seu propi secret, versió i llista de subscripcions, de manera que un secret rotat o un desplegament defectuós en un consumidor no afecta els altres.

Mostres de codi

Per garantir la seguretat del teu endpoint de webhook, verifica l’autenticitat de les sol·licituds entrants amb el secret_shared_key de la destinació.
Utilitza X-Signature-V2. És la variant més resistent a la recodificació que fan els middleware, i autentica completament el cos (inclosa la decision).

Node.js / Express (recomanat: X-Signature-V2)

Si pots llegir els bytes en brut abans que cap analitzador els toqui, la variant original X-Signature funciona de la mateixa manera, però signa el cos en brut. La mantenim a la secció heretada següent per completesa.

Python / FastAPI (recomanat: X-Signature-V2)

PHP / Laravel (recomanat: X-Signature-V2)

Els valors per defecte del JSON de PHP no reprodueixen la forma canònica. Cal sobreescriure’n quatre, i si en falta només un, canvien els bytes signats i el resum mai no coincideix: La trampa dels objectes buits és la que fa més mal. Els payloads de Didit porten sovint mapes buits, com risk_view.countries.risk_scores, risk_view.crimes.risk_scores i risk_view.custom_list, de manera que una conversió associativa d’anada i tornada trenca la signatura en sessions aprovades habituals, en lloc de fer-ho només en algun cas excepcional i poc freqüent.
Hi ha dues coses més que cal saber:
  • Els nombres en coma flotant amb valor enter no necessiten cap tractament especial en PHP. Didit els serialitza com a enters (100.0 → 100), i el json_encode de PHP escriu un float amb valor enter de la mateixa manera, així que no cal cap pas shortenFloats, a diferència de la mostra de Node.js de dalt.
  • Mantén serialize_precision en -1 (el valor per defecte des de PHP 7.1). Si el teu servidor el sobreescriu amb 17, json_encode escriu 87.42 com 87.420000000000002 i totes les comprovacions de X-Signature-V2 fallen.
Si no aconsegueixes que la forma canònica coincideixi, verifySignatureRaw de dalt és l’alternativa més simple: el $request->getContent() de Laravel retorna els bytes sense tocar, de manera que X-Signature funciona sempre que res davant de PHP recodifiqui el cos. Precisament aquest és el cas per al qual està dissenyat X-Signature-V2, i per això es prova primer V2.

Proves

No cal que executis una verificació completa per provar el teu endpoint.
  • Des de Business Console > API & Webhooks > Try Webhook, tria un escenari (p. ex. approved_full_features, declined_face_mismatch, in_review_aml_hit, business_session_approved, transaction_created, activity_created, user_status_updated) i envia un webhook amb el format complet a la URL de la teva destinació.
  • Cada escenari es signa amb les mateixes tres capçaleres de signatura i la mateixa codificació canònica que el trànsit de producció, incloses les dades de prova amb unicode (approved_kyc_with_unicode), perquè puguis confirmar que X-Signature-V2 funciona a través del teu middleware. Els lliuraments de prova porten dades d’exemple i es marquen amb una capçalera addicional X-Didit-Test-Webhook: true (i amb un sufix (Test) al User-Agent), perquè no afectin l’estat de producció.
  • Torna a reproduir qualsevol lliurament històric des de la pestanya Lliuraments d’una destinació si necessites depurar una regressió.
Per a les proves de funcionament bàsic d’extrem a extrem, executa una verificació real a través d’un flux de treball de prova de la teva pròpia aplicació: els webhooks resultants fan servir la mateixa estructura, les mateixes capçaleres i la mateixa política de reintents que els escenaris de Try Webhook.

Exemples

Sessió KYC aprovada (status.updated)

Sessió rebutjada amb advertències (status.updated)

Sessió empresarial aprovada (status.updated, KYB)

Transacció creada (transaction.created)

Canvi d’estat d’un intercanvi de Travel Rule (travel_rule.status.updated)

travel_rule_status conté un dels 13 estats d’intercanvi documentats a Travel Rule. rail és INTERNAL, TRP, GTR, TRUST, VERIFYVASP, SYGNA o EMAIL (cadena buida fins que se selecciona una via, si no se n’ha pogut determinar cap, i sempre en els registres sunrise), o TEST_VASP per a una transferència de sandbox que ha respost el Didit Test VASP, i direction és INBOUND o OUTBOUND. Un esdeveniment de sandbox porta "environment": "sandbox", i un esdeveniment TEST_VASP porta també test_vasp: true i test_vasp_scenario (l’escenari que ha respost). Quan Didit crea una transacció per a una transferència de Travel Rule (una crida POST /v3/transactions/, un registre sunrise posterior al dipòsit, una consulta TRP entrant o la part entrant de la via INTERNAL), envia primer l’esdeveniment transaction.created d’aquesta transacció i després els esdeveniments travel_rule.status.updated de la transferència. Una regla que canvia l’estat de la transacció durant aquest pas també pot enviar transaction.status.updated abans de transaction.created, i un registre sunrise que s’adjunta a una transacció de dipòsit que ja has creat no envia cap transaction.created. Cada webhook s’envia i es reintenta de manera independent, de manera que un esdeveniment reintentat pot arribar després d’un de posterior: fes que el teu gestor depengui de transaction_id i torna a llegir la transacció quan necessitis el seu estat actual. Una transferència enviada per TRUST no rep mai un esdeveniment COMPLETED, perquè TRUST no envia res que Didit pugui llegir: es manté a AWAITING_COUNTERPARTY fins al termini de confirmació i després passa a EXPIRED. A GTR, VerifyVASP i Sygna Bridge, Didit llegeix la resposta de la contrapart des de la xarxa i l’esdeveniment la segueix (consulta xarxes de Travel Rule).

Canvi de compliment del flux de treball (workflow.compliance_changed)

transition.from i transition.to són cadascun un dels valors següents: compliant, gaps_detected, pending_change, unknown_coverage o not_evaluated. severity és actionable quan s’han detectat llacunes, indicative per a un canvi pendent i informative quan s’han resolt llacunes. Didit envia un esdeveniment per cada flux de treball que ha canviat.

Suggeriments de regla de transacció creats (transaction_rule_suggestions.created)

kind és ADD per a una regla nova, TWEAK per a un canvi en una regla existent i DISABLE per desactivar-ne una. rule_id és null per a ADD. open_count és el nombre de suggeriments encara oberts després de l’execució, incloent-hi els nous. La configuració dels suggeriments de regla activa o desactiva aquest webhook; consulta Webhooks de transaccions.

Esdeveniments d’Investigator (investigator.*)

Els dotze esdeveniments investigator.* fan servir la mateixa estructura (event_id, webhook_type, timestamp, created_at, application_id, environment) i les mateixes capçaleres de signatura que qualsevol altre esdeveniment. Només porten identificadors i xifres: mai un nom, un motiu que hagi escrit un revisor, una narrativa ni res que hagi escrit l’usuari final. No tenen session_id; l’element al qual fan referència s’indica a item.
provenance indica quina versió de l’Investigator ha escrit l’informe:
  • engine és la versió del motor de l’Investigator: un identificador opac de vuit caràcters. Canvia cada vegada que canvia el motor, de manera que dos informes amb el mateix engine els ha escrit el mateix motor.
  • agent_version és la versió de l’agent.
  • policy_version és la versió de la teva pròpia política que ha seguit l’informe.
  • model_id és un àlies obsolet que porta el mateix valor que engine. Llegeix engine en lloc seu.
  • prompt_hash ja no s’envia.
item.kind indica el tipus d’element (una sessió, una sessió empresarial, una transacció o un cas) i item.id el seu identificador. Les marques de temps que acaben en _at són cadenes ISO 8601. Subscriu-te a aquests esdeveniments indicant les cadenes exactes a subscribed_events, igual que qualsevol altre esdeveniment.

Canvi d’estat de l’entitat d’usuari (user.status.updated)

Sessió reenviada

Obsolet: X-Signature amb el cos en brut

Encara s’envia X-Signature en cada lliurament. És un HMAC-SHA256 sobre els bytes exactes que transmet Didit (json.dumps(..., sort_keys=True, separators=(",", ":"))). Utilitza-la només quan puguis llegir el cos en brut abans que cap middleware el modifiqui.

Obsolet: format de webhook V2

Els camps següents només s’apliquen quan una destinació està fixada a webhook_version: "v2". També existeix una fixació "v1" encara més antiga (una tercera forma de decisió, en singular) per a les destinacions creades abans de V2; contacta amb suport abans de confiar-hi. Les noves integracions han d’utilitzar V3 (el valor per defecte), que es documenta més amunt i utilitza matrius en plural.
Els objectes per funcionalitat són els mateixos en les dues versions: una destinació V2 rep exactament el match_score, risk_score, score_breakdown, risk_view i review_status per cada coincidència, i el score agregat que rep V3 (vegeu Informe AML). Fixar la destinació a V2 canvia on es troba l’informe AML dins de decision, però no el que conté. Si un consumidor final encara necessita les formes V2, crea una destinació separada fixada a webhook_version: "v2" i mantén els nous consumidors a V3.

Relacionats

Darrera modificació el 7 de novembre del 2026