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.
A faster elevation endpoint for long routes
An elevation profile for a hiking trail or a driving route is rarely a single coordinate. It is dozens, sometimes hundreds, of points along a path, each needing an elevation figure to build a climb chart or estimate effort along the way. That pattern of use, many coordinates in service of one continuous route, is what we specifically optimized for in a recent pass over /v1/elevation.
The endpoint's request and response shape has not changed, and everything documented at /docs/elevation-lookup/ still applies exactly as written. What changed is how efficiently a large batch of coordinates along a route gets processed internally, aimed at reducing the time it takes to get an elevation profile back for a long path rather than a single isolated point.
Since a batch request counts each coordinate as one item, exactly as it always has, this improvement affects speed, not pricing or quota behavior. A route with two hundred coordinate points still counts as two hundred requests against whatever allowance applies, whether that is the free daily allowance, prepaid credit at €0.0001 a request, or coverage under an Unlimited package. What changes is how long the response takes to come back, which matters directly for anything building a route profile interactively rather than as a background job.
This same improvement carries through to our Open-Elevation compatibility host at /compatibility/open-elevation/, since it draws on the same underlying elevation endpoint. Anything already sending route-length batches through that host benefits from the faster processing without any change needed on the integration side.
Routing and hiking applications tend to be exactly where this kind of improvement is felt most directly, since an elevation profile that takes noticeably longer to load than the route itself creates a visible lag for a user waiting on a map. A faster response for these longer, route-shaped batches closes that gap.
If your application requests elevation for routes made up of many coordinates, whether for hiking, cycling, or driving directions, you should notice this as a quiet improvement in how quickly a full profile comes back, with nothing else about the integration needing to change. Full endpoint documentation remains at /docs/elevation-lookup/.