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.
TomTom vs MapQuest vs HERE for enterprise geocoding needs
TomTom, MapQuest, and HERE all show up in enterprise procurement conversations for location data, and all three have deep roots in navigation and mapping that predate a lot of the newer entrants in the space. That shared history means their APIs carry some structural similarity, but their typical deployment contexts differ enough to matter when picking one, or migrating between them.
TomTom Search is closely tied to TomTom's navigation and automotive heritage, and it shows up frequently in fleet management and in-vehicle navigation software. Its response format uses a results array with a position object and an address block including fields like freeformAddress. Authentication is a query parameter key, consistent with most consumer-facing mapping APIs.
MapQuest Geocoding has the longest consumer mapping history of the three, and its API reflects an older but well-tested design: a results array containing a nested locations array, each with a latLng object and address fields like adminArea5 for city. It remains a reasonable fit for applications that value stability and a long track record over newer feature sets.
HERE Geocoding and Search leans more explicitly enterprise and automotive, with an items array structure carrying position and structured address fields, and authentication through either an API key or an OAuth token, which is more typical of platforms built with larger, more security-conscious enterprise customers in mind from the start.
For enterprise buyers, the practical differences that matter are usually less about the JSON field names, which are all reasonably well-documented and similar in spirit, and more about contract structure, account management, and how volume pricing has historically been negotiated. That is exactly the layer a compatibility approach can simplify, since it removes the geocoding response format as a variable in the decision.
My Geocode runs compatibility hosts for all three: TomTom's results and position structure at /compatibility/tomtom/, MapQuest's nested locations array at /compatibility/mapquest/, and HERE's items array at /compatibility/here/. Enterprise teams evaluating a consolidation, or looking to reduce vendor count without a parsing rewrite for each system currently on a different one of these three, can test all three shapes under one account and one flat pricing model.
That pricing model removes the tiered negotiation entirely: 2,500 free requests a day with no key, 2,500 more free per key per day counted per network, then prepaid credit at €0.0001 per request or an Unlimited key at €50 a month, with every endpoint, including all three compatibility hosts, priced identically regardless of volume tier.