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.
Improved coverage for rural and low-density postal codes
Dense cities are the easy case for postal code data. Boundaries are well documented, addresses are numerous, and data providers tend to prioritize them naturally because that is where the volume of queries lives. Rural and low-density areas have always been the harder case, with fewer addresses spread across larger boundaries that are easier to get slightly wrong. We put specific effort into improving /v1/postcode coverage exactly there.
The endpoint's request and response shape is unchanged, documented in full at /docs/postal-code-lookup/. What improved is accuracy in the areas that tend to be weakest across postal code data generally: sparsely populated regions where a postal boundary might cover a wide area with relatively few actual addresses inside it, and where small errors in the underlying data are historically more common because there is less traffic to surface them.
This matters for a specific, often underserved set of use cases: logistics and delivery services covering rural routes, agricultural and land-based businesses operating outside dense population centers, and any address form that needs to work correctly regardless of whether a user lives in a city center or somewhere far more sparsely populated. An address lookup that works reliably only in cities is a gap that shows up exactly when a rural customer tries to use it, often without anyone noticing until a specific complaint arrives.
Pricing and quota behavior are unaffected. A postal code lookup in a dense city and one in a sparsely populated rural area cost exactly the same, counted the same way against the free allowance, prepaid credit, or an Unlimited package, and a batch of postal codes still counts each one individually.
We think coverage quality in lower-density areas is worth investing in specifically, rather than treating it as naturally solved once city coverage is strong, since the two do not actually correlate. A provider can have excellent coverage in major cities and noticeably weaker coverage everywhere else, and that gap is invisible until it directly affects a real address lookup for a real customer somewhere outside a city center.
If your application serves customers outside major population centers, whether for delivery, field service, or general address validation, this improvement should be visible as more reliable postal code matches in exactly the areas that used to be hardest to get right. Full documentation for the endpoint remains at /docs/postal-code-lookup/.