Skip to main content

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.json document on the brand’s domain)
  • Default policiesoptimizationApplyMode, 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:
  1. The advertiser’s /.well-known/brand.json (per the AdCP spec)
  2. The AdCP brand registry
  3. Brandfetch enrichment
Pass 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.
See the Brand object guide for the brand resolution model in detail.

Uniqueness

The conceptual Interchange advertiser identity is BrandRef × 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-free resolve_buyer_brand operation to show the brand-confirmation card. The user then confirms by creating the advertiser normally.

Create an advertiser

Get / list advertisers

List rows return the summary shape — 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
List supports filtering: status, name (partial match), sandbox (true/false), plus limit and offset pagination.

Update an advertiser

sandbox is immutable after creation. To convert sandbox work to production, create a new production advertiser. When frequencyCaps is provided on update, it replaces all existing non-archived caps. Pass an empty array to clear; omit the field to leave caps untouched.

Archive / restore

Linked accounts

The linkedAccounts 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

Filters: storefrontId + sourceId (must be paired), status (active, pending_approval, payment_required, suspended, closed). Pagination: take, skip.
Response
The response carries the full 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

Returns the same 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).
Linked accounts surface external account IDs (e.g. acc_67890) so cross-platform reporting and pass-through execution can target them without re-discovering credentials. The linkId is the Interchange-side primary key for the link itself; the accountId is the source-side account.

Sandbox advertisers

Set sandbox: 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 buys
  • AUTO — suggestions are applied immediately
The advertiser-level setting is the default for campaigns under the advertiser. Each campaign can override it.

Campaign

Marketing initiatives owned by the advertiser

Brand

Brand identity resolved from AdCP registry or /.well-known/brand.json

Frequency caps

Buyer-side caps enforced by Scope3 across publishers

Creatives

Manifest-based creatives nested under campaigns