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

# Create a license key

> License keys authenticate every ingest request. How to create one, where it goes, and the four things it deliberately does not control.

A license key is the credential your services use to send telemetry. It is not a
login: it authenticates ingest only, and it is separate from the session token
that signs you into the dashboard.

<Info>
  **Before you start.** Creating a key requires the **Admin** role on your
  organization. A rough idea of [how ingest works](/get-started/how-it-works)
  helps but is not required.
</Info>

## Create one

<Steps>
  <Step title="Open Settings → License Keys">
    In the dashboard.
  </Step>

  <Step title="Select New Key and name it">
    The name is for you — use something that identifies where the key will live,
    like `checkout-prod` or `staging-collector`.
  </Step>

  <Step title="Copy the key immediately">
    It is shown once. See the warning below.
  </Step>
</Steps>

Keys look like this — the prefix `oiq_` followed by 32 hexadecimal characters:

```text theme={null}
oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e
```

<Danger>
  **The full key is shown exactly once.** Only a hash of the key is stored, so
  it cannot be shown or recovered later. The key list afterwards displays a
  short prefix so you can tell keys apart, never the key itself. If you lose it,
  create a new key and revoke the old one.
</Danger>

Any signed-in user can see the list of keys — names, prefixes, creation time and
last-used time — but not the key material.

## Use it

Send the key as the `X-License-Key` header on every ingest request:

```http theme={null}
X-License-Key: oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e
```

With an OpenTelemetry SDK, the standard environment variable sets it for you:

```bash theme={null}
export OTEL_EXPORTER_OTLP_HEADERS="X-License-Key=oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e"
```

The receiver also accepts the key as a bearer token, which is useful when a tool
you cannot modify only lets you set an `Authorization` header:

```http theme={null}
Authorization: Bearer oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e
```

If both headers are present, `X-License-Key` wins. There is
[one further reason to prefer it](/send-data/endpoints#authentication): rate
limiting buckets by that header, falling back to source IP without it.

## Rotating and revoking

**Revoke** a key from the same Settings page. Revocation is immediate and
permanent — a revoked key cannot be reinstated, and it disappears from the key
list.

There is no single-step rotate action. To rotate a key without a gap in
coverage:

<Steps>
  <Step title="Create the new key" />

  <Step title="Deploy it to every service using the old one" />

  <Step title="Confirm the new key's last-used timestamp is advancing" />

  <Step title="Revoke the old key" />
</Steps>

Doing it in that order matters: revoking first means every request in between is
rejected with a `401`, and that data is not buffered anywhere on our side.

<Warning>
  **Validation results are cached briefly.** The receiver caches key validation
  for a few minutes, so a revoked key can be accepted for a short window after
  you revoke it. Treat revocation as "effective within minutes", not instantly,
  and rotate a leaked key rather than relying on revocation alone to stop
  traffic already in flight.
</Warning>

## What a key does and does not control

Keys are tenant-wide ingest credentials. Being precise about their limits saves
you from designing around capabilities that are not there.

| A key                                                                      |                                                                                                       |
| :------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------- |
| **is not scoped** to a service, environment or signal type                 | Every key for your account can send every signal your plan includes                                   |
| **does not expire**                                                        | It is valid until revoked                                                                             |
| **cannot be restricted** to particular source addresses from the dashboard |                                                                                                       |
| **does not decide which signals are accepted**                             | That is a property of your account's enabled features. Turning off a signal affects every key at once |

The practical consequence: a key's blast radius is your whole tenant, so create
separate named keys per deployment. You cannot limit what a leaked key can send,
but you can revoke exactly the one that leaked without touching the others —
which is only possible if you did not share one key everywhere.

## Next

<CardGroup cols={2}>
  <Card title="Send data with OpenTelemetry" icon="telescope" href="/send-data/otel/collector">
    Point an exporter at your endpoint.
  </Card>

  <Card title="Endpoints and errors" icon="list" href="/send-data/endpoints">
    Every path, status code and limit.
  </Card>
</CardGroup>