Skip to main content
The Sellers page and the public V3 seller/connection nouns plus save_connection are available to every buyer account. An Interchange-provisioned signup sandbox is the narrow exception: its verified Agent Registration receives the reversible setup contract, including unmap and remove, but not seller selection, billing, feature-policy, or spend authority.
open_connections_page launches Sellers — the buyer’s unified catalog for Global Market Makers, Regional Market Makers, and Marketplace sellers. The page shows only sales sources: creative, signal, measurement, optimization, and composite agents belong on their own surfaces. Ordinary Marketplace sellers appear once they are transaction-ready, while curated Market Makers remain visible with their current readiness status. The page keeps marketplace classification, marketplace readiness, account-wide selection, required action, and per-advertiser activation separate. It is a widget launcher: the tool accepts optional positive integer-string advertiserId and sellerId seeds. Omit both for the account overview. Pass connectionAction: "connect" with sellerId to open that seller’s connection setup. The launcher itself is read-only; authorization begins only after the buyer confirms in the widget. The launcher returns only a UI resource directive plus the supplied seeds, and the page then self-fetches its own data. It is buyer-only; writes remain limited to the page’s host-authorized seller, connection, billing, and mapping operations. A seller is the commercial counterparty: one exact Storefront that can be discovered and selected even before it is connected. A connection is one buyer-account authorization grant to that seller. One seller can therefore have zero, one, or several connections. Each connection can expose several provider accounts (for example, child ad accounts under one authorized business manager); those accounts are detail inside the connection, not additional seller or connection nouns.

​
From an agent (MCP)

Ask in natural language — “show my sellers”, “set up my connection to Meta”, “connect Google Ads”, or “map this account to an advertiser” — and the agent calls open_connections_page after resolving the seller when necessary. Omit advertiserId to open the account overview:
When the user is working with a known advertiser, pass its numeric id as a string to open Sellers in that advertiser’s scope:
To open one seller, pass its exact Storefront id. Add connectionAction when the user asked to set up another authorization grant; it opens the relevant detail and leaves the final action to the buyer:
Do not invent an id. Resolve advertiser ids from the advertiser catalog or the active conversation scope, and seller ids from search({kind: "seller"}). Account-scope responses preserve the empty {} result; scoped responses echo only the supplied widget seeds. The response carries the Sellers page resource (ui://agentic-api/connections/mcp-app.html) in _meta; a host that renders MCP-UI widgets opens the page. Hosts that don’t render widgets receive a plain confirmation and no connection data — the tool never returns connection facts itself. The embedded app uses the same public V3 contract available to agents: search/get for sellers, connections, and advertisers (provider accounts and mappings are bounded detail on a connection); save_connection for connection desired state; and save_ask for a supply request. Advertiser setup uses the resource-bound, app-only open_add_advertiser handoff. The former app-only bridge remains a temporary rolling-deploy fallback only when the host reports that the public V3 capability is unavailable; service, authorization, and schema errors are shown instead of silently switching protocols. The app never receives the generic api_call tool.

​
From a headless agent

An agent can perform the same workflow without rendering this page:
  1. Call search with kind: "seller" to find the Seller id.
  2. Call save_connection with that sellerId and authorization.
  3. Open the returned authorization.url in an interactive browser, or show the URL to the user when the host is headless.
  4. Poll search or get with kind: "connection" until authorization and account discovery complete.
  5. Use save_connection to refresh/select an account and map it to an advertiser. To enable reporting for exactly one connected account, send { "connectionId": "901", "enhancedReporting": { "accountId": "1204", "enabled": true } }. This is account-scoped and is not a seller feature policy.
  6. The same tool can unmap the advertiser or remove the connection if setup needs to be reversed, including while using a signup sandbox.
Continue search with the returned nextCursor until it is absent. The Sellers widget initially pages the seller, connection, and advertiser collections; it does not fetch every provider account up front. Opening a seller lazily calls get(kind: "connection") for that seller’s grants and caches the detail by connection id. Connection detail returns provider accounts and advertiser mappings in bounded pages; when accountsPage.hasMore or accountMappingsPage.hasMore is true, call get again with the corresponding connectionAccountsOffset or connectionMappingsOffset. save_connection reports the committed action as successful even if an immediate readback is temporarily unavailable. In that case object is null and the response tells the agent to reconcile with get; do not retry the write based only on a readback warning. OAuth providers redirect from a one-time Interchange launch. Bearer providers show a focused Interchange form. In both cases the provider credential travels between the browser and Interchange only; it is never returned to the model or MCP host. The launch first shows a Continue page, and the one-time capability is consumed only after that button is selected, so link previews and browser prefetching do not invalidate it.

​
What the page reads

Once open, the page loads live data from the public V3 nouns:
  • Sellers — the Storefront catalog, control plane, and declared capabilities
  • Connections — one summary per authorization grant, joined to its seller by sellerId
  • Advertisers — the account’s advertisers and preferred reporting time zones, to map accounts against
Provider accounts and advertiser mappings load only from the selected connection’s bounded detail. The connections projection includes each seller’s declared capabilities, which the page uses to gate event and audience controls. Events and Audiences are independent, off-by-default consents written through update_storefront_connection_policy, and appear only when the seller declares the corresponding sync_event_sources or sync_audiences tool. Capability checks load progressively per connection. While a check is pending or unavailable, the page says so instead of treating the capability as unsupported. Connecting a provider hands off to the provider’s OAuth; mapping an account to an advertiser is a durable write, and the page surfaces the reason inline if a map or unmap fails so you can retry. See the connecting ad platforms guide for the end-to-end flow. An advertiser-scoped seller detail shows each provider account’s effective reporting time zone and whether the provider treats it as buyer-selected, seller-assigned, or seller-fixed. If that zone differs from the advertiser’s preference, the page shows both and flags the mismatch. Reporting dates remain seller-authored: the provider account’s effective zone controls its day boundaries, and mapping does not silently change the advertiser preference.

​
Filter by market or channel

The toolbar has Market and Channel filters alongside the status chips and search box, so you can narrow the list to, for example, every seller selling in the Netherlands or every seller offering CTV. Options are built from the sellers currently loaded on the page, not a separate lookup: a market appears once at least one loaded seller’s coverage includes it, whether through its declared regions or an approved market-maker grant (Global Market Makers match every market; Regional Market Makers match the markets their grant lists). The two filters combine with each other and with the status chips and search box — a seller must match every active filter to appear — and a Clear filters action appears whenever either is set. In the web app, the Sellers page reads market and channel from the URL (for example ?market=NL&channel=ctv), so a shared link opens the page with those filters already applied. Changing a filter afterward updates the toolbar but not the address bar; share a fresh link with the updated market/channel values to hand someone the same filtered view. Inside Claude, ChatGPT, and other chat hosts, the filters are local to that conversation’s view of the page.

​
Remove a provider connection

Remove connection is available in seller detail for an official adapter that has a saved connection. Before anything changes, the page asks you to confirm the organization-wide effect. Confirming archives that connection, revokes and archives its credential, disables the accounts discovered through it, and stops future provider syncs and campaign subscriptions through that grant. Because the grant is shared, this affects every advertiser using the connection. Removing a connection does not erase historical reporting data or advertiser mapping intent. A mapped provider account remains usable when another active grant can reach it; otherwise the mapping is retained but unavailable until the account is reachable again. Any tracked-campaign subscription is stopped as part of the archive. Reconnect the provider to create or restore usable access. Publisher storefronts without an adapter connection record do not show this action; their approval-gated relationship lifecycle is separate.