Every IP geolocation API gets asked the same question sooner or later: "why does it say I'm in Wichita?" Fair question. The answer says a lot about how IP location data actually works, and if you're about to build on an IP geolocation API, it's worth ten minutes to understand what's underneath — because the data is genuinely useful, just not for what most people first assume.
Where the location actually comes from
There is no GPS involved. Nobody is triangulating anything. IP geolocation is assembled from public records about who administers address space, mostly:
- Regional registry allocations. The five RIRs (ARIN, RIPE, APNIC, LACNIC, AFRINIC — coordinated by IANA) publish which organization each block is allocated to, and in which country.
- BGP routing announcements. Which network is actually announcing the prefix right now, and from where.
- Operator data. WHOIS records, reverse DNS naming conventions, and the geofeed files some ISPs publish voluntarily.
So the honest description of the result is: "this address belongs to a block registered to this operator, associated with this place." That's a statement about paperwork and routing, not about a device. Which is exactly why it's reliable at some resolutions and shaky at others.
What it's genuinely good at
Country-level decisions
Country resolution is the strong case — registries are literally organized by country. Showing prices in the right currency, defaulting the right language, applying regional compliance rules, deciding whether an order needs extra review: all of these work well on IP data alone.
Knowing what kind of network you're talking to
This is the part that gets underrated. The same records that give you a country also tell you the ASN, the operator, and — with some classification work on top — whether the address is residential broadband, a mobile carrier, a business line, or a hosting provider. A signup from a residential ISP in the customer's claimed city and a signup from a rented server in a datacenter are very different events, even if the form data is identical.
Spotting anonymized traffic
VPN exits, open proxies, Tor relays and datacenter ranges are all identifiable with decent coverage, because they live in address space with recognizable ownership. You usually can't say who is behind a VPN — but you can know that you're talking to one, and treat the session accordingly.
What it can't tell you
Three limits come up constantly:
- Street-level precision doesn't exist. City-level is often right for residential broadband, but it degrades fast. If a vendor implies household accuracy from an IP alone, walk away.
- Mobile networks blur everything. Carrier-grade NAT puts thousands of phones behind a handful of exits, sometimes in another region entirely. A phone in one city can surface hundreds of kilometers away.
- The Wichita problem. When only the country is known, many datasets quietly return the country's geographic centroid as coordinates. For the US, that point is near Wichita, Kansas — which is how a farm there ended up being blamed for years of internet misbehavior it had nothing to do with.
That last one is why we return a coordinate_source field and a confidence value on every lookup instead of pretending precision we don't have. If the coordinates are a country centroid, the response says so:
curl "https://ip.geoverio.com/v1/ip/8.8.8.8" \
-H "Authorization: Bearer YOUR_API_KEY"{
"ip": "8.8.8.8",
"location": {
"country": "US",
"latitude": 38,
"longitude": -97,
"coordinate_source": "country_centroid",
"confidence": 0.6
},
"network": {
"asn": 15169,
"org": "Google LLC",
"prefix": "8.8.8.0/24"
}
}A confidence of 0.6 with a centroid source means "US, definitely; the dot on the map, don't trust." Your code can branch on that. Ignoring it is how you end up drawing user maps that cluster in Kansas.
Patterns that hold up in production
Treat IP location as a signal, not a verdict. Use it to decide how much friction to apply — a challenge, a review queue, a different default — rather than as the sole reason to block someone. Legitimate users travel, use VPNs at work, and sit behind weird corporate egress.
Check the network type before the location. "Datacenter IP claiming to be a first-time retail customer" is a stronger fraud signal than any city mismatch. It's also cheaper to act on, since it doesn't depend on precision you may not have.
Cache aggressively. Allocations and routing change on the scale of days and weeks, not milliseconds. Caching lookups for 24 hours is safe for most applications and cuts your bill accordingly.
Handle the honest nulls. A good API returns null for a city it doesn't know rather than a guess. Make sure your UI and your rules have a path for "country only" — it will happen a lot, especially on mobile traffic.
Trying it against real addresses
The fastest way to calibrate your expectations is to look up traffic you already understand: your office egress, your phone on cellular data, your home connection, a cloud VM you rent. You'll see exactly where the data is sharp and where it goes vague — and you'll know that before your users do.
The IP Lookup docs cover the full response — network ownership, connection type, VPN/proxy/Tor detection and a scored risk assessment with the reasons listed out. A free key is enough to run all of the experiments above.