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 batch pricing should match single-request pricing
It is tempting to think of a batch endpoint as a bulk discount opportunity, the same instinct that makes buying a large pack of something feel cheaper per unit than buying pieces individually. That instinct does not actually apply to API requests the way it applies to physical goods. A batch of a thousand address lookups requires the same thousand individual lookups whether they arrive in one connection or a thousand separate ones. There is no economy of scale hiding in the fact that they arrived together, because the expensive part, resolving each lookup, is identical either way.
We price batch and bulk requests exactly the same, per item, as single requests. A thousand-item batch call counts as a thousand requests against your free allowance or your prepaid credit, at the same €0.0001 per request as calling the endpoint a thousand separate times, or covered the same way under an Unlimited key. There is no separate, cheaper batch rate, because there is no separate, cheaper amount of underlying work being done.
Some providers do offer a bulk discount, and the appeal for a customer is obvious: send more, pay less per unit. The reasoning behind that discount is worth questioning rather than just welcoming. If the marginal cost of serving a lookup is genuinely close to constant, the way it is for most geocoding, IP, and time zone lookups, a bulk discount is not passing along a real efficiency gain. It is a pricing decision to charge more to smaller customers to subsidize a lower rate for larger ones, dressed up as a reward for volume rather than what it actually is, a cross-subsidy.
Flat, item-based pricing avoids that cross-subsidy entirely. A customer sending a hundred requests a day and a customer sending a hundred thousand pay exactly the same rate per request, once both are past the free allowance. Neither is subsidizing the other's usage. This also keeps the free allowance itself fair: a batch call still consumes the same 2,500-request daily allowance at the same one-request-per-item rate, so batching cannot be used to quietly stretch free usage further than an equivalent number of single calls would.
We recognize batching is genuinely useful for reasons that have nothing to do with price: fewer round trips, less connection overhead, simpler code for processing a large, known set of lookups at once. Those are real engineering benefits and worth using batch endpoints for on their own merits. What batching should not become is a mechanism for making the same total amount of work look cheaper on an invoice than it actually is. A thousand lookups cost what a thousand lookups cost, and the price should say so plainly, regardless of how they were packaged into requests.