Webhooks d'entités : événements utilisateur et entreprise

Chaque modification du statut ou des données de profil d’une entité User ou Business émet un webhook, afin que votre système puisse réagir en temps réel. Utilisez les webhooks d’entité pour synchroniser les données de profil, propager les blocages vers d’autres systèmes ou déclencher des flux de conformité en aval.

Catalogue des événements

Événement	Déclencheur
`user.status.updated`	Le statut d’une entité User change (`ACTIVE` ↔ `FLAGGED` ↔ `BLOCKED`)
`user.data.updated`	Les champs de profil d’une entité User changent (nom, date de naissance, portrait, compteurs agrégés, métadonnées)
`business.status.updated`	Le statut d’une entité Business change
`business.data.updated`	Les champs de profil d’une entité Business changent (raison sociale, numéro d’immatriculation, pays, compteurs)

activity.created est accepté dans subscribed_events et couvert par le testeur Try Webhook, mais Didit ne le livre pas actuellement pour le trafic en production. Ne construisez pas de réplication de la chronologie à partir de cet événement.

Didit émet aussi des événements de session, de transaction et de session entreprise qui référencent des champs d’entité. Voir :

Webhooks KYB : événements de session d’entreprise
Webhooks de surveillance des transactions : événements de transaction
Référence des webhooks : vérification de signature, réessais, destinations

Structure des payloads

Les payloads des webhooks d’entité sont à plat : il n’y a ni wrapper data ni clé event. Lisez webhook_type pour router l’événement.

{
  "event_id": "7f3c2c1e-6a1d-4c36-9d8e-0d3b5f4e2a10",
  "webhook_type": "user.status.updated",
  "timestamp": 1776333600,
  "created_at": 1776333594,
  "application_id": "0c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f",
  "environment": "live",
  "vendor_user_id": "9c7d2a30-2f98-4d4f-9d2d-1a7c4b1e5b6a",
  "vendor_data": "user-42",
  "status": "BLOCKED",
  "previous_status": "ACTIVE"
}

Champ	Description
`vendor_user_id` / `vendor_business_id`	Identifiant Didit de l’entité. Les événements `business.*` utilisent `vendor_business_id`.
`vendor_data`	Votre identifiant pour l’entité.
`status`	`ACTIVE`, `FLAGGED` ou `BLOCKED`.
`previous_status`	Uniquement sur `*.status.updated`.
`changed_fields` et `changes`	Uniquement sur `*.data.updated`.
`created_at`	Secondes Unix de la dernière mise à jour de l’entité.
`timestamp`	Secondes Unix auxquelles Didit a envoyé le webhook.

`user.status.updated` / `business.status.updated`

Déclenché à chaque changement de statut. Le payload contient status et previous_status. Il n’indique pas la raison du changement de statut : ouvrez l’entité dans la console si vous avez besoin de la cause.

`user.data.updated` / `business.data.updated`

Déclenché lorsque des champs de profil changent. changed_fields liste les champs modifiés et changes contient les valeurs previous et current de chacun.

{
  "event_id": "5d1e8f9a-0c32-4b6a-a7b6-2b9d6f0a3c41",
  "webhook_type": "user.data.updated",
  "timestamp": 1776333700,
  "created_at": 1776333694,
  "application_id": "0c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f",
  "environment": "live",
  "vendor_user_id": "9c7d2a30-2f98-4d4f-9d2d-1a7c4b1e5b6a",
  "vendor_data": "user-42",
  "status": "ACTIVE",
  "changed_fields": ["full_name", "session_count"],
  "changes": {
    "full_name": { "previous": null, "current": "John Doe" },
    "session_count": { "previous": 2, "current": 3 }
  }
}

Les champs susceptibles d’apparaître dans changed_fields sont :

User : vendor_data, display_name, full_name, date_of_birth, metadata, portrait_image, issuing_states, approved_emails, approved_phones, features, session_count, approved_count, declined_count, in_review_count, first_session_at, last_session_at.
Business : vendor_data, display_name, metadata, legal_name, registration_number, country_code, session_count, approved_count, declined_count, in_review_count, features, first_session_at, last_session_at.

Utilisez changed_fields et changes pour ne synchroniser que les champs modifiés.

Livraison, réessais et signature

Tous les webhooks d’entité suivent le contrat de livraison standard :

Signé avec HMAC-SHA256 dans l’en-tête X-Signature-V2 (recommandé), avec le secret_shared_key de la destination. X-Signature et l’ancien X-Signature-Simple, obsolète, sont également envoyés, ainsi que X-Timestamp.
Réessayé jusqu’à 2 fois, après environ 1 minute puis environ 4 minutes, lorsque votre endpoint répond 5xx ou 404, dépasse le délai d’attente ou ne parvient pas à établir la connexion. La référence des webhooks détaille la politique complète.
Idempotence : chaque webhook possède un event_id unique dans le payload ; dédoublonnez de votre côté.

Voir Référence des webhooks pour la configuration de la destination et des exemples de code de vérification de signature.

Abonnement

Abonnez-vous aux événements d’entité sur une destination de webhook via l’API de gestion ou la Business Console :

curl -X POST https://verification.didit.me/v3/webhook/destinations/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Entity sync",
    "url": "https://yourapp.com/webhooks/didit",
    "subscribed_events": [
      "user.status.updated",
      "user.data.updated",
      "business.status.updated",
      "business.data.updated"
    ]
  }'

Étapes suivantes

Référence des webhooks

Destinations, signatures, réessais et vérification.

Créer une destination

Enregistrez un nouvel endpoint de webhook.

Opérations sur les utilisateurs

Modifications qui déclenchent les webhooks utilisateur.

Présentation

Tarifs

Workflows et vérification

Examen et opérations

Entités (utilisateurs et entreprises)

Paramètres et personnalisation

Sécurité et conformité

Didit Academy

Ressources

Webhooks d'entités : événements utilisateur et entreprise

Catalogue des événements

Structure des payloads

`user.status.updated` / `business.status.updated`

`user.data.updated` / `business.data.updated`

Livraison, réessais et signature

Abonnement

Étapes suivantes

Référence des webhooks

Créer une destination

Opérations sur les utilisateurs

​Catalogue des événements

​Structure des payloads

​user.status.updated / business.status.updated

​user.data.updated / business.data.updated

​Livraison, réessais et signature

​Abonnement

​Étapes suivantes

Référence des webhooks

Créer une destination

Opérations sur les utilisateurs

Catalogue des événements

Structure des payloads

`user.status.updated` / `business.status.updated`

`user.data.updated` / `business.data.updated`

Livraison, réessais et signature

Abonnement

Étapes suivantes