Skip to main content
Returns all accounts the authenticated agent can operate on this vendor agent. Use this to discover existing accounts, check status changes on pending accounts, and retrieve account_id values for use in protocol operations. For upstream-managed account namespaces, list_accounts is not optional discovery polish; it is the namespace discovery contract. The upstream platform owns the accessible account set, so buyers MUST resolve an explicit account_id before the first account-scoped request. If the authenticated credential can access more than one account, the seller MUST expose list_accounts; if it can access exactly one account, the seller SHOULD expose list_accounts returning that singleton so SDKs can auto-select it and still send { "account_id": "..." } on required-account calls. sync_accounts provisioning does not create account-id accounts in 3.0.x unless a future explicit capability declares that mode; if sync_accounts is exposed on these sellers today, use it only for settings updates against an account already identified by account_id. list_accounts works across all vendor protocols — media buy agents, signals agents, governance agents, and creative agents all return accounts through this same task. Response Time: ~1s. Request Schema: static/schemas/source/account/list-accounts-request.json Response Schema: /schemas/v3/account/list-accounts-response.json

Quick Start

List all accounts this agent can operate:

Request Parameters

All parameters are optional. An empty request returns all accounts visible to the authenticated caller. Use account when re-reading one known account by account_id or by natural key (brand + operator, optionally sandbox).

Response

Each account includes:

Single-publisher cardinality

A seller serving exactly one publisher entity MAY return that entity as the sole account on list_accounts responses, regardless of calling principal. The “Direct advertiser with single account” example in list-accounts-response.json is canonical for this case — a single-element accounts[] with no pagination envelope at all. Pagination conformance requiring pagination.has_more: true does not apply when:
  • pagination is absent entirely (canonical single-account shape), or
  • pagination.total_count is present and ≤ 1
Runners SHOULD grade pagination-walk phases as not_applicable in either case. This pattern is conformant; the spec carries no minItems constraint on accounts[] and the single-account example is normative.

Common Scenarios

Poll until account becomes active

After sync_accounts returns pending_approval, poll until the account is ready:

Filter active accounts only

Error Handling

Next Steps