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 TomTom Search
TomTom Search shows up heavily in automotive, fleet management, and navigation software, industries where geocoding accuracy along a route matters as much as raw address matching. Its API key is sent as a query parameter, and its geocoding responses come back as a results array with a position object and an address block containing fields like freeformAddress and municipality.
Software in this space is often built by teams who did not choose TomTom lightly; the decision usually came with evaluation against alternatives already, which means a later migration tends to be driven by cost, redundancy planning, or a broader vendor consolidation effort rather than dissatisfaction with the data itself. That context matters for how a migration gets scoped: it is rarely urgent, and there is usually time to test properly.
My Geocode's TomTom compatibility host reproduces the results array, the position object, and the address fields exactly as TomTom returns them, with the copyright, terms, and privacy text being the only difference. The field reference is documented at /compatibility/tomtom/. Code built around results[0].position.lat and results[0].address.freeformAddress should keep working once the host and key change.
For fleet and automotive software specifically, a few things are worth double checking before the switch goes live:
- Any batch geocoding jobs that run on a schedule, since these are a good first target for testing a new host without touching real-time customer-facing calls
- Retry and timeout logic tuned to TomTom's specific response timing, since these values are often set empirically rather than documented and may need re-tuning
- Any code that reads TomTom-specific confidence or match quality fields, worth a side-by-side comparison against the compatibility host's documented equivalents
Authentication supports an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter, covering however your existing TomTom client sends its key today.
On cost, the structure removes the usual enterprise negotiation step: 2,500 requests a day are free with no key needed, and every key adds its own 2,500 free requests a day counted per network. Past that allowance, it is prepaid credit at €0.0001 per request or an Unlimited key at €50 a month, with every endpoint, including this compatibility host, priced identically. For a fleet operation running geocoding at meaningful volume, having one flat rate rather than a tiered enterprise agreement makes forecasting costs considerably simpler.
If your TomTom usage also includes routing or traffic data alongside geocoding, that part of the stack is out of scope for a geocoding-only migration and can stay on TomTom while the address lookup calls move independently. Splitting a migration along clean feature boundaries like this tends to reduce risk more than trying to move everything in one release.