Skip to main content
New: LLM Observability is now GA

Create a license key

License keys authenticate every ingest request. How to create one, where it goes, and what it does and does not control.

Before you start

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.

Create one

  1. In the dashboard, open Settings → License Keys.
  2. Select New Key and give it a name. 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.

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

text
oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

Creating a key requires the Admin role. 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
X-License-Key: oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

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

bash
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
Authorization: Bearer oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e

If both headers are present, X-License-Key wins.

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.

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.
  • A key does not expire. It is valid until revoked.
  • A key cannot be restricted to particular source addresses from the dashboard.
  • Which signals are accepted is a property of your account's enabled features, not of the individual key. 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 steps