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 charging extra for basic authentication methods
Authentication is one of the more mundane parts of using an API, and it is exactly the kind of mundane detail that ends up gated behind a pricing tier more often than it should be. Some providers reserve certain authentication methods, HTTP Basic auth, or a Bearer token pattern, for higher paid tiers, while a lower tier only supports a single, specific header format. The technical cost difference between validating one authentication style and another is close to nothing. What differs is how convenient each one is for a given customer's existing code, which has nothing to do with how much they should pay to use the API at all.
We accept a key as an X-API-Key header, an Authorization Bearer header, HTTP Basic auth with the key as the username, or a query parameter, on every host, at no extra cost for any of them. Whichever pattern already fits your existing code, whatever library or internal convention your team already uses for other APIs, is very likely already supported without needing to restructure anything just to match a specific format we happened to prefer.
The reasoning behind gating authentication methods by tier is not really about cost. It is about tier differentiation for its own sake: finding features to reserve for a higher-paying customer, even features that cost nothing extra to provide, simply because having more features locked behind a higher tier makes the higher tier look more valuable on a comparison table. Authentication methods are an easy target for this because supporting several of them is genuinely low effort for the provider and genuinely convenient for the customer, which makes gating it purely a monetization decision rather than one grounded in any real cost difference.
We think this kind of gating quietly punishes developers for a decision that has nothing to do with how much value they are getting from the actual data. A team whose existing tooling defaults to Bearer tokens should not pay more than a team whose tooling defaults to a custom header, when both teams are asking the exact same lookup and getting the exact same answer back. The value of the product is the response. The authentication method is plumbing, and plumbing should not carry a price tag based on which pipe happens to fit your existing wall.
There is a broader principle here that applies past authentication specifically: features that cost the provider nothing extra to offer should not become artificial tier boundaries just because they can be. A tier structure built around genuine cost differences, like request volume, is defensible. A tier structure padded out with low-cost conveniences reserved for higher payers exists mainly to make the pricing page look more differentiated than the underlying product actually is.