Étape 1 : Obtenir vos identifiants
Vous disposez de deux méthodes pour obtenir uneapi_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
- Accédez à la console Didit.
- Créez ou sélectionnez votre organisation.
- Rendez-vous dans Paramètres → API et Webhooks.
- Copiez :
- Clé API — utilisée comme en-tête
x-api-keypour chaque appel de vérification. - Clé secrète du webhook — utilisée pour vérifier les signatures HMAC des webhooks.
- Clé API — utilisée comme en-tête
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
- Accédez à la console Didit → Workflows
- Cliquez sur Créer un workflow
- Choisissez un modèle de base :
- Ajoutez des fonctionnalités optionnelles :
- 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 lesession_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.
Option C : Redirection
Redirigez l’utilisateur vers l’URL de vérification.Option D : WebView mobile
Pour les applications mobiles sans SDK natif.É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 :- Créez une destination de webhook dans la Console (API et Webhooks) ou via
POST /v3/webhook/destinations/avecwebhook_version: "v3"et un tableausubscribed_events(par exemple["status.updated"]) - Conservez la
secret_shared_keyrenvoyée lors de la création — il s’agit du secret HMAC pour toutes les variantes de signature - Implémentez un endpoint de webhook sur votre serveur
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.
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é.
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 :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 pourstatus — 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
- Choisissez votre méthode d’intégration :
- Applications mobiles → SDK natifs
- Applications web → SDK web
- Configurez les webhooks : Webhooks
- Planifiez la capacité : Limites de débit
- Gérez chaque statut : Statuts de vérification
- Personnalisez votre workflow : Workflows
- Vérifiez que l’API est accessible : Vérification de l’état
Besoin d’aide
- Assistance : support@didit.me
- Onboarding programmatique : Inscription programmatique