> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eigenpal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Service accounts

> Give each integration its own identity, so its API calls are attributed to it in the audit log and survive staff changes.

A service account is an organization identity for an integration, such as an
ERP connector, a scheduled script or a CI pipeline. It has a role and can
belong to groups like a person, but it never signs in. It acts only through
the API keys you issue to it.

Use a service account instead of a personal API key or a shared "robot" user
when:

* your audit log must show **which integration** made a call, not which person
  happened to create the key;
* the integration must **keep working when that person leaves** (a personal
  key stops working when its owner is removed or demoted);
* you need to give an integration **narrower access** than the person who sets
  it up.

Owners and admins manage service accounts. Admins manage service accounts with
the member role; only owners can create, change or delete a service account
with the admin role, or issue and revoke its keys.

## Create a service account

1. Open **Settings → Service accounts** and select **Create service account**.
2. Give it a name (shown in the audit log), an optional description, a role and
   an owner. The owner is the person accountable for the integration. If they
   leave, the account keeps working and is flagged so an admin can pick a new
   owner.
3. To open private folders, add the service account to groups in
   **Settings → Access control**, the same way you would for a person.

| Role | Access |
| - | - |
| Member | Folders open to everyone, plus private folders opened by its groups. |
| Admin | Every folder. Grant it only when the integration truly needs it. |

## Issue and rotate keys

From the service account, choose **Manage keys** and create a key. You can
also create one from **Developers → API keys**: under **Acts as**, pick the
service account instead of yourself. Copy the key into your integration's
secret store: it is shown only once.

Pick an expiry of up to one year, or **Never** for a key you rotate yourself.
Keys default to 90 days.
To rotate without downtime, create a new key with the same access shown on the
old key, switch the integration to it, then revoke the old key. A service
account can hold several keys at once.

Keys are issued by a signed-in owner or admin. A service account's key cannot
create keys, change service accounts or manage members.

## What the audit log records

Calls made with a service account's key name the service account:

```json theme={null}
{
  "event": { "action": "workflow.updated", "outcome": "success" },
  "actor": {
    "type": "service_account",
    "id": "svc_...",
    "name": "SAP invoice ingest",
    "api_key_id": "eig_..."
  }
}
```

Creating, changing and deleting a service account is recorded as
`service_account.created`, `service_account.updated` and
`service_account.deleted`, with the administrator as the actor. Issuing and
revoking its keys is recorded as `api_key.created` and `api_key.revoked`.

## Delete a service account

Deleting a service account immediately revokes all of its keys and removes its
group memberships and folder access. Past runs and audit entries keep its
name.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.