> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# accept_proposal

> Accept a committed proposal to create, amend, or cancel a MediaBuy.

`accept_proposal` is the single terminal action for the compact proposal lifecycle. It accepts exactly one committed immutable proposal snapshot.

`committed` retains the AdCP 3.1 reservation guarantee: the seller has locked the proposal's commercial terms and reserved its inventory until `expires_at`. Finalization creates that hold; acceptance consumes it and creates, amends, or cancels the MediaBuy.

Depending on `proposal_kind`, acceptance:

* creates a new MediaBuy;
* applies an amendment to an existing MediaBuy; or
* applies a negotiated cancellation.

The proposal already carries the commercial terms, so the request does not repeat packages, dates, targeting, or creatives.

**Request schema:** [`/schemas/3.0.28/media-buy/accept-proposal-request.json`](https://adcontextprotocol.org/schemas/3.0.28/media-buy/accept-proposal-request.json)

```json theme={null}
{
  "idempotency_key": "550e8400-e29b-41d4-a716-446655441011",
  "account": { "account_id": "account_123" },
  "proposal_id": "proposal_committed_456",
  "proposal_terms_digest": "sha256:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
  "name": "Acme summer launch"
}
```

For scalable proposals, include `total_budget`. Acceptance may also set a hard aggregate `daily_budget_cap` and optional shared `budget_cap_timezone`; these constrain execution without changing negotiated pricing. If the proposal carries a signature-required insertion order, include `io_acceptance`.

If the proposal belongs to an `opportunity`, acceptance closes that planning cycle with `accepted_with_seller`; callers may repeat the matching opportunity ID explicitly, while the accepted proposal retains the association.

Success returns the resulting MediaBuy identity, the proposal with `proposal_status: "accepted"`, and `purchase_bindings[]` mapping proposal purchase positions to package IDs for later creative assignment. Acceptance is idempotent. The seller atomically verifies `proposal_id`, `proposal_terms_digest`, expiry, and any `base_media_buy_revision`; stale or mismatched acceptance never applies different terms.

The optional `name` is buyer-authored MediaBuy display metadata, not a
commercial proposal term. A supplied request value wins over `proposal.name`,
is persisted unchanged, and is echoed outside `accepted_proposal`; it is not
covered by `proposal_terms_digest` or the accepted snapshot's `terms_digest`.
When an acceptance creates a MediaBuy and the request omits `name`, the seller
may seed it from `proposal.name` only when that value already satisfies the
MediaBuy constraints: non-whitespace and no longer than 255 characters. The
seller must not silently truncate or rewrite a proposal name to make it fit. A
seeded name is then persisted and reported like any other name.

To receive scheduled reports, a `reporting_webhook` registered on this task needs a buyer-supplied `operation_id` (see [Reporting webhooks](/dist/docs/3.0.28/building/by-layer/L3/webhooks#reporting-webhooks)); sellers MUST NOT send `media_buy_delivery` reports to a registration that omits it.

A completed acceptance MAY include `warnings[]` for non-blocking observations at the commitment boundary. Each warning identifies its package through the returned `media_buy_id` and `purchase_bindings[].package_id`; a continuing condition is also readable as an indicator through [`get_media_buys`](/dist/docs/3.0.28/media-buy/task-reference/get_media_buys). The seller may instead return `input-required` before consuming the proposal. Warnings never appear on failed or submitted arms.

An unexpired committed proposal cannot be rejected merely because its reserved inventory was sold elsewhere. Once `expires_at` passes, the hold lapses and the seller returns [`PROPOSAL_EXPIRED`](/dist/docs/3.0.28/building/verification/compliance-catalog#error-code-proposal-expired); the buyer must request and finalize a fresh proposal.

### Definition pins

Before mutating any state, the seller re-resolves every entry in the proposal's `commercial_terms.definition_pins[]` and compares its current digest with the pin's `content_digest` (see [Definition pins](/dist/docs/3.0.28/media-buy/specification#definition-pins)). The proposal ID and `proposal_terms_digest` can verify while a published definition has changed, because `terms_digest` covers the pin and not the definition it names. A failing pin returns [`REFERENCE_DEFINITION_CHANGED`](/dist/docs/3.0.28/building/verification/compliance-catalog#error-code-reference-definition-changed) with no MediaBuy created or amended, one error per drifted pin in `errors[]`. Each error looks like this:

```json theme={null}
{
  "$schema": "/schemas/3.0.28/core/error.json",
  "code": "REFERENCE_DEFINITION_CHANGED",
  "message": "A pinned definition changed after the proposal was committed.",
  "field": "commercial_terms.definition_pins[0]",
  "recovery": "correctable",
  "details": {
    "ref_kind": "publisher_collection",
    "reference": { "publisher_domain": "sports-network.example", "collection_id": "evening_news" },
    "pin_index": 0,
    "pinned_content_digest": "ea243014f56cbb3b44887a24bf839721e7c0eef44b9d5c36927fda86b99f3fa5",
    "current_content_digest": "fae2a9a11574c1a9a20e8c379e4a194ca47bf6d0a886de980b8de64f046ac24d"
  }
}
```

The buyer calls [`refine_proposals`](/dist/docs/3.0.28/media-buy/task-reference/refine_proposals) to obtain fresh pins, reviews the changed definition, and finalizes again. A definition withdrawn from a successfully fetched document is changed and omits `current_content_digest`; a document that cannot be fetched or parsed is transient, so the seller returns [`SERVICE_UNAVAILABLE`](/dist/docs/3.0.28/building/verification/compliance-catalog#error-code-service-unavailable) without mutating state. An idempotent replay of an acceptance that already completed returns the stored result without re-verifying pins.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.