Skip to main content
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 → API keys

In the dashboard. The product calls these API keys and the ingest surface calls them license keys; they are the same object.
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:
Copy it when it is shown. What authenticates your ingest is a one-way hash of the key, and that is all the platform needs to keep — so treating the creation dialog as your only chance is the safe habit.Where the deployment has a key-encryption keyring configured, the value is additionally sealed at creation so an Admin can display it again from the key list — the eye icon beside the masked prefix. Every display is written to the audit log with the actor and the key. Where no keyring is configured, or for a key created before the deployment had one, that action answers KEY_NOT_RECOVERABLE and the only route is a new key.
Any signed-in user can see the list of keys — names, prefixes, creation time and last-used time. Displaying a key’s value requires Admin.

​
Use it

Send the key as the X-License-Key header on every ingest request:
With an OpenTelemetry SDK, the standard environment variable sets it for you:
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:
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 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.
Revocation drops the cached validation as it happens, across every receiver instance rather than one at a time, so it takes effect in about a second rather than at the end of a cache window. The residual gap is a request already in flight and a very short per-process cache.Rotate a leaked key as well as revoking it. Revocation stops the key; it does not tell you what was sent with it before you noticed.

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