将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
ipstack、ip-api.com 与 ipinfo.io：比较数据结构
IP 地理定位提供商大多使用类似类别的底层数据：国家、地区、城市、坐标和网络归属，但它们以明显不同的结构来组织这些数据，而在评估或切换提供商时，这些结构决定了相当大一部分实际集成工作，多得出人意料。
ip-api.com 偏好扁平结构。country、regionName、city、lat、lon、isp 和 query 等字段直接位于响应的顶层，没有任何嵌套，因此读取速度快，也很容易映射到扁平的数据库行或单行日志。
ipinfo.io 将两对常常成对出现的值压缩成单个字符串：loc 字段以逗号分隔的字符串同时保存纬度和经度，org 字段则把自治系统编号和组织名称合并在一个字符串中，形式类似于一个 AS 编号后跟公司名称。这对于记录日志和快速显示很高效，但在将任一值作为真正的数字使用或进行程序化比较之前，需要先做一次拆分操作。
ipstack 则走向另一个方向，结构更多。它将 type、continent_code、latitude 和 longitude 等顶层字段作为独立的值返回，并把网络和 ISP 详情归入一个嵌套的 connection 对象，而不是一个扁平的字符串，这适合希望将这些详情作为一块独立数据来处理的应用。
这三种结构没有哪一种客观上更好，它们反映的是对调用方如何使用数据的不同假设。扁平结构更便于快速编写临时解析代码。紧凑的合并字符串结构对于每个请求存储一行的日志管道很高效。嵌套结构则让相关字段保持分组，适合构建更复杂内部数据模型的应用。
My Geocode 为这三种结构都提供了兼容主机：ip-api 的扁平字段见 /compatibility/ip-api/，ipinfo 的紧凑 loc 和 org 字符串见 /compatibility/ipinfo/，ipstack 的嵌套 connection 对象见 /compatibility/ipstack/。这意味着像这样的比较不必以为所有人选出唯一的赢家告终；团队可以运行其现有代码已经预期的任何一种结构，甚至可以在评估期间针对同一份底层查询数据测试不止一种结构，因为这三个主机都位于同一平台上，采用相同的认证选项和相同的价格。
由于这里的 IP 查询是端到端完全可用的，而不只是模拟结构，因此可以直接测试这种比较：用一个小脚本以相同的测试 IP 地址访问这三个兼容主机，比较您自己的解析代码实际会收到的输出结构。它们中任何一个的认证都接受 X-API-Key 请求头、Authorization: Bearer、HTTP Basic 认证或查询参数，而且三个主机都无需密钥即可每天免费请求 2,500 次，这使得在确定采用某种结构之前进行并排的结构比较，成本很低。