L’activité d’authentification et la livraison des webhooks associée, qui dépend de la version, sont documentées dans Événements d’authentification et webhooks. N’enregistrez pas de types d’événements d’authentification absents de cette liste auprès de l’API de destination actuelle.
Vue d’ensemble
Les webhooks permettent à Didit de vous transmettre des mises à jour en temps réel dès qu’une session de vérification, une session d’entreprise, un utilisateur fournisseur, une entreprise fournisseur ou une transaction change d’état. En abonnant une ou plusieurs destinations aux événements qui vous intéressent, vous pouvez réagir dès qu’un résultat est prêt, généralement quelques secondes après que l’utilisateur a terminé son parcours. Les webhooks constituent le mode d’intégration recommandé. L’interrogation deGET /v3/session/{id}/decision/ reste prise en charge comme solution de secours, mais elle est plus lente, génère davantage de requêtes et ne remonte pas les événements tels que data.updated, transaction.status.updated ni les changements au niveau des entités, qui ne sont émis que par webhooks. Considérez la livraison des webhooks comme la source de vérité et n’interrogez l’API qu’au démarrage à froid ou pour une réconciliation.
Ce chapitre de la leçon d’intégration de Didit Academy reprend à la présentation des webhooks.
La leçon Academy consacrée à l’intégration aborde les webhooks à partir de 3:12 : l’ajout d’une destination, le choix des événements et le secret de signature que vous utiliserez pour effectuer la vérification plus bas.
Utilisateurs de Cloudflare / WAF. Didit envoie les webhooks depuis l’adresse IP statique
18.203.201.92 avec User-Agent: DiditWebhook/2.0 +https://didit.me. Si votre edge bloque les clients inconnus, autorisez cette IP dans Security > WAF > Tools > IP Access Rules et choisissez Autoriser pour le nom d’hôte de réception.Types d’événements
Utilisez la valeur exacte dans le tableausubscribed_events d’une destination. Il n’existe pas de caractère générique : listez chaque famille que vous souhaitez recevoir. Vous pouvez répartir les événements sur plusieurs destinations.
Les valeurs de ce tableau constituent l’ensemble complet des événements auxquels vous pouvez vous abonner : il n’existe aucun
session.status.updated, kyc.completed ni événement similaire. La seule autre livraison effectuée par Didit est le rappel kyb.registry_search.resolved non signé, qui est envoyé à l’URL webhook_url que vous transmettez à l’endpoint POST /v3/kyb/search/ pour chaque requête, et jamais à une destination de webhook.
Structure du payload
Envelope
Tous les webhooks partagent la même enveloppe. Les champs sont toujours sérialisés avecsort_keys=True et des séparateurs compacts (, / :) afin que le même payload produise la même signature des deux côtés.
Pour les événements de session (
status.updated, data.updated sur les sessions classiques et les sessions d’entreprise), l’enveloppe contient en plus :
Exemple d’enveloppe de session
Tableaux pluriels V3 (important)
Dansdecision, chaque résultat par fonctionnalité se présente sous la forme d’un tableau afin qu’un même workflow puisse inclure plusieurs instances de la même fonctionnalité (par exemple, plusieurs contrôles d’identité sur différents documents) :
node_id correspondant au graphe du workflow, ainsi qu’un status propre à la fonctionnalité. Ne lisez pas les anciens champs singuliers du format V2 (id_verification, nfc, liveness, face_match, phone, email, poa, aml, ip_analysis, database_validation) : ils n’apparaissent que si une destination est explicitement configurée avec webhook_version: "v2".
Les résultats de Signature électronique se trouvent dans signatures[], présents uniquement lorsque le workflow comporte une étape de signature électronique : un élément par signataire, avec le signataire, la confirmation par code, le certificat, l’horodatage, les empreintes et les chemins de téléchargement de chaque document, ainsi que le PDF de preuve. Il n’existe pas d’événement de signature distinct : status.updated vous indique quand les lire. Voir le rapport de signature électronique.
Les résultats de Vérification bancaire se trouvent dans bank_verifications[], un élément par étape de vérification bancaire. La valeur method de chaque élément indique comment le compte a été vérifié : open_banking (connexion à la banque), account_lookup (contrôle du compte), ou un repli sur statement ou microdeposits, et null tant qu’aucun compte n’a été évalué. Lorsque la personne a choisi Continuer sans votre banque, continued_without_bank vaut true et continuation indique la raison. method vaut alors none, sauf si une tentative a été évaluée auparavant : voir Lorsque la personne ne peut pas vérifier sa banque. Un compte vérifié par contrôle du compte ne donne accès à aucune donnée financière ; financial_data.not_collected liste donc les soldes, transactions ou revenus que l’étape demandait. Voir Méthodes de vérification bancaire.
Bloc Investigator
Unedecision V3 pour une session utilisateur ou entreprise contient aussi investigator : le dernier examen Investigator de la session, ou null si la session n’en a jamais eu.
Les fonctionnalités de collecte de documents, Documents KYB et Document AI, n’ont pas de tableau dédié contenant plusieurs éléments. Elles apparaissent dans la liste
features[] de la décision sous la forme { "feature": "DOCUMENT_AI", "node_id": "…" } (une entrée par nœud). Voir Document AI.
Les décisions de Vérification des utilisateurs contiennent aussi un objet unique biometric_consent : il indique si la session exigeait un consentement biométrique explicite, le trigger, le status de la réponse et ses preuves. status: "pending" avec reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" signifie qu’un SDK natif antérieur à la version 4.10.0 a capturé un visage sans l’étape de consentement. Voir Consentement biométrique.
Clés de méthode de vérification d’identité
Chaque élémentid_verifications[] indique la méthode de vérification d’identité qui l’a produit. Un gestionnaire peut ainsi traiter différemment les preuves réellement reçues :
Les gestionnaires existants continuent de fonctionner sans modification : une session avec document définit
verification_method sur document et laisse les autres champs à null. Les types champ par champ figurent dans Modèles de données.
Session de portefeuille approuvée (status.updated)
Payloads des événements d’entité
ACTIVE, FLAGGED ou BLOCKED. user.data.updated et business.data.updated conservent le champ status et ajoutent un tableau changed_fields ainsi qu’une table changes au format { field: { previous, current } }. Les événements business.* utilisent vendor_business_id à la place de vendor_user_id.
Payloads des événements de transaction
Les webhooks de transaction empruntent la même infrastructure de diffusion et utilisent la même enveloppe, mais identifient la transaction au lieu de la session :action_required vaut null, ou correspond à l’action en attente de l’utilisateur (type wallet_ownership ou verification_session, avec son url) décrite dans Actions requises de l’utilisateur.
Les nouvelles transactions ont APPROVED par défaut. Si une règle, une liste de blocage ou un workflow modifie le statut pendant la création, le payload initial transaction.created reflète ce statut final. transaction.status.updated a la même structure, avec le status mis à jour. Les statuts de transaction sont APPROVED, IN_REVIEW, DECLINED ou AWAITING_USER ; severity vaut UNKNOWN / LOW / MEDIUM / HIGH / CRITICAL et direction vaut INBOUND / OUTBOUND. transaction.created et transaction.status.updated ne sont envoyés que pour les applications en production. Les échanges Travel Rule en sandbox émettent bien travel_rule.status.updated avec environment: sandbox.
Callback de recherche dans le registre KYB
Le flux asynchronePOST /v3/kyb/search/ envoie un payload supplémentaire qui n’est pas un événement de destination : lorsque vous transmettez un webhook_url à la requête de recherche, Didit envoie un callback kyb.registry_search.resolved à cette URL dès que le registre a répondu. Il diffère des webhooks de destination sur trois points :
- Il est non signé : aucun en-tête
X-Signature*. Didit le signale à la place avecX-Didit-Unsigned-Callback: true. Pour le valider, comparezrequest_idà l’identifiant renvoyé par la requête de recherche. - Le nom de l’événement figure dans
event_type(et non danswebhook_type), et il n’y a niapplication_idnienvironment. timestampetcreated_atsont des entiers correspondant à l’époque Unix, comme pour les autres webhooks, mais contrairement aucreated_atISO de l’endpoint de recherche.
timestamp et reste non signée. Consultez l’API du registre KYB pour le schéma complet de la liste de candidats.
Vérification de la signature
Chaque webhook est signé avec HMAC-SHA256 à l’aide dusecret_shared_key de la destination. Trois en-têtes de signature sont envoyés afin que vous puissiez choisir celui qui fonctionne avec votre environnement technique :
En-têtes toujours envoyés par Didit :
Pendant 24 heures après la rotation du secret de signature d’une destination, les livraisons transportent aussi
X-Signature-Previous, X-Signature-V2-Previous et X-Signature-Simple-Previous (voir Rotation du secret de signature).
Rotation du secret de signature
Vous effectuez la rotation du secret de signature d’une destination dans la Business Console. Pendant 24 heures après une rotation, chaque livraison vers cette destination porte trois en-têtes supplémentaires, calculés avec le secret qui a été remplacé :
Un gestionnaire qui accepte une correspondance sur un en-tête de signature ou sur son en-tête
-Previous continue de vérifier pendant le déploiement du nouveau secret : l’ancien secret correspond à l’en-tête -Previous, et le nouveau à l’en-tête habituel.
Les exemples de code ci-dessous procèdent ainsi.
Déployez le nouveau secret dans les 24 heures, car après ce délai, seul le nouveau secret permet la vérification.
previous_secret_expires_at sur GET /v3/webhook/destinations/{destination_uuid}/ indique la fin des 24 heures.
Les nouvelles tentatives et les renvois sont signés à nouveau avec le secret actuel de la destination au moment de leur envoi, et ne portent les en-têtes -Previous que pendant les 24 heures. Effectuer une nouvelle rotation dans les 24 heures retire immédiatement le plus ancien secret : seul le secret qui était en vigueur jusqu’à cette nouvelle rotation continue de permettre la vérification via les en-têtes -Previous, pendant 24 heures à compter de la nouvelle rotation.
Les en-têtes -Previous n’existent que pour les destinations de webhook.
Le secret_shared_key au niveau de l’application, qui signe l’ancien webhook_url, ne prévoit aucune période de chevauchement : sa rotation avec rotate_secret_key sur PATCH /v3/webhook/ invalide immédiatement l’ancien secret.
X-Signature-Simple est déprécié
Il s’agit d’une contrainte de compatibilité, et non d’un défaut que nous pouvons corriger sur place. La chaîne canonique à quatre champs est un contrat sur le format transmis : chaque récepteur qui vérifie X-Signature-Simple recalcule exactement ces quatre champs. Modifier ce que l’en-tête signe casserait donc silencieusement tous ces récepteurs sur le chemin de vérification. Couvrir le corps exige aussi une forme canonique spécifiée du JSON, que les deux parties reproduisent octet par octet, et Didit en fournit déjà une avec X-Signature-V2. Plutôt que d’ajouter une seconde variante couvrant le corps, avec ses propres règles de canonicalisation, l’en-tête reste inchangé et est déprécié au profit des variantes existantes qui couvrent le payload complet.
Concrètement, cela signifie :
- Rien ne change au niveau du transport.
X-Signature-Simplecontinue d’être envoyé à chaque livraison, calculé de la même manière. Les vérificateurs existants continuent de fonctionner, et nous annoncerons toute suppression bien à l’avance. - Les nouvelles intégrations doivent utiliser
X-Signature-V2. Cette signature est compatible avec les middlewares et couvre le payload entier. - Si vous ne pouvez pas abandonner
X-Signature-Simple, vérifiez-le, puis récupérez l’enregistrement depuis l’API plutôt que de le lire dans le corps du webhook.
Pourquoi trois variantes
Certains frameworks web (analyseurs de corps Express, middlewares Django, passerelles API) réencodent silencieusement le JSON avant que votre gestionnaire ne le lise. Si le corps d’origine contenait"José" et que votre middleware le réécrit en "José", les octets changent alors que les données sont identiques, et X-Signature échoue. X-Signature-V2 est calculé à partir d’une forme JSON canonique (clés triées, séparateurs compacts, Unicode non échappé) que presque tous les middlewares reproduisent de manière déterministe. Quant à X-Signature-Simple, déprécié, il se rabat sur la signature d’une courte chaîne indépendante de l’analyseur lorsque même cela échoue. Comme il ne signe que cette courte chaîne et jamais le corps, il ne peut pas garantir l’intégrité du corps.
Ordre de vérification recommandé
- Essayez d’abord
X-Signature-V2. RéencodezJSON.parse(body)avec les clés triées et Unicode préservé, puis comparezHMAC-SHA256(secret, canonical)à l’en-tête avectimingSafeEqual. - Si la V2 échoue et que vous pouvez lire les octets bruts, essayez
X-SignatureavecHMAC-SHA256(secret, rawBody). - Ce n’est qu’en cas d’échec des deux que vous revenez à
X-Signature-Simple, obsolète, avecHMAC-SHA256(secret, "{timestamp}:{session_id}:{status}:{webhook_type}"). Cette méthode n’authentifie que l’enveloppe : considérez ledecisiondu corps comme non fiable et récupérez-le de nouveau viaGET /v3/session/{session_id}/decision/avant d’agir.
-Previous correspondant est présent, acceptez une correspondance avec l’un ou l’autre des deux en-têtes (voir Rotation du secret de signature).
Dans tous les cas, rejetez toute requête datant de plus de 5 minutes (abs(now - X-Timestamp) > 300) afin de vous protéger contre les rejeux.
Politique de nouvelles tentatives
Si votre endpoint répond par un5xx ou un 404, Didit effectue jusqu’à 2 nouvelles tentatives avec un backoff exponentiel :
- 1er réessai : environ 1 minute après l’échec initial.
- 2e réessai : environ 4 minutes après le 1er réessai.
attempt : 1 pour la première livraison d’un événement, puis un numéro supérieur de un à celui de la tentative répétée, pour chaque réessai ou renvoi.
Les réessais automatiques sont envoyés à l’URL de la première tentative, même si vous avez modifié depuis le url de la destination.
Un renvoi manuel est envoyé à l’URL actuelle de la destination : corriger l’URL corrige donc aussi le renvoi.
Autres règles de livraison à connaître :
- Le délai d’attente de la requête HTTP sortante est de 5 secondes.
- Didit bloque les livraisons vers des URL privées ou localhost, par mesure de protection contre le SSRF, et ne suit jamais les redirections. Utilisez un endpoint HTTPS public qui répond directement.
- Une
urlde destination contenant une barre oblique inverse brute, un caractère de contrôle, ou plus d’un@dans l’autorité est rejetée comme malformée : une telle URL ne peut pas être créée, et une URL existante ne peut ni être relivrée ni être rejouée. Utilisez une URL simplehttps://host/path, avec au plus une section d’informations utilisateur (pour les URL de webhook de type authentification de base). - Un
2xxest considéré comme un succès. Les délais d’attente et les échecs de connexion sont réessayables (ils apparaissent comme504ou503dans le journal de livraison). Les réponses3xxet4xx, autres que404, ne sont pas réessayées. - Lors d’un réessai, Didit recalcule les signatures avec un nouvel
X-Timestamp, de sorte que le couple horodatage-signature soit toujours cohérent. - Les réessais et les renvois sont signés avec le secret de signature actuel de la destination au moment de leur envoi.
Ordre de livraison
Didit ne garantit pas l’ordre dans lequel les webhooks vous parviennent. Chaque livraison est mise en file d’attente séparément, et un réessai arrive plusieurs minutes après la première tentative : unstatus.updated pour Approved peut donc vous parvenir avant un événement antérieur pour In Progress.
Concevez votre récepteur en conséquence :
- Traitez un webhook comme le signal qu’un élément a changé. Lorsque l’ordre compte, appelez
GET /v3/session/{session_id}/decision/et agissez selon lestatusactuel. - Ne laissez jamais un événement plus ancien écraser un état plus récent : comparez le
created_atde l’événement avec le dernier que vous avez enregistré pour cet enregistrement, et ignorez l’événement s’il est plus ancien. - Dédupliquez à l’aide de
event_id, qui reste identique entre les réessais.
Configurer une destination
Vous pouvez gérer les destinations depuis la Business Console > API & Webhooks ou via l’API de gestion.1
Créer la destination
Appelez
POST /v3/webhook/destinations/ (ou cliquez sur Ajouter une destination dans la console) avec un label, une url publique, un webhook_version ("v3") et un tableau subscribed_events contenant chaque famille d’événements que cet endpoint doit recevoir. Au moins un événement est requis, et aucun caractère générique n’est accepté.2
Stocker le secret_shared_key
La réponse à la création renvoie le
secret_shared_key de la destination. Conservez-le avec vos autres secrets serveur : il appartient à cette seule destination et sert d’entrée aux trois variantes de signature HMAC-SHA256. GET /v3/webhook/destinations/{destination_uuid}/ le renvoie à nouveau aux appelants disposant d’une clé API et aux utilisateurs de la console qui peuvent consulter les webhooks.3
Implémenter l'endpoint
Exposez une route
POST HTTPS publique, lisez le corps brut, vérifiez la signature (en privilégiant X-Signature-V2), contrôlez la fenêtre temporelle de l’horodatage, puis traitez les événements en fonction de webhook_type. Renvoyez un 2xx dès que le traitement est mis en file d’attente : effectuez les traitements lourds de manière asynchrone.4
Confirmer la réception
Surveillez l’onglet Livraisons de la destination. Un webhook fonctionnel renvoie
200 en une seconde ou deux. Un 5xx ou un 404 déclenche la politique de nouvelles tentatives de Didit ; les livraisons échouant de manière persistante sont abandonnées après le second réessai.5
Itérer avec Try Webhook
Utilisez les scénarios de la console Try Webhook pour faire passer votre endpoint par des payloads approuvés, refusés, en cours d’examen, KYB, entité, activité et transaction, avant d’activer le trafic de production.

Envoyez des webhooks de test directement depuis la Business Console pour valider votre endpoint avant la mise en production.
Exemples de code
Pour garantir la sécurité de votre endpoint de webhook, vérifiez l’authenticité des requêtes entrantes à l’aide dusecret_shared_key de la destination de webhook.
Node.js / Express (X-Signature-V2 recommandé)
X-Signature fonctionne de la même façon, mais elle signe le corps brut. Nous la présentons dans la section consacrée aux anciens formats, ci-dessous, par souci d’exhaustivité.
Python / FastAPI (X-Signature-V2 recommandé)
PHP / Laravel (X-Signature-V2 recommandé)
Les valeurs JSON par défaut de PHP ne reproduisent pas la forme canonique. Quatre d’entre elles doivent être surchargées, et l’oubli d’une seule change les octets signés, de sorte que l’empreinte ne correspond jamais :
Le piège des objets vides est celui qui fait le plus de dégâts. Les payloads de Didit contiennent couramment des dictionnaires vides, comme
risk_view.countries.risk_scores, risk_view.crimes.risk_scores et risk_view.custom_list. Un aller-retour associatif casse donc la signature sur des sessions approuvées tout à fait ordinaires, et non dans un cas limite rare.
- Les flottants à valeur entière n’exigent aucun traitement particulier en PHP. Didit les sérialise sous forme d’entiers (
100.0→100), etjson_encodede PHP écrit de la même manière un flottant entier. Aucune étapeshortenFloatsn’est donc requise, contrairement à l’exemple Node.js ci-dessus. - Conservez
serialize_precisionà-1(valeur par défaut depuis PHP 7.1). Si votre hébergeur la fixe à17,json_encodeécrit87.42sous la forme87.420000000000002, et chaque vérificationX-Signature-V2échoue.
verifySignatureRaw ci-dessus est la solution de repli la plus simple : $request->getContent() de Laravel renvoie les octets intacts, donc X-Signature fonctionne tant qu’aucun élément placé devant PHP ne ré-encode le corps. C’est exactement le cas pour lequel X-Signature-V2 est conçue, ce qui explique pourquoi V2 est essayée en premier.
Tests
Vous n’avez pas besoin d’exécuter une vérification complète pour tester votre endpoint.- Depuis Business Console > API & Webhooks > Try Webhook, choisissez un scénario (par exemple
approved_full_features,declined_face_mismatch,in_review_aml_hit,business_session_approved,transaction_created,activity_created,user_status_updated) et envoyez un webhook complet à l’URL de votre destination. - Chaque scénario est signé avec les mêmes trois en-têtes de signature et le même encodage canonique que le trafic de production, y compris des données de test Unicode (
approved_kyc_with_unicode), afin que vous puissiez vérifier queX-Signature-V2fonctionne à travers votre middleware. Les livraisons de test contiennent des données d’exemple et sont marquées par un en-tête supplémentaireX-Didit-Test-Webhook: true(ainsi que par un suffixe(Test)dans leUser-Agent), afin qu’elles n’affectent pas l’état de production. - Rejouez n’importe quelle livraison historique depuis l’onglet Livraisons d’une destination si vous devez diagnostiquer une régression.
Exemples
Session KYC approuvée (status.updated)
Session refusée avec avertissements (status.updated)
Session entreprise approuvée (status.updated, KYB)
Transaction créée (transaction.created)
Statut d’échange Travel Rule modifié (travel_rule.status.updated)
travel_rule_status prend l’une des 13 valeurs de statut d’échange décrites dans Travel Rule.
rail vaut INTERNAL, TRP, GTR, TRUST, VERIFYVASP, SYGNA ou EMAIL (chaîne vide tant qu’aucun rail n’est sélectionné, si aucun n’a pu être déterminé, et toujours pour les enregistrements sunrise), ou TEST_VASP pour un transfert sandbox auquel le Didit Test VASP a répondu, et direction vaut INBOUND ou OUTBOUND.
Un événement sandbox contient "environment": "sandbox", et un événement TEST_VASP contient aussi test_vasp: true et test_vasp_scenario (le scénario qui a répondu).
Lorsque Didit crée une transaction pour un transfert Travel Rule (un appel POST /v3/transactions/, un enregistrement sunrise après dépôt, une demande entrante TRP ou la portion entrante sur le rail INTERNAL), il envoie d’abord l’événement transaction.created pour cette transaction, puis les événements travel_rule.status.updated du transfert.
Une règle qui modifie le statut de la transaction pendant cette étape peut aussi envoyer transaction.status.updated avant transaction.created, et un enregistrement sunrise rattaché à une transaction de dépôt que vous avez déjà créée n’envoie aucun transaction.created.
Chaque webhook est livré et réessayé indépendamment, si bien qu’un événement réessayé peut arriver après un événement plus récent : utilisez transaction_id comme clé dans votre gestionnaire et relisez la transaction lorsque vous avez besoin de son état actuel.
Un transfert envoyé via TRUST ne reçoit jamais d’événement COMPLETED, car TRUST ne renvoie rien que Didit puisse lire : il reste à AWAITING_COUNTERPARTY jusqu’à l’échéance de confirmation, puis passe à EXPIRED. Via GTR, VerifyVASP et Sygna Bridge, Didit lit la réponse de la contrepartie sur le réseau et l’événement la suit (voir Réseaux Travel Rule).
Conformité du workflow modifiée (workflow.compliance_changed)
transition.from et transition.to prennent l’une des valeurs compliant, gaps_detected, pending_change, unknown_coverage ou not_evaluated.
severity vaut actionable lorsque des écarts ont été détectés, indicative pour un changement en attente et informative lorsque les écarts ont été résolus.
Didit envoie un événement par workflow modifié.
Suggestions de règles de transaction créées (transaction_rule_suggestions.created)
kind vaut ADD pour une nouvelle règle, TWEAK pour la modification d’une règle existante et DISABLE pour désactiver une règle. rule_id vaut null pour ADD.
open_count correspond au nombre de suggestions encore ouvertes après l’exécution, nouvelles suggestions comprises.
Les paramètres des suggestions de règles activent ou désactivent ce webhook ; voir Webhooks de transaction.
Événements Investigator (investigator.*)
Les douze événements investigator.* utilisent la même enveloppe (event_id, webhook_type, timestamp, created_at, application_id, environment) et les mêmes en-têtes de signature que tous les autres événements. Ils ne contiennent que des identifiants et des chiffres : jamais de nom, de motif saisi par un réviseur, de récit ni de contenu rédigé par l’utilisateur final. Ils n’ont pas de session_id ; l’élément concerné est indiqué dans item.
provenance indique la version de l’Investigator qui a rédigé le rapport :
engineest la version du moteur Investigator : un identifiant opaque de huit caractères. Il change à chaque modification du moteur ; deux rapports ayant la même valeur deengineont donc été rédigés par le même moteur.agent_versionest la version de l’agent.policy_versionest la version de votre propre politique que le rapport a suivie.model_idest un alias obsolète qui porte la même valeur queengine. Utilisez plutôtengine.prompt_hashn’est plus envoyé.
item.kind indique le type d’élément (une session, une session entreprise, une transaction ou un dossier) et item.id son identifiant. Les horodatages dont le nom se termine par _at sont des chaînes ISO 8601. Abonnez-vous à ces événements en listant les chaînes exactes dans subscribed_events, comme pour tout autre événement.
Statut de l’entité utilisateur modifié (user.status.updated)
Session soumise à nouveau
Ancienne méthode X-Signature sur le corps brut
X-Signature est toujours envoyé à chaque livraison ; il s’agit d’un HMAC-SHA256 calculé sur les octets exacts que Didit transmet (json.dumps(..., sort_keys=True, separators=(",", ":"))). Ne l’utilisez que si vous pouvez lire le corps brut avant que tout middleware ne le modifie.
- Node.js
- Python
Ancienne méthode : format de webhook V2
Les objets par fonctionnalité sont identiques dans les deux versions : une destination V2 reçoit exactement les champs de chaque résultat
match_score, risk_score, score_breakdown, risk_view et review_status, ainsi que le score global, comme en V3 (voir Rapport AML). Fixer la version V2 change l’emplacement du rapport AML dans decision, pas son contenu.
Si un consommateur en aval a encore besoin des structures V2, créez une destination de webhook distincte configurée sur webhook_version: "v2", et gardez vos nouveaux consommateurs sur la V3.
Voir aussi
- API des destinations de webhook : lister, créer, mettre à jour et supprimer des destinations, et consulter les journaux de livraison.
- Créer une destination de webhook : schéma de la requête et de la réponse, y compris le
secret_shared_keyde la destination. - Modèles de données : schéma canonique de chaque objet par fonctionnalité intégré dans
decision. - Schéma de décision : liste complète des champs de l’objet
decisionintégré dans les webhooks de session. - Statuts de vérification : valeurs exactes de
statuset transitions mentionnées plus haut. - Limites de débit : limites applicables lorsque vous interrogez
GET /v3/session/{id}/decision/en solution de repli.