The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
Why we didn't build a browser SDK first
A browser SDK is an easy thing to ask for and a genuinely bad idea for a lot of what a geocoding or IP lookup API actually does. Resolving an IP address to a location is meaningful specifically because it happens on the server, where the request's real origin is visible. Ship that same lookup into client-side JavaScript running in a visitor's browser and you have not made the integration more convenient. You have moved an authenticated API key into the one place on the entire request path where anyone can open developer tools and read it.
This is why we did not prioritize a browser SDK ahead of plain HTTP support and compatibility hosts. A key accepted as an X-API-Key header, a Bearer token, HTTP Basic auth, or a query parameter works the same on every host, called from wherever your server-side code already lives: a backend service, a serverless function, a batch job, anywhere the request already has a reason to originate from infrastructure you control rather than a browser tab you do not.
IP geolocation specifically only makes sense server side. The entire value of the lookup comes from resolving the actual IP address making the request, which for most meaningful use cases, fraud checks, localization, analytics you control yourself rather than sell, needs to happen where that IP address is authoritative: your server, receiving the request directly, not a browser environment where the "IP" a client-side call would report is either irrelevant or trivially spoofable.
Geocoding a typed address is less clearly server-only, and there is a real argument for wanting address autocomplete to feel responsive directly in a form, in the browser, without a round trip through your own backend first. We are not against that pattern existing eventually. We are against building it as the first and primary integration path, ahead of the plain server-side HTTP access that the majority of real use cases, checkout flows, shipping calculators, fraud checks, actually need and that does not require exposing a credential to the public.
The broader pattern we are pushing back on is treating "ships a browser SDK" as a checkbox every API is expected to have, regardless of whether client-side access to that particular kind of data makes sense. For a lookup where the server-side context is the entire point, a browser SDK mostly just answers a marketing question, "does this look modern and convenient", at the cost of a real security question, "where does this credential end up living." We would rather answer the security question first and let convenience follow it, not the other way around.
None of this rules out a lighter, browser-friendly tool eventually, scoped specifically to the cases where client-side use genuinely makes sense, like a form autocomplete that never needs your account's real credential to function. What it should not be is the first thing we ask a customer to trust, ahead of the plain HTTP path that already covers the majority of real integrations safely.