Passer au contenu principal
GET
curl
Le payload contenu dans request_body est celui décrit dans Webhooks, et les en-têtes sont ceux présentés dans vérification de signature. Pour renvoyer la livraison, utilisez Renvoyer la livraison du webhook de session.

Autorisations

x-api-key
string
header
requis

La clé API de votre application, issue de Développeurs -> Clés API dans la Business Console. La clé principale dispose d'un accès complet. Une clé nommée peut être restreinte : aucun, lecture ou écriture par ressource, limitée à certains workflows ou aux sessions approuvées, à une liste d'adresses IP et à une date d'expiration. 401 signifie que la clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a été envoyée, que la clé n'a pas accès à cette ressource ou action, ou que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur une route de session signifie que la session est hors des workflows ou des statuts de la clé. Une clé sans accès aux médias reçoit les URL d'images, de vidéos et de PDF à null, et une clé sans accès en écriture aux sessions reçoit les liens et tokens de session à null. Voir https://docs.didit.me/console/api-keys.

Paramètres de chemin

sessionId
string<uuid>
requis

UUID de la session de vérification, utilisateur (KYC) ou entreprise (KYB) : le session_id renvoyé par POST /v3/session/. Le serveur le résout pour les deux types de session.

Doit être un UUID valide. La route ne correspond qu'aux UUID bien formés ; une valeur malformée est donc rejetée par le routeur d'URL avant l'exécution de tout code d'application et la réponse est une page HTML 404 plutôt que l'enveloppe JSON {"detail": ...} illustrée ci-dessous.

webhook_uuid
string<uuid>
requis

UUID de la livraison : le uuid d'une entrée renvoyée par GET /v3/session/{sessionId}/webhooks/. Il doit appartenir à la session présente dans le chemin.

Réponse

La livraison, avec ses en-têtes et son corps de requête.

Une tentative de livraison de webhook enregistrée pour une session de vérification, avec les en-têtes et le corps exacts de la requête envoyée par Didit.

uuid
string<uuid>
requis

ID de livraison. Utilisez-le comme {webhook_uuid} pour obtenir ou renvoyer cette livraison.

session_id
string<uuid>
requis

La session à laquelle appartient la livraison (la session indiquée dans le chemin).

request_url
string<uri> | null
requis

URL à laquelle la livraison a été envoyée.

response_status
integer | null
requis

Code d'état HTTP renvoyé par votre endpoint. null tant que la livraison est en file d'attente et n'a pas encore été tentée. Lorsqu'aucune réponse HTTP n'a été reçue, Didit enregistre son propre statut : 504 lorsque votre endpoint n'a pas répondu dans un délai de 5 secondes, 503 en cas d'échec de connexion, 400 lorsque l'URL a été rejetée car non sécurisée (par exemple une adresse privée ou interne), et 404 pour toute autre erreur de requête. Un code supérieur ou égal à 400 est considéré comme une livraison échouée.

status
string | null
requis

Statut de la session lors de la génération de l'événement, par exemple In Progress, Approved ou Declined.

webhook_type
enum<string>
requis

Nom d'événement webhook pris en charge. Utilisez ces chaînes exactes dans subscribed_events ; les valeurs non prises en charge sont rejetées.

Options disponibles:
status.updated,
data.updated,
user.status.updated,
user.data.updated,
business.status.updated,
business.data.updated,
activity.created,
transaction.created,
transaction.status.updated,
travel_rule.status.updated,
workflow.compliance_changed,
transaction_rule_suggestions.created,
auth.signup,
auth.login,
auth.login_failed,
auth.password_reset_requested,
auth.password_reset_completed,
auth.mfa_changed,
auth.new_device,
auth.account_locked,
investigator.report.ready,
investigator.decision.automated,
investigator.decision.overridden,
investigator.decision.contested,
investigator.question.raised,
investigator.automation.paused,
investigator.rfi.answered,
investigator.rfi.overdue,
investigator.drift.detected,
investigator.sla.breached,
investigator.qa.failed,
investigator.external.report.ready
request_header
string
requis

Texte JSON (une chaîne de caractères) des en-têtes de requête envoyés par Didit : Content-Type, X-Signature, X-Signature-V2, X-Signature-Simple, X-Timestamp et User-Agent. Analysez-le avec un parseur JSON. Il contient les signatures, jamais le secret de signature.

request_body
string
requis

Texte JSON (une chaîne de caractères) du payload exact envoyé par Didit, clés triées, comprenant event_id et timestamp. Analysez-le avec un parseur JSON ; voir Format du payload. Pour une clé restreinte sans media: read, les URL de médias qu'il contient sont null ; sans sessions: write, les tokens de session et les liens de vérification hébergés sont null. Un corps modifié de cette manière ne correspond plus à ses signatures. Didit n'enregistre pas le corps de réponse renvoyé par votre endpoint.

created_at
string<date-time>
requis

Date et heure de création de la livraison.

Dernière modification le 7 novembre 2026