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 migration should take an afternoon, not a quarter
A migration project that gets scoped as a quarter of engineering time to switch a location data provider is usually not a quarter of genuinely necessary work. It is a quarter of work created by design decisions made years earlier: a proprietary response format that has to be unwound field by field, an SDK whose method calls are scattered through a codebase in places nobody documented, error handling built around one provider's specific status codes. None of that complexity is inherent to the idea of looking up an address or an IP. All of it is inherited from choices that made the original integration convenient at the cost of making a future migration expensive.
We built 17 compatibility hosts specifically to make that quarter unnecessary for anyone whose existing integration already speaks one of those provider shapes. If your code calls a well-known geocoding or IP API's endpoint and parses its specific response format, pointing that same code at our matching compatibility host should require changing a base URL and an API key, not rewriting the parsing logic that has been working fine for years. Authentication accepts a key as a header, a bearer token, HTTP Basic auth, or a query parameter, so whatever pattern your existing code already uses is very likely already supported.
An afternoon-scale migration is not a claim we make lightly, because we know exactly how much effort it took on our side to make that true: matching another provider's response shape field by field, testing it against real requests, and holding that shape stable so a customer's existing code has no reason to notice a difference beyond where the request goes. That work is front loaded onto us specifically so it does not have to happen, again, downstream, in every customer's codebase that wants to test whether switching is worth it.
The broader point extends past our own compatibility hosts: a migration that takes a quarter is diagnostic information about the previous integration, not a natural property of switching providers in general. If leaving a provider requires a multi-month project, someone, somewhere, benefited from that friction existing, whether or not it was built deliberately to create it. A provider genuinely confident in its data, pricing, and reliability has no reason to make switching away difficult, because the entire pitch should be that a customer who tries it will not want to leave, not that leaving is too expensive to attempt.
We would rather compete on whether the product is worth staying with, evaluated honestly, on the same afternoon a customer could just as easily switch away. Making that afternoon possible cost us real engineering effort. We think it is effort that should have been spent, and that any provider unwilling to spend it is quietly telling you something about how confident it actually is in what it is selling.