Why Interchange needs access to your ad server

If you sell through an ad server, you connect it to Interchange as an ad-server-backed source (executionType: MANAGED_SALES_AGENT). That connection needs read and trafficking access to your ad server. This page explains what Interchange does with that access, what to grant for each supported ad server, and why the grant stays narrow. For the step-by-step setup, see Storefront onboarding; to compare an ad server against the other source families, see Choosing a source.

​

Why does Interchange need access?

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

​

What does Interchange do with your ad server?

With access granted, Interchange operates against it in three ways, the same across every supported ad server:

• 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 orders and line items in your ad server under the advertiser you route the buyer to. See Buyer routing. What actually reaches your ad server is governed by your approval settings — you can require human review of every media buy and creative before anything serves (the default, and the lowest-risk posture). See Reviewing buyer transactions.
• Reads delivery back. It reads impressions, spend, and pacing so delivery and reporting roll up to the buyer.

Interchange does not change your ad-server settings, manage your users, or touch inventory you do not sell through your storefront.

​

What access do I grant?

The grant differs by ad server, but the principle is the same: the least privilege that can read inventory and traffic campaigns, nothing more.

​

Google Ad Manager — a least-privilege service account

With GAM you never share a login password or API token — Scope3 provisions a service account dedicated to your organization, and you grant its email a role. Grant the service-account email 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:

​

FreeWheel and SpringServe — forwarded, never stored

FreeWheel connects through Scope3’s partner program: you grant Scope3 access in the FreeWheel partner portal and tell us when it’s live, and Scope3 picks up the partner API credentials there — you don’t hand over a login password or personal API token. SpringServe uses your account login or a token. Two properties hold for both: FreeWheel may provision reporting and forecasting separately from the base API connection. If either capability is missing, ask your FreeWheel representative to enable it for the API user. Interchange records that state and stops calling the denied capability instead of retrying indefinitely. Once FreeWheel confirms the grant, use the diagnosis’s Access confirmed - re-check action for reporting or forecasting; a successful check resumes the paused capability without replacing credentials or reconnecting the source.

• Prefer the auto-refreshing grant. FreeWheel’s client ID + secret and SpringServe’s email + password each mint short-lived tokens that refresh themselves, so the connection keeps working without you re-entering anything. The pre-minted token paths (FreeWheel’s 7-day key, SpringServe’s API token) are for testing — they expire and don’t refresh.
• Scope3 never persists them. The credentials are forwarded to the managed ad-server source at provision time and are not stored by Scope3. Where a secret is held at all (see below), it’s encrypted and never returned.

​

How your credentials are handled

• Encrypted, never echoed. Any stored inventory-source credential (API key, username/password, JWT key) is encrypted at rest and referenced only by an opaque auth_secret_ref. API responses surface authConfigured: true, never the secret itself.
• No shared admin login. GAM is a scoped service account you grant and revoke yourself; FreeWheel/SpringServe use API credentials that mint short-lived tokens — not a human admin seat.
• You stay in control. Remove the GAM service-account user, or rotate the FreeWheel/SpringServe credential, and Interchange’s access stops.
• Nothing to re-key. Interchange reads your existing inventory directly, so your storefront sells what you already run.

​

Verifying the connection

After you grant access, Interchange provisions the source and probes the connection. For credential-backed adapters like FreeWheel and SpringServe, a failed credential probe stops setup before the source is accepted; re-check the credentials or grant, then submit again. Common failures right after setup: After a source is accepted, the source dashboard separates first-sync progress from action-required failures: a running initial inventory sync means the source is connected but not live yet, while adapter authentication or access failures mean the connection needs to be reconnected or reconfigured. You can read the current connection state — including the enabled/disabled state (deactivatedAt) and the most recent lastErrorCode — with Get ad-server connection, and re-probe upstream reachability with Test connection.

​

Related