> ## Documentation Index
> Fetch the complete documentation index at: https://agenticadvertisingorg-snap-format-preview-links.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Making your inventory available to AI agents

> Seller integration guide for AdCP. How publishers, SSPs, and ad platforms expose inventory to AI buyer agents through standardized product discovery and media buy tasks.

AI agents are starting to buy media. When an agency's AI assistant is evaluating ad inventory across platforms, it needs a way to discover what you sell, understand your pricing and targeting options, and execute a buy — all through a standard interface.

AdCP (Ad Context Protocol) provides that interface. If you're a publisher, SSP, or ad platform, implementing AdCP makes your inventory accessible to any compliant buyer agent without requiring custom integrations for each one.

## Why this matters

Today, every platform requires buyers to learn a proprietary API. That works when humans are doing the buying. But AI agents work across many platforms simultaneously, and they need a shared language for common operations.

Platforms that implement AdCP are discoverable by buyer agents out of the box. Platforms that don't require each buyer to build a custom integration — which limits the pool of agents that can access your inventory.

## What you need to implement

AdCP sell-side integration has four parts:

<Steps>
  ### Publish publisher authorization

  Publish an `adagents.json` file on each publisher domain. This file declares the publisher's properties and the agents authorized to sell or enrich that inventory — similar to how `ads.txt` works for supply chain transparency.

  ```json theme={null}
  {
    "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json",
    "contact": {
      "name": "Example Publisher",
      "email": "adops@publisher.example.com",
      "domain": "publisher.example.com"
    },
    "properties": [
      {
        "property_id": "publisher_home",
        "property_type": "website",
        "name": "Example Publisher",
        "publisher_domain": "publisher.example.com",
        "identifiers": [{ "type": "domain", "value": "publisher.example.com" }]
      }
    ],
    "authorized_agents": [
      {
        "authorization_type": "property_ids",
        "url": "https://ads.publisher.example.com/mcp",
        "authorized_for": "Example Publisher direct inventory",
        "property_ids": ["publisher_home"],
        "signing_keys": [
          {
            "kid": "publisher-sales-prod-2026",
            "kty": "OKP",
            "alg": "EdDSA",
            "crv": "Ed25519",
            "x": "w8zcY1LZqV4n1oKbfyq3n2q3sL2uV3z7kEw1m9Qjv4A",
            "use": "sig"
          }
        ]
      }
    ]
  }
  ```

  Buyer agents check `adagents.json` to verify publisher authorization and, for mutating seller authorizations, publisher-pinned signing keys. They discover the agent's protocol coverage from `get_adcp_capabilities`, not from `adagents.json`.

  ### Publish operator identity

  Publish `brand.json` at `https://{your-domain}/.well-known/brand.json` for the organization operating the sales agent. `adagents.json` tells buyers which publisher authorizes a sales agent; `brand.json` tells buyers which operator is claiming the sales path, which properties it represents, and where to find signing keys.

  For publisher-owned sales teams, list owned or direct properties. For networks and SSPs, list represented properties with `relationship: "delegated"` or `relationship: "ad_network"` and make sure that value matches the publisher's `authorized_agents[].delegation_type` in `adagents.json`. The two files form the bilateral verification chain: the operator declares "I sell this property", and the publisher confirms "this operator is authorized to sell it". A publisher that delegates sales should still publish `adagents.json`; its own `brand.json` is recommended for publisher identity and portfolio context, but the delegated operator's `brand.json` is the required identity record for the agent buyers call.

  For the full sell-side setup pattern, including direct publisher and delegated network examples, see [seller setup](/docs/brand-protocol/seller-setup).

  ```json theme={null}
  {
    "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
    "version": "1.0",
    "id": "example_publisher",
    "url": "https://publisher.example.com",
    "names": [{ "en_US": "Example Publisher" }],
    "properties": [
      {
        "type": "website",
        "identifier": "publisher.example.com",
        "relationship": "owned"
      }
    ],
    "agents": [
      {
        "type": "sales",
        "url": "https://ads.publisher.example.com",
        "id": "publisher_sales",
        "jwks_uri": "https://ads.publisher.example.com/.well-known/jwks.json"
      }
    ]
  }
  ```

  The `agents[].jwks_uri` lets buyers resolve your public signing keys. The protocol requires verifiable signatures and discoverable public keys; it does not require a specific KMS vendor. Production agents should back private signing keys with KMS/HSM or a managed secret system. Sellers that send AdCP webhooks should publish an `adcp_use: "request-signing"` JWK in that JWKS so buyers can verify outbound webhook signatures. Deprecated `adcp_use: "webhook-signing"` keys remain accepted on the webhook path for backward compatibility. See [request signing](/docs/building/by-layer/L1/request-signing) for the key-publication and webhook-signing profile.

  ### Expose your inventory

  Implement `get_products` to describe what you sell. Each product represents a buyable unit — a display placement, a video slot, a sponsored listing, a newsletter sponsorship. Buyer agents call this with a `buying_mode` and optional `brief`:

  ```json theme={null}
  {
    "buying_mode": "brief",
    "brief": "Premium display placements for consumer electronics brand"
  }
  ```

  Your response includes structured product objects with pricing, formats, and delivery types:

  ```json theme={null}
  {
    "products": [
      {
        "product_id": "homepage_leaderboard",
        "name": "Homepage leaderboard",
        "channels": ["display"],
        "format_ids": [
          { "agent_url": "https://ads.publisher.example.com", "id": "display_728x90" }
        ],
        "pricing_options": [
          {
            "pricing_option_id": "cpm_standard",
            "pricing_model": "cpm",
            "floor_price": 8.00,
            "currency": "USD"
          }
        ]
      }
    ]
  }
  ```

  The richer the product metadata, the better buyer agents can match your inventory to campaign requirements.

  For content-centric inventory like podcasts, CTV, or live events, products reference shows and can offer exclusivity:

  ```json theme={null}
  {
    "products": [
      {
        "product_id": "signal_noise_sponsorship",
        "name": "Signal & Noise — Category Sponsorship",
        "description": "Category-exclusive sponsorship of the Signal & Noise podcast, including pre-roll and mid-roll host read placements.",
        "collections": [{ "publisher_domain": "crestnetwork.example.com", "collection_ids": ["signal_noise"] }],
        "publisher_properties": ["crestnetwork_podcast"],
        "channels": ["podcast"],
        "placements": [
          { "kind": "seller_inline", "placement_id": "pre_roll", "name": "Pre-roll (30s)", "mode": "targetable" },
          { "kind": "seller_inline", "placement_id": "host_read", "name": "Mid-roll host read (60s)", "mode": "targetable" }
        ],
        "delivery_type": "guaranteed",
        "exclusivity": "category",
        "format_ids": [
          { "agent_url": "https://ads.publisher.example.com", "id": "audio_30s" }
        ],
        "pricing_options": [
          {
            "pricing_option_id": "flat_monthly",
            "pricing_model": "flat_rate",
            "fixed_price": 15000,
            "currency": "USD"
          }
        ]
      }
    ]
  }
  ```

  See [Collections and installments](/docs/media-buy/product-discovery/collections-and-installments) for the full content model and [Media products](/docs/media-buy/product-discovery/media-products#exclusivity) for exclusivity patterns.

  ### Accept and fulfill buys

  Implement `create_media_buy` to accept campaign instructions from buyer agents. A media buy includes the product, budget, schedule, and any targeting parameters.

  ```json theme={null}
  {
    "account": { "account_id": "acct-56789" },
    "brand": { "brand_id": "nova-electronics" },
    "proposal_id": "prop-homepage-leaderboard",
    "total_budget": { "amount": 10000, "currency": "USD" },
    "start_time": "2026-04-01T00:00:00Z",
    "end_time": "2026-04-30T23:59:59Z"
  }
  ```

  Your platform processes the buy according to your normal workflow — whether that's instant activation, internal review, or an approval queue. AdCP's asynchronous status system (`completed`, `working`, `submitted`, `input-required`) lets you model any workflow.

  <Note>
    **Status must be persisted, not computed from flight dates.** Store `status` as an explicit database field, updated only by protocol events — not by comparing `start_time`/`end_time` to the current date. Date arithmetic cannot produce `paused`, `canceled`, or `rejected`; those states are driven by explicit commands. See [lifecycle states](/docs/media-buy/media-buys#lifecycle-states) for the full implementation requirement.
  </Note>
</Steps>

## Industry-specific guidance

The core integration steps above apply to all sellers. If you're an **ad network aggregating across multiple platforms**, see the [ad networks deep dive](/docs/sponsored-intelligence/networks) for product modeling, account chains, catalog forwarding, and `adagents.json` for networks.

If you sell inventory for publishers you don't own (as a network or SSP), declare those properties in your [brand.json](/docs/brand-protocol/brand-json#property-relationships) with the appropriate `relationship` value (`delegated` or `ad_network`). This creates bilateral verification — you declare the relationship, and each publisher confirms by authorizing your agent with the matching `delegation_type` in their adagents.json.

For vertical-specific product modeling, pricing patterns, and measurement:

* **AI platforms and AI ad networks**: See the [Sponsored Intelligence guide](/docs/sponsored-intelligence/overview) for sponsored responses, AI search products, generative creative from catalogs, and SI Chat Protocol handoffs.
* **Retail media networks**: See the [commerce media guide](/docs/media-buy/commerce-media) for sponsored product listings, closed-loop attribution, and in-store measurement.

## Accounts and sandbox

Production sales agents should implement the accounts protocol. [`sync_accounts`](/docs/accounts/tasks/sync_accounts) and [`list_accounts`](/docs/accounts/tasks/list_accounts) let buyers establish billing relationships, track spend per advertiser, and manage multiple operators buying on behalf of different brands through a single agent.

The account model depends on your platform:

* **Walled gardens** (social platforms, AI platforms, retail media networks) typically use account-id namespaces — set `require_operator_auth: true` in [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) so each operator authenticates independently, expose `list_accounts` when the upstream platform owns the namespace, and require buyers to pass discovered `account_id` values.
* **Open platforms** (publishers, SSPs) can use buyer-declared accounts — the agent is trusted and declares accounts via `sync_accounts`.

See [Accounts and Agents](/docs/building/by-layer/L2/accounts-and-agents) for full workflows.

**Sandbox support is strongly recommended.** Declare `account.sandbox: true` in your capabilities so buyers can validate the full integration — product discovery, media buy creation, delivery reporting — before committing real spend. Buyer-declared account sellers provision test accounts through `sync_accounts` with `sandbox: true`; account-id namespace sellers expose pre-existing sandbox accounts through `list_accounts` or out-of-band setup. Without sandbox, buyers must test against live inventory, which slows adoption and increases onboarding friction. See [Sandbox mode](/docs/media-buy/advanced-topics/sandbox) for implementation details.

## Delivery reporting

All Media Buy Protocol sales agents MUST implement [`get_media_buy_delivery`](/docs/media-buy/task-reference/get_media_buy_delivery) and include `reporting_capabilities` on every product. Buyer agents pull performance data — impressions, clicks, spend, conversions — in a standardized format. This is how agents monitor campaigns across platforms without logging into each dashboard individually. See [Required tasks by protocol](/docs/protocol/required-tasks) for the full list of required seller tasks.

Sellers building AdCP into their production stack should consider enrolling in the **[AAO Verified (Live)](/docs/building/verification/aao-verified)** qualifier once they're serving real campaigns. (Live) adds continuous observability of live delivery data on a designated compliance account, distinct from the (Spec) qualifier earned automatically by storyboard passing. Opt-in, no new infrastructure on the seller side — grant the [`attestation_verifier`](/docs/accounts/overview#standard-named-scope-attestation_verifier) scope on one account with live campaigns.

## Product design patterns

Different inventory types use different AdCP features:

| Inventory type         | Key features                                                                   |
| ---------------------- | ------------------------------------------------------------------------------ |
| Standard display/video | `format_ids`, `delivery_type: "non_guaranteed"`, auction pricing               |
| Podcast sponsorship    | `shows`, `placements` (host read), `delivery_type: "guaranteed"`, flat\_rate   |
| CTV series sponsorship | `shows`, `exclusivity`, `delivery_type: "guaranteed"`                          |
| Live event             | `shows` (cadence: event), `episodes` (flexible\_end, tentative), `exclusivity` |
| Retail media           | `catalog_types`, `catalog_match`, metric optimization                          |

For content-centric inventory, see [Collections and installments](/docs/media-buy/product-discovery/collections-and-installments). For exclusivity and sponsorship patterns, see [Media products](/docs/media-buy/product-discovery/media-products#exclusivity).

## Governance enforcement

Buyer agents increasingly require governance compliance before committing spend. Implementing governance makes your inventory eligible for brand-safe campaigns, reduces post-campaign disputes, and signals to buyer agents that your platform takes brand suitability seriously. Three governance domains are relevant to sellers.

### Property governance via adagents.json

Your `adagents.json` file is the foundation of property governance. It declares which properties you sell, which agents are authorized to sell them, and which governance agents have data about your inventory. Buyer agents use this to verify supply path authorization and discover property intelligence — if your `adagents.json` is missing or incomplete, buyer agents cannot verify that you are authorized to sell what you claim.

Declare `property_features` entries to point buyers toward governance agents that score your properties for quality, sustainability, or brand safety. See the [property governance specification](/docs/governance/property/specification) for the full schema and the [adagents.json tech spec](/docs/governance/property/adagents) for publisher-side setup.

### Content standards enforcement

When a buyer includes a `content_standards_ref` in a `get_products` or `create_media_buy` request, they are asking you to enforce brand suitability rules during delivery. Your responsibilities: fetch the standards from the referenced governance agent, evaluate whether you can enforce them, reject the buy if you cannot, and calibrate your local evaluation model against the governance agent via `calibrate_content`. After delivery, push content artifacts back to the buyer so they can validate compliance independently.

If you cannot meaningfully enforce a buyer's content standards, reject the buy rather than accepting it and failing silently. See the [content standards implementation guide](/docs/governance/content-standards/implementation-guide) for the full sales agent workflow.

### Execution checks

When a buyer's account has governance agents configured (via [`sync_governance`](/docs/accounts/tasks/sync_governance)), the seller MUST call [`check_governance`](/docs/governance/campaign/tasks/check_governance) with `media_buy_id` and `planned_delivery` before confirming a media buy. This is a binding validation — the governance agent verifies the seller's planned delivery against the buyer's campaign plan.

```javascript theme={null}
// Before confirming create_media_buy
const check = await governanceAgent.checkGovernance({
  plan_id: mediaBuy.plan_id,  // from the create_media_buy request
  caller: "https://seller.example.com",
  governance_context: mediaBuy.governance_context,  // opaque — pass through, do not parse
  media_buy_id: mediaBuy.media_buy_id,
  phase: "purchase",
  planned_delivery: {
    geo: { countries: ["US"] },
    channels: ["olv"],
    start_time: mediaBuy.start_time,
    end_time: mediaBuy.end_time,
    total_budget: mediaBuy.total_budget.amount,
    currency: mediaBuy.total_budget.currency
  }
});

if (check.status === "denied") {
  // Committed checks are always binding — do not confirm the media buy
  return { error: "GOVERNANCE_DENIED", detail: check.explanation };
}

if (check.status === "conditions" && retries < 3) {
  // Conditions restrict what the seller can deliver — e.g., narrower geo,
  // blocked channels, reduced frequency. The seller adjusts their own
  // delivery parameters (not the buyer's budget) and re-calls check_governance.
  // If the seller cannot satisfy the conditions, reject the media buy.
  const adjusted = applyConditions(plannedDelivery, check.conditions);
  if (!adjusted) {
    return { error: "GOVERNANCE_CONDITIONS_UNSATISFIABLE", detail: check.conditions };
  }
  // Re-check with adjusted delivery (governance agents SHOULD deny after 3 re-calls)
  return await checkGovernanceWithRetry(request, adjusted, retries + 1);
}
if (check.status === "conditions") {
  return { error: "GOVERNANCE_CONDITIONS_RETRY_LIMIT", detail: check.conditions };
}

// check.status === "approved" — proceed with confirmation
```

Execution checks cover three phases of the media buy lifecycle:

| Phase          | When to call                                                                            | What's checked                                      |
| -------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------- |
| `purchase`     | Before confirming `create_media_buy`                                                    | Budget, geo, channels, flight dates, policies       |
| `modification` | Before confirming [`update_media_buy`](/docs/media-buy/task-reference/update_media_buy) | Change magnitude, reallocation, new parameters      |
| `delivery`     | Periodically during delivery                                                            | Pacing, spend rate, geo drift, channel distribution |

Sellers can adopt execution checks incrementally — start with purchase-only (one call per `create_media_buy`), then add modification and delivery checks. See [`check_governance`](/docs/governance/campaign/tasks/check_governance) for the full specification.

### Campaign governance context

When a buyer includes `governance_context` in the protocol envelope of a `create_media_buy` request, store it alongside the media buy. This is an opaque value — you don't interpret it, you just persist and forward it.

Pass `governance_context` back to the buyer's governance agent on every lifecycle event for that media buy:

| Lifecycle event       | How governance\_context flows                                                                              |
| --------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Create**            | Received in `create_media_buy` envelope. Store it. If calling `check_governance`, include it.              |
| **Activate**          | Include stored `governance_context` when calling `check_governance` with the seller's `planned_delivery`.  |
| **Update**            | Include on `check_governance` for modifications. The governance agent uses it to track cumulative changes. |
| **Pause / Resume**    | Include if calling `check_governance`. The governance agent updates pacing state.                          |
| **Cancel / Complete** | Include so the governance agent can close out budget tracking and produce final audit.                     |
| **Delivery webhooks** | Include in webhook payloads so the governance agent can correlate delivery data.                           |

The governance agent uses `governance_context` to reconnect each event to the original plan, campaign, and budget state. Without it, the governance agent has no way to track the media buy across its lifecycle.

If `governance_context` is not present in the original request, skip governance calls — the buyer is not using campaign governance for this media buy.

### Creative governance

Buyer agents may require creative evaluation before delivery — security scanning, content categorization, or quality scoring. As a seller, you participate by submitting creative manifests to governance agents via `get_creative_features` and honoring the feature requirements the buyer sets (for example, blocking creatives flagged for `auto_redirect` or `credential_harvest`). You do not need to implement the evaluation yourself; specialist governance agents handle that.

See the [creative governance overview](/docs/governance/creative/index) for the feature-based evaluation model and multi-agent collaboration pattern.

### For Sponsored Intelligence sellers: generation-time enforcement

Traditional sellers apply governance as a post-delivery filter — classify content, then block what fails. Sponsored Intelligence platforms generate creative at serve time, which means governance rules can be enforced during generation rather than after the fact. When a buyer pushes content standards, apply them as constraints on your generation pipeline so unsuitable content is never produced. This gives brands a fundamentally stronger guarantee: suitability is built into the output, not bolted on as a check afterward. See the [Sponsored Intelligence guide](/docs/sponsored-intelligence/overview) for how content standards integrate with catalog-driven creative generation.

## How it connects to your existing stack

AdCP sits alongside your existing APIs and dashboards. It doesn't replace your self-serve platform or your internal campaign management system. It adds a standard interface that AI agents can use.

| Your existing system    | How AdCP relates                                                        |
| ----------------------- | ----------------------------------------------------------------------- |
| Self-serve dashboard    | AdCP serves a different audience (AI agents, not humans)                |
| Management API          | AdCP provides a standard subset; your API provides the full feature set |
| Ad server (GAM, custom) | AdCP sends campaign instructions; your ad server handles delivery       |
| OpenRTB integration     | AdCP handles campaign setup; OpenRTB handles impression-level auctions  |

## Getting started

<CardGroup cols={2}>
  <Card title="adagents.json builder" icon="hammer" href="https://agenticadvertising.org/adagents/builder">
    Create and validate your adagents.json file using the interactive builder.
  </Card>

  <Card title="Media buy specification" icon="file-lines" href="/docs/media-buy/specification">
    Full reference for sell-side task implementations: products, media buys, and delivery reporting.
  </Card>

  <Card title="Building with AdCP" icon="rocket" href="/docs/building">
    Implementation guides, SDKs, and integration patterns.
  </Card>

  <Card title="Operating an agent" icon="gears" href="/docs/building/operating/operating-an-agent">
    What sits behind protocol compliance — activation, storage, hosting, and build-vs-buy.
  </Card>

  <Card title="Ask Addie" icon="message-bot" href="https://adcontextprotocol.org/chat">
    Ask questions about implementing AdCP for your platform — no code required.
  </Card>

  <Card title="Sponsored Intelligence guide" icon="microchip" href="/docs/sponsored-intelligence/overview">
    Product modeling and workflows for AI platforms and ad networks.
  </Card>

  <Card title="Commerce media guide" icon="cart-shopping" href="/docs/media-buy/commerce-media">
    Product modeling and workflows for retail media networks.
  </Card>
</CardGroup>