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. The step must list at least one allowed or blocked jurisdiction. Creating a workflow whose IP_JURISDICTION step has both lists empty returns 400. See Create workflow → Step configuration.
This check fails open on unknown locations. A valid IP 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, it returns 200 with verdict: "UNAVAILABLE" and action: "allow" rather than blocking or erroring. A value that isn’t a valid IPv4 or IPv6 address returns 400.

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.

Step not configured

If the session’s workflow doesn’t include the IP_JURISDICTION step, or the session has no workflow, the check returns 409 and nothing is evaluated or stored. Add the step to the workflow first.

Error responses