Title
Page icon
Create new category
Edit page index title
Edit category
Edit link
Api Keys
API Keys
Explanation (Core Concepts)
What are API Keys?
API keys let you call xDP's APIs programmatically — from a CI/CD pipeline, a scheduler, or an external script — without using your personal browser session. As a Governance & Security Administrator, you use API keys to give automation a durable, auditable identity that's separate from any one person's interactive login, so pipelines keep working even if a user's password changes and access can be revoked per-integration without affecting anyone else.
Under the hood, an API key is a cryptographically random access key / secret key pair generated through xDP's identity backend (Admin Central) the moment you create it. xDP never stores the secret key itself — only key metadata (owner, name, creation time, expiry) is kept, so the raw secret exists in exactly one place: the response you get back at creation time.
Key Concepts
Access key — The public identifier half of the key pair; safe to log or reference, but not sufficient on its own to authenticate.
Secret key — The private half of the key pair; treat it like a password. xDP shows it to you exactly once, at creation.
Key owner — The user the key authenticates as. Actions taken with the key carry that owner's permissions and show up under their identity in audit trails.
Expiry (Valid Till) — An optional date after which the key stops authenticating. Keys created without one are valid for a long default window, so setting an explicit expiry is how you bound the blast radius of a leaked key.
Capabilities
API key management in xDP is organized around a single API Keys screen, addressing three use cases:
Generate (provisioning) — Create a new access key / secret key pair scoped to your identity, named so you and other admins can tell integrations apart later.
Inventory (monitoring) — See every key that exists for your tenant: who owns it, when it was created, and when it expires. Use the search box to find a key by name.
Revoke (configuration) — Delete a key immediately when an integration is retired or a credential is suspected of being compromised.
Note: The key pair can only be downloaded once, immediately after creation. If you lose the downloaded file, there is no way to retrieve the pair again — you must delete the key and generate a new one.
Tutorial (Getting Started)
Prerequisites
You're signed in to xDP with a role that grants the
API Keyspermission (view, and create/modify if you intend to generate or delete keys).You know which system or pipeline will use the key, so you can give it a name that identifies its purpose later.
Note: If no keys exist yet for your tenant, the API Keys table shows an empty state rather than a blank screen.
Your First Workflow
This walkthrough generates your first API key and downloads it securely.
Click the Settings icon in the main navigation, then open API Keys.
On the API Keys page, click Generate API Key.
On the Generate API key page, enter a Display Name that identifies what will use this key (for example,
airflow-ci-pipeline).Optionally choose a Valid Till date to bound how long the key stays active — the key expires automatically after that date.
Click Generate Key.
On the confirmation screen, click Download API Key to download the access key / secret key pair as a file — this is the only time you can retrieve them.
Store the downloaded file in your secrets manager or CI/CD vault, then delete it from your local downloads.
Example: A data engineer wiring up a nightly Airflow DAG that calls xDP's job-submission API generates a key named
airflow-nightly-etlwith a 90-day expiry, then stores the downloaded pair in the pipeline's secrets store — instead of embedding a personal login.
How-to Guides
Rotate an API key without breaking automation
You already have a working key in production and need to replace the secret without a gap in service.
Generate a new key with a different name (for example, append
-v2) rather than deleting and recreating the existing one first.Update the calling system to use the new access key / secret key pair.
Confirm the calling system authenticates successfully with the new key.
Delete the old key from the API Keys table.
Tip: Rotating via a new key name avoids downtime — deleting the old key first breaks any caller still using it until the new one is wired in.
Revoke a compromised or unused key
Open Settings → API Keys.
Find the key by its Key Name, or use Search By Name if the table is long.
Click the delete (trash) icon at the end of the key's row.
Confirm when prompted.
Verify the key no longer appears in the table, and confirm the dependent system now fails to authenticate with the old credentials (expected).
Warning: Deletion is immediate and irreversible. Any pipeline still using the deleted key starts failing authentication right away.
Reference
API Keys table fields
Field | Description |
|---|---|
Key Name | The display name you assign at creation; identifies the key's purpose in the inventory table. Optional — older keys may show blank. |
API Key | The access key (public identifier) shown in the inventory table. |
User | The identity the key authenticates as; the key's owner. |
Created On | Timestamp the key was generated. |
Valid Till | Expiry date; defaults to a far-future date when no Valid Till was set at creation. |
Use Search By Name above the table to filter by Key Name, and the delete icon at the end of a row to revoke that key.
Authenticating with an API key
Send both halves of the key pair as request headers on each call:
Header | Value |
|---|---|
| The access key from the downloaded key file. |
| The secret key from the downloaded key file. |
xDP validates the pair against your tenant's identity backend and resolves the request to the key owner's identity and permissions — the same authorization rules that apply to that user's interactive session apply to API calls made with their key.
Best Practices
Tip: Name every key for the system that uses it, not the person who created it — ownership metadata already tracks the creator, and a purpose-based name survives staff turnover.
Set an expiry on every key. An unbounded key is a permanent liability; a dated one limits how long a leak stays exploitable.
Use one key per integration. Sharing a single key across multiple pipelines means revoking it for one breaks all of them.
Store secrets in a vault, not in code. Never commit an access key / secret key pair to a repository or a shared document.
For additional help, contact our Support Team!
©2026, Acceldata Inc — All Rights Reserved.