Using the older navigation? The workspace navigation guide maps Send, Measure, and Build to the existing pages and legacy labels.
API keys are long-lived, tenant-scoped credentials for the partner API. Keep them server-side and manage them under Build → API keys.
Create a Key
- Sign in and open Build → API keys.
- Confirm the LIVE/TEST workspace switch matches the environment you intend to call.
- Select New API key.
- Give the key a descriptive label and choose its allowed scope.
- Copy the secret immediately. Connect shows it once.
The Connect credentials card labels the workspace identifier Account ID. In API and environment
configuration this value maps to tenant_id / CONNECT_TENANT_ID.
Connect-minted keys use an ac_live_… or ac_test_… prefix. Treat the suffix
as opaque; do not validate a fixed length, UUID layout, or hex alphabet in your
application. Tenant IDs are opaque tenant_* workspace slugs, not UUIDs.
LIVE and TEST behavior
TEST is a credential and delivery mode within a workspace; it is not a separate data plane. Use an isolated workspace and non-production deployment for automated fixtures. New TEST launches and their assessment events remain excluded from LIVE Skills and Value calculations. Historical records without a recorded mode cannot establish prior separation.
Skills, capability, graph, CALE and xAPI statement API families currently return
403 TEST_MODE_UNSUPPORTED for TEST credentials. The corresponding dashboard
surfaces show an unavailable state in TEST mode. Use an authorized LIVE key only
for intended LIVE evidence; changing modes does not bypass subscription or role
requirements.
Scopes
public_api: normal customer and partner integrationsinternal_product: approved product-to-product callersadmin: privileged operational callers
There is no generic read or write scope. Each route declares its accepted
scopes in OpenAPI.
Send a Key
Prefer Bearer authentication:
curl https://app.allureconnect.com/api/v1/packages \
-H "Authorization: Bearer $CONNECT_API_KEY"
X-API-Key is also supported. If both headers are sent, Bearer wins.
Never send an API key to /api/customer/*; those routes require a signed-in
Clerk browser session. Never expose a key in browser JavaScript, a launch URL,
logs, screenshots, support tickets, or source control.
Store Keys
Use a server-side secret manager or protected environment variable:
const apiKey = process.env.CONNECT_API_KEY;
if (!apiKey) throw new Error('CONNECT_API_KEY is not configured');
Recommended controls:
- separate LIVE and TEST keys;
- one key per integration or deployment boundary;
- least-privileged scope;
- restricted access to production secrets;
- request-log monitoring under Build → Request logs;
- immediate rotation after suspected exposure.
Rotate or Revoke
The Rotate row action creates a replacement and revokes the old key atomically. It preserves the stored key's scope, LIVE/TEST mode, expiry, permissions and client restrictions. Copy the replacement secret from the one-time reveal and update consumers immediately; the old key stops working as soon as rotation succeeds.
For a staged replacement with an overlap period, use separate create and revoke operations in Build → API keys:
- Create a replacement key.
- Put the new secret in every consuming system.
- Verify requests appear under Request logs with the replacement key.
- Revoke the old key from the dashboard.
There is no public POST /api/admin/api-keys endpoint. There is no public DELETE /api/admin/api-keys/{id} endpoint. Automation should use an approved
internal provisioning workflow rather than copying dashboard-only routes.
Revoked secrets return:
{
"error": "API key required",
"code": "API_KEY_REQUIRED"
}
Incident Checklist
If a key may be compromised:
- Revoke it in the dashboard.
- Create and securely distribute a replacement.
- Review Request logs for unexpected paths, status codes, and timestamps.
- Rotate any downstream secret that was stored beside it.
- Record the incident without pasting the secret into the ticket.
See the API reference and error codes.