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

# Service Accounts

> Create least-privilege workload identities for Jobs, Endpoints, integrations, and CI.

Service Accounts are non-human principals. Use them whenever RevoEngine or an external system must act without an interactive person: scheduled Jobs, CI/CD, server integrations, durable Agents, and API clients.

## Create a workload identity

Open **Service Accounts**, select **Add**, and configure:

| Field         | Required | Purpose                                                                       |
| ------------- | -------- | ----------------------------------------------------------------------------- |
| Name          | Yes      | Stable workload name; the UI validates the service-account naming pattern.    |
| Owner type    | Yes      | `USER` or `GROUP`.                                                            |
| Owner         | Yes      | The accountable person or team selected from the corresponding catalogue.     |
| Metadata      | No       | Environment, system, cost centre, rotation owner, or other organization data. |
| Advanced data | No       | Instance-specific advanced attributes; manage under your identity policy.     |

The platform creates the account email/identifier; it is displayed as read-only after creation.

Reopen the account to assign **Groups**, **Permission groups**, and API keys. Ownership is accountability metadata—it does not automatically grant the owner the service account's runtime permissions.

## Design one account per trust boundary

Do not share one service account across unrelated systems. Separate identities let you rotate or disable one integration without stopping every workload.

```text theme={null}
svc-checkout-prod       -> Endpoint invocation and Orders access
svc-settlement-worker   -> settlement Job and restricted finance Tables
svc-ci-release          -> Component release permissions only
```

Use metadata such as `environment`, `system`, `ownerTeam`, and `rotationPolicy` for discovery. Never store the key value itself in metadata.

## Grant access

1. Add the account to a Permission group containing only the required platform roles.
2. Add it to Groups used by restricted Tables, Views, or Storage folders.
3. Test the exact API or automation operation.
4. Remove any temporary administrative access used during setup.

The account executing a Job or integration is re-evaluated at runtime. A template created by an administrator does not inherit administrator access.

## API keys

Open a saved Service Account and select **API Keys**. Create a key for one client or deployment, store the value once in a secret manager, and record its owner and rotation date.

```bash theme={null}
curl "$REVO_PLATFORM_URL/api/v1/automation/job" \
  -H "Authorization: Bearer $REVO_API_KEY"
```

Keys inherit the account's current status, platform roles, Permission groups, and resource ACLs. Disabling the account invalidates admission without requiring every key row to be deleted first.

<Warning>
  Never paste a key into Component source, metadata, Job input, Chat, Assistant, screenshots, or documentation. Resolve it from an approved secret manager or RevoEngine Secrets.
</Warning>

## Lifecycle and roles

The UI supports save, API-key management, activate, disable, enable/disable platform access, delete, and restore.

| Action                                                        | Role                                                     |
| ------------------------------------------------------------- | -------------------------------------------------------- |
| List, inspect, and open API Keys                              | `USER_READ`, `USER_WRITE`, or `USER_ADMIN` as applicable |
| Edit identity and membership                                  | `USER_WRITE` or `USER_ADMIN`                             |
| Activate, disable, change platform access, delete, or restore | `USER_ADMIN`                                             |

Disable immediately when ownership is unclear or a credential may be exposed. Before permanent deletion, move any Jobs, Schedules, Agents, and external clients to a replacement principal.

## Rotation runbook

1. Create a new key for the same Service Account.
2. Deploy it to the consumer's secret store.
3. Verify a real authenticated request and expected ACL behavior.
4. Revoke the old key.
5. Monitor authorization failures and workload status.
6. Record the new rotation date without recording the key value.

## Production checklist

* One account per system, environment, or trust boundary.
* Explicit human or Group owner.
* Least-privilege Permission groups.
* Explicit membership for restricted resources.
* Separate keys per client deployment.
* Documented rotation and emergency-disable procedure.
* No unattended automation under a user identity.

See [Permissions](/operate/permissions), [Groups](/operate/groups), and [Secrets](/operate/secrets).