> For the complete documentation index, see [llms.txt](https://docs.artific.nl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.artific.nl/en/for-administrators/access/service-accounts.md).

# Service accounts

Accounts for software rather than people. Found under **User management → Service accounts**.

## What they are for

When another system needs to talk to the platform (a website, a back-office application, a scheduled job), it needs an identity. Using a person's account for this is a bad idea: it breaks when they leave, their rights change for unrelated reasons, and audit trails become meaningless.

A service account is an account with no person behind it, its own credentials, and rights you control deliberately.

## Creating one

**Add service account**.

| Field             | Notes                                                         |
| ----------------- | ------------------------------------------------------------- |
| **Name**          | What the account is for.                                      |
| **Email address** | Generated automatically from the name. Read-only.             |
| **Description**   | Which system uses it, who owns that system, and what it does. |

Name it after the consuming system (`Website chat integration`, `Nightly report job`) so that a year from now, someone can tell what breaks if they disable it.

After creating, you are taken straight to its rights.

## Rights

A service account gets its rights exactly as a person does: through **user group membership**. There is no separate permission model.

The **Rights** tab lists its groups. **Add account to groups** adds more; the delete button on a row removes one.

{% hint style="warning" %}
Give a service account the narrowest set of groups that lets it do its job. It is a set of credentials sitting in another system, and it will do whatever those credentials allow if they ever leak. Consider creating a group specifically for the integration rather than reusing a broad staff group.
{% endhint %}

## API keys

The **Keys** tab manages the credentials the consuming system uses.

**Create a new API key** asks for:

| Field            | Notes                         |
| ---------------- | ----------------------------- |
| **API Key name** | Which system holds this key.  |
| **Expiry date**  | Optional, up to a year ahead. |

{% hint style="danger" %}
The key is shown once, when created, and downloaded to your device. It cannot be recovered afterwards. If it is lost, delete it and create a new one.
{% endhint %}

Keys are listed with their status (**Valid** or **Expired**), their name, and their creation and expiry dates. Deleting a key revokes it immediately.

## Activating and deactivating

The status column shows **Active** or **Inactive**. Deactivating blocks all authentication for the account without deleting anything, and is reversible.

Deactivate first whenever you suspect a problem or are decommissioning an integration. It stops access immediately, and you can reverse it if you were wrong.

## Deleting

Deleting a service account removes all its API keys permanently, revokes access to everything it reached, and breaks any process depending on it.

The confirmation lists exactly those consequences. Deactivate first, wait to see what breaks, then delete.

## Running them well

* **One service account per integration.** Shared accounts make it impossible to revoke one system without breaking another.
* **One key per environment**, so a test system and a live one can be revoked separately.
* **Set expiry dates**, so keys get reviewed rather than living forever.
* **Record the owner** in the description. Orphaned integrations are the hardest thing to clean up safely.
* **Review the list periodically** and deactivate anything nobody can account for.

See also [API access](/en/for-administrators/tools/api-access.md) for the developer-facing side.