What we shipped this month: geocoding, IP, time zone and more
A roundup of recent work across the API: new compatibility hosts, faster time zone and elevation lookups, dashboard features, and clearer quota visibility.
Seventeen compatibility hosts is a lot to keep track of one announcement at a time, so we put all of them in a single place: a compatibility matrix at /compatibility/ listing every drop-in host we support, side by side, with a direct link to each one's own documentation.
The list covers Google Maps Platform, Bing Maps REST Services, HERE Geocoding and Search, Mapbox Geocoding, Geocode.Farm, OpenStreetMap Nominatim, OpenCage, LocationIQ, Geoapify, TomTom Search, MapQuest Geocoding, Geocodio, PositionStack, ip-api.com, ipinfo.io, ipstack and Open-Elevation. Between them, that covers geocoding, IP geolocation and elevation lookups, reproducing each original provider's request and response shape exactly, aside from copyright, terms and privacy text, which is ours.
The point of putting them on one page is not just tidiness. It means a team weighing which provider to move away from can see the full field at once, rather than discovering compatibility hosts one at a time through separate announcements. If your stack touches more than one of these providers, whether that is Mapbox for geocoding and ipinfo.io for IP lookups, or any other combination, the matrix makes it clear that all of them can be consolidated behind one My Geocode account and one key.
That consolidation is the real advantage of the compatibility approach generally. A single key authenticates against every host on the list, using whichever of our four standard methods your integration already prefers: an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter. Usage across all of them counts toward the same free allowance, the same prepaid credit balance, or the same Unlimited package, and every response, regardless of which host produced it, carries the same quota headers. One account, one key, one bill, covering however many separate providers your integration used to depend on.
For teams considering a broader migration rather than swapping a single provider, this matrix is the natural starting point, and general migration guidance sits alongside it at /docs/compatibility/. Each host's own documentation page covers the specific request parameters and any details worth knowing before switching.
We plan to keep this page current as compatibility coverage evolves, so it remains the single reference for what is available rather than something that goes stale between individual announcements.