Zum Hauptinhalt springen
POST
Python
Übermitteln Sie eingegebene Identifikatoren und angegebene Identitätsattribute, wählen Sie die auszuführenden Prüfungen aus und prüfen Sie jedes Ergebnis separat. Verwenden Sie zuerst Betrugsprüfung planen, um Eingabeanforderungen und geschätzte Kosten zu prüfen.

Profil auswählen

Fixieren Sie profile_version, damit die gewählten Standardwerte und die Entscheidungsrichtlinie explizit festgelegt sind. Das Standardprofil ist standard, Version 2026-08-27. Version 2026-09-14 fügt optionales Social Enrichment für E-Mail-Adresse und Telefonnummer hinzu und erfasst jede abgeschlossene Prüfung als native Sitzung der Benutzerverifizierung. In dieser Version sind kostenpflichtige Zusatzleistungen optional und müssen aktiv ausgewählt werden. Version 2026-09-14.1 aktiviert außerdem Abfragen von Identifikatoren im globalen Betrugsnetzwerk für Organisationen im Enterprise-Tarif, die weltweit Daten teilen. Version 2026-09-14.2 fügt eine optionale Selfie-zu-CPF-Referenzprüfung für Brasilien hinzu. Frühere Versionen behalten ihr ursprüngliches Verhalten bei. Die aktuellen Profile unterstützen das Risiko von E-Mail-Adressen, das Telefonrisiko, das IP-Risiko, geeignete Datenbankvalidierung und die private Netzwerkhistorie Ihrer Anwendung. Die auf Selfies basierende Identitätsbindung erfordert Version 2026-09-14.2. Wird sie in früheren Versionen ausgewählt, gibt die Anfrage not_available_in_profile_version zurück.

Angegebene Identität und Kontext

Übergeben Sie E-Mail-Adresse, Telefonnummer und staatliche Identifikatoren in subject.identifiers. Staatliche Identifikatoren erfordern das ausstellende Land; manchmal wird zusätzlich ein Aussteller benötigt, wenn Nummern nur innerhalb einer Region eindeutig sind. Übergeben Sie Namen, Geburtsdatum, Staatsangehörigkeit und Adresse in subject.attributes. Diese Angaben sind Behauptungen, die dort verglichen werden, wo eine ausgewählte Quelle sie unterstützt. Dass sie übermittelt wurden, macht sie nicht zu verifizierten Fakten. Verwenden Sie context für die IP-Adresse des Verifizierungsversuchs, den User-Agent, den Zweck, das Land und jede erforderliche Einwilligungserklärung. So wird getrennt, welche Informationen den Verifizierungsversuch betreffen und welche die Person. Für unterstützte biometrische Prüfungen übergeben Sie subject.selfie als Base64-codiertes JPEG, PNG oder WebP mit maximal 6 MB. Eine passende Bilddaten-URI wird ebenfalls akzeptiert. Senden Sie kein Referenzbild, keine externe URL und keinen Speicherschlüssel.

Selfie und angegebener Identifikator

Wählen Sie biometric_identity, übermitteln Sie einen brasilianischen tax_number-Identifikator und ein Selfie und bestätigen Sie context.consent_obtained. Die Referenzprüfung stellt fest, ob dieses Selfie zu der Inhaberin bzw. dem Inhaber der angegebenen CPF gehört. Fehlt die Einwilligung, gibt die Anfrage consent_required zurück. Bei nicht unterstützten Ländern wird unsupported_region zurückgegeben. Das Modul hat einen Preis pro Prüfung, der auf dem Datenbankvalidierungstarif Ihrer Organisation basiert. Prüfen Sie den Tarif, bevor Sie die Prüfung ausführen. Wenn die Referenzprüfung eine Antwort liefert, ist identity_relationship.result entweder match, mismatch oder inconclusive. Eine nicht eindeutige Antwort erfordert eine manuelle Prüfung und wird niemals als Nichtübereinstimmung behandelt. Das Ergebnis stellt nur die Beziehung zwischen Selfie und CPF fest. Es validiert keinen übermittelten Namen oder Geburtsdatum, beweist keine Lebenderkennung und sucht kein Gesicht im Internet oder im globalen Betrugsnetzwerk. Namen und Geburtsdatum bleiben Behauptungen, sofern keine andere ausgewählte Quelle Nachweise für diese Felder liefert. Zeitüberschreitungen und Quellfehler sind nicht verfügbare Ergebnisse und werden nicht berechnet. Abgeschlossene, nicht eindeutige Antworten werden mit demselben Preis pro Referenzprüfung berechnet. Das Selfie wird von dieser Prüfung weder im Ergebnis aufgenommen noch als Sitzungsmedium gespeichert.

Prüfungen auswählen

checks.include wählt Module aus, und checks.exclude hat Vorrang. Eine explizit leere include-Liste deaktiviert alle optionalen Verarbeitungsschritte; die Normalisierung läuft weiterhin. Wenn include fehlt, werden die Standardwerte des fixierten Profils verwendet. Social Enrichment für E-Mail-Adresse und Telefonnummer wird separat mit email_social und phone_social ausgewählt. Dafür sind ein gültiger, passender Identifikator erforderlich. Es wird kein OTP gesendet.

Ergebnisse getrennt lesen

Jedes Modul meldet seinen Ausführungsstatus, den Grund und die abrechenbaren Einheiten. not_requested, excluded_by_caller, missing_required_input und source_unavailable beschreiben unterschiedliche Ergebnisse. Eine fehlende Quelle ist weder eine Nichtübereinstimmung der Identität noch ein Ergebnis ohne Risiko. attribute_evidence beschreibt Nachweise auf Feldebene, während risk die Dimensionen Identität, Kontakt, Gerät, Verhalten und globales Betrugsnetzwerk getrennt hält. Eine gemeinsam genutzte E-Mail-Adresse, ein gemeinsames Gerät oder ein anderer gemeinsamer Identifikator ist eine beobachtete Verbindung. Sie ist kein Beweis dafür, dass zwei Konten zur selben Person gehören oder dass Betrug begangen wurde. recommendation ist die Empfehlung der Prüfung; sie ändert nicht den Status eines anderen Datensatzes. Ergebnisse des Social Enrichment erscheinen unter enrichment. Nicht verfügbare Ergebnisse werden dabei klar von abgeschlossenen Ergebnissen unterschieden.

Globales Betrugsnetzwerk

Wählen Sie networks_cross_org aus, um unterstützte E-Mail-Adressen, Telefonnummern und korrekt mit Namespace versehene Dokumentkennungen im gemeinsamen Netzwerk abzufragen. Die Abfrage erfordert den Enterprise-Tarif und einen auf global gesetzten Freigabemodus Ihrer Organisation. Fehlen diese Voraussetzungen, meldet der Tarif das Modul mit available: false und availability_reason: "entitlement_required". Eine Prüfung, die dieses Modul auswählt, überspringt es mit dem Status skipped und dem Grund entitlement_required. Derselbe Grund gilt, wenn Networks für Ihre Organisation nicht aktiviert ist. Sandbox-Anwendungen unterliegen weder dem Tarif noch dem Freigabemodus: Bei einer unterstützten Kennung läuft das Modul und liefert ein leeres Beispielergebnis. Die Abfrage nutzt das bestehende Lesekontingent Ihrer Organisation und protokolliert den Lesezugriff im Audit-Log. Sie verursacht keine Gebühr pro Abfrage. Das Planen einer Prüfung fragt den gemeinsamen Index nicht ab und verbraucht sein Lesekontingent nicht. network.cross_organization enthält signals_checked und die offengelegten aggregierten insights, sobald die Prüfung abgeschlossen ist. Jede Erkenntnis enthält den Signaltyp, die Ergebnisklassen, die Anzahl der Beitragenden, die Aktualitätsklasse und die Branchenkategorien, aber Letztere nur, wenn die Offenlegung aktiviert ist. Er identifiziert niemals eine andere Organisation, ein anderes Konto, eine andere Person oder eine andere Verifizierung. Ergebnisse unterhalb des Schwellenwerts für die Offenlegung werden weggelassen. Eine leere Liste belegt nicht, dass keine Betrugshistorie vorliegt. Ein offengelegtes gemeinsames Signal löst eine Prüfempfehlung aus, niemals eine automatische Ablehnung oder einen Identitätsabgleich. Eine nicht verfügbare Abfrage meldet ihren Grund getrennt von einer abgeschlossenen, leeren Abfrage. Verliert Ihre Organisation später den organisationsübergreifenden Zugriff, etwa nach einer Tarifänderung oder wenn der Freigabemodus nicht mehr global ist, blenden das Abrufen von Ergebnissen, Wiederholungsversuche und Sitzungsdetails die gemeinsamen Aggregate und die daraus abgeleiteten Risikonachweise aus. Die ursprüngliche Empfehlung bleibt eine historische Entscheidung. Lesezugriffe ändern den Verifizierungsstatus nicht.

Sitzungen, Wiederholungsversuche und Gebühren

check_id ruft das gespeicherte Ergebnis über Betrugsprüfung abrufen ab. Wenn vorhanden, kennzeichnet request_id die zugehörige native Verifizierungssitzung. Die Versionen 2026-09-14, 2026-09-14.1 und 2026-09-14.2 erstellen diese Sitzung immer, auch wenn nur die private Netzwerkhistorie ausgewählt ist. Wenn Sie client_reference mit demselben Anfragekörper erneut verwenden, gibt die Anfrage das ursprüngliche Ergebnis zurück, ohne eine weitere Ausführung oder Gebühr, solange diese Prüfung existiert. Ein anderer Anfragekörper mit derselben Referenz liefert 409. Läuft die Ausführung noch, wiederholen Sie dieselbe Anfrage nach dem Intervall aus Retry-After in der Antwort. Wird die zugehörige Verifizierung gelöscht, wird auch das Ergebnis der Betrugsprüfung gelöscht; der Abruf liefert danach 404. Eine Prüfung, die während der Ausführung gelöscht wird, kann kein abgeschlossenes Ergebnis veröffentlichen. Die Preise richten sich nach den aktuellen Vorauszahlungs- oder Vertragstarifen Ihrer Organisation. Nicht verfügbare und übersprungene Module werden nicht berechnet, und die private Netzwerkhistorie hat keine Gebühr pro Prüfung. Sandbox-Prüfungen verwenden Beispielantworten ohne kostenpflichtige Anfragen an Anbieter und ohne Gebühren.

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.

Body

subject
object
erforderlich
client_reference
string

Ihre eigene Referenz für diese Prüfung. Dient gleichzeitig als Idempotenzschlüssel: Bei Wiederverwendung mit demselben Body wird die ursprüngliche Prüfung zurückgegeben, ohne die Module erneut auszuführen oder abzurechnen; bei Wiederverwendung mit einem anderen Body wird 409 zurückgegeben.

Required string length: 1 - 255
profile
string
Standard:standard

Orchestrierungsprofil-ID. Standardmäßig das Didit-Profil standard.

Required string length: 1 - 64
profile_version
string

Eine eingefrorene Profilversion anpinnen. Standardmäßig die aktuelle Version des Profils.

Required string length: 1 - 32
context
object
checks
object
vendor_data
string
Maximum string length: 1000
metadata
any

Antwort

check_id
string<uuid>
erforderlich
client_reference
string | null
erforderlich
processing_status
enum<string>
erforderlich
  • pending - Ausstehend
  • running - Wird ausgeführt
  • completed - Abgeschlossen
  • failed - Fehlgeschlagen
Verfügbare Optionen:
pending,
running,
completed,
failed
profile_id
string
erforderlich
profile_version
string
erforderlich
created_at
string<date-time>
erforderlich
completed_at
string<date-time> | null
erforderlich
inputs
object[]
erforderlich
modules
object[]
erforderlich
attribute_evidence
object[]
erforderlich
compound_evidence
object[]
erforderlich
risk
object[]
erforderlich
network
object
erforderlich
recommendation
enum<string>
erforderlich
  • approve - Genehmigen
  • review - Prüfen
  • reject - Ablehnen
Verfügbare Optionen:
approve,
review,
reject
next_action
enum<string>
erforderlich
  • none - Keine
  • manual_review - Manuelle Prüfung
  • step_up - Step-Up
  • resubmit_capture - Erneute Erfassung einreichen
Verfügbare Optionen:
none,
manual_review,
step_up,
resubmit_capture
decision_reasons
string[]
erforderlich
coverage
object
erforderlich
usage
object[]
erforderlich
request_id
string<uuid>

Native-Verifizierungssitzung, die für diese Prüfung erstellt wurde.

enrichment
object
identity_relationship
object | null
vendor_data
string | null
metadata
unknown
Zuletzt geändert am 7. November 2026