Guide: Configure a Bearer prefix for an Airnode API-key header

An Airnode wrapper can declare a Bearer-style prefix for a custom API-key header with x-airnode-auth-scheme. The deployment variable then contains the key alone. The prefix belongs in the API description, rather than being repeated inside that variable.

This is a documented provider-onboarding configuration, checked on October 28, not a new launch or an executed integration test. It concerns the Airnode's credential for the upstream API, a separate layer from client-facing MCP access.

Describe the header

Suppose an API expects a header shaped like X-Partner-Key: Bearer <key>. A hypothetical security-scheme entry would be:

"partnerKey": {
  "type": "apiKey",
  "in": "header",
  "name": "X-Partner-Key",
  "x-airnode-auth-scheme": "Bearer"
}

The scheme name, partnerKey, identifies the credential definition. The name field identifies the actual HTTP header, while in: header selects its location. OpenAPI's Security Scheme and Security Requirement objects provide that underlying structure: a security requirement refers to a named scheme. Defining a scheme and saying that it applies are separate parts of the description.

Airnode's extension adds the prefix behavior. According to its documentation, Airnode writes the configured word and one space before the key when constructing the upstream credential header. Setting name to a custom header does not itself describe that prefix.

Keep the deployment value separate

Airnode maps a security scheme to an environment variable. For this prefixed header, that variable holds only the key, without Bearer at its start. The API description therefore records the header contract; the deployment supplies the credential value. No real key is included in the example.

Know the boundary

The documented setting is for a header-based API key. Airnode rejects it on a key sent in the query string. It is also an Airnode-specific x- extension, so its presence does not establish that another OpenAPI tool implements the same behavior.

The current Airnode wrapping documentation supplies the provider-side reference. This configuration example establishes no runtime result, integration approval or deployment date.