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

Canonical: https://forkbrief.com/news/730aafc4-62f4-49c7-ba46-fc9d160a56ad
Published: 2026-10-28T19:00:39.734Z
Publisher: Fork Brief

Keep a custom header name, its Bearer-style prefix and the deployment key value distinct in a documented Airnode configuration.

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](https://forkbrief.com/news/aab56674-cf01-483d-9f8c-a8e7a9491e9a).

### Describe the header

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

```json
"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](https://spec.openapis.org/oas/v3.1.1.html#security-scheme-object) 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](https://airnodehub-docs.api3.org/airnode/wrapping-an-api) supplies the provider-side reference. This configuration example establishes no runtime result, integration approval or deployment date.

## Sources

- [Wrapping an API: upstream keys and custom API-key header prefixes](https://airnodehub-docs.api3.org/airnode/wrapping-an-api) — AirnodeHub documentation
- [OpenAPI Specification v3.1.1: Security Scheme, Security Requirement and Specification Extensions](https://spec.openapis.org/oas/v3.1.1.html) — OpenAPI Initiative

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)