Vue d’ensemble
La Recherche faciale est une recherche biométrique 1:N : Didit extrait le plus grand visage détecté dans votre champuser_image et le recherche dans l’index de recherche faciale de votre application — les visages enrôlés à partir de sessions de vérification, d’appels API autonomes sauvegardés, d’ajouts directs de visages sur des profils utilisateurs et de vos listes de blocage ou d’autorisation. Elle est distincte de Correspondance faciale, qui est 1:1 — Correspondance faciale compare un selfie avec la photo d’un document spécifique, tandis que Recherche faciale pose la question : « avons-nous déjà vu cette personne auparavant ? ».
Deux comportements essentiels sont à comprendre avant d’analyser le rapport :
- Seules les correspondances avec la liste de blocage entraînent un refus. Le champ
face_search.statusprend la valeurDeclineduniquement lorsqu’un avertissementFACE_IN_BLOCKLISTouPOSSIBLE_FACE_IN_BLOCKLISTest déclenché. Les correspondances en double retournent à elles seules le statutApproved— inspectezmatchesetwarnings, pas seulementstatus. - Persistance et enrôlement optionnels. Lorsque
save_api_request=true(valeur par défaut), l’appel est conservé en tant que session de type API et le visage recherché est enrôlé dans votre index de recherche faciale. Les visages enrôlés par des appels de Recherche faciale sont exclus des futurs résultats de Recherche faciale, de sorte que des recherches répétées ne correspondent jamais entre elles. Transmettezsave_api_request=falsepour une requête ponctuelle : rien n’est stocké et le visage n’est pas enrôlé.
Où apparaissent les résultats
Recherche faciale est une API autonome. Les résultats de recherche sont renvoyés de manière synchrone, uniquement dans la réponse àPOST /v3/face-search/, sous la forme d’un objet unique face_search au niveau racine :
face_searches[] — la convention de tableau au pluriel utilisée par id_verifications[], aml_screenings[] et liveness_checks[] sur l’endpoint de décision de session ne s’applique pas ici.
Lorsque save_api_request=true (valeur par défaut), l’appel est également conservé sous forme de session de type API :
- Business Console — la session apparaît dans votre liste de sessions avec l’image recherchée, les correspondances et les avertissements.
GET /v3/session/{sessionId}/decision/— récupérable en utilisant lerequest_idrenvoyé comme identifiant de session. Les données conservées apparaissent sous la forme d’une entréeFACE_SEARCHdansfeatures[]et d’un élémentliveness_checks[]contenant les correspondancesmatchesstockées (avec des valeursmatch_image_urlnouvellement signées) et leswarnings— et non sous la forme d’un objetface_search.
save_api_request=false, le champ request_id est un UUID de corrélation éphémère : la session n’est jamais stockée, elle ne peut donc pas être récupérée depuis la Console ou l’endpoint de décision.
Schéma
Consultez Recherche faciale dans la référence des modèles de données pour consulter les tableaux de champs faisant autorité. La structure ci-dessous reflète ce que l’endpoint renvoie réellement à l’exécution.matches[]est limité à 5 entrées au-dessus du seuil de similarité minimal, classées par ordre décroissant de similarité (search_type=blocklisted_or_approvedclasse d’abord les entrées sur liste de blocage, puis sur liste d’autorisation, puis selon la similarité).sourceindique l’origine de l’enrôlement du visage correspondant :session— une session de vérification ou un appel API autonome sauvegardé ;imported— un visage importé directement sur un profil utilisateur ;list_entry— un visage rattaché à l’une de vos listes ;retained_template— un gabarit biométrique sans image que l’application a conservé après la suppression de la session source.session_id,session_number,statusetapi_servicesont ànullpour les correspondances de typeimported,list_entryetretained_template.- Les correspondances
retained_templatecontiennentvendor_user_id,vendor_dataetbiometric_template_id;match_image_url,user_detailset tous les éléments liés à une session valent toujoursnull: la session à l’origine du visage n’existe plus et le gabarit ne contient aucune image ni donnée d’identité. Le champis_blocklistedest toujours àfalsepour un gabarit conservé ; un visage sur liste de blocage est signalé séparément comme une correspondance de typelist_entry. Vous pouvez purger le gabarit avecDELETE /v3/biometric-templates/{biometric_template_id}/. api_servicecorrespond au type d’API autonome de la session trouvée (en majuscules, par exemplePASSIVE_LIVENESS) et est ànulllorsque le visage correspondant provient d’une session de vérification de workflow standard.user_detailsprovient de la vérification de document de la session correspondante. Pour les correspondancessource: imported, ce champ est renseigné à partir du profil utilisateur (full_namerenseigné,document_type/document_numberà null) ; il est ànullsi aucune donnée d’identité n’existe (par exemple pour des sessions de détection du vivant uniquement).- Les avertissements utilisent une structure simplifiée par rapport aux avertissements de workflow : il n’y a pas de champ
node_id. Le contrat de réponse documenté (FaceSearchResponseSerializer) déclare les cinq champsrisk,additional_data,log_type,short_description,long_description; le payload d’exécution contient en plusfeature, qui vaut toujours"LIVENESS"ici. Consultez les avertissements de Recherche faciale. - Les correspondances pour un même utilisateur ne sont pas exclues — contrairement à la détection de doublons dans les workflows, l’endpoint autonome ne filtre pas les sessions antérieures ayant le même
vendor_data. Ainsi, un utilisateur légitime récurrent correspondra à ses propres sessions précédentes.
Valeurs de statut
La valeurface_search.status au niveau racine est calculée à partir de warnings[]. Le status au niveau de la correspondance reflète le résultat de vérification de la session correspondante et fonctionne de manière indépendante.
Remarque : lorsque l’image recherchée ne contient aucun visage détectable, l’API renvoie une erreur HTTP
400 avec {"error": "No face detected in the image"} avant qu’un objet face_search ne soit créé — aucun statut Declined n’est attribué dans ce cas. En cas de crédits insuffisants, l’API renvoie une erreur HTTP 403 avant tout traitement de l’image.
Exemples
Approuvé — correspondance en doublon, pas de liste de blocage
Refusé — correspondance avec la liste de blocage
Ressources associées
- Avertissements de Recherche faciale — tous les codes d’avertissement que la recherche peut émettre
- Référence de l’API de recherche faciale — paramètres de requête et modes
search_type - Modèles de données — Recherche faciale — schéma canonique
- Webhooks — payloads
status.updatedpour les sessions persistantes
Lorsque
save_api_request=true, les valeurs de match_image_url sont des URL signées à courte durée de vie — appelez à nouveau l’endpoint de décision de la session avec le request_id renvoyé pour en obtenir de nouvelles. Lorsque save_api_request=false, il s’agit de chemins de stockage internes non téléchargeables directement. Ne conservez de votre côté que l’ID de la session correspondante, le statut et similarity_percentage — ne conservez pas l’image biométrique sous-jacente.