# 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 management** > **Service accounts**.
2. Select **Create service account**.
3. Enter a display name. The canonical name is generated from the display name as you type; edit it if you need a specific stable 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, then select **Save identity**. Select **Remove expiry** to make the account non-expiring. Overview also shows the account's ownership, creation time, and principal ID.

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.

## The Infuse IoT API Access Account

Organisations linked to Infuse-IoT Cloud include a managed service account named **Infuse IoT API Access**. Infuse creates it when the organisation is linked, and it holds the **IoT Admin** role for that organisation.

The account and its IoT Admin assignment are managed by Infuse. If you need to block its credentials, suspend the account rather than revoking it, because Infuse relies on the account for the organisation's IoT link.

Because it has full organisation-level IoT access, prefer creating a separate service account with a narrower IoT role for each integration, such as **IoT Viewer** for read-only reporting or **Device Operator** for device configuration updates.

## Issue an API Key

1. Open the service account's **API keys** tab.
2. Enter a key name and optional expiry. Leave the expiry blank for a key that does not expire.
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.

To rotate without downtime, issue a replacement key before revoking the old one. Select **Remove expiry** beside an existing key to keep using it with no expiry. See [API Keys](/docs/iam-and-access/api-tokens#remove-a-key-expiry).

Viewing, issuing, or revoking service-account keys requires credential-management permission in the organisation.

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.

The same key can call Infuse Platform APIs and the Infuse-IoT Cloud API. Exchange it with the audience of the API you are calling; see [Token Exchange](/docs/iam-and-access/token-exchange).

## 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.