Panoramica
La Ricerca facciale è una ricerca biometrica 1:N: Didit prende il volto più grande rilevato nella tuauser_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èDeclinedsolo quando scatta un avvisoFACE_IN_BLOCKLISToPOSSIBLE_FACE_IN_BLOCKLIST. Le sole corrispondenze duplicate restituisconoApproved— esaminamatchesewarnings, non solostatus. - 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. Passasave_api_request=falseper 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 rispostaPOST /v3/face-search/, come singolo oggetto face_search a livello principale:
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 ilrequest_idrestituito come id di sessione. I dati salvati emergono come voceFACE_SEARCHinfeatures[]e come elemento diliveness_checks[]che contiene imatchessalvati (con valorimatch_image_urlappena firmati) e iwarnings— non come oggettoface_search.
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.matches[]è limitato a 5 voci al di sopra della soglia minima di somiglianza, ordinate per somiglianza decrescente (search_type=blocklisted_or_approvedposiziona per prime le voci in blocklist, poi quelle in allowlist, quindi per somiglianza).sourceindica 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,statuseapi_servicesononullper le corrispondenze di tipoimported,list_entryeretained_template.- Le corrispondenze
retained_templateincludonovendor_user_id,vendor_dataebiometric_template_id, e sono semprenullpermatch_image_url,user_detailse 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è semprefalseper un modello biometrico conservato; un volto in blocklist viene segnalato separatamente come corrispondenzalist_entry. Rimuovi il modello conDELETE /v3/biometric-templates/{biometric_template_id}/. api_serviceè il tipo di API autonoma della sessione corrispondente (in maiuscolo, ad es.PASSIVE_LIVENESS) enullquando il volto corrispondente proviene da una normale sessione di verifica del workflow.user_detailsproviene dalla verifica del documento della sessione corrispondente. Per le corrispondenze consource: importedviene invece compilato a partire dal profilo utente (full_nameimpostato,document_type/document_numbernull); ènullquando 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 campirisk,additional_data,log_type,short_description,long_description; il payload di runtime include inoltrefeature, 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 diface_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
- Avvisi di Ricerca facciale — ogni codice di avviso che la ricerca può emettere
- Riferimento API di Ricerca facciale — parametri di richiesta e modalità
search_type - Modelli di dati — Ricerca facciale — schema canonico
- Webhook — payload
status.updatedper le sessioni persistenti
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.