Migrating a Zapier or Make automation to a new geocoding host
No-code automations built on a geocoding step need a different migration approach than custom code does. Here is how to handle that switch.
Migrating from Google Maps Platform: what changes, what stays
Google Maps Platform is often the first geocoding API a team ever wires up, mostly because it is the biggest name in the room. Its authentication model is familiar to most developers by now: an API key tied to a billing account inside a Google Cloud project, sent as a query parameter on every request. Its geocoding responses come back as a JSON object with a results array, a status field, a formatted_address string, and a nested geometry.location object holding latitude and longitude.
The part that usually worries teams about switching is the parsing code built around that exact shape. Address components, viewport bounds, place IDs, all of it gets read by functions scattered across a codebase, and rewriting those functions is the kind of task nobody wants to schedule. This is the specific problem a compatibility host is built to avoid.
My Geocode runs a Google Maps compatibility host that reproduces Google's own geocoding request and response format field for field. The only text in the response that belongs to us is the copyright, terms, and privacy language; everything else, including field names and nesting, matches what your code already expects. In practice, migrating means changing a host name and a key, not touching a parser. Details are at /compatibility/google-maps/.
What stays the same:
- The JSON structure your code already parses
- The query parameter style for sending a key, if that's what your client uses
- The general request pattern (address in, structured location data out)
What changes:
- The host you send requests to
- The key itself, issued by us instead of Google
- The billing account requirement, replaced by a simpler credit or subscription model
Because a key can be sent as an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter, a client library that already authenticates its own particular way tends to keep working without modification. That flexibility matters more than it sounds like it should, since a lot of migration pain in practice comes from libraries that assume one specific way of passing credentials.
On pricing, the model is simple: 2,500 requests a day are free from any address with no key required, and every key also gets 2,500 free requests a day counted per network. Past that, it is prepaid credit at €0.0001 per request, or an Unlimited package at €50 a month, and every endpoint including every compatibility host costs the same. There are no separate tiers to negotiate depending on which product you call.
Optional extra fields, ground elevation, IP threat signals, and network detail, are available on any compatibility host by adding mg_extras=1 or an X-MG-Extras header, without breaking the shape the rest of your code depends on. That gives you a path to richer data later without a second migration.
If your integration also touches reverse geocoding, autocomplete, or postal code lookups, the same host-and-key swap applies, though the exact request and response shape for those endpoints is worth reviewing against your current code before you cut over, since address formatting conventions vary by country. Testing a slice of production traffic against the new host before the full switch is a reasonable way to confirm the shape lines up with what you expect. See /docs/compatibility/ for the full field reference across all compatibility hosts.