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.
Faster response times after an infrastructure upgrade
Every request to My Geocode travels through the same serving infrastructure before an answer comes back, regardless of which endpoint it hits or which compatibility host it is shaped for. We recently completed an upgrade to that shared infrastructure, and the result is faster response times across the board.
This is a platform-wide change rather than something specific to one endpoint. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete and /v1/postcode all sit on the same upgraded stack, as do all seventeen compatibility hosts. Nothing about request parameters, response fields, authentication methods, or pricing has changed as part of this. The upgrade is entirely behind the scenes, visible only in how quickly a response comes back.
For most integrations, this kind of improvement is felt rather than measured precisely, a general sense that calls come back a little quicker than before. For integrations doing meaningful volume, particularly batch jobs processing many items in sequence, or anything with autocomplete-style traffic firing repeatedly as a user types, the effect compounds across many requests and becomes easier to notice directly. An autocomplete field that sends a request on every keystroke of an eight character search term makes eight calls in the time it takes to type it, and shaving even a small amount off each one changes how the whole interaction feels, in a way a single standalone lookup would not show at all.
We treat infrastructure work like this as a continuous responsibility rather than a one-time project. A geocoding API that people build real products on top of needs to keep performing well as usage grows, not just on the day it launches, and that means revisiting the serving stack periodically rather than leaving it untouched indefinitely. This upgrade is one step in that ongoing process, not a final destination.
Because every endpoint and every compatibility host runs through the same shared stack, an upgrade like this only has to happen once to benefit all of them, rather than being repeated endpoint by endpoint or host by host. That shared design is also why a change here never touches request formats, response fields or the quota engine: those live at a different layer entirely.
None of the quota or billing mechanics change as a result. Every response still carries the same full set of quota headers, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit and X-Quota-Reset, and the free allowances, prepaid credit rate, and Unlimited package price are all unchanged.
The same shared stack is what every compatibility host runs on as well, so a TomTom-shaped call and a native call to /v1/forward see identical gains, and the improvement is not something that needs to be requested per host or negotiated separately for a specific integration.
If your integration is sensitive to response time, whether because it is user-facing or because it processes high volumes of batch requests, you should notice a difference without needing to change anything on your end. Full documentation for every endpoint remains exactly as it was, available at /docs/.