Skip to main content
A service account represents an application or automated job independently of a person’s sign-in. Define its owner, purpose, and required permissions before issuing machine credentials.
Service accounts are being rebuilt around machine-to-machine authentication. Listing, creation, and service-account API-key operations currently return HTTP 501. The dashboard page and public contracts do not establish a usable service-account lifecycle.

​
Prepare an automation identity

Work with the workspace administrator and the person responsible for the application.
1

Describe the workload

Record the application name, environment, owner, and expected API operations. Separate a production workload from development or local testing.
2

Specify access

List required resources and read or write actions. Identify any publication, deletion, or credential-management actions that need an explicit review step.
3

Define credential operations

Assign responsibility for credential storage, rotation, revocation, and incident response. Record how the application should behave when access expires or is removed.
The service-account list and creation contract remain reference material for the unavailable operations. Repeated requests will not enable them. Personal API keys have a separate implemented lifecycle. They retain human ownership and should not be described as service accounts. If that ownership model does not meet your workload’s requirements, keep the integration’s identity setup pending.
The current backend rejects service-account operations with HTTP 501, including requests from that form.
The prior API-key-backed implementation has been removed. Wait for the supported replacement lifecycle.