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 we would rather lose a sale than hide a limit in fine print
There is a specific, tempting shortcut available to any company writing its own pricing page: describe the good parts prominently and let the limits live in a footnote, a support article three clicks away, or language vague enough that most readers will assume the more generous interpretation. It works, in the narrow sense that it converts more signups than a page that states every limit plainly up front. It also produces a predictable, later cost: a customer who discovers a limit the hard way, mid-integration or on an invoice, and now feels misled rather than simply informed.
We would rather take the smaller number of signups that comes from stating limits clearly than the larger number that comes from letting people sign up without fully understanding what they are getting. The free allowance is 2,500 requests a day, counted per network and shared between keyless and keyed use from that network. That is a genuinely useful number for evaluation and small-scale use, and it is also, plainly, a limit. Saying so directly, rather than emphasizing "free" and leaving the ceiling for someone to discover through a failed request, is the version of honesty that costs us something in the short term.
The trade only looks bad if you measure success purely in signup counts. Measured over the life of a customer relationship, it looks different. A customer who understood the limits before committing and chose to proceed anyway is a customer who is not going to feel surprised or deceived later, because nothing about their situation changed between signup and the moment they actually hit a threshold. A customer who signed up under a vaguer impression, and then discovers the real ceiling once it affects them, has a legitimate grievance, and legitimate grievances turn into public complaints, refund requests, and reputational cost that outlasts the value of the signup that caused them.
This same logic applies to why quota headers exist on every response rather than only in account dashboard, why rate limits are published as real numbers in the documentation instead of described vaguely, and why the Unlimited key is actually unlimited rather than unlimited with an undisclosed soft cap. Each of these is a place where the vaguer, more generous-sounding version would probably convert slightly better on first impression, and the honest version is the one we chose anyway.
We do not think this makes us unusually virtuous. It is closer to a bet about what kind of company survives its own customers actually using the product at scale, for years, rather than just signing up once. A pricing page optimized purely to maximize signups treats the signup as the finish line. We think the signup is closer to the starting line, and the fine print you did not read is exactly the part of the relationship that determines whether the years after signup go well.