Enforce data residency for a region

Routeplane can hard-lock regulated personal data to providers resident in a given jurisdiction. The lock engages only when a request actually carries regulated data, so the header is a safe no-op on ordinary traffic. For the model behind this, see Sovereign routing.

Set the jurisdiction

Pass the region in x-routeplane-residency (or set it as the key's server-side default). The header can narrow the default but never disable it.

bashpin to India (IN)

curl -s https://<gateway-host>/v1/chat/completions \
  -H 'content-type: application/json' \
  -H 'x-routeplane-api-key: rp_...' \
  -H 'x-routeplane-residency: IN' \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"My PAN is ABCDE1234F"}]}'

The classifier detects regulated identifiers (Aadhaar, PAN, email, phone today). When it fires and a jurisdiction applies, routing is restricted to in-region providers, no client header or routing config can widen that lock.

Understand the fail-closed behavior

It fails closed. If a request carries regulated data and no in-jurisdiction provider is eligible, Routeplane refuses with 422 rather than let the data leave the region. Enforcement is per request, not per deployment, so one gateway safely serves both regulated and ordinary traffic.

To guarantee a request can be served in-region, make sure the key has at least one resident provider configured for that jurisdiction (for India that is typically an Azure OpenAI deployment in an Indian region). See Configuration.