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.
The case against proprietary response formats
Ask why an API returns a nested, custom object model instead of a plain, flat JSON structure, and the honest answer is rarely a technical one. A proprietary shape does not make a lookup faster or more accurate. It makes the response harder to swap out, because every field name, every nesting level, and every custom status code your code learns to handle is a small piece of vendor-specific knowledge baked into your application.
We think that is backwards. A response format should describe the data, not the vendor. Coordinates, addresses, offsets, and elevations are the same concepts regardless of who answers the request, so the shape returned for them should be about as plain as the concepts themselves. That is also why 17 of our hosts return the exact response shape of another provider's own API: the data is ours, but the shape is one your code may already understand, because it is not really our shape to invent in the first place.
Proprietary formats also tend to accumulate oddities that have nothing to do with the underlying data and everything to do with a provider's internal history. A field gets renamed for an internal migration and the old name lingers as a deprecated alias nobody wants to remove. A status gets represented as a string in one endpoint and a numeric code in another because they were built by different teams years apart. None of this is malicious. It is just what happens when a format is never designed against an external standard, only against a company's own evolving codebase.
The fix is not complicated: pick a plain structure, document it once, and hold it stable. We do that across our own native endpoints and we go one step further with compatibility hosts, matching another provider's shape exactly so a codebase that already parses that shape needs no changes at all beyond a base URL and a key. That is a bigger commitment than it sounds. It means when the shape we are matching has an awkward field name or an inconsistent nesting choice, we keep the awkwardness, because the entire value of the compatibility host is fidelity, not improvement.
A proprietary format is sometimes defended as giving a provider room to add richer data over time. We do not think richness requires an unfamiliar shape. Optional fields, like elevation or IP threat detail, can sit alongside a standard response as additions rather than replacements, so a caller who does not ask for them never has to parse around them, and a caller who does ask gets them without learning a new format.
None of this is really about JSON formatting as a technical preference. It is about who bears the cost of a shape decision. A proprietary format puts that cost on every customer who ever has to read the response. A plain or matched format puts it on us, in the design work of keeping things predictable. That is where the cost belongs.