IAM & Access

Service Accounts

Create and manage organisation service accounts, access, and API-key credentials.

A service account is a non-human identity for a shared application, backend integration, agent, CI/CD process, or unattended workload.

The service account owns its access. An API key only authenticates as that account; it does not carry separate roles or permissions. Every active API key for one service account therefore receives the same current access.

Use a separate service account when workloads need different owners, environments, permissions, or lifecycle controls. Do not create differently privileged keys on one account.

Create a Service Account

  1. Open Access > Service accounts.
  2. Select Create service account.
  3. Enter a display name and canonical name.
  4. Add an optional purpose and account expiry.
  5. Select Create.

The account belongs to the active organisation and starts with no access and no credentials.

The Service accounts section is available only to administrators with the required principal-management permission.

Manage Identity and Status

Open a service account and use Overview to update its display name, canonical name, purpose, or optional account expiry.

A service account can be:

  • Active: its unexpired credentials can authenticate.
  • Suspended: all credentials are temporarily blocked while its identity and access configuration are retained.
  • Expired: the account expiry has passed. Extend or remove the expiry before issuing another key or returning the account to active use.
  • Revoked: the account is permanently retired and cannot be reactivated.

Use Suspend for a reversible operational stop, Reactivate to resume an eligible suspended account, and Revoke account only for permanent retirement. Revoked accounts are hidden from the list by default but retained for audit; select Show revoked to view them.

Assign Access

Open the account's Access tab to:

  • assign or revoke compatible organisation roles,
  • add or revoke narrow direct permission grants,
  • review roles inherited through groups,
  • inspect effective permissions and the source of each permission.

A role must support the Service account principal type before it can be assigned directly or inherited through a group.

Prefer roles and groups for reusable access patterns. Use direct grants only for a narrow exception, with an explicit scope and optional lifetime.

Issue an API Key

  1. Open the service account's API keys tab.
  2. Enter a key name and optional expiry.
  3. Select Issue key.
  4. Copy the generated key immediately to a server-side secret manager.

The complete value is shown only once and cannot be displayed again.

Issuing a key does not grant access. The key authenticates as the service account and uses whatever access the account has when a request is authorised.

Choose Between a Personal Key and a Service Account

Use a personal API key for your own CLI, development tool, or script when its actions should be attributed to you and follow your current access.

Use a service account for production services, shared integrations, automation, or any workload that must continue independently of one person's organisation membership.

Keep API keys server-side. Do not expose them in browser code, mobile apps, public repositories, device firmware, or customer-visible examples.