# Service Accounts and Automation

Source: https://www.jawsdeploy.net/guides/service-accounts-and-automation

A service account is an identity for software. Each one has scoped permissions and a rotatable API key.

A service account is the identity CI tools and automation scripts use to call the Jaws Deploy REST API. It's distinct from a human user: no UI login, no email, no group membership - just an ID, an API key, and a scoped permission set.

## Creating one

In **Workspace -> Service accounts**, click **New**. Give it a name that describes its job (`teamcity-checkout-build`, `github-actions-platform`). Pick the permissions it needs - usually `releases.create` for a CI integration, plus `deployments.create` if the integration also triggers deployments.

## API keys

Each service account can hold one or more API keys. Keys are rotatable independently - rotate by creating a new one, distributing it to consumers, and revoking the old one. Keys are shown once at creation and never displayed again.

## Same pattern works for any CI tool

The API key is stored in the CI tool's secrets store, never in source.

```
Connect-JawsDeploy `
    -Url      "https://deploy.acme.internal" `
    -Account  "teamcity-checkout-build" `
    -ApiKey   $env:JAWS_API_KEY

New-JawsDeployRelease `
    -Workspace "default" `
    -Project   "checkout-service" `
    -Version   "$buildNumber"
```

> **// One service account per integration - Don't share keys across pipelines.**
> 
> A separate service account per CI integration means revoking one key affects exactly one consumer. It also makes the audit log readable: "who created this release?" gives you the specific pipeline, not a generic shared account.