Service accounts

A service account is a machine identity in an org — a Connected ID of type Service. It is not an org member: it has no linked user, takes no seat, and never appears in the member list or in SCIM /Users. Base path: /api/org/{slug}/service-accounts (signed-in member of the organization).

Method · Route	Scope	Purpose
POST /	org.role.create	Create a service account. Body: name, scopes[], description?. Returns serviceAccountId, name, email, roleId, roleKey, scopes.
GET /	org.setting.read	List the org’s service accounts: id, name, email, status, createdAt, newest first.

POST / returns 403 with error = "PERMISSION_DENIED" when a requested scope covers an Owner-only scope (view.billing, org.org.billing_manage, Roost access) that the caller does not hold.

What POST / does

1. Creates the service identity with no linked user and no membership tier — a machine badge, not a membership. Its email is {name}@service.{slug} (name lower-cased, spaces replaced by -).
2. Creates a dedicated role with key svc-{name}-{id8}, where id8 is the first eight characters of the new serviceAccountId.
3. Adds each requested scope to that role (creating the permission catalog entry if new).
4. Assigns the role to the service account, compiling its permissions.

So a service account’s permissions flow through the same RBAC model as human members — see Roles & permissions and Permission scopes. Because the badge has no linked user, service accounts are excluded from seat counting, member listings, SCIM provisioning, and the membership-type derivation — see Connected ID.