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.
A cleaner error format across every endpoint
An error response is not a footnote to an API, it is part of the contract every integration relies on just as much as a successful one. We have standardized the error format across every native endpoint on My Geocode, so a failure looks the same regardless of which part of the API produced it.
Whether a request fails because of a missing parameter, an invalid key, exhausted quota, or a malformed coordinate, the response follows a single, predictable structure. That consistency means error-handling code written once, against one endpoint, works the same way against every other native endpoint without needing separate handling logic for each one.
Quota-related failures deserve particular mention, since they are the most common kind an active integration will encounter. When a request would exceed a key's or a network's allowance, the response makes that clear, and the quota headers already present on every response, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining and the rest, tell you exactly how much room was available before the request that failed. That combination means a client can distinguish a quota problem from an authentication problem or a bad request from the response alone, without guessing.
Compatibility hosts are a deliberate exception to this standardization, and for good reason. Their entire purpose is to reproduce another provider's request and response shape exactly, and that includes how errors look. A request shaped for Bing Maps REST Services that fails still gets an error in Bing's own error format, because matching that shape precisely, success or failure, is the whole point of a drop-in host. Standardizing errors there would break the very compatibility the host exists to provide.
For anything built against our native endpoints, this cleaner format should make error handling noticeably simpler to write and maintain. A single parsing routine, a single set of expected fields, and consistent behavior across /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete and /v1/postcode alike.
Full documentation of the error format, including field names and common causes, is available at /docs/errors/. If your integration currently has separate error-handling branches for different native endpoints, this is a good moment to simplify that down to one.