Zum Hauptinhalt springen

Übersicht

Die Sitzungsentscheidung gibt das Ergebnis jedes Standortverifizierungsschritts in zwei Listen zurück: geolocation_checks[] enthält den akzeptierten Versuch jedes Schritts und geolocation_attempts[] führt jeden Versuch in chronologischer Reihenfolge auf. Beide befinden sich unter GET /v3/session/{sessionId}/decision/ (siehe Sitzung abrufen) sowie im Webhook status.updated. Ein Workflow ohne Standortschritt gibt für beide null oder eine leere Liste zurück.

geolocation_checks[]

Ein Element pro Standortschritt (node_id), basierend auf dessen neuestem Versuch.

geolocation_attempts[]

Jeder Versuch jedes Standortschritts, der älteste zuerst, mit denselben Feldern für Messung, Unsicherheit, Bereich und Distanz wie in geolocation_checks[] mit Ausnahme von warnings, plus: Versuche, die durch eine erneute Einreichung hinfällig wurden, werden weggelassen. Die rohe Client-Einreichung und die Challenge werden niemals zurückgegeben.

Felder für Statusregeln und Verzweigungen

Benutzerdefinierte status_rules und Verzweigungsregeln können die folgenden Felder auslesen: geolocation.status, geolocation.outcome, geolocation.permission, geolocation.latitude, geolocation.longitude, geolocation.accuracy_m, geolocation.accuracy_confidence, geolocation.age_seconds, geolocation.measured_at, geolocation.source, geolocation.platform, geolocation.country (ISO 3166-1 alpha-3), geolocation.region, geolocation.city, geolocation.is_mock, geolocation.integrity, geolocation.inside_geofence, geolocation.ip_distance_km, geolocation.ip_consistent, geolocation.document_distance_km, geolocation.attempts, geolocation.consent_at, geolocation.inside_areas, geolocation.blocked_areas, geolocation.anonymizers (vpn, proxy, tor, spoofing, emulator) und geolocation.consecutive_mismatches. Ein fehlender Wert entspricht nur is_empty, sodass eine für ein Betrugssignal definierte Regel niemals bei fehlenden Daten auslöst.

Verwandte Themen

Zuletzt geändert am 7. November 2026