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.
Not every location question is really a geocoding question. Sometimes the only thing an application actually needs is the postal code for a given area, or the area covered by a given postal code, without the broader address resolution that forward or reverse geocoding provides. /v1/postcode exists specifically for that narrower question, as its own dedicated endpoint rather than a side effect of a more general lookup.
Keeping it separate from /v1/forward and /v1/reverse matters for a few practical reasons. It means the request shape can be built specifically around postal code parameters rather than adapted from a broader address structure. It means the response can focus on exactly what a postal-code-only integration needs, without extra address fields to filter out. And it means documentation, available in full at /docs/postal-code-lookup/, can explain postal code behavior on its own terms rather than as a subsection of a longer geocoding guide.
Authentication follows the same rules as every other endpoint: an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth with the key as the username, or a query parameter, all accepted identically. Pricing is the same as well, drawing on the same free daily allowance, whether from the calling network or from the key, and the same €0.0001 a request in prepaid credit or Unlimited package coverage beyond that.
Batch requests work here exactly as they do everywhere else on the platform: each postal code or address submitted in a single call counts as one request, not the call as a whole. A team validating postal codes across a large customer list can send that list as a batch and expect the same per-item counting that applies to any other bulk operation on My Geocode.
Having a dedicated endpoint also makes the postal code compatibility work across our seventeen compatibility hosts more precise, since providers that offer their own dedicated postal lookup can be matched exactly rather than approximated through a broader geocoding shape.
If your application only needs postal code information and has previously been sending broader geocoding requests just to extract that one field, /v1/postcode is worth switching to directly. It is documented fully at /docs/postal-code-lookup/, alongside the rest of our endpoint reference at /docs/.