Zum Hauptinhalt springen
GET
cURL

KYC- und KYB-Unterstützung

Dieser Endpoint funktioniert sowohl für Sitzungen zur Benutzerverifizierung (KYC) als auch zur Unternehmensverifizierung (KYB). Die Antwort enthält immer ein oberstes Feld session_kind:
  • "user": Sitzung zur Benutzerverifizierung (KYC). Die Antwort enthält id_verifications, liveness_checks, face_matches, nfc_verifications, poa_verifications und database_validations.
  • "business": Sitzung zur Unternehmensverifizierung (KYB). Die Antwort enthält registry_checks, document_verifications und key_people_checks.
Beide Arten enthalten aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews und contact_details. Außerdem enthalten beide die gemeinsamen Felder auf oberster Ebene: session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at und expires_at. Didit gleicht die session_id mit beiden Sitzungsarten ab, zuerst mit der Benutzerverifizierung (KYC), dann mit der Unternehmensverifizierung (KYB), und gibt die passende Sitzung zurück. UUIDs sind innerhalb einer Anwendung eindeutig, daher gibt es keine Mehrdeutigkeit. Die vollständige Übersicht der typspezifischen Funktionen finden Sie in der Übersicht über Sitzungen.

Beispiele

Antwort (gekürzt):

Verarbeitung der Antwort auf Ihrer Seite

Status, Entscheidungsverlauf und Prüffelder

Jede Entscheidung zeigt, wie ihr status zustande gekommen ist.

Aufbewahrung biometrischer Daten

biometric_retention ist immer vorhanden. deletes_at ist das Datum, an dem die Live-Daten zur Biometrie der Sitzung gelöscht werden. jurisdictions listet die US-Bundesstaaten auf, deren biometrische Vorschriften für die Person eine Löschfrist festlegen (US, wenn der Bundesstaat unbekannt ist). deletes_at ist null, solange noch kein Datum gilt.

Standortverifizierung

Enthält der Workflow einen Schritt zur Standortverifizierung, enthält die Entscheidung zwei Arrays. geolocation_checks[] hat je Schritt ein Element: den akzeptierten Versuch mit dem Ergebnis, den Koordinaten und deren Genauigkeit, den Abgleichen mit dem IP-Standort und der hinterlegten Adresse sowie die warnings des Schritts. geolocation_attempts[] listet jeden Versuch jedes Schritts auf, den ältesten zuerst, mit dem Zeitpunkt des Eingangs. Workflows ohne diesen Schritt liefern beide Felder als null. Alle Felder und Ergebnisse finden Sie im Bericht zur Standortverifizierung.

Workflow-Routing-Ereignisse

?include=events fügt den Ereignisverlauf der Sitzung hinzu. Neben den Schritt- und Statusänderungen hinterlässt ein Workflow, der über Verzweigungsknoten läuft, pro Routing-Entscheidung ein Ereignis. So kann eine Integration (oder die Zeitleiste in der Console) erklären, warum eine Sitzung mit einem bestimmten Ergebnis endete, ohne den Workflow-Graphen manuell nachzuvollziehen: Beide Ereignisse enthalten wie alle anderen Ereignisse sent_at in Millisekunden und haben kein component, feature_step oder step: Sie stammen von der Workflow-Engine und nicht vom Gerät des Benutzers. Eine „else“-Verzweigung (eine Verzweigung ohne Bedingungen) zählt als passende Verzweigung; fallback ist nur dann true, wenn nichts zutraf. Knoten mit nur einer ausgehenden Kante treffen keine Entscheidung und hinterlassen kein Ereignis. Dieselbe Struktur enthält außerdem workflow_terminal_node_id: die node_id des zuletzt aufgezeichneten Workflow-Statusknotens, der einen Sitzungsstatus gesetzt hat, oder null, wenn keine solche Knoten-ID aufgezeichnet wurde. Dies ist die historische Herkunft des Workflows. Manuelle Genehmigungen, Ablehnungen und erneute Einreichungen löschen diesen Wert nicht; ein späterer Workflow-Statusknoten ersetzt ihn. Wenn ein Workflow beispielsweise eine Sitzung an einen Knoten In Review sendet und ein Prüfer sie anschließend genehmigt, lautet der aktuelle status Approved, während workflow_terminal_node_id weiterhin auf den Knoten In Review verweist. Der Wert kann auch belegt bleiben, während eine erneute Einreichung läuft. Lesen Sie den aktuellen status sowie die Ereignis- und activity_reviews-Zeitleisten, um Workflow-Ergebnisse von späteren manuellen Entscheidungen zu unterscheiden.

Frühere Einreichungen (?include=resubmissions)

Eine erneute Einreichung schickt den Benutzer zu den von Ihnen ausgewählten Schritten zurück und behält bei, was diese Schritte zuvor zurückgegeben haben. ?include=resubmissions fügt ein Array resubmissions hinzu, das älteste zuerst, mit einem Eintrag pro Anfrage zur erneuten Einreichung. Jeder Eintrag enthält die Ergebnisse, die diese Anfrage ersetzt hat, sodass Sie jederzeit nachlesen können, was der Benutzer zuvor eingereicht hat. Es funktioniert für Benutzer-Sitzungen (KYC) und Unternehmens-Sitzungen (KYB), und Sie können es mit Ereignissen kombinieren (?include=events,resubmissions). Ohne den Parameter bleibt die Antwort unverändert. Die aktuellen Ergebnisse (id_verifications und die übrigen auf oberster Ebene) beschreiben immer die neueste Einreichung. Schritte, die nicht zurückgeschickt wurden, behalten dort ein einziges Ergebnis.
Wenn Sie eine Sitzung löschen, werden die Ergebnisse aller Einreichungen zusammen mit ihr gelöscht.

Ausweisverifizierungsmethoden

Jedes Element in id_verifications[] gibt an, welche der drei Ausweisverifizierungsmethoden es erzeugt hat. So erkennen Sie, ob ein Dokument ausgelesen, ein Register abgefragt oder eine Wallet-Anmeldung durchgeführt wurde, ohne dies aus den jeweils ausgefüllten Feldern zu erraten: Eine Dokumentsitzung meldet document und documentary und belässt die übrigen Felder auf null, daher benötigen bestehende Integrationen keine Anpassung. Die Typen der einzelnen Felder finden Sie unter Datenmodelle.

Biometrische Einwilligung

Entscheidungen der Benutzerverifizierung enthalten ein Objekt biometric_consent: ob die Sitzung eine ausdrückliche biometrische Einwilligung verlangt hat, den trigger, der sie verlangt hat, den status der Antwort und deren Nachweis. Zwei Werte zeigen an, dass die Einwilligung nicht eingeholt wurde: Wann der Schritt erscheint und was die einzelnen Werte bedeuten, steht unter Biometrische Einwilligung; jedes Feld steht unter Datenmodelle.

Bankverifizierung

Wenn der Workflow einen Bankverifizierungs-Schritt enthält, enthält die Entscheidung bank_verifications[] für beide Sitzungsarten: einen Eintrag pro Schritt, und null, bis ein Schritt einen Eintrag erzeugt. Unterscheiden Sie die Bank-Anmeldung von der Kontoprüfung anhand von method, nicht anhand von ownership.method: ownership.method ist der Namensvergleich, der den Score erzeugt hat. Jedes Feld ist im Schema BankVerificationResult der Antwort dieses Endpoints enthalten.

E-Signatur

Wenn der Workflow einen E-Signatur-Schritt enthält, enthält die Entscheidung signatures[] für beide Sitzungsarten. Es gibt einen Eintrag pro Unterzeichner: einen bei einer Benutzerverifizierung, einen pro Schlüsselperson, die bei einer Unternehmensverifizierung unterzeichnet. Workflows ohne diesen Schritt geben den Schlüssel gar nicht zurück. Laden Sie die Dateien mit Ihrem API-Schlüssel über die Pfade herunter. Alle Felder finden Sie im E-Signatur-Bericht.

Fehler

Verwandte Themen

Autorisierungen

x-api-key
string
header
erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Pfadparameter

sessionId
string<uuid>
erforderlich

UUID der Verifizierungssitzung, deren Entscheidung Sie abrufen möchten. Dies ist die von POST /v3/session/ zurückgegebene session_id. Derselbe Pfad funktioniert sowohl für Sitzungen der Benutzerverifizierung (KYC) als auch der Unternehmensverifizierung (KYB) — der Server löst die ID für beide Sitzungstypen auf.

Muss eine gültige UUID sein. Die Route stimmt nur mit wohlgeformten UUIDs überein, sodass ein fehlerhafter Wert vom URL-Router abgelehnt wird, bevor Anwendungscode ausgeführt wird, und die Antwort eine 404-HTML-Seite anstelle des unten gezeigten JSON-Antwortobjekts {"detail": ...} ist. Validieren Sie das UUID-Format clientseitig, um einen Eingabefehler von einem echten 404 für eine fehlende Sitzung unterscheiden zu können.

Beispiel:

"11111111-2222-3333-4444-555555555555"

Abfrageparameter

include
enum<string>

Kommagetrennte Liste zusätzlicher Payload-Abschnitte. Unterstützte Werte: events und resubmissions, einzeln oder zusammen (events,resubmissions). Wenn include=events übergeben wird, enthält die Antwort zusätzlich die Ereignis-Timeline der Sitzung (events, einschließlich der Routing-Ereignisse WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED, die auf der Seite „Sitzung abrufen“ beschrieben sind), das vollständige Aktivitätsprotokoll (activity_reviews), Sperrlisten-Flags (blocklisted), eine sitzungsbezogene Kostenaufschlüsselung (cost_breakdown), Workflow-Metadaten (workflow_type, workflow_version, workflow_version_id und workflow_terminal_node_id – der letzte erfasste Workflow-Statusknoten, der einen Sitzungsstatus festgelegt hat, oder null, falls keiner erfasst wurde; historische Herkunftsinformation, die durch manuelle Genehmigungen, Ablehnungen oder erneute Einreichungen nicht gelöscht wird und durch einen späteren Workflow-Statusknoten ersetzt wird) sowie Sitzungsmetadaten (api_service — String oder null, nur für Standalone-API-Sitzungen gesetzt; session_type — API, HOSTED oder MIGRATED; has_device_nfc_support — Boolean). Zwei Felder ändern sich gegenüber der einfachen Struktur: Der session_kind-Diskriminator auf oberster Ebene wird ausgelassen (die Ereignisstruktur existiert nur für Benutzersitzungen) und das Array features wechselt von einfachen Strings zu {feature, node_id}-Objekten – wobei die E-Mail-Funktion als EMAIL statt EMAIL_VERIFICATION gemeldet wird. Diese erweiterte Struktur wird hauptsächlich von der Didit Console verwendet; die meisten API-Integrationen sollten den Parameter weglassen. KYB-Einschränkung: include=events gilt nur für Benutzer-(KYC-)Sitzungen. Unternehmenssitzungen (session_kind = "business") geben immer die standardmäßige Unternehmensentscheidungsstruktur zurück – events, activity_reviews, blocklisted, cost_breakdown und die zusätzlichen workflow_*-/Sitzungsmetadaten werden für Unternehmenssitzungen niemals zurückgegeben, und ihr features-Array bleibt ein einfaches String-Array. Mit include=resubmissions (sowohl für Benutzer- als auch für Unternehmenssitzungen) enthält die Antwort außerdem resubmissions: einen Eintrag pro Anfrage auf erneute Einreichung, die älteste zuerst, jeweils mit number, created_at, previous_status, nodes, reasons, requested_by und results (was die erneut eingereichten Schritte vor der Anfrage unter denselben Schlüsseln und in derselben Struktur wie die aktuellen Ergebnisse zurückgegeben haben). Jeder Eintrag in cost_breakdown enthält usage_type, price, details und created_at: Ein erneut eingereichter Schritt, der nochmals ausgeführt wird, wird als neuer Posten abgerechnet.

Verfügbare Optionen:
events,
resubmissions,
events,resubmissions
Beispiel:

"events"

Antwort

Vollständiger Entscheidungsbericht. session_kind unterscheidet die beiden Formen: user-Sitzungen enthalten die unten gezeigten KYC-Funktions-Arrays; business-Sitzungen enthalten stattdessen registry_checks, document_verifications und key_people_checks neben den gemeinsamen Arrays. Funktions-Arrays sind null, bis der Workflow diese Funktion ausgeführt hat; Medien-URLs sind kurzlebige, vorsignierte Links.

session_id
string<uuid>

Die eindeutige Kennung der Sitzung.

session_kind
enum<string>

Diskriminator, der angibt, ob es sich um eine Sitzung zur Benutzerverifizierung (KYC) oder Unternehmensverifizierung (KYB) handelt. Bei user gelten die KYC-Funktions-Arrays (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) und die Unternehmens-Arrays fehlen. Bei business enthält die Payload stattdessen registry_checks, document_verifications, key_people_checks sowie die gemeinsamen Arrays (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses). Wird weggelassen, wenn include=events übergeben wird – die Ereignisstruktur existiert nur für Benutzersitzungen, daher entfällt der Diskriminator in dieser Variante.

Verfügbare Optionen:
user,
business
shared_from_session
string<uuid> | null

Für eine mit POST /v3/session/import-shared/ geklonte Sitzung: die session_id der ursprünglichen Sitzung in der Quellanwendung. null für jede andere Sitzung. Wird weggelassen, wenn include=events übergeben wird.

shared_from_session_number
integer | null

session_number der Quellsitzung, wenn diese Sitzung aus einer anderen Anwendung Ihrer Organisation importiert wurde. Andernfalls null.

session_number
integer | null

Die Nummer der Sitzung.

session_url
string<uri> | null

Die URL der Sitzung.

status
enum<string>

Gesamter Lebenszyklusstatus der Sitzung — das zusammengefasste Workflow-Ergebnis. Endgültige Werte sind Approved, Declined, In Review, Expired, Kyc Expired und Abandoned; Not Started, In Progress, Awaiting User und Resubmitted zeigen an, dass die Sitzung den Workflow noch durchläuft.

Verfügbare Optionen:
Not Started,
In Progress,
Awaiting User,
In Review,
Approved,
Declined,
Resubmitted,
Expired,
Kyc Expired,
Abandoned
status_override
object | null

Vorhanden, wenn ein Prüfer status manuell gesetzt hat. null, wenn der Status automatisch vergeben wurde. Dient zur Unterscheidung einer manuellen von einer automatischen Genehmigung.

decision_trace
object

Wie der Status erreicht wurde: wer ihn festgelegt hat und welche Warnungen dazu geführt haben.

linked_records
object | null

Eine Zusammenfassung anderer mit der Sitzung verknüpfter Datensätze. null, wenn nichts anzuzeigen ist, sowie für Workflows, die einen Standard zur Altersabsicherung deklarieren.

workflow_id
string<uuid> | null

Stabiler Identifikator der Workflow-Gruppe, die diese Sitzung erzeugt hat. Workflows sind versioniert – dieser Wert identifiziert den Workflow selbst, nicht die spezifische Version.

features
string[]

Liste der für diese Sitzung konfigurierten Verifizierungsfunktionen als Anzeigenamen: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (Standortverifizierung) (Sitzungen zur Unternehmensverifizierung verwenden das KYB-Funktionsset: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Bei include=events wird jeder Eintrag zu einem Objekt {feature, node_id} anstelle einer einfachen Zeichenkette, und die E-Mail-Funktion wird umbenannt: Sie erscheint im Ereignismodus als EMAIL anstelle des hier verwendeten EMAIL_VERIFICATION.

Die Funktion der Sitzung.

vendor_data
string | null

Die Vendor-Daten der Sitzung.

metadata
object | null

Die Metadaten der Sitzung.

expected_details
object | null

Erwartete Details, die bei der Sitzungserstellung angegeben wurden — verwendet für die Kreuzvalidierung mit extrahierten Daten (KYC) oder zum Vorausfüllen der Suche im Unternehmensregister (KYB). Gibt genau die Schlüssel zurück, die bereitgestellt wurden; null, wenn keine angegeben wurden. KYC-Sitzungen enthalten die Personenfelder; Unternehmenssitzungen (KYB) enthalten company_name, registry_country und registration_number.

contact_details
object | null

Kontaktdaten, die bei der Erstellung der Sitzung angegeben wurden (verwendet für Benachrichtigungs-E-Mails, vorausgefüllte Telefon-/E-Mail-Verifizierung und Kommunikationssprache). null, wenn weder eine E-Mail-Adresse noch eine Telefonnummer angegeben wurde.

callback
string<uri> | null

Die Callback-URL der Sitzung.

id_verifications
object[] | null

Array von Ausweisverifizierungsberichten (OCR), die von Ausweisdokument-Schritten im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – lesen Sie id_verifications[0] und iterieren Sie, falls Ihr Workflow mehr als eine Ausweisprüfung ausführen kann (beispielsweise eine primäre Prüfung plus eine zusätzliche Prüfung). null, bis mindestens ein Ausweisschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, extrahierten Dokumentfeldern, Bild-URLs, Qualitätswerten, MRZ, Adress-Parsing, sitzungsübergreifenden Übereinstimmungen sowie warnings[].

nfc_skip_reason
enum<string> | null

Warum die NFC-Chip-Verifizierung nicht ausgeführt wurde; wird angegeben, wenn der Workflow einen NFC-Schritt enthält. null, solange NFC aussteht oder wenn der Chip tatsächlich gelesen wurde. Werte: USER_SKIPPED – der Benutzer hat sich entschieden, den Schritt auf einem NFC-fähigen Gerät zu überspringen (durch allow_nfc_skip erlaubt); DOCUMENT_WITHOUT_CHIP – das Dokument besitzt keinen lesbaren NFC-Chip (kein elektronisches Dokument nach ICAO 9303); CHIP_CERTIFICATE_UNAVAILABLE – das Signaturzertifikat des Ausstellungslands (CSCA) für den Ausgabezeitraum des Dokuments ist nicht verfügbar, sodass die Chipsignatur nicht überprüft werden kann; DEVICE_WITHOUT_NFC – das Gerät hat kein NFC-Lesegerät gemeldet; INTEGRATION_WITHOUT_NFC_ACCESS – die Verifizierung lief ohne natives SDK (z. B. in einem Webbrowser), das keinen Zugriff auf das NFC-Lesegerät des Telefons hat; MRZ_KEY_UNAVAILABLE – der Chip-Zugriffsschlüssel konnte nicht aus der MRZ des Dokuments abgeleitet werden; JPKI_UNAVAILABLE – das Dokument ist eine japanische My Number Card, deren Chip über JPKI gelesen wird, und JPKI war für diese Verifizierung nicht verfügbar: es ist nicht aktiviert oder das native SDK der App kann keine My Number Cards lesen.

Verfügbare Optionen:
USER_SKIPPED,
DOCUMENT_WITHOUT_CHIP,
CHIP_CERTIFICATE_UNAVAILABLE,
DEVICE_WITHOUT_NFC,
INTEGRATION_WITHOUT_NFC_ACCESS,
MRZ_KEY_UNAVAILABLE,
JPKI_UNAVAILABLE
nfc_verifications
object[] | null

Array von NFC- / ePass-Berichten, die von NFC-Schritten im Workflow-Graphen erzeugt wurden. Dies ist immer ein JSON-Array, niemals ein einzelnes nfc-Objekt – lesen Sie nfc_verifications[0] und iterieren Sie, falls Ihr Workflow NFC mehr als einmal ausführen kann. null, bis mindestens ein NFC-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, chip_protocol, chip_data, authenticity (SOD + DG-Integrität), certificate_summary sowie warnings[]. Eine japanische My Number Card wird über JPKI anstelle von ICAO 9303 ausgelesen: Ihr Eintrag weist chip_protocol: "jpki" auf, führt ihre Nachweise unter jpki und lässt die ICAO-Felder null. Wenn der NFC-Schritt übersprungen wurde, bevor er überhaupt angeboten werden konnte (Dokument ohne Chip, fehlendes Zertifikat, keine gemeldete NFC-Fähigkeit, unlesbarer MRZ-Schlüssel, JPKI für eine My Number Card nicht verfügbar), bleibt dies null und nfc_skip_reason erklärt den Grund; ein Überspringen beim Schritt selbst (Benutzer hat auf Überspringen getippt oder das Lesegerät war zum Scanzeitpunkt nicht verfügbar) erzeugt dennoch einen Bericht mit is_nfc_skipped: true.

liveness_checks
object[] | null

Array von Berichten zur Liveness-Erkennung, die von Schritten zur Liveness-Erkennung im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – niemals ein einzelnes liveness-Objekt. null, bis mindestens ein Schritt zur Liveness-Erkennung Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, method, score, reference_image, video_url, optionaler age_estimation, sitzungsübergreifenden matches[] sowie warnings[].

face_matches
object[] | null

Array von Gesichtsabgleichsberichten, die von Gesichtsabgleichsschritten im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – niemals ein einzelnes face_match-Objekt. null, bis mindestens ein Gesichtsabgleichsschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, Ähnlichkeits-score, source_image, target_image sowie warnings[].

phone_verifications
object[] | null

Array von Telefonverifizierungsberichten – immer ein JSON-Array, niemals ein einzelnes phone-Objekt. null, bis mindestens ein Telefonschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der Telefonnummer und Ländermetadaten, lifecycle[], matches[] sowie warnings[].

email_verifications
object[] | null

Array von E-Mail-Verifizierungsberichten – immer ein JSON-Array, niemals ein einzelnes email-Objekt. null, bis mindestens ein E-Mail-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der E-Mail-Adresse, Daten zu Datenlecks, lifecycle[], matches[] sowie warnings[].

poa_verifications
object[] | null

Array von Adressnachweis-Berichten (POA) – immer ein JSON-Array, niemals ein einzelnes poa-Objekt. null, bis mindestens ein POA-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der Dokumentdatei-URL, Aussteller, Datumsangaben, geparster Adresse sowie warnings[].

document_ai_documents
object[] | null

Document AI-Berichte gruppiert nach Workflow-Knoten — immer ein JSON-Array, niemals ein einzelnes Objekt. null, bis mindestens ein Document AI-Schritt Daten erzeugt hat. Nur vorhanden, wenn session_kind = user. Jeder Eintrag ist eine Knotengruppe mit einem aggregierten status, der node_id, einem items[]-Array der Ergebnisse pro Dokument (extrahierte Daten zugeordnet nach dem konfigurierten Feldschlüssel) und warnings.

questionnaire_responses
object[] | null

Array von Fragebogen-Antwortberichten – immer ein JSON-Array, niemals ein einzelnes questionnaire-Objekt. null, bis mindestens ein Fragebogenschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, der Fragebogen-Metadaten, Abschnitten mit Formularelementen sowie den Antworten des Benutzers.

bank_verifications
object[] | null

Ergebnisse der Bankverifizierung, ein Eintrag pro Schritt der Bankverifizierung, für die Benutzer- und Unternehmensverifizierung. null, bis ein Schritt ein Ergebnis erzeugt. Das Feld method jedes Eintrags gibt an, wie das Konto verifiziert wurde: open_banking (Bank-Anmeldung) oder account_lookup (Kontoabfrage) oder ein statement- bzw. microdeposits-Fallback, und none, wenn die Person vor der Auswertung eines Versuchs ohne Bank fortgefahren ist (continued_without_bank). Siehe Bank-Verifizierungsmethoden.

signatures
object[]

E-Signatur-Ergebnisse, ein Element pro Unterzeichner und Signaturschritt, für Benutzerverifizierung und Unternehmensverifizierung (KYB). Nur vorhanden, wenn der Workflow einen E-Signatur-Schritt enthält; ein leeres Array, bis ein Unterzeichner diesen erreicht. Siehe den E-Signatur-Bericht.

aml_screenings
object[] | null

Array von AML-Screening-Berichten — immer ein JSON-Array, niemals ein einzelnes aml-Objekt. null, bis mindestens ein AML-Schritt Daten erzeugt hat. Jedes Element ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled und warnings[].

ip_analyses
object[] | null

Array von Geräte- und IP-Analyse-Berichten – immer ein JSON-Array, niemals ein einzelnes ip_analysis-Objekt. null, bis mindestens ein IP-Analyseschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, IP- und Geolokalisierungsdaten, Geräte-Fingerprint sowie warnings[]. Einträge mit doppeltem (node_id, ip_address, device_fingerprint) werden serverseitig dedupliziert.

geolocation_checks
object[] | null

Array von Standortverifizierungsergebnissen, eines pro Standortverifizierungsschritt: der akzeptierte Versuch dieses Schritts. null, bis ein Standortverifizierungsschritt Daten erzeugt hat. Frühere Versuche desselben Schritts befinden sich in geolocation_attempts.

geolocation_attempts
object[] | null

Jeder Versuch jedes Standortverifizierungsschritts dieser Sitzung, der älteste zuerst. Versuche, die durch eine erneute Einreichung ersetzt wurden, werden ausgelassen. Ein Workflow, der geolocation_checks über seine Antwort-Attribute zurückhält, hält auch diese Liste zurück.

database_validations
object[] | null

Array von Berichten zur Datenbankvalidierung — immer ein JSON-Array, niemals ein einzelnes database_validation-Objekt. null, bis mindestens ein Schritt der Datenbankvalidierung Daten erzeugt hat. Jedes Element ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, screened_data, der dienstspezifischen validations[] (jeweils mit ihren Register-source_data) und warnings[]. Die Felder screened_data und source_data variieren je nach Land:

ARG (Argentinien): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Verwendet die biometrische Validierung des Gesichtsabgleichs von RENAPER. Das Geschlecht wird automatisch aus der Gesichtsanalyse oder dem Vornamen abgeleitet, wenn es im Dokument nicht vorhanden ist (z. B. bei Führerscheinen)

BOL (Bolivien): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Brasilien): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data enthält für erfolgreiche CPF-Übereinstimmungen immer {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16}. Erfolgreiche Abfragen für Erwachsene setzen diese Flags auf false. Der Dienst Receita Federal Consulta CPF kann HTTP 422 (Minderjährige unter 18) oder 451 (unter 16) mit durch das LGPD zurückgehaltenen Daten zurückgeben; in diesen Fällen setzt source_data die Minor-Flags entsprechend auf true, enthält den Upstream-HTTP-Status, und die Validierung auf Feldebene lautet no_match. Die vollständige Codeliste finden Sie im Abschnitt zu Brasilien in der Referenz zu den Ergebnis-Codes der Datenbankvalidierung.

CHL (Chile): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (Kolumbien): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Costa Rica): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (Dominikanische Republik): screened_data: {personal_number}. source_data: {identification_number} (gibt nur valid/invalid zurück)

ECU (Ecuador): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (Spanien): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Guatemala): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (Honduras): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (Mexiko): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Verwendet das Zivilregister RENAPO. Für MEX ist außerdem ein separater INE-Gültigkeitsprüfungsdienst als zusätzliche Einzelvalidierung verfügbar.

PAN (Panama): screened_data: {personal_number, selfie}. source_data: {identification_number}. Verwendet die biometrische SIB-Validierung

PER (Peru): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Paraguay): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (El Salvador): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (Uruguay): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (Venezuela): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

database_validation_not_performed_reason
object | null

Warum eine konfigurierte Datenbankvalidierung kein Ergebnis geliefert hat, als {code, message} plus Kontextfelder. Nur vorhanden, wenn database_validations den Wert null für einen Workflow hat, der diesen Schritt enthält, damit Sie unterscheiden können zwischen „das Register hat zugestimmt“ und „es wurde nichts ausgeführt“. Andernfalls null.

reviews
object[]
assignee
object | null

Der Konsolen-Prüfer, dem die Sitzung zugewiesen ist, oder null, wenn sie niemandem zugewiesen ist.

waiting_since
string<date-time> | null

Wann die Sitzung begonnen hat, auf eine Prüfung zu warten. null, es sei denn, die Sitzung ist In Review und Ihre Anwendung legt eine Prüffrist fest.

sla_due_at
string<date-time> | null

Wann die Prüfung fällig ist. null, es sei denn, die Sitzung ist In Review und Ihre Anwendung legt eine Prüffrist fest.

created_at
string<date-time>

Zeitstempel, zu dem die Sitzung erstellt wurde (ISO 8601, UTC).

expires_at
string<date-time> | null

Zeitstempel, zu dem diese Sitzung planmäßig abläuft. Wird bei Benutzerverifizierungs-Sitzungen (KYC) festgelegt, wenn bei der Erstellung ein Ablauf konfiguriert wurde (oder sobald der Status Approved die KYC-Ablaufberechnung auslöst). null für Sitzungen ohne konfigurierten Ablauf und für Arten, die keinen Ablauf verwenden (z. B. Sitzungen zur Unternehmensverifizierung (KYB), die nie ein expires_at erhalten haben).

registry_checks
object[] | null

Prüfungen des Unternehmensregisters. Nur vorhanden, wenn session_kind = business. Jedes Element enthält die vollständige Unternehmensregister-Payload.

key_people_checks
object[] | null

Aggregierte Prüfungen der Schlüsselpersonen. Nur vorhanden, wenn session_kind = business. Jedes Element verwendet die Zwei-Bucket-Struktur (registry, submitted, ubo_kyc_summary).

document_verifications
object[] | null

Prüfungen der Dokumentenverifizierung, gruppiert nach Workflow-Knoten. Nur vorhanden, wenn session_kind = business.

environment
enum<string>

Gibt an, ob die Sitzung von einer Live-Anwendung (live) oder einer Sandbox-Anwendung (sandbox) erstellt wurde. Sandbox-Sitzungen sind kostenlos, vollständig simuliert und stellen niemals Credits in Rechnung.

Verfügbare Optionen:
live,
sandbox
sandbox_scenario
string | null

Das Sandbox-Szenario, mit dem die Sitzung erstellt wurde. null für Live-Sitzungen und für Sandbox-Sitzungen, die ohne ein solches erstellt wurden.

resubmissions
object[]

Wird nur mit include=resubmissions zurückgegeben, für Benutzer- und Unternehmenssitzungen. Ein Eintrag pro erneuter Einreichungsanfrage, die ältesten zuerst. Jeder Eintrag enthält die Ergebnisse, die die erneut eingereichten Schritte vor der Anfrage zurückgegeben haben, sodass frühere Einreichungen lesbar bleiben. Durch das Löschen der Sitzung werden alle Einreichungen gelöscht.

Gibt an, ob die Sitzung eine ausdrückliche biometrische Einwilligung vor einer Gesichtserfassung erforderte, warum dies der Fall war und welcher Nachweis für die Antwort vorliegt. Nur für Sitzungen der Benutzerverifizierung (KYC); dasselbe Objekt befindet sich in der decision von Sitzungs-Webhooks. null, wenn die Sitzung nie ausgewertet wurde, beispielsweise bei einem Workflow ohne Gesichtserfassung. Felder ohne erfassten Wert sind null. Ein natives SDK unter Version 4.10.0 oder eines, das seine Version nicht meldet, kann den Einwilligungsschritt nicht anzeigen: Seine Gesichtserfassungen laufen wie bisher ab, und eine Sitzung, die eine Einwilligung erforderte, meldet dann status: "pending" mit reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". Siehe Biometrische Einwilligung.

investigator
object | null

Die neueste Investigator-Prüfung des Elements, oder null, wenn es nie eine hatte. Wird von der V3-Sitzungs- und Business-Sitzungsentscheidung übermittelt (und somit von status.updated-Webhooks).

biometric_retention
object

Wann die Live-Biometriedaten dieser Sitzung gelöscht werden.

fraud_check
object | null

Das Ergebnis eines Fraud-Check-API-Aufrufs. null für jede andere Sitzung.

full_session_video
string<uri> | null

Ablaufende URL der Gesamtsitzungsaufzeichnung. Wird nur zurückgegeben, wenn Ihre Organisation Videos der gesamten Sitzung aufzeichnet.

full_session_video_recorded_at
string<date-time> | null

Wann die Aufzeichnung der gesamten Sitzung erstellt wurde. Wird nur zurückgegeben, wenn Ihre Organisation Videos der gesamten Sitzung aufzeichnet.

Zuletzt geändert am 7. November 2026