Skip to main content

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

Custom status_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.
Last modified on October 31, 2026