> ## 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. # What's new in AdCP 3.2 > Adopter overview of AdCP 3.2: compact media buying, targeting-aware discovery, canonical creative workflows, stronger security, portable evidence, and operational reconciliation. # What's new in AdCP 3.2 **3.2 is in beta.** Beta.9 is the current protocol checkpoint. TypeScript `@adcp/sdk@14.0.0-beta.13` and Python `adcp==8.0.0b9` embed beta.6, so use the signed beta.9 artifact directly unless your SDK explicitly names beta.9. Python higher-level helpers remain partial, and Go exact support is still pending. See the [3.2 beta program](/dist/docs/3.2.0-beta.9/reference/3-2-beta) before testing. AdCP 3.2 makes the protocol easier to implement as a set of explicit agent operations. It separates product listing, proposal negotiation, purchase, and operational control; makes targeting and creative capabilities discoverable; and strengthens the evidence and security contracts that autonomous execution depends on. Existing 3.1 integrations can remain pinned to `"3.1"`. The broad 3.x `get_products`, `create_media_buy`, and `update_media_buy` facades remain available for compatibility. New integrations should prefer the compact 3.2 tools after capability discovery. ## The 3.2 feature set ### A smaller, explicit media-buy lifecycle Seven task-specific tools replace overloaded modes in the compatibility facades: * `list_products` lists published offers; * `request_proposals`, `refine_proposals`, and `decline_proposals` manage immutable proposal snapshots; * `buy_products` purchases published offers directly; * `accept_proposal` executes committed new-buy, amendment, or negotiated cancellation terms; * `control_media_buy` applies revision-checked operational controls inside the accepted commercial envelope. Sellers advertise the subset they support through `media_buy.lifecycle_tools`. Its absence tells callers to use the compatibility facades. See [Proposal negotiation](/dist/docs/3.2.0-beta.9/media-buy/product-discovery/proposal-negotiation) for the end-to-end draft → refine → finalize → accept flow. ### Targeting that survives discovery and execution Targeting-aware discovery separates concrete constraints from future selectability. Buyers place known values in `targeting_overlay` and use `required_overlay_support` when values will be chosen later. Sellers return configured products whose price, forecast, expiry, and targeting resolution match the request. The 3.2 surface includes portable demographics, country-aware subdivisions, named places, browser families, property exclusions, audience evidence, and exact package readback. Products can also disclose per-package cardinality for country inclusion, country exclusion, and proximity targeting before a buyer creates or updates a package. See [Targeting-aware product discovery](/dist/docs/3.2.0-beta.9/reference/migration/targeting-aware-discovery). ### Commercial terms and controls are explicit 3.2 adds seller-optimized shared budgets, bidding policy, atomic total-budget updates, daily caps, creative rotation, contingent revenue-share pricing, and structured warnings and durable indicators. Commercial changes outside an accepted proposal flow through refinement; operational changes inside accepted terms use `control_media_buy`. This split gives buyers one recovery rule: follow the accepted terms and current revision for control; request a new immutable commercial snapshot for anything that changes those terms. ### Canonical creative workflows Canonical format declarations become the authoring and discovery path. Creative agents advertise stable capability IDs and supported operations; products expose accepted `format_options[]`; build and transformer calls select those capabilities directly. 3.2 also adds image pixel-density and rendition-set semantics, creative localization, optional async preview, audio loudness constraints, VAST 4.3 and validation levels, structured accessibility rejection detail, and synthetic depiction provenance. `list_creative_formats` remains a compatibility task, but new discovery must use product format options and creative capabilities. Exact plural `format_ids` fields are deprecated for removal in 4.0. ### Portable evidence and safer asset access Portable attestations allow a producer to reference signed evidence without embedding the full assertion in every payload. Audience evidence, rights grants, runtime signal quality, and brand-verifier authorization build on the same reference-and-verification pattern. Inline cloud credentials in secured asset payloads are deprecated. Prefer short-lived signed URLs, pre-authorized workload identity, or bounded asset-scoped bearer tokens. See [Migrating secured asset access](/dist/docs/3.2.0-beta.9/reference/migration/asset-access). ### Stronger request integrity Request signing remains optional in 3.2, but a 3.2 signing profile has one cryptographic posture: every accepted signature on a body-bearing request covers `content-digest`. Legacy `"either"` and `"forbidden"` profiles remain only for explicit 3.0/3.1 compatibility endpoints. Request `Signature` and `Content-Digest` binary values also move from the 3.1 unpadded Base64URL override to RFC 8941 padded standard Base64. Parser selection comes from the trusted endpoint/profile. Webhook v1 keeps its separately routed legacy Base64URL encoding throughout 3.x. 3.2 also grades OAuth discovery consistency, tightens signed-response verifier errors, and requires integer `error.retry_after` values from 3.2 producers. ### Better convergence and accountability Capability-change notifications, account status notifications, snapshot/log repair rules, demographic and spot-level delivery reporting, package metric accountability, and relationship-scoped indicators make asynchronous agent state easier to reconcile. The compliance bundle adds deterministic read-filter checks, fixture resolution, grounded readbacks, and capability-selected runtime projections so agents are graded against behavior they actually advertise. ### Experimental governance and Trusted Match revisions The experimental campaign-governance surface gains task-scoped enforcement, authenticated caller binding, opaque plan authorization, prepared execution, and governance-owned outcome reconciliation. Trusted Match experimental surfaces refine publisher authentication, router merge behavior, context attribution, and publisher-owned creative data. These remain experimental. Implementers must inspect `experimental_features`, pin an exact 3.2 release, and follow the applicable migration notice. ## Reference implementation evidence The reference training agent is useful evidence, but it is not a badge and it does not turn every schema addition into an implementation claim. The current 3.2 corpus draws the boundary as follows: | Surface | Executable evidence | Current boundary | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compact product and proposal lifecycle | `compact_product_lifecycle`, `compact_direct_buy_lifecycle`, declined-proposal, expired-proposal, and structured-rejection storyboards | End-to-end on the reference sales tenant; implementations still advertise only the lifecycle tools they actually serve. | | Targeting-aware discovery | `targeting_aware_discovery` covers conflicting legacy input, hard brief interpretation, forecasts, exact and modified configured products, fixed inventory, cardinality, compatibility, create, update, and readback | End-to-end on the reference sales tenant. Optional 3.1 downshift runs only when that release is advertised. | | Canonical creative validation | `premium_display_canonical_validation` and `ctv_experience_validate_input`, plus policy-backed rejection and asset-filter storyboards | Strong executable coverage. Native localization and lifecycle-webhook coverage remain capability- and runner-dependent. | | Portable attestations and audience evidence | Versioned `attestations`, `rights-attestations`, `governance-runtime-attestations`, and `audience-evidence` vector suites | Deterministic trust, binding, revocation, cache-reuse, and requirement-mode coverage. These library fixtures do not claim a live issuer/resolver network or replace an agent storyboard. | | Timezone and operational controls | Account-timezone and budget-cap-timezone storyboard families, plus deterministic media-buy read filters | End-to-end for the declared reference-agent routes. | | OAuth and cache isolation | `oauth_setup` and wholesale product/signal cache-scope isolation storyboards | Protocol and transport behavior are exercised independently of any one commercial workflow. | | Experimental governance and Trusted Match | Property-list webhook signing and publisher-authentication rejection storyboards | Partial reference evidence only; experimental declarations and exact-version pinning remain mandatory. | | Advanced delivery reporting | `advanced_delivery_reporting` covers metric narrowing, `time_based_views`, canonical `by_format` rows, limits, truncation disclosure, and applied-sort echoes across discovery, purchase, simulation, and delivery | End-to-end on the reference sales tenant for the declared product capabilities. Expanded channel-specific OOH/audio metrics remain separate coverage work. | | Audience activation | `audience_activation_discovery` covers the experimental feature gate, catalog-wide method union, per-product declarations, vendor-constrained matching, OR and wildcard semantics, and exclusion of undeclared products | Discovery is end-to-end on the reference sales tenant. External dataset or distributed-segment binding remains an account-setup integration until the external-source runtime extension lands; the storyboard does not imply that runtime exists. | The CI matrix resolves applicable storyboards from each tenant's live capability declaration, keeps skipped and quarantined work visible, and uses ratcheted floors only as regression guards. See [Known Limitations](/dist/docs/3.2.0-beta.9/reference/known-limitations#conformance-and-testing) for the remaining runner and coverage gaps. ## What requires adopter attention | If you are… | Review before advertising 3.2 | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Any seller or service | Advertise `"3.2-beta.N"` only for the exact beta served, echo it on responses, and keep 3.1 traffic on its negotiated contract. | | A buyer | Gate compact tools and optional targeting on capabilities; do not infer 3.2 support from a major-only declaration. | | A media-buy implementer | Use `media_buy_status` on create/update success payloads; root `status` is the task-envelope state. | | A signing implementation | Require `content-digest` coverage for every signed body on a 3.2 signing endpoint. | | A creative implementation | Prefer canonical capability and product format discovery; retain legacy conversion only at a proven compatibility boundary. | | An SDK maintainer | Generate from the signed beta.6 tarball, name the exact supported bundle, and feed accepted protocol corrections into a later beta. | | A compliance operator | Test beta.6 from its signed assets, or keep an exact beta.5 SDK pairing; retain end-to-end integration evidence and do not issue a 3.2 badge from a beta. | ## Start here 1. Read the [3.2 beta program](/dist/docs/3.2.0-beta.9/reference/3-2-beta). 2. Follow [Migrating from 3.1 to 3.2](/dist/docs/3.2.0-beta.9/reference/migration/3-1-to-3-2). 3. Choose the exact package and support level in [Choose your SDK](/dist/docs/3.2.0-beta.9/building/by-layer/L4/choose-your-sdk). 4. Use the [Release Notes](/dist/docs/3.2.0-beta.9/reference/release-notes#version-3-2-0) for the cumulative record.