Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Building a route elevation chart for a running app
Runners planning a route care about hills in a way that is hard to judge from a flat map alone, since two routes of the same distance can feel completely different depending on how much climbing is packed into them, and a running app's feature request board had one item near the top for months: show the elevation profile of a planned route before someone commits to running it.
The app's routing feature already produced a sequence of coordinates describing a planned run, generated from a start point, an end point, and the app's own path-finding logic along real streets and trails. What was missing was elevation data for each point along that path. /v1/elevation filled that gap directly: a list of coordinates sent in a single request came back as a matching list of elevation values, in the same order, ready to plot against the runner's cumulative distance along the route.
The resulting chart, elevation against distance, gave runners exactly what the feature request had been asking for: a clear view of where the climbs sat along a planned run, how steep each one looked relative to the rest of the route, and a total elevation gain figure that became, alongside distance and estimated pace, one of the headline numbers shown for every saved route in the app.
Sampling density mattered for cost control here, similar to how a cycling app would approach the same problem. A short neighborhood run needed elevation sampled fairly frequently to produce a smooth, accurate-looking chart, while a longer route could use a coarser sampling interval without the resulting chart looking noticeably different to a runner glancing at it, since a bulk elevation request counts each point as one billed item and the app's engineering team tuned sampling interval by route length specifically to avoid requesting far more points than the resulting chart's visual resolution actually needed.
The app added one more small feature on top of the same data: a "climb difficulty" badge on saved routes, calculated from total elevation gain relative to distance, giving runners a quick way to compare two routes of similar length without reading a full chart for each one, similar in spirit to how a hiking app might use the same underlying calculation for trail difficulty, just tuned for the shorter distances and different pace expectations of a typical run rather than a hike.
User engagement with saved routes increased after the feature launched, which the app's team attributed specifically to runners feeling more confident committing to an unfamiliar route once they could see what they were actually signing up for in terms of climbing, rather than discovering a route's difficulty only partway through running it for the first time.
Elevation lookups ran once per saved route rather than per run, since a route's elevation profile does not change between runs of it, keeping total request volume proportional to how many distinct routes users created rather than to total app usage, comfortably inside the free daily allowance for an app of moderate active user size.
Documentation for the endpoint, including point limits per request, is at /docs/elevation-lookup/.