Zum Hauptinhalt springen

Übersicht

Die Gesichtssuche ist eine biometrische 1:N-Suche: Didit nimmt das größte erkannte Gesicht in Ihrem user_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.status ist nur dann Declined, wenn eine Warnung vom Typ FACE_IN_BLOCKLIST oder POSSIBLE_FACE_IN_BLOCKLIST ausgelöst wird. Reine Duplikat-Treffer geben Approved zurück – prüfen Sie daher matches und warnings, nicht nur den status.
  • Optionale Persistierung und Registrierung. Wenn save_api_request=true gesetzt 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 Sie save_api_request=false fü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 auf POST /v3/face-search/ als einzelnes face_search-Objekt auf oberster Ebene zurückgegeben:
Es gibt an keiner Stelle ein plurales 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ückgegebenen request_id als Sitzungs-ID. Die persistierten Daten erscheinen als FACE_SEARCH-Eintrag in features[] sowie als Element in liveness_checks[], das die gespeicherten matches (mit frisch signierten match_image_url-Werten) und warnings enthält – nicht als face_search-Objekt.
Wenn 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.
Hinweise zu den Feldern:
  • matches[] ist auf maximal 5 Einträge oberhalb des Ähnlichkeitsschwellenwerts begrenzt, sortiert nach absteigender Ähnlichkeit (search_type=blocklisted_or_approved ordnet gesperrte Einträge zuerst ein, danach freigegebene und anschließend nach Ähnlichkeit).
  • source gibt 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, status und api_service sind für Treffer mit imported, list_entry und retained_template jeweils null.
  • retained_template-Treffer enthalten vendor_user_id, vendor_data und biometric_template_id, während match_image_url, user_details und alle sitzungsbezogenen Felder stets null sind: Die Sitzung, aus der das Gesicht hervorging, existiert nicht mehr und das Template enthält weder Bild- noch Identitätsdaten. is_blocklisted ist bei einem beibehaltenen Template immer false; ein gesperrtes Gesicht wird separat als list_entry-Treffer gemeldet. Löschen Sie das Template mit DELETE /v3/biometric-templates/{biometric_template_id}/.
  • api_service ist der eigenständige API-Typ der zugeordneten Sitzung (in Großbuchstaben, z. B. PASSIVE_LIVENESS) und null, wenn das übereinstimmende Gesicht aus einer regulären Workflow-Verifizierungssitzung stammt.
  • user_details stammt aus der Dokumentenprüfung der zugeordneten Sitzung. Bei Treffern mit source: imported wird das Feld stattdessen aus dem Benutzerprofil befüllt (full_name ist gesetzt, document_type/document_number sind null); es ist null, 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 Felder risk, additional_data, log_type, short_description, long_description; die Laufzeit-Payload enthält zusätzlich feature, 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_data nicht heraus, sodass ein wiederkehrender legitimer Benutzer mit seinen eigenen früheren Sitzungen übereinstimmt.

Statuswerte

Der übergeordnete face_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

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.
Zuletzt geändert am 7. November 2026