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 IPv6 adoption still gets wrong across this industry
IPv6 has been available for long enough that treating it as a secondary concern is no longer a reasonable engineering shortcut, yet plenty of IP-related tooling still behaves as though IPv4 is the real traffic and IPv6 is the exception to be handled if there is time left over. This shows up in small ways: rate limiting logic written around IPv4-style address blocks without an equivalent, well-considered concept for IPv6, or documentation that quietly assumes an IPv4 address format in its examples and leaves IPv6 handling as an implied afterthought.
We built network-level quota tracking around both address families deliberately, not as an IPv6 patch bolted onto IPv4-first logic. Every network gets a shared free allowance, a /24 block for IPv4 addresses and a /48 block for IPv6 addresses, and both are treated as first class groupings rather than one being the primary design and the other an accommodation. The distinction between a /24 and a /48 is not arbitrary. It reflects how each address family is actually allocated by the regional internet registries responsible for handing out blocks, so the grouping means the same practical thing, a reasonably sized network, in both cases.
Getting this wrong matters specifically for a location and IP data API, because the entire category of network-level and IP-based lookups depends on correctly parsing, matching, and rate limiting across both address formats. An API that quietly handles IPv6 as an edge case is more likely to produce inconsistent quota behavior, incorrect network groupings, or outright parsing failures for IPv6 traffic, at exactly the moment IPv6 adoption keeps growing and a meaningful share of real requests arrive over it rather than IPv4.
Part of why this gets under-invested in industry-wide is that IPv4 traffic still represents a large share of total volume for a lot of services, which makes IPv6 edge cases feel like a low priority relative to the effort of getting them genuinely right. We think that reasoning discounts the trend line too heavily. A share of traffic that keeps growing is not well served by infrastructure that treats it as a permanent minority case, and the cost of fixing IPv6 handling properly only grows the longer a system's core logic is built assuming IPv4 as the default.
None of this is a dramatic claim. It is a request to take IPv6 as seriously as IPv4 in the actual design of rate limiting, quota tracking, and lookup logic, not just in a compliance checkbox that says an API technically accepts IPv6 addresses without a syntax error. Accepting an address format and handling it with the same care as the more common one are different achievements, and a lot of infrastructure across this industry has only really managed the first one.