Skip to main content
This page is for a seller bringing their own AdCP sales agent into Interchange as supply — how Interchange uses the Ad Context Protocol (AdCP) to connect your agent as a storefront inventory source.
This is the storefront (sell-side) view. If you instead want to connect Claude, ChatGPT, or another assistant as a client of the Interchange API, see Built for agents. For how Interchange itself consumes AdCP as a buyer (Discover Products, campaigns), see How Interchange uses AdCP (buy side).

​
Ways inventory comes in

A storefront draws supply from one or more sources:
  • AGENT — an external AdCP-compatible sales agent Interchange connects to. This is the “bring your own agent” path and the focus of this page.
  • MANAGED_SALES_AGENT — an operator-owned ad server with Interchange-managed sales-agent plumbing.
  • LINKED_STOREFRONT — wholesale inventory from the pool of listed, transacting storefronts.
  • MODULAR_SOURCE — composed from private modules (avails, booking, trafficking, reporting).
See Choosing a source for the full comparison.

​
What you bring (external AGENT)

There are two parts: the technical setup for your agent, and bringing the inventory it sells.

​
1. Technical setup

  1. A conformant AdCP agent endpoint that advertises its supported_protocols and versions via get_adcp_capabilities. Interchange supports AdCP 3.0 and 3.1.
  2. Signing keys (JWKS) — set up your request/webhook signing keys and publish your jwks.json so Interchange can verify your agent’s signed calls and you can verify ours. This is a required step, not an afterthought. See Authentication.
  3. Credentials for authenticating to your agent endpoint.
  4. Real-time targeting (TMP), if you serve through it — connect the TMP Router so serve-time targeting and macros resolve. See Real-time targeting.
  5. (Optional) a brand.json that brands the agent as operator-owned (“I own this agent”). Helpful for identity, not strictly required.

​
2. Bringing inventory — onboard your publishers

You don’t hand Interchange a separate list of formats and inventory — that comes from onboarding the publishers your agent sells for. For each publisher (that’s you if you’re a publisher; each partner if you’re a sales house or network), that publisher’s properties must authorize your agent:
  • An adagents.json lives on the publisher’s domain (not necessarily yours) and authorizes your agent for that publisher’s properties. Properties can be non-web (CTV, audio, app, DOOH), so this is about properties, not just websites.
  • Authorization is bound to the publisher domain — an agent is authorized only for properties a publisher has granted it (presence in authorized_agents[] alone isn’t sufficient).
  • A publisher’s adagents.json is also where their placements, formats, and other property details are declared.
So a sales house representing 50 publishers needs each of those 50 publishers’ domains to authorize the agent — the authorization is per-publisher, across all your partners.

​
Conformance: pass the storyboards for your agent type

Interchange validates identity against the AAO registry (not self-reported). What “compliance” means concretely: your agent should pass the AAO storyboards for the kind of agent you are. A sales agent passes the base sales-agent storyboard plus the ones for what you sell — guaranteed, non-guaranteed, retail, and so on. Passing storyboards lights up which interactions Interchange can have with you — it’s capability gating, not a checkbox. Compliance is advisory when you connect a source and enforced at go-live; only AAO-compliant sources surface to buyers. See Storefront overview for marketplace review and AAO gating.
The depth of adagents.json / domain-validation handling is actively expanding through our AAO-integration work; treat this as current behavior, not the final shape.

​
How your agent participates (the AdCP surfaces we use)

Which surfaces light up depends on the storyboards your agent passes (above). Once connected, Interchange uses these AdCP surfaces against your agent:
AdCP surfaceWhat Interchange does with your agent
get_adcp_capabilitiesReads your declared protocols, versions, and capabilities at connect time.
get_productsCalls your agent as one seller in a buyer’s discovery query; your products are stamped with your storefront identity.
create_media_buy / update_media_buyRoutes a buyer’s media buy to your agent; updates are guarded against capabilities your agent doesn’t declare.
get_media_buy_deliveryPulls delivery from your agent and rolls it up.
sync_creativesSyncs creatives to your agent, optionally through an operator creative-review queue. See Creative reviews.
sync_accountsSyncs buyer accounts to your agent.
check_governanceWhen a buyer brings a governance agent, your agent validates the action against it before fulfilling (see Governance below).
Webhook / request signing (RFC 9421)Verifies signed webhooks from your agent; our outbound calls are signed. See Authentication.
You can monitor your source’s live behavior — per-call outcomes, errors, and latency — in Inventory-source diagnostics.

​
Governance agents

A buyer can bring their own governance agent — an external service that validates campaign actions (budget, brand safety, regulatory compliance) before they execute — and Interchange supports this. We will support third-party governance agents; a buyer doesn’t depend on us to provide one. What that means for you as a seller: support the AdCP governance protocol so you can transact with governance-enabled buyers. When a buyer’s governance agent is in play, your agent calls check_governance to validate each action and fulfills as approved. The governance agent — not you — holds the consolidated audit trail. (Campaign governance is an evolving AdCP surface; see the FAQ for credentials and audit.)

​
FAQ

Questions sellers ask when integrating. Each answer is what AdCP defines (the protocol’s source of truth) plus what Interchange does today (the delta).
AdCP: publishers declare which sales agents may sell their inventory in a /.well-known/adagents.json file on their own domain (with ads.txt managerdomain delegation). Authorization is bound to the publisher domain — you publish an accurate declaration; you aren’t required to run a validation algorithm yourself.Interchange: every publisher your agent works with must authorize it. We check that through the AAO registry and its SDK — if your authorization is good in AAO, it’s good with us; if it isn’t good in AAO, it isn’t good with us. So make sure each publisher you represent authorizes your agent in their adagents.json (authorization is bound to the publisher domain; presence in authorized_agents[] alone isn’t sufficient) and that you’re compliant in AAO. See Discover agents.
AdCP: a governance agent is an external service the buyer configures and registers via sync_governance, which hands the seller the agent’s URL plus the credential to call check_governance. Per the shipped spec that credential is a Bearer token ("schemes": ["Bearer"], at least 32 characters) — so bearer is the defined mechanism for this leg, not a discouraged one. Rotation is replace-semantics: re-run sync_governance with new credentials and they overwrite the old. AdCP does, however, treat a static, long-lived shared bearer as an interim floor for calls that mutate state or commit spend, and is standardizing RFC 9421 request signing (keys published via the agent’s JWKS, discoverable through brand.json → agents[]) — recommended in 3.0 and slated to become required for mutating calls in a later release. (The governance decision is separately returned as a signed governance_context JWS you verify against the agent’s published keys — that signing is on the response, not on your stored call credential.)Interchange: treat the stored bearer as short-lived and rotatable, scope it tightly, and revoke-and-reissue on any suspected leak — don’t rely on a single static shared secret, and move toward keypair-backed request signing as AdCP standardizes it. For the credentials you hold to call Interchange itself (signing keys, service tokens), rotation follows create-new → deploy → revoke-old. See Authentication.
AdCP: the governance agent holds the consolidated audit trail — a first-class, structured, timestamped, attributable record served via get_plan_audit_logs. The seller’s role is to validate each action via check_governance and fulfill as approved; outcome and delivery reporting flow through the orchestrator. The seller is not required to maintain or hand over an audit-log store for the governance agent — keeping your own operational logs is part of running your business. (This is an AdCP 3.0 experimental surface and may change.)Interchange: when a buyer brings a governance agent, that audit trail lives with the governance agent, not with us. Our first-party activity log records actions taken in Interchange for platform accountability — it is separate from, and not a substitute for, the AdCP governance audit trail.

​
Where the truth lives

AdCP specification

The protocol’s source of truth — tasks, authorization, and governance.

Choosing a source

Compare AGENT, managed, linked, and modular sources.

Discover agents

How adagents.json resolution and authorization work.

Storefront overview

AAO compliance and marketplace listing for sellers.