Passer au contenu principal
Ce guide vous présente le flux complet pour intégrer la vérification d’identité Didit via l’API REST : obtenir des identifiants, créer une session, la présenter à l’utilisateur et recevoir les résultats.

Étape 1 : Obtenir vos identifiants

Vous disposez de deux méthodes pour obtenir une api_key :

Option A : Inscription programmatique (sans navigateur)

Idéale pour le CI/CD et les agents IA. Deux appels API — POST /programmatic/register/ puis POST /programmatic/verify-email/ — renvoient directement l’api_key. → Consultez Inscription programmatique pour le flux complet, les règles de mot de passe, la durée de validité du JWT et la politique de verrouillage.

Option B : Depuis la console Didit

  1. Accédez à la console Didit.
  2. Créez ou sélectionnez votre organisation.
  3. Rendez-vous dans Paramètres → API et Webhooks.
  4. Copiez :
    • Clé API — utilisée comme en-tête x-api-key pour chaque appel de vérification.
    • Clé secrète du webhook — utilisée pour vérifier les signatures HMAC des webhooks.

Variables d’environnement


Étape 2 : Créer un workflow

Avant de créer des sessions, vous avez besoin d’un workflow de vérification. Les workflows définissent les étapes de vérification que les utilisateurs doivent suivre.

Créer dans la console

  1. Accédez à la console Didit → Workflows
  2. Cliquez sur Créer un workflow
  3. Choisissez un modèle de base :
  1. Ajoutez des fonctionnalités optionnelles :
  1. Copiez votre ID du workflow
Consultez la documentation des workflows pour découvrir les options de configuration détaillées.

Étape 3 : Créer une session de vérification

Appelez l’API pour créer une session pour votre utilisateur.

Requête

Paramètres de requête

Exemple complet avec toutes les options

expected_details.expected_document_types restreint l’étape de vérification d’identité à des types de documents spécifiques — l’écran de sélection de documents n’affiche que les types demandés. Valeurs autorisées : P (passeport), ID (carte nationale d’identité), DL (permis de conduire), RP (titre de séjour), HIC (carte d’assurance maladie), TC (carte fiscale), SSC (carte de sécurité sociale). Les valeurs sont insensibles à la casse et dédupliquées ; les valeurs inconnues renvoient 400. Consultez la Référence de création de session pour le schéma complet.

Réponse

201 Created :

Champs clés de la réponse

Idempotence. Lorsque vendor_data est fourni et qu’une session inachevée (Not Started, In Progress, Resubmitted ou Awaiting User) avec le même vendor_data existe déjà sur la dernière version publiée du workflow, cette session existante est renvoyée (toujours en 201) au lieu d’en créer une en double — avec son callback et ses metadata mis à jour avec les nouvelles valeurs, et son status reflétant la session existante.
Un x-api-key manquant renvoie 403 avec {"detail": "You do not have permission to perform this action."}, le même corps qu’une clé valide sans autorisation. Une clé incorrecte, révoquée ou expirée renvoie 401. Des crédits insuffisants renvoient 400. Consultez la Référence de l’API de création de session pour la documentation complète.

Étape 4 : Présenter la vérification à l’utilisateur

Choisissez la façon de présenter le parcours de vérification à votre utilisateur :

Option A : SDK natif (recommandé pour mobile)

Utilisez le session_token avec les SDK natifs pour l’intégration de la caméra, du NFC et de la biométrie. → SDK iOS · SDK Android · React Native · Flutter

Option B : iframe InContext (recommandé pour le web)

Intégrez la vérification dans votre page à l’aide de l’url renvoyée à l’Étape 3.
→ iframe InContext

Option C : Redirection

Redirigez l’utilisateur vers l’URL de vérification.
→ Redirection web

Option D : WebView mobile

Pour les applications mobiles sans SDK natif.
→ WebView sur iOS/Android

Étape 5 : Recevoir les résultats

Par webhook (recommandé)

Les webhooks avertissent votre serveur en temps réel lorsque le statut de la vérification change. Configuration :
  1. Créez une destination de webhook dans la Console (API et Webhooks) ou via POST /v3/webhook/destinations/ avec webhook_version: "v3" et un tableau subscribed_events (par exemple ["status.updated"])
  2. Conservez la secret_shared_key renvoyée lors de la création — il s’agit du secret HMAC pour toutes les variantes de signature
  3. Implémentez un endpoint de webhook sur votre serveur
Exemple de payload de webhook : À l’intérieur de decision, chaque résultat par fonctionnalité est fourni sous la forme d’un tableau au pluriel (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …) — une entrée par nœud dans le workflow. Il s’agit du contrat V3 et il est fondamental : ne développez jamais votre logique autour d’une clé au singulier comme nfc / id_verification / liveness.
L’objet decision n’est présent que lorsque status est Approved, Declined, In Review ou Abandoned (un événement Resubmitted contient resubmit_info à la place). Didit réutilise le même event_id pour les tentatives de relance et les destinations multiples — basez votre idempotence dessus. Consultez Modèles de données pour connaître l’ensemble des tableaux au pluriel et des champs. Vérifier la signature (X-Signature-V2, recommandé) : X-Signature-V2 est un HMAC-SHA256 calculé sur un réencodage canonique du corps JSON : flottants à valeur entière réduits en entiers, clés triées récursivement, séparateurs compacts, Unicode préservé.
→ Documentation complète des webhooks, incluant X-Signature sur les octets bruts, X-Signature-Simple obsolète sur l’enveloppe seule, et comment choisir. Didit réessaie les livraisons ayant échoué (5xx, 404, délai d’expiration) jusqu’à 2 fois (~1 min, puis ~4 min) et le délai d’expiration est de 5 secondes — renvoyez un code 2xx rapidement.

Par API (optionnel)

Récupérez le même payload de décision à tout moment :
La structure de la réponse (tableaux au pluriel) est identique à celle de l’objet decision contenu dans le payload du webhook, et l’endpoint peut être appelé à n’importe quel moment du cycle de vie de la session. Utilisez les webhooks pour les mises à jour en temps réel et réservez les appels d’API pour la récupération rétroactive des données, les audits et les reconstructions — l’endpoint /decision/ est soumis à une limite de débit de 600 requêtes GET/min par clé API (voir Limites de débit). Sémantique des erreurs : un session_id inconnu renvoie un 404 avec {"detail": "Not found."} ; les échecs d’authentification se traduisent par un 403 — cet endpoint ne renvoie jamais 401. Les URL des médias dans la réponse sont des liens pré-signés à courte durée de vie — récupérez-les rapidement plutôt que de les stocker durablement. → Référence de l’API de récupération de session

Exemples de code complets

Node.js / Express

Python / FastAPI


Statuts de session

Voici les 10 valeurs possibles pour status — des chaînes de caractères exactes et sensibles à la casse (notez que Kyc Expired n’utilise qu’un seul K majuscule) : Consultez Statuts de vérification pour découvrir le cycle de vie complet, les transitions et le diagramme Mermaid.

Prochaines étapes

  1. Choisissez votre méthode d’intégration :
  2. Configurez les webhooks : Webhooks
  3. Planifiez la capacité : Limites de débit
  4. Gérez chaque statut : Statuts de vérification
  5. Personnalisez votre workflow : Workflows
  6. Vérifiez que l’API est accessible : Vérification de l’état

Besoin d’aide

Dernière modification le 7 novembre 2026