> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect your sales agent
> How Interchange uses AdCP to integrate your sales agent as a storefront inventory source — the seller (supply) side.
This page is for a **seller bringing their own AdCP sales agent into Interchange as supply** — how Interchange uses
the [Ad Context Protocol (AdCP)](https://docs.adcontextprotocol.org) 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](/v2/setup/built-for-agents). For how Interchange
itself consumes AdCP as a buyer (Discover Products, campaigns), see
[How Interchange uses AdCP (buy side)](/v2/concepts/adcp-on-the-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](/v2/storefront/inventory-sources/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`](https://docs.adcontextprotocol.org/docs/protocol/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](/v2/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](/v2/storefront/tmp/overview).
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`](/v2/storefront/tasks/discover-agents) 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](/v2/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 surface | What Interchange does with your agent |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`get_adcp_capabilities`](https://docs.adcontextprotocol.org/docs/protocol/get_adcp_capabilities) | Reads your declared protocols, versions, and capabilities at connect time. |
| [`get_products`](https://docs.adcontextprotocol.org/docs/media-buy/task-reference/get_products) | Calls your agent as one seller in a buyer's discovery query; your products are stamped with your storefront identity. |
| [`create_media_buy`](https://docs.adcontextprotocol.org/docs/media-buy/task-reference/create_media_buy) / [`update_media_buy`](https://docs.adcontextprotocol.org/docs/media-buy/task-reference/update_media_buy) | Routes a buyer's media buy to your agent; updates are guarded against capabilities your agent doesn't declare. |
| [`get_media_buy_delivery`](https://docs.adcontextprotocol.org/docs/media-buy/task-reference/get_media_buy_delivery) | Pulls delivery from your agent and rolls it up. |
| [`sync_creatives`](https://docs.adcontextprotocol.org/docs/creative/task-reference/sync_creatives) | Syncs creatives to your agent, optionally through an operator creative-review queue. See [Creative reviews](/v2/storefront/creative-reviews/overview). |
| [`sync_accounts`](https://docs.adcontextprotocol.org/docs/accounts/tasks/sync_accounts) | Syncs buyer accounts to your agent. |
| [`check_governance`](https://docs.adcontextprotocol.org/docs/governance/campaign/tasks/check_governance) | When 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](/v2/authentication). |
You can monitor your source's live behavior — per-call outcomes, errors, and latency — in
[Inventory-source diagnostics](/v2/storefront/inventory-sources/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`](https://docs.adcontextprotocol.org/docs/governance/campaign/tasks/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](/v2/storefront/tasks/discover-agents).
**AdCP:** a governance agent is an *external* service the buyer configures and registers via
[`sync_governance`](https://docs.adcontextprotocol.org/docs/accounts/tasks/sync_governance), which hands the
seller the agent's URL plus the credential to call
[`check_governance`](https://docs.adcontextprotocol.org/docs/governance/campaign/tasks/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](/v2/authentication).
**AdCP:** the **governance agent holds the consolidated audit trail** — a first-class, structured,
timestamped, attributable record served via
[`get_plan_audit_logs`](https://docs.adcontextprotocol.org/docs/governance/campaign/tasks/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](/v2/storefront/activity/overview) 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
The protocol's source of truth — tasks, authorization, and governance.
Compare AGENT, managed, linked, and modular sources.
How `adagents.json` resolution and authorization work.
AAO compliance and marketplace listing for sellers.