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 — see AdCP versioning & negotiation for how the version your agent serves is negotiated.
  2. Signing keys (JWKS) — set up your request/webhook signing keys so Interchange can verify your agent’s RFC 9421-signed calls and you can verify ours. This is a required step, not an afterthought, if you sign with RFC 9421 — for webhook verification specifically, Interchange discovers your JWKS through brand.json → agents[].jwks_uri (see item 5 below), not a standalone jwks.json URL. 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. A brand.json at /.well-known/brand.json on your agent’s origin. Optional if you never sign or verify over RFC 9421 — but required the moment you do: it’s how Interchange resolves the JWKS for verifying your RFC 9421-signed webhook deliveries (e.g. the storefront-catalog invalidation webhook). Also brands the agent as operator-owned (“I own this agent”) for identity purposes.

​
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: understand the AAO signal

The AAO registry is the source of truth for agent registration and compliance verdicts. Interchange reads those registry results; it does not define AAO storyboards itself. What “compliance” means operationally: 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. Interchange uses AAO signals in three different ways:
  • Registration is a connect-time gate. An external AGENT source must be registered with AAO before it can be connected.
  • Compliance is advisory for source connection and storefront activation. A non-passing verdict is surfaced as a warning, but it does not block going live.
  • Marketplace listing is a separate Scope3 review step after activation. AAO compliance is an important signal in that review, but it is not the same thing as the activation gate.
See Storefront onboarding for the connect-time table and Storefront overview for marketplace review.
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: Wholesale product and signal catalog requests are not part of the ordinary pass-through path. Interchange sends those catalog requests to a third-party sales agent only when product composition is on for the storefront and your agent reports AdCP 3.1+ support. If your storefront is using pass-through, buyer requests still call your agent live through the normal discovery and media-buy surfaces above. 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 the agent URL implied by the source model. We inspect the publisher’s resolved adagents.json document using the fallback-aware resolution described in Discover agents. If that resolved publisher file does not grant the agent, Interchange surfaces an advisory warning today and keeps setup/product authoring moving. Treat it as a publisher-owned authorization problem to fix before depending on that inventory. This is separate from AAO compliance: compliance is the registry’s storyboard verdict; authorization is the publisher’s adagents.json grant.
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.