Skip to main content
POST
IP Jurisdiction
Resolves the applicant’s IP address to a jurisdiction (via MaxMind GeoLite2) and evaluates it against the session’s ip-jurisdiction step configuration — allowed/blocked jurisdiction lists, plus optional datacenter-IP handling. Persists its result to the session. Jurisdictions are compared as ISO 3166 codes: a country (CA, US) or a country-subdivision (CA-ON, US-WA). The resolved location matches a list entry if either its country code or its country-subdivision code is listed. Evaluation order: blocked list → allowed list (when non-empty) → datacenter rule.
This check fails open on unknown locations. A valid IPv4 address that can’t be geolocated — private (10.x, 192.168.x), loopback, reserved, or documentation ranges such as 203.0.113.x, or a lookup miss — returns CLEAR / allow with evidence.locationDetails: "Unknown", because the jurisdiction lists can’t be applied. Validate that ip_address is the applicant’s public address before calling, and treat a "Unknown" location as no signal rather than a pass.
This check fails soft. If an internal error occurs, or the supplied ip_address isn’t a valid IPv4 address, it returns 200 with verdict: "UNAVAILABLE" and action: "allow" rather than blocking or erroring.

Request

Headers

Body parameters

Bodies use snake_case field names — there are no camelCase aliases.

Example request

Response

200 — Success

Verdicts

Evidence

trusted_ip_list entries (CIDRs, or ASNs like AS64496) exempt an IP from the datacenter rule only — they don’t bypass the jurisdiction lists.

Error responses