id and carrying a role (MEMBER, ADMIN, or SUPER_ADMIN) that gates what the caller can do. A user can belong to several accounts; the account API lets you read the current context, list the accounts you can access, and switch your integration between them.
Accounts can form a parent/child hierarchy. An ADMIN can spin up child accounts under a parent (creating the parent on the fly if the customer was standalone), set each customer’s registered customerDomain, and configure membership so that users with a verified matching-domain email auto-join without manual approval. Separately, each user manages their own notification preferences — the set of event types and channels (email, in_app) they opt into.
Key concepts
| Concept | Description |
|---|---|
| Current account | The customer context the request authenticates as — id, company, name, role, customerDomain |
| Child account | A customer created under a parent in the hierarchy; only children can be deleted |
customerDomain | Registered organization domain; required before domain auto-join can be enabled |
| Membership | Per-customer access settings, notably allowDomainAutoJoin |
| Notification preferences | Per-user opt-ins of notificationType × channel |
| Role | MEMBER, ADMIN, or SUPER_ADMIN; admin-only operations require ADMIN on the target customer |
Task reference
Get current account
GET /accounts/current — your current contextList customer accounts
GET /accounts — accounts you can accessCreate child account
POST /accounts/create-child — add a child customerUpdate customer domain
PATCH /accounts/:customerId/domain — set the org domainDelete child account
DELETE /accounts/:customerId — remove a child customerGet membership
GET /accounts/:customerId/membership — read access settingsUpdate membership
PATCH /accounts/:customerId/membership — toggle domain auto-joinGet notification preferences
GET /notification-preferences — your opt-insUpdate notification preferences
PUT /notification-preferences — replace your opt-ins