The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
What coordinate precision marketing gets backwards
Latitude and longitude returned to fifteen decimal places look impressively exact. The fifteenth decimal place of a coordinate corresponds to a distance smaller than an atom, which should be an immediate signal that the precision on display has nothing to do with the accuracy of the underlying match. A geocoding result derived from a postal boundary centroid, a rooftop match, or a rough area estimate does not become more accurate because the response carries more digits after the decimal point. It just carries more digits.
This distinction, precision versus accuracy, gets blurred constantly in how location data gets presented. Precision is how many digits a number has. Accuracy is how close that number actually is to the real location. A coordinate can be extremely precise and substantially wrong, and a response format that leads with a long decimal string invites the reader to assume the two are the same thing, when they are not related at all beyond the fact that one can disguise the absence of the other.
We think the more honest thing a response can do is describe what kind of match actually produced the coordinate, rather than relying on decimal length to imply a level of confidence the underlying method may not support. A rooftop-level match and a city-centroid fallback are different in kind, not just in decimal precision, and collapsing that difference into "more decimal places means better" hides exactly the information a developer needs to decide whether a given result is good enough for their use case, whether that is drawing a pin on a map or routing a delivery vehicle.
This connects directly to why we are careful about how we describe our own forward geocoding, reverse geocoding, and autocomplete endpoints. It would be easy to return coordinates with a long decimal tail and let that stand in for a confidence claim we are not prepared to make plainly. We would rather be specific about what the endpoint returns and let the actual match information speak for itself than lean on decimal formatting to imply more than the underlying data justifies.
There is a practical takeaway here for anyone consuming a geocoding API, not just for how we chose to build ours: decimal places in a coordinate are not evidence of quality. What matters is whether the response tells you, in plain terms, what was actually matched, at what level of specificity, so you can decide for yourself whether that specific answer is good enough for the decision you are about to make with it. A long string of digits after the decimal point answers a question about formatting. It does not answer the question that actually matters, which is whether the point in the world that those digits describe is the right one.