Monitor your key's usage before you hit a limit
Watching your quota headers as you go tells you when a limit is approaching, well before a request actually gets rejected.
Distance between two addresses is not something a geocoding API returns directly, since a distance calculation only needs coordinates, which the forward endpoint already gives you for any address you send it.
Geocode each address separately, or together in a single bulk request, to get a latitude and longitude pair for each.
POST /v1/forward
Content-Type: application/json
["221B Baker Street, London", "10 Downing Street, London"]{
"status": "ok",
"results": [
{"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}},
{"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {}}
]
}With two coordinate pairs in hand, apply the standard haversine formula, which converts the difference in latitude and longitude into a straight-line distance across the Earth's surface. Most programming languages have a small, well-tested haversine implementation available as a short function or a common library, so there is no need to write the trigonometry from scratch.
distance_km = haversine(51.5237, -0.1585, 51.5033, -0.1276)The haversine formula expects latitude and longitude in radians, but the coordinates in an API response are always in degrees. Plugging degree values straight into a formula written for radians will produce a distance that looks plausible at a glance but is quietly wrong by a large factor. Convert degrees to radians first, or use a library function that documents which unit it expects, and check the result against a distance you already know before trusting it in production.
The same calculation extends naturally to more than two points. Geocode every stop on a route in one bulk request, then sum the haversine distance between each consecutive pair of coordinates to get a rough total route length, useful for a quick delivery route estimate even before you have real turn-by-turn routing in place.
total_km = haversine(a, b) + haversine(b, c) + haversine(c, d)A haversine calculation gives straight-line distance, not driving or walking distance along real roads. For most uses, such as sorting nearby locations or estimating rough proximity, straight-line distance is good enough and needs nothing beyond the coordinates you already have. If you specifically need routed travel distance, that is a separate kind of calculation outside what a geocoding lookup provides.
Two points on opposite sides of the antimeridian, or very close to a pole, can trip up a naive distance formula that does not account for longitude wrapping around from 180 to negative 180. This is rare for typical address-to-address distance checks, but worth testing for if your application legitimately spans that part of the globe.
Geocoding two addresses costs two requests, whether sent as separate calls or one bulk call. The distance math itself, once you have both coordinate pairs, happens entirely in your own code and costs nothing further against your allowance.
If either address is one you have geocoded before and cached, only the new address needs a fresh request, cutting the cost for that particular calculation to one request instead of two.
Distance calculations are one geocoding request away for any address you have not already resolved to coordinates. See the forward geocoding docs for the full response shape.