x-api-key has seven spellings, 798 providers and no IANA registration

x-api-key has seven spellings, 798 providers and no IANA registration

The apis.io headers section counts every header declared across 159,590 specification files from 27,956 providers. The clearest finding is at the top. Authorization is first at 1,381 providers. x-api-key is second at 798, spelled seven different ways, and it is not an IANA-registered header. The second most declared header in the API economy is a convention nobody standardized.

The scan found 6,666 distinct names. A header earns a page if IANA registers it, a regulation reaches it, or 25 or more providers declare it. That produces 308 pages and leaves 6,514 in the tail. 97 headers are spelled more than one way.

What the counts look like

Header Providers Spellings Note
Authorization 1,381 3 IANA registered
x-api-key 798 7 Not registered
Retry-After 329 3 Reached by PSD2
Idempotency-Key 169 4 Not registered
X-RateLimit-Limit 130 4 The older form
RateLimit-Limit 32 3 The newer form
Sunset 10 2 Lifecycle
Deprecation 7 2 Lifecycle
DPoP 1 1 Only SIMBA Chain

The lifecycle rows are the ones I would act on. 329 providers document how to slow a client down, and 10 declare the header that tells it an endpoint is going away. Agents depend on that signal more than people do, because nobody is reading the changelog on their behalf.

Reading the numbers honestly

Counts measure contracts, and contracts have authors. X-Amz-Date shows 98 providers, and 94 of those are Amazon or AWS services. X-WP-Total shows 121, which reads as one platform’s default output and not as 121 separate decisions. x-v shows 61, because Australia’s Consumer Data Right mandates it, and its declarers run through banks and energy companies. A provider count can mean a market choice, one platform’s output or a legal requirement. The section marks the regulated ones, 33 in all, which is what makes that distinction readable.

156 IANA-registered headers were never observed in any contract. Some of that is a blind spot. Sec-GPC, Clear-Site-Data and Permissions-Policy are reached by regulation and show zero, but they travel at the browser and edge layer, where an OpenAPI file rarely looks.

What we should fix

The page counts in: header parameters and headers: mappings, so an API that declares bearer auth only through securitySchemes is outside the Authorization number. That 1,381 is a floor, and x-api-key has the same limit. We should count security schemes too, or state the limit on those pages.

Two data bugs turned up while writing this. Six headers carry no category, including X-Correlation-Id at 34 providers and api-version at 29. The landing page builds its groups by category, so these six have pages but appear in no group. And Idempotency-Key is labeled a response header while x-idempotency-key is labeled request, even though they do the same job.

Takeaway

If you are designing an API, use one spelling, declare Sunset and Deprecation, and put your auth in securitySchemes as well as your docs. The data is at apis.io/headers/.

← The top score in Weather & Geospatial belongs to a Spanish company registry