The most fragmented header in the catalog — 667 providers, seven different spellings, no standard, no registry entry.
x-api-key
Authentication de facto — unregistered request 7 spellings
There is no X-API-Key standard. There never was. It is a convention that emerged because Authorization felt heavyweight for a simple key, and it has since become one of the most widely declared headers in the API economy without ever acquiring a definition.
What that costs is visible in the catalog. Across the providers that declare it, this one header is spelled seven different ways — X-API-Key, X-Api-Key, X-API-KEY, x-api-key, X-api-key, x-Api-Key, x-API-Key. HTTP field names are case-insensitive, so every one of these is the same header on the wire. But a contract is not the wire. Generated clients key off the string, documentation renders the string, and a developer reading two of your endpoints sees two different headers.
The X- prefix itself was deprecated for new headers by RFC 6648 in 2012. The convention outlived the deprecation by a wide margin.
The registry
Not registered with IANA. It is a de facto or vendor field — real, widely used, and governed by nothing but convention.
In the catalog
Declared by 667 providers across 13,265 published specification files in the API Evangelist catalog, where it appears as a request header — sent by the client.
It is spelled 7 different ways across those contracts — x-api-key, X-API-Key, X-API-KEY, X-Api-Key, x-Api-Key, x-API-Key. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.
Using it
If you are shipping a new API, use Authorization with a defined scheme instead. If you already ship X-API-Key — and most of the catalog does — pick one spelling, use it in every contract you publish, and declare it as an apiKey security scheme rather than as a header parameter. Consistency here costs nothing and removes a whole category of client bug.
Governed by these rules
Machine-enforceable governance rules from rules.apievangelist.com that apply to this header when it appears in an OpenAPI.
OpenAPI Components Headers Error error
Utilizing the headers object in the centralized OpenAPI components library helps make headers reusable across API requests and responses
Guidance: Rate Limits →OpenAPI Components Headers Info info
Utilizing the headers object in the centralized OpenAPI components library helps make headers reusable across API requests and responses
Guidance: Rate Limits →OpenAPI Headers Hyphenated Pascal Case error
HTTP headers should follow Hyphenated-Pascal-Case naming convention for consistency and readability, such as Content-Type, X-Request-Id, or Accept-Language.
Guidance: Naming →OpenAPI Security Schemes API Keys In Header Error error
Having components security schemes which possesses an api-key property that allows to configure how API keys are applied to operations have a in of header set.
Guidance: Security →OpenAPI Security Schemes API Keys Info info
Having components security schemes which possesses an api-key property that allows to configure how API keys are applied to operations.
Guidance: Security →