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.
ipstack vs ip-api.com vs ipinfo.io: comparing the shape of the data
IP geolocation providers mostly draw on similar categories of underlying data, country, region, city, coordinates, and network ownership, but they package it in noticeably different shapes, and those shapes drive a surprising amount of the actual integration work when you evaluate or switch between them.
ip-api.com favors a flat structure. Fields like country, regionName, city, lat, lon, isp, and query sit directly at the top level of the response with no nesting, which makes it fast to read and simple to map onto a flat database row or a single log line.
ipinfo.io compresses two commonly paired values into single strings: a loc field holding latitude and longitude together as a comma-separated string, and an org field that combines the autonomous system number and organization name in one string, something like an AS number followed by a company name. This is efficient for logging and quick display but requires a split operation before either value can be used as a proper number or compared programmatically.
ipstack goes the other direction with more structure. It returns top-level fields like type, continent_code, latitude, and longitude as separate values, and groups network and ISP detail into a nested connection object rather than a flat string, which suits applications that want that detail treated as its own distinct piece of data.
None of these three shapes is objectively better; they reflect different assumptions about how a caller will use the data. A flat structure is faster to write ad hoc parsing code against. A compact combined-string structure is efficient for logging pipelines that store one line per request. A nested structure keeps related fields grouped for applications building a more elaborate internal data model.
My Geocode runs compatibility hosts for all three of these exact shapes: ip-api's flat fields at /compatibility/ip-api/, ipinfo's compact loc and org strings at /compatibility/ipinfo/, and ipstack's nested connection object at /compatibility/ipstack/. This means a comparison like this one does not have to end in a single winner chosen for everyone; a team can run whichever shape its existing code already expects, or even test more than one shape against the same underlying lookup data during an evaluation, since all three hosts sit on the same platform with the same authentication options and the same pricing.
Because IP lookups are fully working end to end here, not shape-only, this comparison can be tested directly: point a small script at all three compatibility hosts with the same test IP addresses and compare the actual output structure your own parsing code would receive. Authentication for any of them accepts an X-API-Key header, Authorization: Bearer, HTTP Basic auth, or a query parameter, and 2,500 requests a day are free with no key needed on any of the three, which makes a side-by-side structural comparison a low-cost exercise before committing to one shape over another.