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.
A delivery service that only covers a certain area needs a way to reject addresses outside that area before an order gets placed, not after a driver discovers it during dispatch.
When a customer submits their delivery address, geocode it before accepting the order.
GET /v1/forward?q=10 Downing Street, London&limit=1{
"status": "ok",
"results": [
{"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {}}
]
}With the customer's coordinates and your fixed delivery hub coordinates in hand, calculate the straight-line distance between the two using a standard haversine formula in your own code, and compare it against your delivery radius.
distance_km = haversine(hub_lat, hub_lon, 51.5033, -0.1276)
if distance_km > max_radius_km:
reject_order()A low confidence score on the geocoding result means the address itself was ambiguous, not necessarily that it falls outside your radius. Handle a low-confidence match separately from a clean out-of-radius rejection, perhaps by asking the customer to confirm or refine their address rather than rejecting the order outright.
A business running more than one delivery hub should calculate distance to every hub, not just one, and accept the order if any hub's radius covers the address. Assigning the order to whichever hub came back closest also sets up the fulfillment side correctly from the same calculation, since you already have the winning hub's identity once you have sorted by distance.
nearest_hub = min(hubs, key=lambda h: haversine(h.lat, h.lon, cust_lat, cust_lon))
if nearest_hub.distance_km > nearest_hub.max_radius_km:
reject_order()Do not reject an order the instant distance_km exceeds max_radius_km by a trivial amount, such as a few dozen meters, without giving the customer any explanation or recourse. An address sitting essentially on the boundary line is a normal outcome of drawing a radius on a map, and a flat rejection with no context reads as arbitrary to a customer who lives two streets outside a line they cannot see. Showing the calculated distance and the covered radius, rather than a bare rejection, at least explains why.
A straight-line radius is a simple approximation and will occasionally include a point that is technically far by road, or exclude one that is close by road but far in a straight line, such as across a river with no nearby bridge. For most delivery zone checks this approximation is good enough, and refining it further would require routing data outside what a geocoding lookup provides.
Each address check is one geocoding request, or one request per candidate hub compared if you check the address against a hub list through separate calls rather than reusing the same coordinates locally, since only the address itself needs geocoding, not each hub. A delivery form checking every submitted order stays well within the 2,500 free requests a day included with every key for a typical local business, moving onto prepaid credit only once order volume grows substantially.
Rejecting an out-of-area order at submission time, rather than at dispatch, saves both sides a wasted conversation later. Full parameter details are on the forward geocoding docs, and current pricing tiers are on the pricing page.