Skip to main content
An API key authenticates requests to oleander’s API and CLI as its owning principal. A principal can own multiple keys. Keys do not receive roles directly: IAM checks use the owner’s assigned roles, so changing those roles changes the key’s IAM access.

​
Where to manage keys

All keys are managed in one place, Settings → Config → API keys: your own keys, Application and Agent keys, and legacy keys, each on its own tab. The former Settings → Personal → API keys page redirects there. Human keys are self-service: even an OrganizationAdmin cannot view, create, or revoke another Human’s keys. Authorized administrators can manage Application and Agent keys. Permission to view a principal does not grant permission to view that principal’s keys. The TokenSelfAdmin role grants Describe, Create, and Revoke for the acting principal’s own keys. See API-key scopes and actions for finer control.

​
Create and use a key

Choose Create API key, enter a description and expiration, and select Generate API key. When managing Application or Agent keys, choose the owning user. The generated key acts as that owner, not the administrator who created it. The key list shows status, type, last use, and expiration, and lets authorized users copy the key value. Describe on API keys therefore grants access to credentials, not just metadata. Store keys in environment variables or a secret manager; never commit them to source control. API keys also carry lineage event scopes. These are separate from the resource scopes used in IAM permissions and do not replace the owner’s compute or warehouse grants.

​
Expiration and revocation

Keys can have an expiration or no expiration. Use Revoke in the key’s actions menu to mark it revoked. The UI has no separate Rotate action; replacing a key means creating a new key, updating its consumers, and revoking the old one.

​
OleanderSystem’s default key

The system-managed OleanderSystem principal owns a default key used by internal workflows, including OpenLineage reporting. Revoking it can interrupt those workflows. Provisioning retries preserve the original key and its revocation state; creating another key does not automatically replace that default key for internal consumers.

​
Legacy keys

Legacy keys are organization-wide credentials created before principal-owned keys. They do not follow the owner-and-role model described above, and operations requiring a principal identity reject them. The Legacy tab uses separate management permissions: Principals → All principals → Describe to list keys and Manage grants on the same scope to revoke them. Use principal-owned keys for IAM-controlled workloads.