What we shipped this month: geocoding, IP, time zone and more
A roundup of recent work across the API: new compatibility hosts, faster time zone and elevation lookups, dashboard features, and clearer quota visibility.
Navigation and logistics software often has TomTom Search baked in at a fairly deep level, since location lookups there tend to sit next to routing and mapping calls built by the same team, in the same style. Moving one piece without touching the rest is exactly what our compatibility host is designed to make possible.
It reproduces TomTom Search's request parameters and response body exactly, with the sole difference being copyright, terms and privacy text, which reflects My Geocode instead of the original provider. Wherever your code sends a TomTom-shaped geocoding request today, it can send that same request to our host, and the response parses the same way without any changes to your existing logic.
Routing and mapping calls built by the same team tend to share conventions: the same retry logic, the same error handling, the same expectations about timing. Matching TomTom Search's request and response shape exactly, rather than offering a similar but different geocoding API, means that surrounding logic does not need to be re-tested just because one call in the middle now points somewhere else.
Authentication uses our usual four options: an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth with the key as the username, or a query parameter. Whichever your current TomTom integration already relies on is accepted here as well, without modification.
Pricing is identical to every other host and endpoint on the platform. Any address gets 2,500 free requests a day with no key needed, counted per network. A key adds a further 2,500 free requests a day of its own. Beyond both allowances, prepaid credit is €0.0001 a request, or an Unlimited package covers usage for €50 a month, with no extra charge for using a compatibility host over a native one.
Teams running navigation or logistics software often split traffic across more than one key, one per environment or one per internal service, so a problem in staging never eats into production quota. The keys page in the dashboard, at /dashboard/keys, supports generating and naming additional keys the same way for a TomTom-shaped integration as for any other.
Quota headers are attached to every response on this host too: X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used and X-Credits-Remaining are all present, giving a level of usage insight a direct TomTom integration would not otherwise surface.
If a project wants more than the standard compatible response, adding mg_extras=1 to the request, or sending an X-MG-Extras header, layers optional extra fields on top, entirely by choice, leaving the base response shape untouched unless you specifically ask for more.
The host is documented at /compatibility/tomtom/, and general migration guidance for compatibility hosts across the platform is at /docs/compatibility/. Redirecting an existing TomTom-shaped integration here takes a changed host name and a fresh key, nothing else.