Vai al contenuto principale

Panoramica

La Ricerca facciale è una ricerca biometrica 1:N: Didit prende il volto più grande rilevato nella tua user_image e lo cerca all’interno dell’indice di ricerca facciale della tua applicazione — volti registrati da sessioni di verifica, chiamate API autonome salvate, caricamenti diretti di volti nel profilo utente e le tue blocklist e allowlist. È diversa dal Confronto facciale, che è 1:1 — il Confronto facciale confronta un selfie con la foto presente su un documento specifico, mentre la Ricerca facciale si chiede: “abbiamo già visto questa persona da qualche parte in precedenza?”. È importante comprendere due comportamenti prima di analizzare il report:
  • Solo le corrispondenze con la blocklist comportano un rifiuto. face_search.status è Declined solo quando scatta un avviso FACE_IN_BLOCKLIST o POSSIBLE_FACE_IN_BLOCKLIST. Le sole corrispondenze duplicate restituiscono Approved — esamina matches e warnings, non solo status.
  • Persistenza e registrazione facoltative. Quando save_api_request=true (impostazione predefinita), la chiamata viene salvata come sessione di tipo API e il volto cercato viene registrato nel tuo indice di ricerca facciale. I volti registrati dalle chiamate di Ricerca facciale sono esclusi dai risultati futuri della Ricerca facciale, in modo che ricerche ripetute non corrispondano mai tra loro. Passa save_api_request=false per una query una tantum: non viene memorizzato nulla e il volto non viene registrato.

Dove compaiono i risultati

La Ricerca facciale è un’API autonoma. I risultati della ricerca vengono restituiti in modo sincrono, unicamente nella risposta POST /v3/face-search/, come singolo oggetto face_search a livello principale:
Non esiste alcun array al plurale face_searches[] — la convenzione degli array al plurale usata da id_verifications[], aml_screenings[] e liveness_checks[] sull’endpoint di decisione della sessione non si applica qui. Quando save_api_request=true (impostazione predefinita), la chiamata viene salvata anche come sessione di tipo API:
  • Business Console — la sessione compare nell’elenco delle tue sessioni con l’immagine di ricerca, le corrispondenze e gli avvisi.
  • GET /v3/session/{sessionId}/decision/ — recuperabile utilizzando il request_id restituito come id di sessione. I dati salvati emergono come voce FACE_SEARCH in features[] e come elemento di liveness_checks[] che contiene i matches salvati (con valori match_image_url appena firmati) e i warnings — non come oggetto face_search.
Quando save_api_request=false, request_id è un UUID di correlazione temporaneo: la sessione non viene mai salvata, quindi non può essere recuperata dalla Console o dall’endpoint di decisione.

Schema

Consulta Ricerca facciale nel riferimento ai modelli di dati per le tabelle canoniche dei campi. La struttura riportata di seguito riflette ciò che l’endpoint restituisce effettivamente in fase di esecuzione.
Note sui campi:
  • matches[] è limitato a 5 voci al di sopra della soglia minima di somiglianza, ordinate per somiglianza decrescente (search_type=blocklisted_or_approved posiziona per prime le voci in blocklist, poi quelle in allowlist, quindi per somiglianza).
  • source indica l’origine di registrazione del volto corrispondente: session — una sessione di verifica o una chiamata API autonoma salvata; imported — un volto caricato direttamente su un profilo utente; list_entry — un volto associato a una delle tue liste; retained_template — un modello biometrico senza immagini che l’applicazione ha conservato dopo l’eliminazione della sessione di origine. session_id, session_number, status e api_service sono null per le corrispondenze di tipo imported, list_entry e retained_template.
  • Le corrispondenze retained_template includono vendor_user_id, vendor_data e biometric_template_id, e sono sempre null per match_image_url, user_details e qualsiasi dato relativo alla sessione: la sessione che ha generato il volto non esiste più e il modello non contiene immagini né dati identificativi. is_blocklisted è sempre false per un modello biometrico conservato; un volto in blocklist viene segnalato separatamente come corrispondenza list_entry. Rimuovi il modello con DELETE /v3/biometric-templates/{biometric_template_id}/.
  • api_service è il tipo di API autonoma della sessione corrispondente (in maiuscolo, ad es. PASSIVE_LIVENESS) e null quando il volto corrispondente proviene da una normale sessione di verifica del workflow.
  • user_details proviene dalla verifica del documento della sessione corrispondente. Per le corrispondenze con source: imported viene invece compilato a partire dal profilo utente (full_name impostato, document_type/document_number null); è null quando non esistono dati identificativi (ad esempio nelle sessioni con il solo Rilevamento della vitalità).
  • Gli avvisi utilizzano una struttura ridotta rispetto agli avvisi del workflow: non è presente alcun node_id. Il contratto di risposta documentato (FaceSearchResponseSerializer) dichiara i cinque campi risk, additional_data, log_type, short_description, long_description; il payload di runtime include inoltre feature, che qui è sempre "LIVENESS". Consulta Avvisi di Ricerca facciale.
  • Le corrispondenze con lo stesso utente non sono escluse — a differenza del rilevamento dei duplicati nei workflow, l’endpoint autonomo non esclude le sessioni precedenti con lo stesso vendor_data, quindi un utente legittimo che ritorna trova corrispondenze nelle proprie sessioni precedenti.

Valori di stato

Il valore di face_search.status a livello principale è derivato da warnings[]. Lo status a livello di corrispondenza riflette l’esito della verifica della sessione corrispondente ed è indipendente. Nota: quando l’immagine cercata non contiene alcun volto rilevabile, l’API restituisce HTTP 400 con {"error": "No face detected in the image"} prima che venga creato un oggetto face_search — non esiste alcuno stato Declined per questo caso. Crediti insufficienti restituiscono HTTP 403 prima di qualsiasi elaborazione delle immagini.

Esempi

Approvata — corrispondenza duplicata, nessuna blocklist

Rifiutata — corrispondenza con blocklist

Correlati

Quando save_api_request=true, i valori di match_image_url sono URL firmati e di breve durata — effettua nuovamente una richiesta all’endpoint di decisione della sessione con il request_id restituito per ottenerne di nuovi. Quando save_api_request=false, sono percorsi di archiviazione interni e non sono scaricabili direttamente. Memorizza solo l’id della sessione corrispondente, lo stato e similarity_percentage sul tuo sistema — non conservare l’immagine biometrica sottostante.
Ultima modifica il 7 novembre 2026