Overview
The session decision returns the result of every Location verification step in two lists:geolocation_checks[] holds each step’s accepted attempt, and geolocation_attempts[] lists every attempt in order.
Both are on GET /v3/session/{sessionId}/decision/ (see Retrieve session) and in the status.updated webhook.
A workflow with no Location step returns null or an empty list for both.
geolocation_checks[]
One item per Location step (node_id), taken from its newest attempt.
geolocation_attempts[]
Every attempt of every Location step, oldest first, with the same measurement, uncertainty, area and distance fields as geolocation_checks[] except warnings, plus:
Attempts a resubmission retired are left out.
The raw client submission and the challenge are never returned.
Fields for status rules and branches
Customstatus_rules and branch rules can read these fields:
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) and geolocation.consecutive_mismatches.
A missing value matches only is_empty, so a rule written for a fraud signal never fires on missing data.
Related
- Location verification - how the step works and what it costs.
- Location verification warnings - every
LOCATION_*code. - Webhooks -
status.updatedcarries the lists. - Data models - Warning object - the shape of every entry in
warnings[].