​

What’s new in AdCP 3.2

AdCP 3.2 turns a media-buy conversation into a commercial lifecycle that software can safely operate. A buyer can move from a brief to seller-authored plans, negotiate typed terms, reserve inventory, accept one exact snapshot, and operate the resulting campaign without asking either agent to infer which kind of change is happening. That is the release’s central upgrade: conversational on the outside, explicit and accountable on the inside. Targeting and creative capabilities are discoverable, commercial terms are immutable and digestible, retries are safe, and operational changes no longer rewrite the agreement they came from. 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 for the end-to-end draft → refine → finalize → accept flow. This is more than a naming cleanup. Each boundary has a distinct business meaning: Because the seller advertises an explicit subset of lifecycle tools, teams can adopt the model incrementally. A sales agent can delegate proposal planning to an internal specialist while keeping one public endpoint and one execution identity. A client can add proposal exploration before it adds purchasing. Cross-agent transfer of a committed hold is deliberately not implied: the agent that accepts a proposal must be able to authenticate its buyer binding, resolve the immutable snapshot, and consume its inventory hold atomically.

​

A durable connection for authenticated principals

3.2 adds an experimental principal layer for configuration that belongs to an authenticated caller’s standing relationship with a seller, rather than to one advertiser account or media buy. The seller’s authorization system still issues credentials and resolves the stable party before AdCP begins; the protocol does not turn a self-asserted agent URL or key ID into identity. After authentication, sync_principal lets a buyer agent or operator synchronize the sections a seller advertises:

• caller-level webhook subscriptions, including a one-call endpoint kill switch;
• reusable reporting destinations whose setup and suspension state can be shared across separately authorized accounts; and
• declarations of asynchronous AdCP versions, signing algorithms, and experimental features the caller can consume.

get_principal is the side-effect-free repair path. It returns the seller-resolved principal kind, an opaque configuration version for guarded replacement, destination generations and setup state, and the accepted intersection of caller declarations with seller support. principal.changed invalidates cached state after seller-side changes. Principal configuration never grants advertiser-account authority. Every account and reporting-feed binding is still authorized independently, and credential rotation preserves a record only when the seller maps the new credential to the same stable principal. The surface remains experimental so implementers can validate rotation, multi-account destination reuse, revocation timing, and delegated-operator boundaries before it freezes.

​

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 — including committed inventory selection: placement_selection for placements and collection_selection for collections, the latter materializing concrete selectors even when the selection came from collection-list references. 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.

​

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.

​

Where the commercial contract ends in 3.2

accept_proposal creates or changes an executable MediaBuy under one exact commercial snapshot. It does not by itself standardize payment rails, invoice settlement, foreign-exchange authority, delivery disputes, credits, or makegoods. Those remain account, contract, or platform integrations unless the participants advertise and use a relevant AdCP capability. The 3.3 commercial-completion workstream is defining the smallest portable post-acceptance lifecycle backed by adopter requirements. That boundary is deliberate: 3.2 makes acceptance precise without claiming to replace every financial or legal system behind a seller.

​

Cross-channel architecture, capability-specific depth

The lifecycle applies across digital and offline channels, but implementation and reconciliation depth varies by channel. A seller’s advertised products, formats, reporting capabilities, and lifecycle tools remain the source of truth. The cross-channel maturity workstream will publish the channel-by-lifecycle matrix and recruit contributors for print, broadcast, OOH, and place-based audio gaps.

​

Programmed channels have first-class identity and carriage

Collections can declare kind: "channel" for continuously programmed audio or video streams, including FAST, virtual linear, and syndicated audio channels. FAST describes a carriage and monetization model rather than a separate inventory kind. The channel owner remains the canonical collection publisher while distribution[].property_ids identifies each host app carrying it. A generic platform_channel_id supplies a host-scoped channel namespace when no platform-specific identifier exists. This keeps the inventory axes separate: the host app is the property, the programmed stream is the collection, and the avail is the placement. An owner’s distribution entry is a discovery assertion only. Verified owner-sold carriage still requires the host’s adagents.json to authorize the sales agent for the host property, narrowed by the owner’s external collection selector. Hosts do not need to duplicate the collection or enumerate owner-managed placements. See programmed channels and owner-sold carriage.

​

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-tagged audio delivery through the audio_vast canonical, 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.

​

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. The 3.3 production security profile will evaluate a stronger capability-declared production floor—including signed spend commits, least privilege, external-reference protections, audit, and anomaly limits—without silently breaking baseline 3.x compatibility. Mandatory signing across spend-committing operations remains a 4.0 floor. 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: 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 for the remaining runner and coverage gaps.

​

What requires adopter attention

​

Start here

1. Read the 3.2 beta program.
2. Follow Migrating from 3.1 to 3.2.
3. Choose the exact package and support level in Choose your SDK.
4. Use the Release Notes for the cumulative record.