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

# Headers

> Every header Lectr reads and what it does with them.

## Request headers

These are headers your application sends to Lectr on each request.

***

### X-Lectr-Key

**Required.** Identifies your organisation and authenticates the request.

```
X-Lectr-Key: lc_key_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

|                 |                                                                   |
| --------------- | ----------------------------------------------------------------- |
| Required        | Yes — requests without this header return `401`                   |
| Format          | `lc_key_` followed by a random string                             |
| Where to get it | Dashboard → Settings → Integration                                |
| Storage         | Treat like a password — environment variable only, never hardcode |

Requests with a missing or invalid key are rejected immediately. The upstream
provider never sees them.

***

### X-Lectr-Feature

**Optional.** Tags the request with the feature that made it.

```
X-Lectr-Feature: chat
```

|                    |                                                                   |
| ------------------ | ----------------------------------------------------------------- |
| Required           | No                                                                |
| Valid values       | Any non-empty string up to 100 characters                         |
| Recommended format | Lowercase, hyphens for spaces — `onboarding-assistant`            |
| Missing            | Request processed normally, grouped under `untagged` in dashboard |
| Invalid            | Stored as-is, never rejected                                      |

Enables per-feature cost, latency, and error breakdowns in the dashboard.
Required for feature-based routing rules (coming soon).

See [Feature Tagging](/guides/feature-tagging) for the full guide.

***

### X-Lectr-Task

**Optional.** Declares the type of work the request is doing.

```
X-Lectr-Task: classification
```

|              |                                                                        |
| ------------ | ---------------------------------------------------------------------- |
| Required     | No                                                                     |
| Valid values | `classification` `summarisation` `extraction` `generation` `reasoning` |
| Missing      | Heuristic signals used for recommendations                             |
| Invalid      | Stored as-is, no influence on recommendations                          |

Treated as a high-confidence signal by the recommendation engine.
`reasoning` tasks are never recommended for model downgrade — hardcoded protection.

See [Task Types](/guides/task-types) for the full guide.

***

### X-Lectr-Provider

**Optional.** Overrides automatic provider detection.

```
X-Lectr-Provider: anthropic
```

|              |                                              |
| ------------ | -------------------------------------------- |
| Required     | Only for Azure OpenAI                        |
| Valid values | `openai` `anthropic` `groq` `gemini` `azure` |
| Missing      | Provider auto-detected from model name       |
| Invalid      | Logged, defaults to `openai`                 |

Use this when Lectr misdetects a provider or when a new model isn't in the
detection registry yet. Always required for Azure since Azure endpoint URLs
are org-specific and can't be inferred from the model name.

See [Multi-Provider Setup](/guides/multi-provider-setup) for the full guide.

***

### Authorization

**Required.** Your provider API key — forwarded directly to the upstream provider.

```
Authorization: Bearer sk-...
```

|           |                                                                            |
| --------- | -------------------------------------------------------------------------- |
| Required  | Yes — forwarded to provider as-is (OpenAI, Groq, Gemini)                   |
| Anthropic | Send as `Authorization: Bearer sk-ant-...` — Lectr rewrites to `x-api-key` |
| Azure     | Send as `Authorization: Bearer <key>` — Lectr rewrites to `api-key`        |
| Storage   | Never stored, never logged, exists in memory per request only              |

Your provider key is never persisted. Lectr normalises the auth header format
per provider — you always send `Authorization: Bearer`, Lectr handles the rest.

***

## Response headers

Lectr does not add custom headers to responses. The response your application
receives is identical to what the provider returned — headers included.

***

## Header quick reference

| Header             | Required   | Purpose                                  |
| ------------------ | ---------- | ---------------------------------------- |
| `X-Lectr-Key`      | ✅ Yes      | Org authentication                       |
| `Authorization`    | ✅ Yes      | Provider API key passthrough             |
| `X-Lectr-Feature`  | No         | Feature tagging for dashboard breakdowns |
| `X-Lectr-Task`     | No         | Task type for smarter recommendations    |
| `X-Lectr-Provider` | Azure only | Provider override                        |