Why Interchange needs access to your GAM network

If you sell through Google Ad Manager, you connect it to Interchange as an ad-server-backed source (executionType: MANAGED_SALES_AGENT). That connection needs read and trafficking access to your GAM network. This page explains what Interchange does with that access, the permission level to grant, and why the grant stays narrow. For the step-by-step setup, see the Google Ad Manager service-account grant; to compare GAM against the other source families, see Choosing a source.

​

Why does Interchange need access to GAM?

Buyers transact against your storefront, not against GAM directly. Your storefront is the sales agent buyers reach; your Merchandising Agent answers their briefs. For that to work over your existing GAM inventory, Interchange manages the AdCP sales-agent plumbing in front of your ad server, and that plumbing has to talk to GAM on your behalf. Without access, Interchange has nothing to discover, sell, or report against — your GAM inventory stays invisible to buyers.

​

What does Interchange do with GAM?

With access granted, Interchange operates against your network in three ways:

• Reads your inventory. It syncs your existing ad units, placements, and products so your Merchandising Agent can compose buyer-facing products from what you already run. You do not re-key inventory into Interchange.
• Traffics campaigns. When a buyer transacts against your storefront, Interchange creates and manages the corresponding line items and orders in GAM under the advertiser you route the buyer to. See Buyer routing.
• Reads delivery back. It reads impressions, spend, and pacing from GAM so delivery and reporting roll up to the buyer.

Interchange does not change your network settings, manage your GAM users, or touch inventory you do not sell through your storefront.

​

What permission level do I need?

Google Ad Manager is the one ad-server adapter where you never paste a password or API token into Scope3. Instead, Scope3 provisions a per-customer service account and returns its email address. You add that service-account email as a user in your GAM network and grant it a role. Grant the least-privilege role that can read inventory and traffic campaigns — Trafficker, or a custom role with the equivalent API permissions. That is the whole grant: You control the grant from your own GAM admin console and can revoke it at any time.

​

Why is this setup helpful?

A service-account grant is safer and lower-maintenance than handing over a login:

• No shared password. You never share a human login or a long-lived API token. Access is a service account scoped to one role, that you grant and revoke yourself.
• Least privilege. The Trafficker-equivalent role covers exactly what selling requires — reading inventory, trafficking campaigns, reading delivery — and nothing more.
• You stay in control. The grant lives in your GAM admin console. Remove the service-account user and Interchange’s access stops.
• Nothing to re-key. Interchange reads your existing GAM inventory directly, so your storefront sells what you already run.

​

Verifying the connection

After you grant access, Interchange provisions the source with your numeric network code and probes the connection. Two failures are common right after setup: You can read the current connection state — including provisioningStatus and the most recent lastErrorCode — with Get ad-server connection, and re-probe upstream reachability with Test connection.

​

Related