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.
Why documentation quality matters more than feature count
A pricing page listing forty endpoints looks more capable than one listing fifteen. It is also, frequently, a warning sign. Building an endpoint is a fraction of the work of making it usable. The rest is documentation: clear parameter descriptions, real example requests and responses, honest notes about edge cases, and a plain explanation of what happens when something goes wrong. Skip that work across forty endpoints and you get forty features that exist technically and barely at all practically.
We would rather have fewer things documented well than more things documented poorly. A developer evaluating an API rarely reads the feature list first. They read the docs, try an example request, and form an opinion about the whole company within the first few minutes based on whether that example actually works as written. If it does not, the feature count on the marketing page stops mattering, because the trust required to keep reading just left the room.
Good documentation for us means a few concrete things, not a vague commitment. It means authentication is explained with every accepted method shown plainly, not just the one the provider prefers. It means rate limits are stated as real numbers, not "generous limits apply." It means error codes are listed with what actually causes each one, so a developer debugging a failed request can find the answer in the docs instead of guessing from a status code alone. None of this requires more engineering. It requires someone deciding that writing it down clearly is not optional busywork attached to the real product.
There is also a compounding cost to documentation that is merely adequate. A developer who cannot find an answer in the docs opens a support ticket, and now solving that one question costs staff time on top of the engineering time already spent building the feature. Multiply that across enough customers hitting the same unclear paragraph and the "savings" from writing thin documentation quickly turn negative. Clear documentation is not a nice-to-have layered on top of the API. It is cheaper than the alternative, once you count the support load an unclear paragraph generates.
We also think documentation quality is one of the few signals a prospective customer can actually evaluate before committing to an integration. You cannot easily test a provider's uptime history in five minutes, and you cannot fully judge data accuracy without integrating first. You can, in five minutes, read the docs and judge whether the company writing them understood the product well enough to explain it plainly, or whether the docs read like an afterthought bolted onto a feature list built for a sales page.
A long feature list is easy to write. Documentation that a developer can actually build against on the first try is not, and that difference is exactly why it matters more.