Skip to main content
An account is the entity the authenticated user is operating as. Every buyer request runs in the context of one account, identified by a numeric 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.

​
Account model

Full user-context responses returned by account creation and switching separate the product an account uses from its access and approval state: Each account has its own registered customerDomain and membership settings. When an enterprise organization manages more than one account, organization membership grants management access through that hierarchy but does not create direct account membership. Separately, each user manages their own notification preferences — the set of event types and channels (email, in_app) they opt into.

​
Key concepts

​
Task reference

Set up buyer identity

Confirm whole-operator or specific-unit scope before new AdCP 3.2 provisioning

Get current account

GET /accounts/current — your current context

List accounts

GET /accounts — accounts you can access

Update account domain

PATCH /accounts/:customerId/domain — set the registered domain

Get membership

GET /accounts/:customerId/membership — read access settings

Update membership

PATCH /accounts/:customerId/membership — toggle domain auto-join

Get notification preferences

GET /notification-preferences — your opt-ins

Update notification preferences

PUT /notification-preferences — replace your opt-ins