Commencer
Intégrer / SDK
Vérification des utilisateurs
Vérification d'entreprise
Surveillance des transactions
Journal des modificationscurl -X GET 'https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/decision/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Accept: application/json'from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.retrieve_decision(
"11111111-2222-3333-4444-555555555555",
)
print(result)import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await didit.sessions.retrieveDecision("11111111-2222-3333-4444-555555555555");
console.log(result);ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()
result, err := client.Sessions.RetrieveDecision(ctx, "11111111-2222-3333-4444-555555555555", didit.SessionsRetrieveDecisionParams{})
if err != nil {
log.Fatal(err)
}
fmt.Printf("%+v\n", result)import me.didit.Didit;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result = client.sessions().retrieveDecision("11111111-2222-3333-4444-555555555555");
System.out.println(result);<?php
require 'vendor/autoload.php';
use Didit\DiditClient;
// Reads DIDIT_API_KEY.
$didit = new DiditClient();
$result = $didit->sessions->retrieveDecision('11111111-2222-3333-4444-555555555555');
print_r($result->toArray());require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.retrieve_decision("11111111-2222-3333-4444-555555555555")
puts result.to_husing System;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await client.Sessions.RetrieveDecisionAsync("11111111-2222-3333-4444-555555555555");
Console.WriteLine(JsonSerializer.Serialize(result));API de récupération de session : décisions KYC et KYB
Récupérez les décisions KYC ou KYB complètes avec Didit : identité, vivacité, AML, registre et OCR en une réponse, en 2s. Paiement à l’appel.
curl -X GET 'https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/decision/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Accept: application/json'from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.retrieve_decision(
"11111111-2222-3333-4444-555555555555",
)
print(result)import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await didit.sessions.retrieveDecision("11111111-2222-3333-4444-555555555555");
console.log(result);ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()
result, err := client.Sessions.RetrieveDecision(ctx, "11111111-2222-3333-4444-555555555555", didit.SessionsRetrieveDecisionParams{})
if err != nil {
log.Fatal(err)
}
fmt.Printf("%+v\n", result)import me.didit.Didit;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result = client.sessions().retrieveDecision("11111111-2222-3333-4444-555555555555");
System.out.println(result);<?php
require 'vendor/autoload.php';
use Didit\DiditClient;
// Reads DIDIT_API_KEY.
$didit = new DiditClient();
$result = $didit->sessions->retrieveDecision('11111111-2222-3333-4444-555555555555');
print_r($result->toArray());require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.retrieve_decision("11111111-2222-3333-4444-555555555555")
puts result.to_husing System;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await client.Sessions.RetrieveDecisionAsync("11111111-2222-3333-4444-555555555555");
Console.WriteLine(JsonSerializer.Serialize(result));Prise en charge KYC et KYB
Cet endpoint fonctionne pour les sessions de Vérification des utilisateurs (KYC) et de Vérification d’entreprise (KYB). La réponse contient toujours un champ de premier niveausession_kind :
"user": session de Vérification des utilisateurs (KYC). La réponse contientid_verifications,liveness_checks,face_matches,nfc_verifications,poa_verifications,database_validations."business": session de Vérification d’entreprise (KYB). La réponse contientregistry_checks,document_verifications,key_people_checks.
aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews, contact_details, ainsi que les champs communs de premier niveau (session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at, expires_at).
Didit résout le session_id pour les deux types de session (Vérification des utilisateurs d’abord, Vérification d’entreprise ensuite) et renvoie celle qui correspond. Les UUID sont uniques par application : il n’y a donc aucune ambiguïté.
Consultez l’aperçu des sessions pour le tableau complet des fonctionnalités propres à chaque type.
Exemples
- Vérification des utilisateurs (KYC)
- Vérification d'entreprise (KYB)
curl https://verification.didit.me/v3/session/4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a/decision/ \
-H "x-api-key: YOUR_API_KEY"
{
"session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
"session_kind": "user",
"session_number": 1024,
"session_url": "https://verify.didit.me/...",
"status": "APPROVED",
"workflow_id": "wf_kyc_standard",
"vendor_data": "user-42",
"features": "ID_VERIFICATION,LIVENESS,FACE_MATCH,AML",
"id_verifications": [
{ "node_id": "feature_ocr_1", "status": "Approved", "document_type": "Passport", "full_name": "John Doe", "barcodes": [], "...": "..." }
],
"liveness_checks": [
{ "node_id": "feature_liveness_1", "status": "Approved", "score": 0.98 }
],
"face_matches": [
{ "node_id": "feature_face_match_1", "status": "Approved", "score": 0.94 }
],
"aml_screenings": [
{ "node_id": "feature_aml_1", "status": "Approved", "total_hits": 0, "score": 0 }
],
"phone_verifications": [],
"email_verifications": [],
"questionnaire_responses": [],
"ip_analyses": [],
"reviews": [],
"contact_details": { "email": "alex.sample@example.com", "phone": null },
"expected_details": null,
"metadata": {},
"callback": null,
"created_at": "2026-04-16T10:00:00Z",
"expires_at": "2026-04-23T10:00:00Z"
}
curl https://verification.didit.me/v3/session/bs-01HJX1.../decision/ \
-H "x-api-key: YOUR_API_KEY"
{
"session_id": "bs-01HJX1...",
"session_kind": "business",
"session_number": 89,
"session_url": "https://verify.didit.me/...",
"status": "APPROVED",
"workflow_id": "wf_kyb_standard",
"vendor_data": "biz-acme-001",
"features": ["KYB_REGISTRY", "KYB_COMPANY_AML", "KYB_DOCUMENTS", "KYB_KEY_PEOPLE"],
"registry_checks": [
{
"status": "Approved",
"node_id": "feature_kyb_registry",
"data_resolved": true,
"company": {
"uuid": "...",
"node_id": "feature_kyb_registry",
"status": "Approved",
"registry_status": "active",
"company_name": "Acme Corporation Limited",
"registration_number": "12345678",
"country_code": "GBR",
"company_type": "Private Limited",
"incorporation_date": "2010-05-14",
"registered_address": "1 Main Street, London EC1A 1AA, United Kingdom",
"tax_number": "SAMPLE-TAX-12345",
"risk_level": "LOW",
"verification_status": "verified",
"is_from_registry": true,
"fetch_status": "resolved",
"alternative_names": ["Acme Ltd"],
"nature_of_business": "Software publishing",
"registered_capital": "100000 GBP",
"website": "https://acme.example",
"email": "alex.sample@example.com",
"phone": "+15550101000",
"legal_entity_identifier": "529900XXXXXXXXXXXXX",
"financial_summary": {},
"officers": [
{ "uuid": "...", "name": "Jane Doe", "role": "director", "nationality": "USA", "is_active": true, "kyc_status": "Approved", "kyc_session_url": "https://verify.didit.me/..." }
],
"beneficial_owners": [
{ "uuid": "...", "name": "John Smith", "entity_type": "person", "roles": ["ubo"], "ownership_min_shares": 40, "ownership_max_shares": 40, "kyc_status": "Pending", "effective_ownership_percent": 40.0 }
],
"addresses": [],
"industries": [],
"accounts": [],
"registry_data": { },
"user_provided_data": { },
"confirmed_by_user_at": "2026-04-16T10:10:00Z",
"is_editable": false
},
"ownership_structure": { },
"warnings": []
}
],
"aml_screenings": [
{
"node_id": "feature_kyb_company_aml",
"status": "Approved",
"total_hits": 0,
"score": 0,
"entity_type": "COMPANY",
"hits": []
}
],
"document_verifications": [
{
"status": "Approved",
"node_id": "feature_kyb_documents",
"items": [
{ "uuid": "...", "document_type": "certificate_of_incorporation", "status": "Approved", "file_url": "https://...", "ocr_data": { } }
],
"groups": { "legal_presence": { "approved": 1, "pending": 0, "missing": 0 } },
"required_groups": ["legal_presence", "ownership_structure"],
"warnings": []
}
],
"key_people_checks": [
{
"status": "Approved",
"node_id": "feature_kyb_key_people",
"officers": [
{ "uuid": "...", "name": "Jane Doe", "role": "director", "kyc_status": "Approved", "kyc_session_url": "..." }
],
"beneficial_owners": [
{ "uuid": "...", "name": "John Smith", "roles": ["ubo"], "ownership_min_shares": 40, "ownership_max_shares": 40, "kyc_status": "Pending" }
],
"registry": {
"officers": [
{ "uuid": "...", "name": "Jane Doe", "role": "director", "kyc_status": "Approved" }
],
"beneficial_owners": [
{ "uuid": "...", "name": "John Smith", "roles": ["ubo"], "ownership_min_shares": 40, "kyc_status": "Pending" }
]
},
"submitted": {
"parties": [
{ "uuid": "...", "entity_type": "person", "name": "Alice Chen", "role": "ubo", "ownership_percent": 35.0, "requires_verification": true, "kyc_session_status": "Not Started", "kyc_session_url": "https://verify.didit.me/..." }
]
},
"ubo_kyc_summary": {
"total": 2,
"approved": 1,
"flagged": 0,
"pending": 1
},
"warnings": []
}
],
"phone_verifications": null,
"email_verifications": null,
"questionnaire_responses": null,
"ip_analyses": null,
"reviews": [],
"contact_details": { "email": "alex.sample@example.com", "email_lang": "en", "send_notification_emails": true, "phone": null },
"expected_details": null,
"metadata": {},
"callback": null,
"created_at": "2026-04-16T10:00:00Z",
"expires_at": "2026-04-23T10:00:00Z"
}
Traitement de la réponse de votre côté
const res = await fetch(`${BASE}/v3/session/${sessionId}/decision/`, {
headers: { "x-api-key": API_KEY },
});
const decision = await res.json();
switch (decision.session_kind) {
case "user":
handleUserDecision(decision);
break;
case "business":
handleBusinessDecision(decision);
break;
}
Statut, trace de décision et champs d’examen
Chaque décision indique comment sonstatus a été déterminé.
| Champ | Ce qu’il faut lire |
|---|---|
status_override | null lorsque le statut est celui calculé automatiquement. Lorsqu’un réviseur a défini le statut manuellement, il vaut { overridden_at, automatic_status }, où automatic_status correspond au résultat des contrôles. Utilisez-le pour distinguer une approbation manuelle d’une approbation automatique. |
decision_trace | status, decided_by (manual, automatic ou investigator ; null tant que la session n’est pas décidée), decided_at, automatic_status, terminal_node_id, actor (le réviseur à l’origine d’une décision manuelle), warning_counts par log_type plus total, et status_warnings, les avertissements qui ont fixé un statut Declined ou In Review. |
linked_records | Un résumé des autres éléments auxquels la vérification est liée : same_face (les autres personnes dont le visage correspond, et la correspondance la plus proche), earlier_verifications (le nombre de vérifications antérieures pour la même personne) et networks. null lorsqu’il n’y a rien à afficher. |
assignee, waiting_since, sla_due_at | Le réviseur de la Console chargé de la session, depuis quand elle est en attente et l’échéance de l’examen. waiting_since et sla_due_at valent null sauf si la session est In Review et que votre application définit une échéance de revue. |
database_validation_not_performed_reason | { code, message } expliquant pourquoi une Validation en base de données configurée n’a produit aucun résultat. Il permet de distinguer « le registre a confirmé » de « rien n’a été exécuté » lorsque database_validations vaut null. |
shared_from_session, shared_from_session_number | La session source lorsque celle-ci a été importée avec POST /v3/session/import-shared/ ; null sinon. |
sandbox_scenario | Le scénario avec lequel une session sandbox a été créée. |
full_session_video, full_session_video_recorded_at | Une URL temporaire de l’enregistrement et la date de sa création. Renvoyés uniquement si votre organisation enregistre la vidéo de la session complète. |
Conservation des données biométriques
biometric_retention est toujours présent. deletes_at correspond à la date à laquelle les données biométriques actives de la session sont supprimées, et jurisdictions liste les États américains dont les règles biométriques fixent une limite de suppression pour la personne (US lorsque l’État est inconnu). deletes_at vaut null lorsqu’aucune date ne s’applique encore.
Vérification de la localisation
Lorsque le workflow comporte une étape de Vérification de la localisation, la décision contient deux tableaux.geolocation_checks[] contient un élément par étape : sa tentative acceptée, avec le résultat, les coordonnées et leur précision, les contrôles par rapport à la localisation IP et à l’adresse enregistrée, et les warnings de l’étape. geolocation_attempts[] liste chaque tentative de chaque étape, de la plus ancienne à la plus récente, avec la date de réception de chacune. Les workflows sans cette étape renvoient null pour les deux. Chaque champ et chaque résultat figure dans le rapport de vérification de la localisation.
Événements de routage du workflow
?include=events ajoute la chronologie des événements de la session. En plus des changements d’étape et de statut, un workflow qui passe par des nœuds de branchement enregistre un événement pour chaque décision de routage. Une intégration (ou la chronologie de la Console) peut ainsi expliquer pourquoi une session s’est terminée sur un résultat donné, sans reconstituer le graphe du workflow à la main.
event_type | Moment d’écriture | details |
|---|---|---|
WORKFLOW_BRANCH_EVALUATED | Un nœud doté de conditions de branchement a été évalué pendant la progression de la session (nœuds de branchement, ainsi que nœuds de fonctionnalité ou de webhook dotés de branches) | node_id, node_label, node_type, matched_branch_id (la branche retenue, ou null si aucune ne l’a été), fallback (true lorsqu’aucune condition n’a été remplie et que la transition par défaut du nœud a été empruntée), next_node_id, next_node_label |
WORKFLOW_STATUS_NODE_REACHED | Un nœud de statut a été exécuté | node_id, node_label, session_status (la valeur configurée, y compris Determine), resolved_session_status (la valeur obtenue), feature_statuses ([{target, status}]) |
sent_at en millisecondes, comme tous les autres événements, et n’ont ni component, ni feature_step, ni step : ils proviennent du moteur de workflow et non de l’appareil de l’utilisateur. Une branche « else » (une branche sans condition) compte comme une branche retenue ; fallback n’est true que si aucune branche n’a été retenue. Les nœuds qui ne disposent que d’une seule transition sortante ne prennent aucune décision et n’écrivent aucun événement.
La même structure renvoie aussi workflow_terminal_node_id : le node_id du dernier nœud de statut du workflow enregistré qui a défini un statut de session, ou null si aucun identifiant de nœud de ce type n’a été enregistré. Il s’agit d’une trace historique de l’origine du workflow. Les approbations, refus et nouvelles soumissions effectués manuellement ne l’effacent pas ; un nœud de statut de workflow ultérieur le remplace. Par exemple, si un workflow envoie une session vers un nœud En cours d’examen, puis qu’un réviseur l’approuve plus tard, le status actuel est Approved, tandis que workflow_terminal_node_id identifie toujours le nœud En cours d’examen. Il peut aussi rester renseigné pendant qu’une nouvelle soumission est en cours. Pour distinguer les résultats du workflow des décisions manuelles ultérieures, lisez le status actuel, la chronologie des événements et celle de activity_reviews.
{
"event_type": "WORKFLOW_BRANCH_EVALUATED",
"sent_at": 1789336414007,
"details": {
"node_id": "branch-d57da8aa",
"node_label": "Credential required?",
"node_type": "branch",
"matched_branch_id": null,
"fallback": true,
"next_node_id": "status-6ba0bd0d",
"next_node_label": "In Review"
}
}
Soumissions antérieures (?include=resubmissions)
Une nouvelle soumission renvoie l’utilisateur vers les étapes que vous sélectionnez et conserve ce que ces étapes ont renvoyé auparavant.
?include=resubmissions ajoute un tableau resubmissions, du plus ancien au plus récent, avec une entrée par demande de nouvelle soumission.
Chaque entrée contient les résultats que cette demande a remplacés, afin que vous puissiez toujours consulter ce que l’utilisateur a soumis précédemment.
Cela fonctionne pour les sessions utilisateur (KYC) et entreprise (KYB), et vous pouvez le combiner avec les événements (?include=events,resubmissions).
Sans ce paramètre, la réponse ne change pas.
| Champ | Description |
|---|---|
number | 1 pour la première nouvelle soumission de la session, 2 pour la deuxième, et ainsi de suite. |
created_at | Moment où la nouvelle soumission a été demandée. |
previous_status | Statut de la session juste avant la demande. |
nodes | Les étapes du workflow renvoyées à l’utilisateur ([{node_id, feature}]). |
reasons | Le motif donné pour chaque étape, indexé par node_id, ou null. |
requested_by | La personne qui a fait la demande (name, email, type), ou null. |
results | Ce que ces étapes ont renvoyé avant la demande, sous les mêmes clés et dans la même forme que les résultats actuels (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, phone_verifications, email_verifications, aml_screenings, ip_analyses, database_validations, questionnaire_responses, document_ai_documents, geolocation_checks ; pour les sessions entreprise, également document_verifications). Seules apparaissent les clés des étapes qui ont été renvoyées. |
id_verifications et les autres au premier niveau) décrivent toujours la dernière soumission.
Les étapes qui n’ont pas été renvoyées conservent un seul résultat à cet endroit.
{
"status": "In Review",
"id_verifications": [{ "node_id": "feature_ocr", "status": "Approved" }],
"resubmissions": [
{
"number": 1,
"created_at": "2026-10-01T08:31:04.512Z",
"previous_status": "In Review",
"nodes": [{ "node_id": "feature_ocr", "feature": "OCR" }],
"reasons": { "feature_ocr": "Passport photo too blurry" },
"requested_by": { "name": "<reviewer name>", "email": "<reviewer email>", "type": "USER" },
"results": {
"id_verifications": [
{
"node_id": "feature_ocr",
"status": "Declined",
"warnings": [{ "risk": "IMAGE_TOO_BLURRY", "log_type": "error" }]
}
]
}
}
]
}
Méthodes de vérification d’identité
Chaque élément deid_verifications[] indique laquelle des trois méthodes de vérification d’identité l’a produit. Vous pouvez ainsi distinguer une lecture de document d’une consultation de registre ou d’une connexion par portefeuille, sans deviner à partir des champs qui se trouvent être renseignés :
| Champ | Valeur |
|---|---|
verification_method | document, id_lookup ou wallet |
assurance | documentary, data_match ou cryptographic |
wallet_provider | Identifiant du portefeuille du catalogue lorsqu’un portefeuille a produit le résultat, sinon null |
id_lookup | Preuves issues du registre (source, tentatives, comparaison champ par champ, portrait du registre), ou null |
wallet_verification | Preuves de l’identifiant numérique (fournisseur, autorité émettrice, niveau d’assurance, validité de la signature, attributs partagés), ou null |
fallback_from | Raison pour laquelle une méthode autre que le document n’a pas mis fin à l’étape d’identité : la méthode, le motif, et si l’utilisateur a basculé vers la capture de document ou a été refusé |
document et documentary et laisse les autres champs à null, de sorte que les intégrations existantes n’ont aucune modification à faire. Le type de chaque champ est détaillé dans Modèles de données.
Consentement biométrique
Les décisions de vérification des utilisateurs contiennent un objetbiometric_consent : il indique si la session exigeait un consentement biométrique explicite, le trigger qui l’a exigé, le status de la réponse et ses preuves. Deux valeurs indiquent que le consentement n’a pas été recueilli :
| Champ | Valeur | Signification |
|---|---|---|
status + reason | pending + BIOMETRIC_CONSENT_UNSUPPORTED_SDK | Un SDK natif antérieur à 4.10.0, ou un SDK qui n’a pas signalé sa version, a capturé un visage sans l’étape de consentement. La session s’est déroulée comme auparavant. |
status + reason | declined + BIOMETRIC_CONSENT_DECLINED | Un refus a été enregistré. La session est Declined et ses données faciales ont été supprimées. Aucun écran de Didit ne propose de refus aujourd’hui. |
Vérification bancaire
Lorsque le workflow comprend une étape Vérification bancaire, la décision contientbank_verifications[], pour les deux types de session : un élément par étape, null tant qu’aucune étape n’en a produit un.
| Champ | Ce qu’il faut lire |
|---|---|
status | Le verdict de l’étape : Approved, In Review, Declined, Not Finished ou Expired. |
method | Mode de vérification du compte : open_banking (connexion bancaire), account_lookup (vérification du compte), microdeposits ou statement. null tant qu’aucun compte n’a été évalué, et none lorsque la personne a continué sans banque avant qu’une tentative ait été évaluée. |
continued_without_bank, continuation | Indique si la personne a choisi Continue without your bank, et pourquoi : continuation.reason vaut no_route, institution_unsupported, attempts_exhausted ou person_choice. Pour institution_unsupported, continuation.institution_name indique la banque que la personne n’a pas pu utiliser. |
ownership | Comparaison entre le titulaire du compte et l’identité vérifiée : result vaut match, partial_match (correspondance proche), no_match, not_verifiable ou unknown. |
account | Le compte vérifié, masqué. |
financial_data | Soldes, transactions et revenus, lus uniquement par connexion bancaire. not_collected liste les données demandées par l’étape que la méthode n’a pas collectées, par exemple après une vérification de compte. |
connection | La tentative la plus récente : son statut, la banque, le nombre de tentatives effectuées et un reason_code. |
method et non ownership.method : ownership.method correspond à la comparaison de noms qui a produit le score. Tous les champs figurent dans le schéma BankVerificationResult de la réponse de cet endpoint.
Signature électronique
Lorsque le workflow comprend une étape Signature électronique, la décision contientsignatures[], pour les deux types de session. Elle contient un élément par signataire : un pour une Vérification des utilisateurs, un par personne clé qui signe pour une Vérification d’entreprise (KYB). Les workflows sans cette étape ne renvoient pas la clé.
| Champ | Ce qu’il faut lire |
|---|---|
status | signed une fois les documents signés. Toute autre valeur signifie qu’il n’y a pas encore de signature. |
verdict | Approved, In Review, Declined ou Not Finished, défini par les règles de l’étape. |
signer, identity_used | Le signataire et l’identité vérifiée qui le représente. |
confirmation, certificate, timestamp | La confirmation par code à usage unique et les preuves cryptographiques. |
documents[] | Les empreintes de chaque document, son statut, son chemin signed_file et ses fields[] avec leurs valeurs. |
evidence_file | Chemin du PDF contenant les preuves du signataire. |
Erreurs
| Statut | Motif |
|---|---|
404 | Aucune session avec ce session_id n’existe pour cette application (les deux types de session sont vérifiés). |
403 | Privilège read:sessions manquant. |
401 | Clé API invalide. |
Liens connexes
- Vue d’ensemble des sessions : distinction des types de session et matrice des fonctionnalités.
- Schéma de réponse KYB : référence champ par champ de la décision pour les entreprises.
- Statuts de vérification : machine à états commune aux deux types.
- Webhooks : abonnez-vous à
status.updatedpour les sessions de Vérification des utilisateurs et de Vérification d’entreprise (filtrez sursession_kind). - Méthodes de vérification d’identité : capture de document, recherche sans document et portefeuilles d’identité numériques, et ce que chacune ajoute à la session.
- Consentement biométrique : quand le parcours demande un consentement biométrique explicite, et l’objet
biometric_consent. - Rapport de signature électronique :
signatures[], les PDF signés et les preuves. - Méthodes de vérification bancaire :
bank_verifications[]et sonmethod. - Lorsque la personne ne peut pas vérifier sa banque :
continued_without_bank,continuationet le résultat de chaque motif.
Autorisations
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
UUID de la session de vérification dont vous souhaitez récupérer la décision. Il s'agit du session_id renvoyé par POST /v3/session/. Le même chemin fonctionne pour les sessions de Vérification des utilisateurs (KYC) et de Vérification d'entreprise (KYB) — le serveur résout l'identifiant 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. Validez le format de l'UUID côté client afin de distinguer une erreur de saisie d'un véritable 404 pour session introuvable.
"11111111-2222-3333-4444-555555555555"
Paramètres de requête
Liste séparée par des virgules de sections de payload supplémentaires. Valeurs prises en charge : events et resubmissions, seules ou combinées (events,resubmissions). Lorsque include=events est transmis, la réponse contient en plus la chronologie des événements de session (events, y compris les événements de routage WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED décrits sur la page Récupérer une session), le journal d'activité complet (activity_reviews), les indicateurs de liste de blocage (blocklisted), un détail des coûts par session (cost_breakdown), les métadonnées de workflow (workflow_type, workflow_version, workflow_version_id et workflow_terminal_node_id - le dernier nœud de statut de workflow enregistré ayant défini un statut de session, ou null si aucun n'a été enregistré ; provenance historique qui n'est pas effacée par les approbations, refus ou nouvelles soumissions manuels, et qui est remplacée par un nœud de statut de workflow ultérieur), ainsi que les métadonnées de session (api_service — chaîne ou null, défini uniquement pour les sessions d'API autonome ; session_type — API, HOSTED ou MIGRATED ; has_device_nfc_support — booléen). Deux champs changent par rapport à la structure standard : le discriminateur de niveau supérieur session_kind est omis (la structure avec événements n'existe que pour les sessions utilisateur), et le tableau features passe de chaînes simples à des objets {feature, node_id} — où la fonctionnalité d'e-mail est indiquée comme EMAIL au lieu de EMAIL_VERIFICATION. Cette structure enrichie est principalement utilisée par la console Didit ; la plupart des intégrations d'API doivent omettre ce paramètre. Limitation KYB : include=events ne s'applique qu'aux sessions utilisateur (KYC). Les sessions d'entreprise (session_kind = "business") renvoient toujours la structure de décision d'entreprise standard — events, activity_reviews, blocklisted, cost_breakdown et les métadonnées supplémentaires workflow_*/session ne sont jamais renvoyés pour les sessions d'entreprise, et leur tableau features reste un tableau de chaînes simples. Avec include=resubmissions (sessions utilisateur comme entreprise), la réponse contient également resubmissions : une entrée par demande de nouvelle soumission, de la plus ancienne à la plus récente, chacune avec number, created_at, previous_status, nodes, reasons, requested_by et results (ce que les étapes soumises à nouveau ont renvoyé avant la demande, sous les mêmes clés et dans la même structure que les résultats actuels). Chaque élément de cost_breakdown comporte usage_type, price, details et created_at : une étape soumise à nouveau qui est exécutée une seconde fois est facturée comme un nouvel élément.
events, resubmissions, events,resubmissions "events"
Réponse
Rapport de décision complet. session_kind distingue les deux structures : les sessions user contiennent les tableaux de fonctionnalités KYC présentés ci-dessous ; les sessions business contiennent quant à elles registry_checks, document_verifications et key_people_checks aux côtés des tableaux partagés. Les tableaux de fonctionnalités sont null tant que le workflow n'a pas exécuté cette fonctionnalité ; les URL de médias sont des liens présignés à courte durée de validité.
L'identifiant unique de la session.
Discriminateur indiquant s'il s'agit d'une session de Vérification des utilisateurs (KYC) ou de Vérification d'entreprise (KYB). Lorsque la valeur est user, les tableaux de fonctionnalités KYC (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) s'appliquent et les tableaux d'entreprise sont absents. Lorsque la valeur est business, le payload contient à la place registry_checks, document_verifications, key_people_checks ainsi que les tableaux partagés (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses). Omis lorsque include=events est transmis — le format des événements n'existe que pour les sessions utilisateur, le discriminateur est donc supprimé de cette variante.
user, business Pour une session clonée avec POST /v3/session/import-shared/ : le session_id de la session d'origine dans l'application source. null pour toute autre session. Omis lorsque include=events est transmis.
session_number de la session source lorsque cette session a été importée depuis une autre application de votre organisation. null sinon.
Le numéro de la session.
L'URL de la session.
Statut global du cycle de vie de la session — le résultat consolidé du workflow. Les valeurs finales sont Approved, Declined, In Review, Expired, Kyc Expired et Abandoned ; Not Started, In Progress, Awaiting User et Resubmitted indiquent que la session progresse toujours dans le workflow.
Not Started, In Progress, Awaiting User, In Review, Approved, Declined, Resubmitted, Expired, Kyc Expired, Abandoned Présent lorsqu'un réviseur a défini manuellement status. null lorsque le statut est le résultat automatique. Utilisez-le pour distinguer une approbation manuelle d'une approbation automatique.
Show child attributes
Show child attributes
Manière dont le statut a été atteint : qui l'a défini et quels avertissements l'ont provoqué.
Show child attributes
Show child attributes
Un résumé des autres enregistrements liés à la session. null lorsqu'il n'y a rien à afficher, ainsi que pour les workflows déclarant une norme d'assurance de l'âge.
Show child attributes
Show child attributes
Identifiant stable du groupe de workflows qui a généré cette session. Les workflows sont versionnés — cette valeur identifie le workflow lui-même, et non la version spécifique.
Liste des fonctionnalités de vérification configurées pour cette session, sous forme de noms d'affichage : ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (vérification de la localisation) (les sessions de Vérification d'entreprise (KYB) utilisent l'ensemble de fonctionnalités KYB : KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Avec include=events, chaque entrée devient un objet {feature, node_id} au lieu d'une simple chaîne, et la fonctionnalité d'e-mail est renommée : elle apparaît sous la forme EMAIL en mode événements au lieu de EMAIL_VERIFICATION utilisé ici.
La fonctionnalité de la session.
Les données du fournisseur (vendor data) de la session.
Les métadonnées de la session.
Informations attendues fournies lors de la création de la session — utilisées pour la validation croisée avec les données extraites (KYC) ou pour préremplir la recherche dans le registre des sociétés (KYB). Renvoie exactement les clés fournies ; null si aucune n'a été fournie. Les sessions KYC contiennent les champs relatifs à la personne ; les sessions de Vérification d'entreprise (KYB) contiennent company_name, registry_country et registration_number.
Show child attributes
Show child attributes
Coordonnées fournies lors de la création de la session (utilisées pour les e-mails de notification, la vérification préremplie du téléphone/de l'e-mail et la langue de communication). null si aucun e-mail ni numéro de téléphone n'a été fourni.
Show child attributes
Show child attributes
L'URL de rappel de la session.
Tableau de rapports de Vérification d'identité (OCR) produits par les étapes de document d'identité dans le graphe du workflow. Toujours un tableau JSON — lisez id_verifications[0] et itérez si votre workflow peut exécuter plusieurs vérifications d'identité (par exemple une vérification principale plus un contrôle renforcé). null jusqu'à ce qu'au moins une étape d'identité ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, les champs de document extraits, les URL des images, les scores de qualité, la MRZ, l'analyse d'adresse, les correspondances entre sessions et warnings[].
Show child attributes
Show child attributes
Raison pour laquelle la vérification de la puce NFC n'a pas été exécutée, renseignée chaque fois que le workflow comprend une étape NFC. null tant que le NFC est en attente ou lorsque la puce a effectivement été lue. Valeurs : USER_SKIPPED - l'utilisateur a choisi d'ignorer l'étape sur un appareil compatible NFC (autorisé par allow_nfc_skip) ; DOCUMENT_WITHOUT_CHIP - le document ne possède pas de puce NFC lisible (il ne s'agit pas d'un document électronique ICAO 9303) ; CHIP_CERTIFICATE_UNAVAILABLE - le certificat de signature du pays de délivrance (CSCA) couvrant la période d'émission du document n'est pas disponible, la signature de la puce ne peut donc pas être vérifiée ; DEVICE_WITHOUT_NFC - l'appareil a signalé l'absence de lecteur NFC ; INTEGRATION_WITHOUT_NFC_ACCESS - la vérification s'est exécutée sans SDK natif (par exemple dans un navigateur web), qui n'a pas accès au lecteur NFC du téléphone ; MRZ_KEY_UNAVAILABLE - la clé d'accès à la puce n'a pas pu être dérivée de la MRZ du document ; JPKI_UNAVAILABLE - le document est une carte My Number japonaise, dont la puce est lue via JPKI, et JPKI n'était pas disponible pour cette vérification : il n'est pas activé, ou le SDK natif de l'application ne peut pas lire les cartes My Number.
USER_SKIPPED, DOCUMENT_WITHOUT_CHIP, CHIP_CERTIFICATE_UNAVAILABLE, DEVICE_WITHOUT_NFC, INTEGRATION_WITHOUT_NFC_ACCESS, MRZ_KEY_UNAVAILABLE, JPKI_UNAVAILABLE Tableau de rapports NFC / passeport électronique produits par les étapes NFC dans le graphe du workflow. Il s'agit toujours d'un tableau JSON, jamais d'un objet nfc singulier — lisez nfc_verifications[0] et itérez si votre workflow peut effectuer une vérification NFC plus d'une fois. null jusqu'à ce qu'au moins une étape NFC ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, chip_protocol, chip_data, authenticity (intégrité SOD + DG), certificate_summary et warnings[]. Une carte My Number japonaise est lue via JPKI au lieu de l'OACI 9303 : son élément a chip_protocol: "jpki", contient ses preuves sous jpki, et laisse les champs OACI à null. Lorsque l'étape NFC a été ignorée avant même d'avoir pu être proposée (document sans puce, certificat manquant, aucune capacité NFC signalée, clé MRZ illisible, JPKI indisponible pour une carte My Number), cela reste null et nfc_skip_reason en explique la raison ; un contournement au niveau de l'étape elle-même (l'utilisateur a appuyé sur ignorer, ou le lecteur s'est révélé indisponible au moment de la lecture) produit tout de même un rapport avec is_nfc_skipped: true.
Show child attributes
Show child attributes
Tableau de rapports de détection du vivant produits par les étapes de détection du vivant dans le graphe du workflow. Toujours un tableau JSON — jamais un objet liveness singulier. null jusqu'à ce qu'au moins une étape de détection du vivant ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, method, score, reference_image, video_url, l'age_estimation facultative, les matches[] entre sessions et warnings[].
Show child attributes
Show child attributes
Tableau de rapports de correspondance faciale produits par les étapes de correspondance faciale dans le graphe du workflow. Toujours un tableau JSON — jamais un objet face_match singulier. null jusqu'à ce qu'au moins une étape de correspondance faciale ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, le score de similarité, source_image, target_image et warnings[].
Show child attributes
Show child attributes
Tableau de rapports de vérification du téléphone — toujours un tableau JSON, jamais un objet phone singulier. null jusqu'à ce qu'au moins une étape de vérification du téléphone ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, le numéro de téléphone et les métadonnées de pays, lifecycle[], matches[] et warnings[].
Show child attributes
Show child attributes
Tableau de rapports de vérification d'e-mail — toujours un tableau JSON, jamais un objet email singulier. null jusqu'à ce qu'au moins une étape d'e-mail ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, l'adresse e-mail, les données de compromission, lifecycle[], matches[] et warnings[].
Show child attributes
Show child attributes
Tableau de rapports de Justificatif de domicile (POA) — toujours un tableau JSON, jamais un objet poa singulier. null jusqu'à ce qu'au moins une étape POA ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, l'URL du fichier du document, l'émetteur, les dates, l'adresse analysée et warnings[].
Show child attributes
Show child attributes
Rapports Document AI regroupés par nœud de workflow — toujours un tableau JSON, jamais un objet unique. null jusqu'à ce qu'au moins une étape Document AI ait produit des données. Présents uniquement lorsque session_kind = user. Chaque élément est un groupe de nœuds avec un status global, le node_id, un tableau items[] des résultats par document (données extraites indexées par la clé de champ configurée), et warnings.
Show child attributes
Show child attributes
Tableau de rapports de réponses aux questionnaires — toujours un tableau JSON, jamais un objet questionnaire singulier. null jusqu'à ce qu'au moins une étape de questionnaire ait produit des données. Chaque élément est le rapport complet, comprenant node_id, les métadonnées du questionnaire, les sections avec les éléments de formulaire et les réponses de l'utilisateur.
Show child attributes
Show child attributes
Résultats de la vérification bancaire, un élément par étape de vérification bancaire, pour la Vérification des utilisateurs et la Vérification d'entreprise (KYB). null jusqu'à ce qu'une étape en produise un. Le champ method de chaque élément indique comment le compte a été vérifié : open_banking (connexion bancaire) ou account_lookup (vérification de compte), ou une solution de repli statement ou microdeposits, et none lorsque la personne a continué sans banque avant qu'une tentative ne soit évaluée (continued_without_bank). Voir Méthodes de vérification bancaire.
Show child attributes
Show child attributes
Résultats de la Signature électronique, un élément par signataire et par étape de signature, pour la Vérification des utilisateurs et la Vérification d'entreprise. Présent uniquement lorsque le workflow comprend une étape de Signature électronique ; tableau vide jusqu'à ce qu'un signataire l'atteigne. Voir le rapport de Signature électronique.
Show child attributes
Show child attributes
Tableau de rapports de filtrage AML — toujours un tableau JSON, jamais un objet aml unique. null jusqu'à ce qu'au moins une étape AML ait produit des données. Chaque élément est le rapport complet, incluant node_id, le status au niveau de la fonctionnalité, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled et warnings[].
Show child attributes
Show child attributes
Tableau de rapports d'Analyse de l'appareil et de l'IP — toujours un tableau JSON, jamais un objet ip_analysis singulier. null jusqu'à ce qu'au moins une étape d'analyse IP ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, les données IP et de géolocalisation, l'empreinte de l'appareil et warnings[]. Les entrées présentant un doublon (node_id, ip_address, device_fingerprint) sont dédupliquées côté serveur.
Show child attributes
Show child attributes
Tableau de résultats de vérification de localisation, un par étape de vérification de localisation : la tentative acceptée de cette étape. null jusqu'à ce qu'une étape de vérification de localisation ait produit des données. Les tentatives antérieures de la même étape se trouvent dans geolocation_attempts.
Show child attributes
Show child attributes
Chaque tentative de chaque étape de vérification de localisation de cette session, de la plus ancienne à la plus récente. Les tentatives remplacées par une nouvelle soumission sont exclues. Un workflow qui masque geolocation_checks via ses attributs de réponse masque également cette liste.
Show child attributes
Show child attributes
Tableau de rapports de Validation en base de données — toujours un tableau JSON, jamais un objet database_validation singulier. null jusqu'à ce qu'au moins une étape de validation en base de données ait produit des données. Chaque élément correspond au rapport complet, incluant node_id, le status au niveau de la fonctionnalité, screened_data, les validations[] par service (chacune avec son source_data de registre) et warnings[]. Les champs screened_data et source_data varient selon le pays :
ARG (Argentine) : screened_data : {document_number, selfie, gender, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Utilise la validation biométrique par correspondance faciale de RENAPER. Le genre est automatiquement déduit de l'analyse du visage ou du prénom lorsqu'il n'est pas présent sur le document (ex. permis de conduire)
BOL (Bolivie) : screened_data : {document_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, gender}
BRA (Brésil) : screened_data : {tax_number, first_name, last_name, date_of_birth}. source_data inclut toujours {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} pour les correspondances CPF réussies. Les recherches réussies pour les adultes définissent ces indicateurs à false. Le service Consulta CPF de la Receita Federal peut renvoyer HTTP 422 (mineur de moins de 18 ans) ou 451 (moins de 16 ans) avec des données retenues en vertu de la LGPD ; dans ces cas, source_data définit les indicateurs de minorité à true selon le cas, inclut le statut HTTP en amont, et la validation au niveau du champ est no_match. Consultez la section Brésil de la référence des codes de résultat de la Validation en base de données pour la liste complète des codes.
CHL (Chili) : screened_data : {personal_number, first_name, last_name, date_of_birth}. source_data : {identification_number, first_name, last_name, date_of_birth, gender}
COL (Colombie) : screened_data : {document_number, document_type, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, document_type}
CRI (Costa Rica) : screened_data : {personal_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
DOM (République dominicaine) : screened_data : {personal_number}. source_data : {identification_number} (renvoie valid/invalid uniquement)
ECU (Équateur) : screened_data : {personal_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}
ESP (Espagne) : screened_data : {personal_number, document_type, expiration_date, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, document_type, expiration_date}
GTM (Guatemala) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
HND (Honduras) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
MEX (Mexique) : screened_data : {personal_number (CURP), first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Utilise le registre d'état civil RENAPO. Un service distinct de vérification de validité INE est également disponible pour MEX en tant que validation supplémentaire individuelle.
PAN (Panama) : screened_data : {personal_number, selfie}. source_data : {identification_number}. Utilise la validation biométrique SIB
PER (Pérou) : screened_data : {personal_number (DNI), first_name, last_name}. source_data : {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}
PRY (Paraguay) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
SLV (Salvador) : screened_data : {document_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
URY (Uruguay) : screened_data : {personal_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}
VEN (Venezuela) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}
Show child attributes
Show child attributes
Raison pour laquelle une validation en base de données configurée n'a produit aucun résultat, sous la forme {code, message} plus des champs de contexte. Présent uniquement lorsque database_validations est null pour un workflow comportant cette étape, afin de pouvoir distinguer « le registre a validé » de « rien n'a été exécuté ». null dans le cas contraire.
Show child attributes
Show child attributes
Show child attributes
Show child attributes
Le réviseur de la Console auquel la session est assignée, ou null si personne ne la détient.
Show child attributes
Show child attributes
Moment où la session a commencé à attendre un examen. null sauf si la session est In Review et que votre application définit un délai d'examen.
Date limite de l'examen. null sauf si la session est In Review et que votre application définit une date limite d'examen.
Horodatage de création de la session (ISO 8601, UTC).
Horodatage auquel l'expiration de cette session est planifiée. Défini sur les sessions de vérification des utilisateurs (KYC) lorsqu'une expiration a été configurée lors de la création (ou une fois que le statut Approved déclenche le calcul de l'expiration du KYC). null pour les sessions sans expiration configurée, et pour les types qui n'utilisent pas d'expiration (par ex. les sessions de vérification d'entreprise (KYB) qui n'ont jamais reçu d'expires_at).
Vérifications au registre des sociétés. Présent uniquement lorsque session_kind = business. Chaque élément encapsule le payload complet du registre des sociétés.
Show child attributes
Show child attributes
Vérifications agrégées des personnes clés. Présent uniquement lorsque session_kind = business. Chaque élément utilise la structure à deux compartiments (registry, submitted, ubo_kyc_summary).
Show child attributes
Show child attributes
Vérifications de documents groupées par nœud de workflow. Présentes uniquement lorsque session_kind = business.
Show child attributes
Show child attributes
Indique si la session a été créée par une application de production (live) ou une application sandbox (sandbox). Les sessions sandbox sont gratuites, entièrement simulées et ne consomment jamais de crédits.
live, sandbox Le scénario sandbox avec lequel la session a été créée. null pour les sessions de production et pour les sessions sandbox créées sans scénario.
Renvoyé uniquement avec include=resubmissions, pour les sessions utilisateur et d'entreprise. Une entrée par demande de resoumission, de la plus ancienne à la plus récente. Chaque entrée contient les résultats renvoyés par les étapes resoumises avant la demande, afin que les soumissions antérieures restent consultables. La suppression de la session supprime toutes les soumissions.
Show child attributes
Show child attributes
Indique si la session a requis un consentement biométrique explicite avant une capture de visage, pour quelle raison, ainsi que la preuve de la réponse. Sessions de Vérification des utilisateurs (KYC) uniquement ; le même objet figure dans la decision des webhooks de session. Vaut null lorsque la session n'a jamais été évaluée, par exemple un workflow sans capture de visage. Les champs sans valeur enregistrée sont à null. Un SDK natif inférieur à 4.10.0, ou qui ne transmet pas sa version, ne peut pas afficher l'étape de consentement : ses captures faciales s'exécutent comme auparavant, et une session ayant nécessité un consentement signale alors status: "pending" avec reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". Voir Consentement biométrique.
Show child attributes
Show child attributes
Le dernier examen Investigator de l'élément, ou null s'il n'en a jamais eu. Porté par la décision de session V3 et de session d'entreprise (et donc par les webhooks status.updated).
Show child attributes
Show child attributes
Moment où les données biométriques en direct de cette session sont supprimées.
Show child attributes
Show child attributes
Le résultat d'un appel à l'API Fraud Check. null pour toute autre session.
URL temporaire de l'enregistrement complet de la session. Renvoyée uniquement lorsque votre organisation enregistre la vidéo complète de la session.
Date et heure d'enregistrement de la session complète. Renvoyé uniquement lorsque votre organisation enregistre la vidéo complète de la session.