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.
What per-product billing gets wrong about how APIs are used
Open the request log of almost any application that uses location data and you will not find one type of lookup running in isolation. A signup form geocodes an address, checks the IP for a rough network match, and stamps the record with a time zone, all in the same few hundred milliseconds. These are not three separate use cases that happen to share an API provider. They are one workflow that touches three kinds of data.
Per-product billing pretends otherwise. It prices geocoding on one tier, IP lookups on another, and time zone or elevation data as optional add-ons with their own separate fees, as if a company that needs one of these is unlikely to need the others. In practice the opposite is true: needing one of them is usually a sign you need at least one more. An e-commerce checkout that geocodes a shipping address almost certainly also wants to know what time zone to schedule a delivery window in. A fraud check that looks at an IP address usually wants to cross-reference it against an address on file.
We priced My Geocode as one product with one rate. Every endpoint, geocoding, IP lookup, time zone, elevation, postal code, and every compatibility host, costs exactly the same per request. There is no separate price list to reconcile, no tier that adds time zone data only after you have already paid for a geocoding tier. A request is a request, whichever endpoint it hits.
This is not just a comfort for the customer. It reflects how the underlying work actually happens. A lookup against one endpoint does not carry a wildly different cost to serve than a lookup against another at the scale most applications run at. Splitting them into separate products with separate price points does not track a real difference in what it costs to answer the request. It tracks how many separate line items a provider can put on an invoice.
Per-product billing also makes it harder to reason about your own usage. If geocoding is billed one way and IP lookups another, estimating next month's bill means tracking two counters against two rate structures and hoping the mix of calls does not shift in a way that changes the total unpredictably. A flat, unified rate collapses that estimate into one number: total requests times one price. Anyone building a budget for their integration can do that math on the back of an envelope.
There is a deeper assumption buried in per-product pricing that we think is simply wrong: that different kinds of location data serve different customers. In our experience they serve the same customer, at different points in the same request. A logistics platform, a signup flow, and a fraud system all stitch together geocoding, IP, and time zone data into one decision. Pricing that pretends these are separate markets forces customers to either overpay for a bundle they use unevenly or juggle multiple vendors to avoid it. One rate, one endpoint list, is the simpler and more honest answer.