Overview
An Advertiser in Interchange is the commercial media identity on whose behalf campaigns run: a brand care of an operator. The brand answers whose products are being advertised; the operator answers which organization drives the buying. This is an Interchange product projection, not an assertion that AdCP collapses the two entities: AdCP keeps Brand, Operator, Account, and Agent separate. For buyer-declared AdCP accounts,(brand, operator, sandbox) is the natural
key of the account relationship. An upstream-managed account_id instead
names an entry in the seller’s own namespace, whose declared account_scope
may be operator-, brand-, operator-and-brand-, or agent-wide. See
AdCP Accounts and agents.
Direct buying is the identity case where the brand operates its own seat. For
example, Coca-Cola buying directly from an account registered to
coca-cola.com is “Coca-Cola care of Coca-Cola”; Coca-Cola through WPP is
“Coca-Cola care of WPP.” Self-serve is an interface, not an operator
identity: using Interchange directly does not replace Coca-Cola with
“self-serve” as the operator. Likewise, an agent is the software acting for the
operator, not the operator itself. When a buyer account has no registered
domain, current v2 outbound AdCP calls use interchange.io as a platform
operator fallback until the account records its real domain; that fallback is
an implementation compromise, not the meaning of self-serve.
In the current Scope3 v2 buyer API, an advertiser is also the top-level resource
container for media. Every campaign, creative, audience, frequency cap, and
linked partner account belongs to one. The authenticated buyer account
establishes the operator context, so the v2 advertiser payload does not repeat
an operator field.
Renamed from Brand Agent: In v1 this concept was called a “Brand Agent”. In v2 it has been renamed to Advertiser to align with industry terminology used by Google Ads, The Trade Desk, DV360, and Amazon DSP.
Why advertisers matter
- Resource ownership — campaigns, creatives, audiences, and frequency caps all roll up to a single advertiser
- Commercial identity — every advertiser combines a brand reference with the operator acting for it
- Brand identity — every advertiser links to a brand resolved from the AdCP brand registry (or a
/.well-known/brand.jsondocument on the brand’s domain) - Default policies —
optimizationApplyMode, UTM parameters, and frequency caps set on the advertiser flow down to its campaigns - Sandbox isolation — sandbox advertisers route every ADCP call to test accounts, so you can rehearse end-to-end flows without real spend
- Linked accounts — connect the advertiser to existing accounts on upstream platforms (e.g. Snap, programmatic DSPs) for cross-platform reporting and execution
Key fields
The advertiser resource has two response shapes:- Summary — returned by
GET /api/v2/buyer/advertisers(list). A small, fixed set of row-level fields. - Full — returned by
GET /api/v2/buyer/advertisers/:id(get). The complete resource with nested brand, linked accounts, UTM config, and frequency caps.
Summary shape (list rows)
Full shape (single advertiser)
The single-advertiser endpoint returns every field above plus:Brand resolution
Advertisers do not store brand identity directly. Instead, they reference a brand domain or website URL, and Scope3 resolves the brand identity from one of three sources:- The advertiser’s
/.well-known/brand.json(per the AdCP spec) - The AdCP brand registry
- Brandfetch enrichment
brand: "northwind.example" and Scope3 fetches the resolved brand identity, surfacing logos, colors, fonts, tone, and product catalog under linkedBrand when available. If the advertiser is created or updated from enrichment rather than an official registry entry, the response includes brandWarning; do not retry create for that case. After reviewing the enriched details, set saveBrand: true on an update if you want to persist the brand in the registry. If no enrichment data is available, retry create with saveBrand: true only after confirming the advertiser name and brand domain.
Uniqueness
The conceptual Interchange advertiser identity isBrandRef × Operator. The
current v2 resource partitions that identity operationally by
primaryCurrency and sandbox mode. The same brand domain can therefore
back more than one advertiser resource under the same operator when each uses a
different currency — for example one northwind.example resource in USD and
another in EUR. Those rows are separate campaign and billing containers, not
different operator identities. AdCP account relationships have their own
identity rule: buyer-declared sandbox accounts add sandbox: true to the
(brand, operator) natural key, while account-id namespaces use distinct
seller-assigned test-account IDs.
Within a buyer account and sandbox mode, creating a second resource with both
the same brand domain and currency returns a conflict, as does changing an
existing resource’s brand or currency onto a pair already taken by a sibling.
Sandbox and non-sandbox advertisers are tracked separately, so each
(brand domain, currency) pair has its own slot in each mode.
Sub-resources
The advertiser is the hub for many sub-resource collections. Each lives under/api/v2/buyer/advertisers/:advertiserId/... and inherits the advertiser’s auth, brand, and sandbox context.
See the Buyer API Reference for the full request and response shape of each.
Lifecycle
1
Create the advertiser
Provide a name and a brand domain. Optionally link partner accounts, set sandbox mode, configure UTM params, and add buyer-side frequency caps. Sandbox flag is locked after creation.
2
Configure defaults
Update
optimizationApplyMode, UTM params, and frequency caps as your operational policy evolves. Campaigns under the advertiser inherit these defaults unless overridden.3
Run campaigns
Create campaigns under the advertiser. Discovery, audiences, and creatives are scoped to this advertiser.
4
Archive when done
DELETE /api/v2/buyer/advertisers/:id archives the advertiser (soft delete). Use POST /api/v2/buyer/advertisers/:id/restore to bring it back.Common operations
Before creating an advertiser from a domain, buyer MCP clients can call the side-effect-freeresolve_buyer_brand operation to show the brand-confirmation card.
The user then confirms by creating the advertiser normally.
Create an advertiser
Get / list advertisers
id, name, status, sandbox, brand, linkedAccountCount, createdAt, updatedAt. Call GET /api/v2/buyer/advertisers/:id for the full resource (resolved brand object, full linked-account list, UTM config, frequency caps).
List response
status, name (partial match), sandbox (true/false), plus limit and offset pagination.
Update an advertiser
Archive / restore
Linked accounts
ThelinkedAccounts field connects the advertiser to existing accounts on upstream platforms — Snap, programmatic DSPs, agency seats. Each linked account is the pre-existing seat ID a partner already has for this brand or buyer; the link makes that ID addressable to Interchange for cross-platform reporting and pass-through execution.
Use
linkedAccounts whenever the buyer already has a relationship with the upstream platform — an existing Snap seat, a DV360/Trade Desk account, an agency-managed seat. Linked accounts let Interchange reuse the seat ID for unified reporting and pass-through execution without re-provisioning credentials per call. This account choice is independent of campaign mode, BYOA, protocol connectivity, and settlement; do not infer those from routingType.Fields
Each link maps these fields:billingType is a source-defined string. The supported values per source are reported on the discovery endpoint (GET /api/v2/buyer/advertisers/:advertiserId/accounts/available?storefrontId=...&sourceId=... returns billingOptions.supported and billingOptions.default). Common values:
Other values may be supported by individual partners — always check
billingOptions.supported before sending.
Endpoints
List linked accounts
storefrontId + sourceId (must be paired), status (active, pending_approval, payment_required, suspended, closed). Pagination: take, skip.
Response
Link an account
AccountOutput with the server-assigned linkId. To pre-fill the request body, call GET /accounts/available?storefrontId=1&sourceId=src_main first — it returns every discovered account with its supported billingOptions.
Get a single linked account
AccountOutput shape as list. Use this to confirm a link’s current status after a source-side state change (e.g. moving from pending_approval to active).
Sandbox advertisers
Setsandbox: true at creation to mark the advertiser as test-only. All ADCP operations under sandbox advertisers — discovery, media buy creation, execution — route to sandbox-flagged sales agent accounts. No real platform calls are made and no real spend occurs.
Use sandbox advertisers to:
- Rehearse the discovery → execute → report flow end-to-end
- Test creative manifest workflows without notifying publishers
- Train AI agents against the API without billing implications
Optimization apply mode
optimizationApplyMode controls whether Scope3’s RL optimizer applies suggestions to media buys automatically.
MANUAL(default) — suggestions appear in the suggestion feed; a human or agent must approve before they hit media buysAUTO— suggestions are applied immediately
Related concepts
Campaign
Marketing initiatives owned by the advertiser
Brand
Brand identity resolved from AdCP registry or
/.well-known/brand.jsonFrequency caps
Buyer-side caps enforced by Scope3 across publishers
Creatives
Manifest-based creatives nested under campaigns