QueueUp / docs

API keys

Create, list, and revoke API keys for the customer API.

The API keys page is where admins mint Bearer tokens for the customer API. Reach it from the top nav (admin only, Pro and Team plans).

Page elements

  • Create key button. Opens a modal where you pick a name and tick the permissions this key carries. The full key is shown exactly once after creation.
  • Active keys table: name, access summary, prefix (e.g. qu_live_AbCd…), last used, created.
  • Revoke button per row. Revocation is immediate and irreversible; any service still using the key will start receiving 401.

Creating a key

Pick a memorable name. It’s purely cosmetic but it’s what shows up in the Activity log when the key drives a mutation, so something like crm-sync, staging-deploy, or analytics-warehouse beats key1.

Tick the permissions this key should carry. Each row maps to one wire-level scope:

  • Read subscribers (subscribers:read). Lets the key pull paginated subscribers.
  • Create subscribers (subscribers:write). Lets the key submit server-side signups.

Tick both for the typical backend integration. Tick only Read for analytics jobs, CSV exports, or anything where the credential might end up close to a frontend bundle. Permissions on an existing key are immutable; to change them, mint a fresh key with the new set and revoke the old one.

The full scope reference lives in Authentication → Scopes.

After clicking Create, the panel shows a one-time reveal dialog with the full key. Copy it now. The list page only shows the prefix from this point on; the full value is unrecoverable. If you lose it, revoke and create a fresh one.

Plan downgrades

If your plan drops below Pro (cancellation, failed renewal, plan change), every existing key keeps its row but stops working. Calls return 403 feature_not_allowed. Restore the plan and the same keys resume working without re-creation.

Audit trail

Every create and revoke writes one row into the Activity log with the operator’s identity. Mutations made through a key (via the customer API surface) are recorded with the key’s display name as the actor and a small “API key” badge in the log table.