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
- An aiAxonIQ account with the Admin role — creating a key requires it
- A rough idea of how ingest works
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
- In the dashboard, open Settings → License Keys.
- Select New Key and give it a name. The name is for you — use something that identifies where the key will live, like
checkout-prodorstaging-collector. - Copy the key immediately.
Keys look like this — the prefix oiq_ followed by 32 hexadecimal characters:
oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8eCreating 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:
X-License-Key: oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8eWith 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_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8eIf 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:
- Create the new key.
- Deploy it to every service using the old one.
- Confirm the new key's last used timestamp is advancing.
- 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.