Regional availability
KINDI is deliberately a Saudi-only service, at both the network edge
and the data layer.
Which hosts are reachable from where
| Host | Reachable from |
api.kindi.me | Saudi IP addresses only |
dashboard.kindi.me | Saudi IP addresses only |
admin.kindi.me | Saudi IP addresses only |
kindi.me (marketing) | Worldwide |
docs.kindi.me (this site) | Worldwide |
A request to a geo-restricted host from outside Saudi Arabia receives a
bare
403 with no response body. The block happens at the edge
proxy, before the application, so there is no {"detail": ...} JSON to
parse; it is not an authentication failure, and no retry, key re-mint,
or session refresh will change the outcome. See
Error codes for how to tell it apart from an auth
403.Practical consequences:
- Call the API from infrastructure inside Saudi Arabia (your KSA-region backend), not from an end user's browser abroad.
- A CI pipeline or serverless function running outside KSA cannot reach
api.kindi.me; run integration tests from a KSA-hosted runner or mock the API. - The geo lookup is performed offline at the edge; visitor IP addresses are not sent to any third party.
Data residency
All KINDI infrastructure (the API, detection service, database, and file
storage) runs in a single region inside Saudi Arabia. Request text
is processed in-region and never leaves it as part of masking;
/mask
mappings exist only inside the encrypted envelope returned to you, and
nothing recoverable is persisted server-side.The one path where data leaves the region is the one you explicitly
configure: the LLM Proxy forwards your masked
prompt to the provider you chose (OpenAI or Anthropic), which is the
point of masking it first.
Questions about residency or compliance posture: see the
security page or contact us.