> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thewo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Authenticate protected The Wo requests using a server-side API key.

# Authentication

Protected The Wo endpoints use API key authentication.

Authentication is a shared platform capability. Individual products can use
this same mechanism without redefining API key behavior inside each product.

Operational Evidence currently uses this authentication model for both report
generation and current-usage visibility.

During the private beta, API keys are provisioned manually after access
approval.

See [Operational Evidence beta access](/operational-evidence/beta-access) for
the current onboarding process.

Send your API key through the following HTTP header:

```http theme={null}
x-api-key: <your-api-key>
```

For example:

```http theme={null}
POST /v1/evidence/reports
content-type: application/json
x-api-key: <your-api-key>
```

## API keys are secrets

An API key authenticates your integration and must be treated as a secret
credential.

Do not:

* commit API keys to source control;
* include API keys in public documentation;
* include API keys in screenshots;
* send API keys through query parameters;
* write raw API keys to ordinary application logs;
* embed API keys in publicly distributed frontend code;
* embed API keys in publicly distributed mobile applications.

The current API key model is intended for trusted server-to-server
integrations.

Store the credential in a server-side secret manager or environment variable
appropriate for your deployment environment.

## Missing API key

Requests to protected endpoints without the `x-api-key` header are rejected
before the business operation is executed.

Example response:

```http theme={null}
HTTP/1.1 401 Unauthorized
content-type: application/json
```

```json theme={null}
{
  "error": {
    "code": "missing_api_key",
    "message": "The x-api-key header is required.",
    "requestId": "req_123"
  }
}
```

## Invalid API key

Invalid, inactive, or revoked credentials are represented through the same
public error.

This prevents API consumers from learning the internal lifecycle state of a
credential.

Example:

```http theme={null}
HTTP/1.1 401 Unauthorized
content-type: application/json
```

```json theme={null}
{
  "error": {
    "code": "invalid_api_key",
    "message": "The provided API key is invalid.",
    "requestId": "req_123"
  }
}
```

## Authentication service unavailable

If the API cannot safely validate a credential because the authentication
service is temporarily unavailable, the request fails closed.

```http theme={null}
HTTP/1.1 503 Service Unavailable
```

The public error code is:

```text theme={null}
api_key_authentication_unavailable
```

The protected operation is not executed when authentication cannot be
completed reliably.

## Request IDs

Error responses include a `requestId`.

Keep this value when reporting an integration problem because it can be used
to correlate the failed request without exposing the API key itself.

## Product onboarding

Authentication describes how a credential is used after it has been issued.

For the currently available product, continue to
[Operational Evidence beta access](/operational-evidence/beta-access) to
understand manual approval and provisioning.