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 compatibility hosts matter more than a new SDK
Every API company wants you to install its SDK. An SDK is sticky. Once your codebase imports a client library, calls its methods, and depends on its object shapes, switching providers means rewriting the code that talks to the provider, not just changing a URL. That stickiness is often the real business model behind a free and convenient SDK, whether or not anyone says so out loud.
We took a different approach. My Geocode has 17 compatibility hosts, each of which reproduces another provider's own request and response shape. If your code already knows how to call a well-known geocoding API's endpoint and parse its JSON, you can point that exact code at our compatibility host and it keeps working. No SDK to install, no response parsing to rewrite, no proprietary object model to learn.
This sounds like a small thing until you have actually tried to migrate a production system off an API. The endpoint URL is the easy part. The hard part is every place in your codebase that reaches into a specific field name, handles a specific error shape, or assumes a specific pagination style. Those assumptions get scattered across a codebase over years, in places nobody remembers to check. A compatibility host removes the need to find and fix them, because the shape does not change.
An SDK, by contrast, solves a problem you will only face once, connecting to an API for the first time, at the cost of a problem you will face for the life of the product: being bound to that SDK's design decisions. When the SDK ships a breaking change, you absorb it. When it stops maintaining a language binding you rely on, you absorb that too. A plain HTTP compatibility host has none of that surface area. It is just a URL that returns the response shape you already know how to read.
We are not against SDKs in general. A thin wrapper that saves you from writing HTTP boilerplate is a convenience, not a trap, as long as switching away from it later is not the same project as switching providers. The trap is when the SDK's shapes become the only shapes your code understands, so leaving means rewriting instead of reconfiguring.
Building 17 compatibility hosts was more work for us than building one SDK would have been. Each host has to match another provider's response shape closely, field by field, so existing integrations do not notice the difference. We did that work because it moves the cost of switching from your side to ours. You get to test whether our data, our uptime, and our pricing work for you without first paying an integration cost just to find out. See the full list of compatibility hosts or the docs for how each one maps to the original.
A new SDK asks a developer to trust a company's engineering choices for the life of a project. A compatibility host asks for a lot less: change a base URL, maybe an API key, and see what happens. That is a fairer trade, and it is the reason we built compatibility hosts before we built anything else.