Use case

IP Geolocation API for Routing & Regional Experience

Send each request to the nearest region, the right backend, or the correct data boundary — from one lookup.

Where a request originates decides where it should go. One IP lookup gives you the country, EU status, and region to route tenants to the nearest infrastructure, keep data in-region, and pick the right backend — before your app does any real work.


Who uses it

The teams that lean on this most, in rough order of how often we see it.

The signals it uses

Every one ships in the standard response — no add-ons, no tiers.

country / countryCode Pick the nearest region or data centre
is_in_eu Keep EU traffic on EU infrastructure for residency
region Finer routing within large markets
timezone Schedule jobs and support in the user's local time
continent Coarse first-hop routing decisions

How different teams put it to work

The same lookup, applied to how each team routes traffic.

Common questions

How is this different from DNS or CDN routing?

CDN and anycast routing handle static edge delivery. This use case is about application-level decisions — which region or data centre serves a tenant, where data is stored, which backend a checkout hits — based on the country and EU status in the response, resolved in your own code.

Can it help with data residency?

Yes. The country and is_in_eu fields let you keep EU users on EU infrastructure, or pin a tenant to a specific region, from the first request. It's a routing signal, not a legal guarantee — pair it with your storage and processing controls to meet residency obligations.

Is it fast enough to sit in the request path?

Yes. A lookup resolves server-side with a median response under 50ms, so it fits inline in routing logic without noticeable overhead, and results can be cached per session to avoid repeat calls.

Route by region in one request

Free tier: 2,000 lookups/day, no card. Paid plans from $2.50/month. One call per session, under 50ms median response.