Übersicht
Die Gesichtssuche ist eine biometrische 1:N-Suche: Didit nimmt das größte erkannte Gesicht in Ihremuser_image und gleicht es mit dem Gesichtssuchindex Ihrer Anwendung ab – Gesichter, die aus Verifizierungssitzungen, gespeicherten eigenständigen API-Aufrufen, direkt in Benutzerprofile hochgeladenen Gesichtern und Ihren Sperr-/Freigabelisten registriert wurden. Sie unterscheidet sich vom Gesichtsabgleich, der 1:1 erfolgt – der Gesichtsabgleich vergleicht ein Selfie mit dem Porträt auf einem bestimmten Dokument, während die Gesichtssuche die Frage stellt: „Haben wir diese Person schon einmal irgendwo gesehen?“.
Zwei Verhaltensweisen sollten Sie verstehen, bevor Sie den Bericht auswerten:
- Nur Treffer auf der Sperrliste führen zu einer Ablehnung.
face_search.statusist nur dannDeclined, wenn eine Warnung vom TypFACE_IN_BLOCKLISToderPOSSIBLE_FACE_IN_BLOCKLISTausgelöst wird. Reine Duplikat-Treffer gebenApprovedzurück – prüfen Sie dahermatchesundwarnings, nicht nur denstatus. - Optionale Persistierung und Registrierung. Wenn
save_api_request=truegesetzt ist (Standardeinstellung), wird der Aufruf als Sitzung vom Typ API persistiert und das gesuchte Gesicht wird in Ihren Gesichtssuchindex aufgenommen. Gesichter, die durch Gesichtssuche-Aufrufe registriert wurden, sind von zukünftigen Gesichtssuchergebnissen ausgeschlossen, sodass wiederholte Suchanfragen nie miteinander übereinstimmen. Übergeben Siesave_api_request=falsefür eine einmalige Abfrage: Es wird nichts gespeichert und das Gesicht wird nicht registriert.
Wo die Ergebnisse erscheinen
Die Gesichtssuche ist eine eigenständige API. Die Suchergebnisse werden ausschließlich synchron in der Antwort aufPOST /v3/face-search/ als einzelnes face_search-Objekt auf oberster Ebene zurückgegeben:
face_searches[]-Array – die Plural-Array-Konvention, die von id_verifications[], aml_screenings[] und liveness_checks[] auf dem Sitzungsentscheidungs-Endpoint verwendet wird, gilt hier nicht.
Wenn save_api_request=true gesetzt ist (Standardeinstellung), wird der Aufruf zusätzlich als Sitzung vom Typ API persistiert:
- Business-Konsole – die Sitzung erscheint in Ihrer Sitzungsliste mit dem Suchbild, den Treffern und den Warnungen.
GET /v3/session/{sessionId}/decision/– abrufbar unter Verwendung der zurückgegebenenrequest_idals Sitzungs-ID. Die persistierten Daten erscheinen alsFACE_SEARCH-Eintrag infeatures[]sowie als Element inliveness_checks[], das die gespeichertenmatches(mit frisch signiertenmatch_image_url-Werten) undwarningsenthält – nicht alsface_search-Objekt.
save_api_request=false übergeben wird, ist die request_id eine flüchtige Korrelations-UUID: Die Sitzung wird nie gespeichert und kann daher weder über die Konsole noch über den Entscheidungs-Endpoint abgerufen werden.
Schema
Die kanonischen Feldtabellen finden Sie unter Gesichtssuche in der Datenmodell-Referenz. Die nachfolgende Struktur entspricht dem, was der Endpoint zur Laufzeit tatsächlich zurückgibt.matches[]ist auf maximal 5 Einträge oberhalb des Ähnlichkeitsschwellenwerts begrenzt, sortiert nach absteigender Ähnlichkeit (search_type=blocklisted_or_approvedordnet gesperrte Einträge zuerst ein, danach freigegebene und anschließend nach Ähnlichkeit).sourcegibt an, woher das übereinstimmende Gesicht stammt:session– eine Verifizierungssitzung oder ein gespeicherter eigenständiger API-Aufruf;imported– ein direkt in ein Benutzerprofil hochgeladenes Gesicht;list_entry– ein Gesicht, das einer Ihrer Listen zugeordnet ist;retained_template– ein bildfreies biometrisches Template, das die Anwendung nach dem Löschen der ursprünglichen Sitzung beibehalten hat.session_id,session_number,statusundapi_servicesind für Treffer mitimported,list_entryundretained_templatejeweilsnull.retained_template-Treffer enthaltenvendor_user_id,vendor_dataundbiometric_template_id, währendmatch_image_url,user_detailsund alle sitzungsbezogenen Felder stetsnullsind: Die Sitzung, aus der das Gesicht hervorging, existiert nicht mehr und das Template enthält weder Bild- noch Identitätsdaten.is_blocklistedist bei einem beibehaltenen Template immerfalse; ein gesperrtes Gesicht wird separat alslist_entry-Treffer gemeldet. Löschen Sie das Template mitDELETE /v3/biometric-templates/{biometric_template_id}/.api_serviceist der eigenständige API-Typ der zugeordneten Sitzung (in Großbuchstaben, z. B.PASSIVE_LIVENESS) undnull, wenn das übereinstimmende Gesicht aus einer regulären Workflow-Verifizierungssitzung stammt.user_detailsstammt aus der Dokumentenprüfung der zugeordneten Sitzung. Bei Treffern mitsource: importedwird das Feld stattdessen aus dem Benutzerprofil befüllt (full_nameist gesetzt,document_type/document_numbersind null); es istnull, wenn keine Identitätsdaten vorliegen (beispielsweise bei reinen Liveness-Sitzungen).- Warnungen verwenden eine reduzierte Struktur im Vergleich zu Workflow-Warnungen: Es gibt keine
node_id. Der dokumentierte Antwortvertrag (FaceSearchResponseSerializer) deklariert die fünf Felderrisk,additional_data,log_type,short_description,long_description; die Laufzeit-Payload enthält zusätzlichfeature, das hier immer"LIVENESS"lautet. Siehe Warnungen bei der Gesichtssuche. - Treffer desselben Benutzers werden nicht ausgeschlossen – anders als bei der Duplikaterkennung im Workflow filtert der eigenständige Endpoint frühere Sitzungen mit denselben
vendor_datanicht heraus, sodass ein wiederkehrender legitimer Benutzer mit seinen eigenen früheren Sitzungen übereinstimmt.
Statuswerte
Der übergeordneteface_search.status wird aus warnings[] abgeleitet. Der status auf Trefferebene spiegelt das Verifizierungsergebnis der übereinstimmenden Sitzung wider und ist davon unabhängig.
Hinweis: Wenn das Suchbild kein erkennbares Gesicht enthält, gibt die API HTTP
400 mit {"error": "No face detected in the image"} zurück, bevor ein face_search-Objekt erstellt wird – für diesen Fall gibt es keinen Declined-Status. Bei unzureichenden Credits wird HTTP 403 zurückgegeben, bevor eine Bildverarbeitung stattfindet.
Beispiele
Approved — Duplikat-Treffer, keine Sperrliste
Declined — Sperrlisten-Treffer
Verwandte Themen
- Warnungen der Gesichtssuche – alle Warnungscodes, die die Suche ausgeben kann
- API-Referenz zur Gesichtssuche – Anfrageparameter und
search_type-Modi - Datenmodelle – Gesichtssuche – kanonisches Schema
- Webhooks –
status.updated-Payloads für persistierte Sitzungen
Wenn
save_api_request=true gilt, sind die match_image_url-Werte signierte, kurzlebige URLs – rufen Sie den Endpoint für die Sitzungsentscheidung mit der zurückgegebenen request_id erneut ab, um neue URLs zu erhalten. Wenn save_api_request=false gilt, handelt es sich um interne Speicherpfade, die nicht direkt herunterladbar sind. Speichern Sie auf Ihrer Seite nur die übereinstimmende Sitzungs-ID, den Status und similarity_percentage – bewahren Sie das zugrunde liegende biometrische Bild nicht auf.