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.

Before you start. Creating a key requires the Admin role on your organization. A rough idea of how ingest works helps but is not required.

Create one

1. Open Settings → License Keys

   In the dashboard.

2. 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.

3. Copy the key immediately

   It is shown once. See the warning below.

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

oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

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.

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:

X-License-Key: oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

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

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:

Authorization: Bearer oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

If both headers are present, X-License-Key wins. There is one further reason to prefer it: 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:

1. Create the new key
2. Deploy it to every service using the old one
3. Confirm the new key's last-used timestamp is advancing
4. Revoke the old key

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.

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.

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

Send data with OpenTelemetry

Point an exporter at your endpoint.

Endpoints and errors

Every path, status code and limit.