Passer au contenu principal
POST
cURL

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.

Corps

multipart/form-data
front_image
file
requis

Recto du document d'identité. Extensions autorisées : tiff, jpg, jpeg, png, webp, pdf. Taille maximale de téléversement : 10 MB (les fichiers plus volumineux sont rejetés avec une erreur 400). Les PDF sont convertis en image avant l'OCR ; les PDF chiffrés nécessitent front_image_password. Les images sont automatiquement compressées à ~0.5 MB et l'orientation EXIF est appliquée. Téléversez la capture complète, non recadrée, avec les quatre coins du document visibles.

front_image_password
string
write-only

Mot de passe pour déchiffrer front_image lorsqu'il s'agit d'un PDF chiffré. L'envoi d'un PDF chiffré sans mot de passe (ou avec un mot de passe incorrect) renvoie 400.

back_image
file

Verso du document — envoyez-le chaque fois que le document en comporte un (de nombreuses cartes d'identité portent la MRZ ou un code-barres au verso ; l'omettre laisse simplement les champs de la MRZ et du verso vides dans la réponse — cet endpoint ne déclenche pas d'avertissement pour MRZ manquante). Mêmes formats et limites de taille que pour front_image. S'il est omis, back_image et les champs du verso sont null dans la réponse.

back_image_password
string
write-only

Mot de passe pour déchiffrer back_image lorsqu'il s'agit d'un PDF chiffré.

perform_document_liveness
boolean
défaut:true

Analyse les deux images à la recherche de fraude par présentation : rediffusions d'écran (SCREEN_CAPTURE_DETECTED), copies imprimées (PRINTED_COPY_DETECTED) et manipulation de portrait (PORTRAIT_MANIPULATION_DETECTED). L'un quelconque de ces éléments entraîne un refus automatique. Activé par défaut ; définissez sur false pour ignorer le filtrage de fraude et réduire la latence. Lorsqu'il est activé et que le fournisseur ne renvoie aucun score exploitable, la réponse est In Review avec un avertissement DOCUMENT_LIVENESS_NOT_COMPUTED plutôt que Approved.

Exemple:

true

minimum_age
integer | null

Accepté et validé (1–120) mais actuellement non appliqué par cet endpoint — il ne génère jamais d'avertissement MINIMUM_AGE_NOT_MET à partir de ce champ. Appliquez les règles d'âge à partir de date_of_birth/age renvoyés, ou utilisez un workflow de session de vérification avec des restrictions d'âge.

Plage requise: 1 <= x <= 120
expiration_date_not_detected_action
enum<string>
défaut:NO_ACTION

Ce qu'il faut faire lorsqu'aucune date d'expiration ne peut être lue (EXPIRATION_DATE_NOT_DETECTED). Par défaut NO_ACTION, car de nombreux documents d'identité n'affichent pas de date d'expiration. Remarque : une date d'expiration détectée et dépassée entraîne toujours un refus (DOCUMENT_EXPIRED), quelle que soit cette option.

Options disponibles:
NO_ACTION,
DECLINE
invalid_mrz_action
enum<string>
défaut:DECLINE

Que faire lorsque la MRZ extraite échoue à la validation de la clé de contrôle (MRZ_VALIDATION_FAILED). Une MRZ manquante ne génère aucun avertissement sur cet endpoint. Pertinent uniquement pour les documents comportant une MRZ. REVIEW n'est pas pris en charge sur cet endpoint et renvoie 400.

Options disponibles:
NO_ACTION,
DECLINE
inconsistent_data_action
enum<string>
défaut:DECLINE

Ce qu'il faut faire lorsque les données extraites sont incohérentes en interne : DATA_INCONSISTENT, MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME (la zone visuelle ne concorde pas avec la MRZ), ou DOCUMENT_NAME_DIFFERENT_FROM_OTHER_APPROVED_DOCUMENTS.

Options disponibles:
NO_ACTION,
DECLINE
critical_field_occlusion_action
enum<string>
défaut:DECLINE

Ce qu'il faut faire lorsqu'un champ imprimé critique a été physiquement masqué sur la capture (CRITICAL_FIELD_OCCLUSION_DETECTED) - un numéro d'identité, un nom, la date de naissance ou la date d'expiration. Entraîne un refus par défaut, comme les autres risques d'intégrité documentaire de cet endpoint : masquer les numéros sur lesquels un rapport est réconcilié correspond à ce à quoi ressemble un document caviardé. La valeur lue pour un champ masqué est supprimée de l'extraction dans tous les cas, de sorte que l'avertissement *_NOT_DETECTED correspondant l'accompagne généralement. REVIEW n'est pas pris en charge sur cet endpoint et renvoie 400.

Options disponibles:
NO_ACTION,
DECLINE
document_or_personal_number_format_mismatch_action
enum<string>
défaut:NO_ACTION

Ce qu'il faut faire lorsqu'un numéro ne correspond pas au format utilisé par son autorité émettrice pour ce type de document (DOCUMENT_NUMBER_FORMAT_MISMATCH, PERSONAL_NUMBER_FORMAT_MISMATCH). Par défaut NO_ACTION, ce qui signale l'avertissement sans modifier le statut. REVIEW n'est pas pris en charge sur cet endpoint et renvoie 400.

Options disponibles:
NO_ACTION,
DECLINE
preferred_characters
enum<string>
défaut:latin

Système d'écriture préféré pour les champs de nom/adresse sur les documents comportant à la fois du texte latin et non latin (arabe, cyrillique, CJK, …). latin renvoie des valeurs translittérées/latines ; non_latin privilégie le système d'écriture natif.

Options disponibles:
latin,
non_latin
save_api_request
boolean
défaut:true

Lorsque la valeur est true (par défaut), conserve l'appel sous la forme d'une session de type API — visible dans la Business Console, récupérable via GET /v3/session/{sessionId}/decision/ à l'aide du request_id renvoyé, notifiée via un webhook status.updated, et avec les images du document renvoyées sous forme d'URL de médias. Lorsque la valeur est false, rien n'est stocké, request_id est un UUID éphémère et les images sont renvoyées en ligne sous forme de chaînes JPEG en base64.

Exemple:

true

vendor_data
string

Chaîne opaque optionnelle (votre identifiant d'utilisateur interne, e-mail, UUID…) stockée sur la session persistée et renvoyée dans la réponse. Utilisez-la pour corréler les appels d'API avec vos propres enregistrements et pour filtrer les sessions ultérieurement.

Exemple:

"user-123"

metadata
object

Objet JSON optionnel stocké avec la session (lorsque save_api_request=true) et renvoyé dans la réponse. Dans les requêtes multipart, envoyez-le sous forme de champ textuel encodé en JSON (par ex. metadata={"flow":"onboarding"}) — il est analysé sous forme d'objet.

Exemple:

Réponse

Document traité. id_verification.status est Approved, Declined ou In Review ; chaque problème détecté est détaillé dans id_verification.warnings. In Review est renvoyé lorsqu'une vérification demandée de détection du vivant du document n'a produit aucun résultat exploitable (DOCUMENT_LIVENESS_NOT_COMPUTED). Un document problématique renvoie tout de même 200 avec status: "Declined" — inspectez le corps de la réponse, pas seulement le code HTTP. Lorsque save_api_request=true, request_id est l'identifiant de la session enregistrée et les champs d'image sont des URL de médias de courte durée ; avec save_api_request=false, ce sont des chaînes JPEG en base64 intégrées.

request_id
string<uuid>

Identifiant de session persistante lorsque save_api_request=true (utilisable avec GET /v3/session/{sessionId}/decision/) ; sinon un UUID de corrélation temporaire.

id_verification
object
vendor_data
string | null

Écho des vendor_data que vous avez envoyées, ou null.

metadata
object | null

Écho de l'objet metadata que vous avez envoyé, ou null.

created_at
string<date-time>

Horodatage ISO 8601 (UTC) du moment où la réponse a été générée.

Dernière modification le 7 novembre 2026