Service Accounts

A Service Account is a durable, non-human identity for one workload inside one Project. It owns the workload's product scopes and platform-managed request limit. Its Credentials are replaceable secrets; rotating a Credential does not replace the Service Account or lose its attribution history.

Use one Service Account for callers that should share the same permissions, rate budget, and operational identity. Use separate Service Accounts when those boundaries should differ.

Create one in the Dashboard

Open Dashboard → Service Accounts, choose the owning Project, name the workload, and select only the permissions it needs. All available permissions is a convenience selection for the scopes shown today; it is expanded to those exact scopes and never grants future scopes automatically.

After creation, issue a Credential and store its reveal-once value in a server-side secret manager. Project and Service Account creation are Dashboard workflows, not public API operations.

Permission scopes

The currently available scopes are:

Refresh completion can be delivered through project-level webhooks and SSE when those options are released. For now, follow the documented bounded status-polling workflow.

Rate and lifecycle

Every active Credential for a Service Account shares the same platform-managed request limit. Customers can see the effective limit but cannot change it. SteamCall staff can apply an audited override when an operational review requires one.

• Active — active, unexpired Credentials may authenticate.
• Disabled — all Credentials stop authenticating until the Service Account is enabled.
• Archived — the identity and history remain visible, but it cannot authenticate or be enabled.

A Service Account is not a Customer, wallet, human login, or secret. Balance and billing remain Customer-wide, while requests retain both Service Account and exact Credential attribution.

Continue with Credentials, Projects, and Rate limits.