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 "confidence score" marketing gets wrong
A geocoding response that returns a confidence score of 0.87 looks more rigorous than one that just returns a match or does not. It has a decimal point. It implies a model behind it that has been calibrated against something measurable. Sometimes that is exactly what it is. Often, the number is closer to a heuristic dressed up in a format that reads as scientific, and the two are hard to tell apart from the outside.
The trouble with a bare confidence score is that it answers a question nobody asked in those terms. A developer building an address form does not need a probability between zero and one. They need to know something more specific: was the street number matched, or only the street. Was the postal code found, or only the city. Is this a rooftop-level match or a fallback to a wider area centroid. A single float collapses all of that useful, actionable detail into one number that looks precise while telling you less than a plain description would.
We think the honest version of this is to describe what was actually matched, in plain terms, rather than compress it into a score that implies more certainty than the underlying method can support. This matters even more because forward and reverse geocoding are exactly the kind of feature where overselling accuracy causes real damage downstream. An address that resolves to the wrong side of a city because a confidence score above some threshold quietly passed a bad match through is not a rounding error. It is a shipment sent to the wrong location, or a service area check that includes a customer who is actually outside it.
We are not going to claim that our forward geocoding, reverse geocoding, or autocomplete already handles every address pattern with verified accuracy across every case, because that claim would be exactly the kind of overselling we are describing here. What we can say plainly is what the endpoints do and how they are built, without wrapping the description in a number designed to make the confidence sound higher than the reality supports.
A confidence score is not inherently dishonest. Used well, it can genuinely summarize something real about a match, especially when it is documented clearly enough that a developer can see what the number is actually computed from. The problem is when the score becomes the whole answer, marketed as proof of accuracy rather than disclosed as one signal among several, with the underlying method left unstated. A number without an explanation is not more accurate than words. It is just harder to argue with, which is a different thing entirely.
The fix is not complicated, even if it is less flattering on a marketing page. Describe what was matched, in plain language, and let a developer decide for themselves whether that level of detail is good enough for what they are building. A street-level match described plainly is more useful than a 0.91 score with no explanation behind it, because plain language tells you what to check next and a bare number does not.