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 an elevation profile for a cycling app
Riders planning a route care about one number more than any other: how much climbing is involved. A flat forty miles and a hilly forty miles are different rides entirely, and a cycling app built for route planning needed a way to show that difference before someone committed to a ride, not after they were three hills in and regretting it.
The app already had routes as a sequence of coordinates, generated by its own routing engine from a start and end point. What it lacked was elevation at each of those points. /v1/elevation solved that directly: send it a list of coordinates, whether a single point or a long sequence along a route, and it returns the ground elevation for each one. A route with two hundred points along its length came back as two hundred elevation values, still ordered the way they were sent, ready to plot as a profile against distance traveled.
That list, charted against cumulative distance, is the climbing chart riders actually want to see: where the hills are, how steep the approach looks compared to neighboring points, and where the flat stretches sit. The app used it to compute total elevation gain for a route, a single number that turned out to matter more to riders deciding whether to attempt a route than the total distance did.
Because a route could have anywhere from a few dozen to a few hundred points depending on its length, and because a bulk elevation request counts each point as one billed item, the app tuned how many points it sampled per route rather than requesting elevation at the finest possible resolution for every ride. A gentle route sampled every few hundred meters produced a profile just as useful as one sampled every ten meters, at a fraction of the request volume, and the difference was invisible to a rider looking at the resulting chart.
The app also let a rider check a single point on demand, tapping anywhere on the map to see the elevation at that exact spot, which used the same endpoint with a one-point request instead of a full route. Both the single-point and the batch case run through the same call, which kept the app's code simple: one function that accepts a list of coordinates and returns a matching list of elevations, used for both a quick tap and a full route plan.
Traffic scaled with how many routes riders planned rather than how many rides they actually took, since a saved route only needed its profile computed once. For an app with an active but not massive user base, that kept elevation lookups well inside the free daily allowance, with prepaid credit as the natural next step if a popular new feature drove a spike in route planning.
Elevation is one of the few endpoints where a real example is easy to give: a coastal ride will show elevation values near sea level for its early points and rising values as the route climbs inland, a chart that means something to a rider at a glance. Details on request format and point limits are at /docs/elevation-lookup/.