将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
TomTom、MapQuest 与 HERE 在企业级地理编码需求上的对比
TomTom、MapQuest 和 HERE 都经常出现在企业采购位置数据的讨论中，而且三者在导航和地图领域都根基深厚，历史比该领域许多新进入者都要悠久。这种共同的历史意味着它们的 API 在结构上有一定相似之处，但它们典型的部署场景差异足够大，在选择其中之一或在它们之间迁移时不容忽视。
TomTom Search 与 TomTom 在导航和汽车领域的传统紧密相关，经常出现在车队管理和车载导航软件中。它的响应格式使用一个 results 数组，其中包含一个 position 对象和一个 address 块，后者包括 freeformAddress 等字段。身份验证方式是查询参数密钥，与大多数面向消费者的地图 API 一致。
MapQuest Geocoding 在三者中拥有最悠久的消费者地图历史，其 API 体现了一种较老但经过充分检验的设计：一个 results 数组，内含一个嵌套的 locations 数组，每个元素都有一个 latLng 对象和地址字段，例如表示城市的 adminArea5。对于重视稳定性和长期可靠记录、胜过新功能集的应用来说，它仍然是一个合理的选择。
HERE Geocoding and Search 更明确地偏向企业和汽车领域，采用 items 数组结构，包含 position 和结构化的 address 字段，身份验证可以使用 API 密钥或 OAuth 令牌，这在从一开始就面向规模更大、更注重安全的企业客户而构建的平台中更为典型。
对于企业买家而言，真正重要的实际差异通常不在于 JSON 字段名（它们都有相当完善的文档，而且思路相似），而更多在于合同结构、客户管理，以及批量定价以往是如何谈判的。而这恰恰是兼容方案可以简化的层面，因为它把地理编码响应格式从决策变量中移除了。
My Geocode 为这三家都运行了兼容主机：TomTom 的 results 和 position 结构位于 /compatibility/tomtom/，MapQuest 的嵌套 locations 数组位于 /compatibility/mapquest/，HERE 的 items 数组位于 /compatibility/here/。正在评估整合方案的企业团队，或者希望减少供应商数量、又不想为目前分别使用这三家中不同一家的各个系统逐一重写解析代码的企业团队，可以在同一个账户和同一种统一定价模式下测试全部三种结构。
这种定价模式完全免去了分档谈判：无需密钥每天 2,500 次免费请求，每个密钥每天另有 2,500 次免费请求（按网络计算），之后是按每次请求 €0.0001 计费的预付额度，或每月 €50 的 Unlimited 密钥，每个端点（包括全部三个兼容主机）无论用量档位如何，定价都完全相同。