​

What’s new in AdCP 3.3

3.2 added the compact lifecycle and portable evidence. 3.3 is a minor release that so far tightens the places where two conformant 3.2 implementations could still disagree: when an account comes into existence, which agent a signature belongs to, and what a seller’s catalog intake accepts. No stable field, enum value, or task is removed, renamed, or deprecated, and 3.3 adds optional fields and one optional capability object. Schema-valid 3.2 messages stay schema-valid unless they already used a name 3.3 now defines: media_buy.features.catalog_ingestion (previously any boolean was admissible), dooh_placement_attributes.location and dooh_inventory_summary (previously open extension points; lon, not lng), and the now-reserved ext.adcp. Two merged changes are normative narrowings, not additions: what a lazily provisioning seller may do on discovery tasks, and which signatures verify. Both are recorded in Versioning and governance and lead the migration guide.

​

The 3.3 feature set

​

Discovery never provisions an account

Discovery and negotiation tasks, including get_products, list_products, get_signals, request_proposals, refine_proposals, and decline_proposals, MUST NOT create or activate an account, or accept a seller’s default terms on a buyer’s behalf. A lazily provisioning seller provisions only on a task that commits spend or creates account-owned resources, such as create_media_buy, buy_products, accept_proposal, sync_accounts, sync_creatives, sync_catalogs, sync_event_sources, or activate_signal. A seller that provisions lazily instead of exposing sync_accounts MAY answer a discovery task for a complete natural key it would provision, as if that account existed, without creating it; a seller that exposes sync_accounts returns ACCOUNT_NOT_FOUND. (An unresolved account returning ACCOUNT_NOT_FOUND, even where account is optional, was already required and was clarified in 3.2.2.) The advisory storyboard media_buy_seller/unprovisioned_account_reference grades this; its checks become required at runner capability 14.1.0. See Account references before provisioning.

​

One agent-resolution rule for every signing surface

Request signing, webhook signing, governance JWS iss, designated-task response signing, and rights attestations now share one algorithm for deciding which brand.json lists an agent and which keys it may sign with. Agent URLs match by canonical URL everywhere, a publisher’s adagents.json signing_keys pin narrows the accepted keys for sell-side signatures about that publisher’s inventory, and webhook discovery starts from identity.brand_json_url. TMP keeps its own publisher-key model. See Agent resolution. This is a verification change: some signatures that verified under 3.2 can fail, mostly webhook and request signing. The list is in the migration guide.

​

Catalog ingestion declarations

Sellers can declare what their catalog intake accepts in an optional media_buy.features.catalog_ingestion object: accepted catalog types, ingestion modes (feed_url, inline_items), feed formats, content identifier types, an inline batch limit, and whether item status is reported per_item or at the feed_level. A seller that declares it must also declare catalog_management: true, and must reject an unlisted catalog type, ingestion mode, or feed format, and an explicitly supplied content_id_type outside a declared supported_content_id_types list, with UNSUPPORTED_FEATURE before changing state, including on dry runs. Inline items beyond max_inline_items_per_request fail with INVALID_REQUEST. A buyer that finds no declaration should treat ingestion limits as unknown, not unlimited. See sync_catalogs and capabilities.

​

Structured DOOH location

Concrete screens can carry dooh_placement_attributes.location (lat, lon, and a structured address) on placements. Network products can carry dooh_inventory_summary.venue_counts[] to describe aggregate geography by geo_level and geo_code. Both are optional disclosure metadata, and location never changes placement identity. See DOOH.

​

The ext.adcp namespace

ext.adcp is now a registered, AdCP-owned extension namespace. Its first member is an optional opportunity binding for cooperating 3.2 get_products integrations, declared by listing adcp in extensions_supported. It reuses the published 3.2 OpportunityContext shape and is not the core opportunity field. The namespace is reserved for the AdCP working group, so vendors keep their own namespaces. See AdCP opportunity extension.

​

Clarifications and conformance

• authorized_agents[].url in adagents.json is the agent’s full protocol endpoint URL, including its path, and one entry is needed for each agent URL. See Agent URL matching.
• Compliance storyboards gate advanced delivery reporting on advertised wholesale discovery support and proposal-finalization replay on advertised idempotency support, exercise the documented polling path in sales-guaranteed, and provision an explicit sandbox account in the acceptance-policy discovery scenario. These change grading results, not the wire.
• The trust and verification docs now agree with the schemas: only verify_brand_claim and verify_brand_claims carry signed response payloads. Examples use agents[] instead of the deprecated brand_agent and rights_agent fields.

The account-reference and trust-docs clarifications already shipped in 3.2.2 (v3.2.2).

​

What requires adopter attention

​

Still in review

Open 3.3 proposals are in working-group review and are not part of any beta until they merge. The current list is in the 3.3 beta program.

​

Start here

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