Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Migration von TomTom Search
TomTom Search ist in Automobil-, Flottenmanagement- und Navigationssoftware stark vertreten, also in Branchen, in denen die Genauigkeit der Geokodierung entlang einer Route genauso wichtig ist wie der reine Adressabgleich. Der API-Schlüssel wird als Query-Parameter gesendet, und die Geokodierungsantworten kommen als results-Array mit einem position-Objekt und einem address-Block zurück, der Felder wie freeformAddress und municipality enthält.
Software in diesem Bereich wird oft von Teams entwickelt, die sich nicht leichtfertig für TomTom entschieden haben. Der Entscheidung ging meist bereits ein Vergleich mit Alternativen voraus, weshalb eine spätere Migration eher von Kosten, Redundanzplanung oder einer umfassenderen Konsolidierung der Anbieter getrieben ist als von Unzufriedenheit mit den Daten selbst. Dieser Kontext bestimmt, wie eine Migration zugeschnitten wird: Sie ist selten dringend, und meist bleibt Zeit, gründlich zu testen.
Der TomTom-Kompatibilitäts-Host von My Geocode bildet das results-Array, das position-Objekt und die Adressfelder exakt so nach, wie TomTom sie zurückgibt. Der einzige Unterschied sind die Texte zu Urheberrecht, Nutzungsbedingungen und Datenschutz. Die Feldreferenz ist unter /compatibility/tomtom/ dokumentiert. Code, der auf results[0].position.lat und results[0].address.freeformAddress aufbaut, sollte nach der Änderung von Host und Schlüssel weiter funktionieren.
Speziell bei Flotten- und Automobilsoftware sollten Sie einige Dinge doppelt prüfen, bevor der Wechsel live geht:
- Alle Batch-Geokodierungsjobs, die nach Zeitplan laufen, da sie ein gutes erstes Ziel sind, um einen neuen Host zu testen, ohne Echtzeitaufrufe mit Kundenkontakt anzufassen
- Retry- und Timeout-Logik, die auf das spezifische Antwortverhalten von TomTom abgestimmt ist, da diese Werte oft empirisch festgelegt statt dokumentiert werden und eventuell neu eingestellt werden müssen
- Jeglicher Code, der TomTom-spezifische Felder zu Konfidenz oder Trefferqualität liest; hier lohnt sich ein direkter Vergleich mit den dokumentierten Entsprechungen des Kompatibilitäts-Hosts
Die Authentifizierung unterstützt einen X-API-Key-Header, einen Authorization: Bearer-Header, HTTP Basic Auth oder einen Query-Parameter und deckt damit jede Art ab, wie Ihr bestehender TomTom-Client seinen Schlüssel heute sendet.
Bei den Kosten entfällt durch diese Struktur der übliche Schritt der Enterprise-Verhandlung: 2.500 Anfragen pro Tag sind kostenlos, ohne dass ein Schlüssel nötig ist, und jeder Schlüssel fügt eigene 2.500 kostenlose Anfragen pro Tag hinzu, gezählt pro Netzwerk. Jenseits dieses Kontingents gibt es Prepaid-Guthaben zu 0,0001 € pro Anfrage oder einen Unlimited-Schlüssel zu 50 € pro Monat, wobei jeder Endpunkt, einschließlich dieses Kompatibilitäts-Hosts, gleich viel kostet. Für einen Flottenbetrieb mit nennenswertem Geokodierungsvolumen macht ein einheitlicher Tarif statt eines gestaffelten Enterprise-Vertrags die Kostenprognose erheblich einfacher.
Wenn Ihre TomTom-Nutzung neben der Geokodierung auch Routing- oder Verkehrsdaten umfasst, fällt dieser Teil des Stacks nicht in den Rahmen einer reinen Geokodierungsmigration und kann bei TomTom bleiben, während die Aufrufe zur Adressabfrage unabhängig davon umziehen. Eine Migration entlang solch klarer Funktionsgrenzen aufzuteilen, senkt das Risiko meist stärker als der Versuch, alles in einem Release umzuziehen.