Monitor your key's usage before you hit a limit
Watching your quota headers as you go tells you when a limit is approaching, well before a request actually gets rejected.
The browser's built-in location prompt asks for GPS-level precision and requires an explicit permission click, which a lot of visitors decline on reflex. A "detect my location" button does not have to go through that dialog at all if approximate location is good enough for what you are building.
When the button is clicked, submit a request to your own server, which already sees the visitor's IP address on the connection. Look that address up against /v1/ip and use the result directly, with no browser permission dialog involved at any point.
GET /v1/ip{
"status": "ok",
"ip": "198.51.100.23",
"version": 4,
"found": true,
"country": "Italy",
"country_code": "IT",
"region": "Lombardy",
"city": "Milan",
"postcode": "20121",
"lat": 45.4642,
"lon": 9.1900,
"timezone": "Europe/Rome",
"asn": 3456,
"org": "Example ISP"
}Calling the endpoint with no ip parameter, as shown here, looks up whichever address made the request, which is exactly the visitor's own address when your backend calls it on their behalf.
IP-based location is city-level at best, not GPS precision. Label the feature honestly, something like "detect my approximate area" rather than implying pinpoint accuracy, so a visitor is not surprised when the result is a city center rather than their exact street.
The same button pattern works for showing region-appropriate pricing or currency context on a landing page. Since every price is quoted in EUR regardless of visitor location, a button like this would be used to prefill a shipping estimate or a regional contact number rather than to change the currency shown, but the underlying request is identical, one IP lookup returning enough to fill in city and country immediately.
This approach fits store locators, regional content defaults, and shipping estimates, where a city or region is all that is needed. It does not replace GPS location for something like turn-by-turn navigation, where the browser prompt and real device location are genuinely necessary.
Do not treat a corporate network or VPN connection as a special error case that needs handling differently from any other lookup. The endpoint will still return a result, just one centered on wherever that network's registered address happens to be, which can be a different city or even a different country from where the visitor is actually sitting. The right response is the same one you would give for any IP-based estimate: let the visitor override it, rather than trying to detect and specifically flag VPN traffic as unusual.
If found comes back false, which can happen for some address ranges, fall back to asking the visitor to type a location manually rather than showing an error, since the whole point of the button was to save that step, not to introduce a dead end.
Each click is one request. A button used occasionally by visitors stays a tiny fraction of the 2,500 free requests a day included with every key or available from a single address without one. Both IPv4 and IPv6 visitors resolve through the same call, so there is no separate code path needed for either version.
Skipping the permission dialog trades precision for convenience, which is the right trade for a lot of location features. The IPv4 lookup docs cover the endpoint's full response.