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 count bulk requests per item, not per call
A batch endpoint that accepts a thousand addresses in one call and only counts as a single request against your quota looks generous on a pricing page. It is not generous. It is a rounding error waiting to become a capacity problem, because the actual work behind that call, a thousand individual lookups, did not shrink just because it arrived in one envelope.
We count bulk and batch requests the way we count everything else: one item, one request. If you send a thousand addresses in a single batch call, that is a thousand requests against your free allowance or your prepaid credit, exactly as if you had called the endpoint a thousand times separately. The convenience of batching, fewer round trips, less connection overhead, is real and worth having. The cost of the lookups themselves does not change because you asked for them together.
Pricing batch calls artificially cheap creates a strange distortion. It rewards restructuring your integration around large batch calls purely to save money, rather than because batching genuinely fits your workflow. It also makes a provider's actual capacity planning harder to reason about from the outside, since a "request" no longer means a consistent unit of work. A customer comparing providers on requests per day cannot compare fairly if one provider's request might secretly contain a thousand lookups and another's does not.
Item-based counting also keeps our quota headers meaningful. Every response carries a count of what you have used and what is left, and that number only means something if a request is a request regardless of how it was shaped. If a thousand-item batch quietly cost one unit, those headers would tell you almost nothing about your real consumption, and you would find out the true number only when a much larger, unbatched pattern of usage hit a limit you did not expect.
There is a fairness argument too. A customer sending individual calls and a customer sending batches are asking us to do the same total amount of work for the same total price. Charging the batch customer less per lookup, just because the requests are wrapped together, would mean the individual-call customer is effectively subsidizing infrastructure they are not the ones straining. Charging both the same per lookup keeps the price tied to the work, not to how the work was packaged.
None of this makes batching pointless. It is still the right way to send a large, known set of lookups in one round trip, and we support it because fewer connections and less overhead is a real efficiency gain on your side. What batching should not do, on either side of the request, is change what the lookups actually cost. A thousand lookups are a thousand lookups, whether they arrive one at a time over an afternoon or all at once in a single call.