​

Migrating from 3.2 to 3.3

• Required to claim 3.3 behavior: rules that narrow what a conformant implementation may do, including unsupported webhook HMAC and batch bodies, responses that conform to the served release, refinement that carries compliance forward, bounded counterparty-asserted domain lists, seller revisions that advance on every committed change, flight start for committed buys only, flat totals for multi-qualifier metrics, enforceable domain identifiers, property list references through AdCP tasks, and dual emission of platform IDs, request_account as the single account write, the protocol envelope on every task response, major-only requests served the oldest release, closed schemas that stay closed, and capabilities bounded by structure.
• Brand JSON size cap rises to 2 MiB, audience match counts, and the 4 MiB response-size default: three loosened guarantees, so a 3.2 peer can reject or misread what a 3.3 peer sends.
• Recommended: bound agent response size: a new SHOULD that tightens what an adopting buyer accepts.
• Send only to 3.3 peers: new fields a 3.2 validator rejects.
• Deprecations: seller_id on event source and audience results, principal_kind and expected_principal_kind on the principal tasks, the natural-key account reference after provisioning, the account identity-rekey machinery (identity_updates, operator_identity, ACCOUNT_MOVED, ACCOUNT_IDENTITY_CONFLICT, stable_account_id), and condition (b) of request_signature_required; removal no earlier than 4.0.
• SDK and code-generator maintainers: schema-shape changes that alter generated types.

​

Upgrade checklist

​

Withdrawn from 3.3, planned for 4.0

​

Definition pins (published in beta.0 and beta.1, removed after beta.1)

• commercial_terms.definition_pins[], with core/definition-pin.json and enums/definition-pin-ref-kind.json.
• The definition_changed value of proposal-refinement-reason and the drifted_pins[] field on refine_proposals result rows.
• The REFERENCE_DEFINITION_CHANGED error code and error-details/reference-definition-changed.json.
• The definition_pin_probe scenario of comply_test_controller, the definition_pin_drift storyboard, and the definition-pins test vectors.

​

Purchase rights (published in beta.1, removed after beta.1)

​

Installment selection (published in beta.1, removed after beta.1)

​

Where the designs are kept

​

Required to claim 3.3 behavior

​

Discovery tasks never provision an account

• get_products, list_products
• get_signals
• request_proposals, refine_proposals, decline_proposals

​

Signature verification tightens

• A pinned signing_keys key that is not published in the agent’s JWKS is rejected. The pin narrows the accepted keys for sell-side signatures the agent makes about that publisher’s inventory, such as webhooks; it never adds a key and does not apply to the agent’s other traffic. Where a message covers several publishers, the key must match every pin that applies. Publish every pinned key in the agent’s JWKS.
• A pin entry without complete public-key parameters for its kty, such as one with only a kid, matches nothing. Matching is by RFC 7638 thumbprint.
• key_origins is now checked for every webhook signer that publishes brand_json_url, including pinned keys, and origin binding (the agent URL’s eTLD+1 equals the brand_json_url eTLD+1, or a House Portfolio authorized_operators[] entry covers it) applies to webhook signers.
• Webhook discovery starts from identity.brand_json_url. When it is present, buyers MUST use it and MUST NOT fall back. The 3.x fallback reads /.well-known/brand.json at the agent’s host, or its eTLD+1, only for sellers that omit the field. Every resolution failure rejects with webhook_signature_key_unknown.
• Agent URLs match by canonical URL on every surface. Webhook discovery and governance iss no longer compare byte for byte, and the schema’s agent_url_match verifier constraint is now canonical. Two agents[] entries that match canonically are ambiguous only if they differ in type or in resolved JWKS source; entries that agree on both count once.
• Governance buyer identity for signed requests is the exact operator record that agent resolution selected, and iss must match exactly one governance-typed entry.
• Cached or onboarding mappings must be confirmed against the agent’s brand_json_url and re-confirmed within the brand.json cache lifetime.

​

A2A operation-resolution hardening becomes MUST

• strict parsing of unsigned bodies, including JSON-RPC batches and duplicate or case-variant member names, with duplicate keys detected after JSON string decoding ("skill" and "sk\u0069ll" collide);
• A2A Part shape: one content member per Part, no FilePart, and kind agreement;
• task-continuation binding: a message.taskId request must resolve to the task’s original operation and come from the principal that created it.

​

Reporting webhooks without operation_id fail closed

​

Reporting and artifact webhooks can omit authentication

​

Advertise only the measurement terms you accept

​

Audience identifiers keep their wire form

​

Delivery rows may omit impressions

• Receivers MUST NOT treat an absent impressions as zero and MUST NOT derive impression-denominated values (cpm, ctr, completion_rate, viewable_rate) for that row. SDK-generated row types make the field optional; handle undefined or None.
• Senders omit impression-denominated rates on such a row, MUST NOT put views, plays, downloads, or any other count in impressions, and disclose a committed-but-missing metric through by_package[].missing_metrics.
• Version gate. A response served below 3.3 follows the 3.2 schema, which requires impressions (Serving an older pin). In it, a seller with no impression count omits the row and never substitutes impressions: 0.

​

Product rosters can be undisclosed

• Emission gate. A seller serving a release below 3.3 MUST NOT return a product with an empty roster; the 3.2 schema requires one entry, so it omits the product and returns the others (Serving an older pin). Wholesale feeds and webhooks are not defined by this release.
• Allow lists (property_list, collection_list, collection_lists) MAY be accepted against an undisclosed roster. The package runs only on the items the seller matches, with no promise to cover every listed item.
• Exclusion lists (property_list_exclude, collection_list_exclude, collection_lists_exclude) are the buyer’s choice, because the buyer sees the undisclosed roster at discovery. A seller MAY accept one, and if it does it MUST apply the exclusion against its full internal roster. A seller that cannot, for example because it does not itself know every publisher it may serve, rejects it with UNSUPPORTED_FEATURE (correctable).
• Buyers SHOULD treat an undisclosed roster as opaque in brand-safety and governance logic, decide whether it is acceptable for their exclusions, and MAY refuse such products. Sellers SHOULD offer complete rosters where they can.

​

Property domain identifiers have an enforceable format

​

Property list references resolve through AdCP tasks

​

Counterparty-asserted domain lists are bounded

​

Seller revisions advance on every committed change

• Advance the media-buy revision on operator and ad-server edits, on connected-platform changes you ingest, on seller automation such as a review decision that changes a package’s creative approval, and on every applied sync_creatives assignment change (once per affected buy, in the same atomic write as that buy’s assignment change). A platform report that merely echoes a change you already committed is not a new change. Delivery measurements (snapshot, get_media_buy_delivery), indicators, health, impairments and webhook_activity carry their own freshness fields and are not revisioned state. An ingestion pass that observes no change advances nothing, and one atomic ingestion transaction may coalesce its changes into one revision step.
• Append a history entry for each such change. For a change that did not arrive through an AdCP task, set the entry’s origin.kind to seller_operator, seller_system, connected_platform or unknown, the same vocabulary as account.change.origin. The existing actor string is unchanged.
• Seller-optimized allocation: changing a reported cap, target, pacing or lifecycle value advances the revision with origin.kind: "seller_system". Spreading spend between packages inside the accepted caps remains delivery behavior and advances nothing, so for allocation this restates 3.2 rather than tightening it.
• When you maintain a creative seller_revision, account.change.resource_revision carries its value immediately after the change, in the same JSON type.

​

Flight start activates committed buys only

​

Multi-qualifier metrics omit flat totals

​

Responses conform to the served release

​

Refinement carries compliance forward

​

Platform IDs are emitted under both names

​

Account identity is the account ID

• Sellers MUST return account_id on every non-failed sync_accounts provisioning result once the account is resolved, never issue one that might later change, accept { "account_id": "..." } wherever an AccountRef is accepted, and never change it. If you open buyer-declared accounts through sync_accounts, accept settings-update entries keyed by account_id. Such an entry updates attributes, brand.countries and billing included, on the same account. Validate a changed attribute as you do when the account opens, and reject a change you do not support with UNSUPPORTED_FEATURE. currency, timezone, and sandbox are set at opening: you MAY refuse a currency or timezone change, and sandbox never changes. You can review a countries change first: report pending_approval on the entry’s result row, and keep the current countries until you approve. A natural-key reference resolves only when exactly one of the caller’s accounts matches; otherwise return ACCOUNT_AMBIGUOUS, and MAY list the candidates in details.candidates.
• What narrows for sellers. In 3.2, returning account_id was a SHOULD and accepting it was optional. Both are MUST, so a seller that met only the 3.2 wording does not conform. In 3.2, a buyer-declared seller could reject settings-update entries; in 3.3 it accepts them. A provisioning entry never changes an existing account. When it matches exactly one account in your account scope, on brand and operator with its attributes as filters as the request_account deduplication guidance describes, you SHOULD return that account_id instead of opening another. The exact-or-reject rules for billing and payment_terms still apply.
• Buyers store the returned account_id and send it on every later call. Retry with the same idempotency_key. Sending a provisioning entry again is safe with a seller that returns the account the entry matches, but that is a SHOULD, so look a lost ID up through list_accounts. A change to currency or timezone normally means opening a new account.
• Buyers working with 3.0 to 3.2 sellers. An older seller may reject settings-update entries, may not support a countries change, or may treat countries as part of the natural key. When it can’t take the change, keep using the account reference you have, its account_id or the natural key the seller accepted: the account keeps working with its current countries. Open a new account only if you choose to, with a provisioning entry carrying the new countries. It gets its own reference, and the existing account and its media buys stay as they are. Don’t use the deprecated operator_identity rekey to emulate the change.
• Countries and accepted buys. brand.countries decides which products, prices, terms, and reviews apply, not where a buy delivers. Narrowing it never changes a media buy the seller already accepted. A change can make two accounts alike; that is not a conflict, and both keep their IDs. A seller that supports account.requests puts a request_id on a settings-update row it is reviewing, and the request can resolve to the changed account or an account you already hold. A separate new account comes only from a request_account change that sets allow_separate_account: true; otherwise a seller that would only take the change on a new account rejects it with ACCOUNT_CHANGE_REQUIRES_NEW_ACCOUNT. See Account identity.

​

request_account is the single account write where supported

• One write. request_account opens an account (brand and operator) and changes one. With an account_id and other fields, each field is a requested change: the brand’s countries (with a matching domain and brand_id), operator_unit, billing, billing_entity, and payment_terms. A revision guards the change, and it is required when the change touches billing, billing_entity, or payment_terms (a stale one returns CONFLICT). sandbox never changes. currency and timezone change only on a seller that lists them in account.requests.changeable_attributes, and a seller that changes timezone MUST list it; otherwise the change is refused with UNSUPPORTED_FEATURE.
• Outcomes. A request is in_review with a single pending_action saying whose turn it is, resolved, ambiguous, or rejected. A change resolves as updated on the named account, matched to an account the caller already holds, or created as a separate account carrying the change, and in the last two cases the named account is untouched and the seller MUST NOT move media buys, creatives, or reporting between the accounts. A created resolution happens only when the request set allow_separate_account: true (default false). A seller that would take the change only on a separate account otherwise refuses with the correctable ACCOUNT_CHANGE_REQUIRES_NEW_ACCOUNT (#8580, #8582).
• Money terms (beta.3). A request that resolves matched or created MUST carry account, with its billing, billing_entity (without write-only fields), and payment_terms, because they can differ from the terms requested. An updated request that changed billing, billing_entity, or payment_terms carries effective_at, when the new terms take effect. A created separate account carries not_carried_over, the account-level configurations it doesn’t have (#8620). A seller that returned these resolutions without account fails validation.
• Reads. list_accounts takes include_requests and request_ids and returns account_requests[] beside accounts[]. Requests page through requests_pagination and account_requests_pagination; the top-level pagination pages accounts only. The unreleased get_account_requests task is gone, and account.requests.read_task is list_accounts.
• Authorization. The seller resolves account_id against the caller’s access before any other check, so an unreachable account answers like an unknown one. A change needs request_account in the grant’s allowed_tasks with read_only: false, and every changed field in the grant’s field_scopes when it lists them (SCOPE_INSUFFICIENT, READ_ONLY_SCOPE, FIELD_NOT_PERMITTED). A newer change request from the same caller supersedes the open one, which is rejected with CONFLICT and details.superseded_by.
• sync_accounts where account.requests is supported. Buyers SHOULD use request_account, list_accounts, and sync_principal instead. A sync_accounts entry that carries only notification_configs or reporting_delivery_configs is a subscription write: it MUST name an account the caller already holds (otherwise ACCOUNT_NOT_FOUND), and the seller MUST NOT provision, review, or change account attributes for it. A settings update under review carries its request_id.

​

Every task response composes the protocol envelope

• status is required. The envelope required it already, and the schemas now enforce it on every response served at 3.3, including the async status payloads and governance responses that omitted it. A webhook result example carries the task’s status.
• Version fields. core/protocol-envelope.json composes core/version-envelope.json, so adcp_version and adcp_major_version are envelope fields on every response, stamped by the server framework rather than carried as task data. The adcp_version echo validates on the control_media_buy, decline_proposals, buy_products, and accept_proposal responses.
• Open roots. Every response root and status branch is open. The 18 closed ones are reopened: the 3.2 proposal-flow roots and branches, the new 3.3 list_collections, list_proposals, get_media_buy_issue, and report_media_buy_issue responses, and the experimental get_reporting_status failure branches. Closed value objects and rows inside a body stay closed.
• message. A task-level message is at most 2,000 characters, defined once in core/task-message.json and treated as untrusted input by the receiver. A seller whose text is longer MUST truncate it rather than fail the task.
• task_id. One definition, core/task-id.json (type: string, minLength: 1), serves every declaration. An empty task_id is rejected. A submitted response requires task_id, a working body requires status: working, and an input-required body requires status: input-required, each through a shared schema.
• replayed. An absent value means false, and a response may carry replayed: false; replayed: true appears only on a replay.

​

A major-only request is served the oldest supported release

​

Closed schemas stay closed within a major

• Features that needed to add terms to commercial_terms are withdrawn (above), and seller-held change terms are planned for 4.0 instead of shipping as commercial_terms.change_terms[].
• New 3.3 additions sit on open schemas or in sibling fields. target_audiences[] is a sibling of the closed audience_evidence_requirements, vendor_metric_provenance[] is a sibling of the closed vendor_metric_values[] row, and counting_mechanisms reaches the closed canonical measurement terms in 4.0.
• Send a 3.3 field on a reopened schema only to a 3.3 peer. A strict validator on an earlier 3.2 patch still rejects it (Send only to 3.3 peers).

​

Capabilities are bounded by structure

• New and experimental fields enforce the limit with the keywords. Fields stable before 3.3 carry it as the 4.0 annotations, a SHOULD through 3.x that 4.0 turns into the keyword. No schema-valid 3.2 document becomes invalid.
• MAX_CAPABILITIES_BYTES (64 KiB) keeps its name and value as a receiver backstop and deployment guidance: receivers commonly bound response size at the HTTP or gateway layer, and a limit near 64 KiB is a reasonable guard against runaway or hostile documents. It is not a design target and not a rule on senders. It stays the fetch budget of step 1 in the deprecated RFC 9421 key-discovery chain through 3.x.
• Counterparty-asserted lists are unchanged. The 8,192-byte budget per field and 16,384 bytes together stand, as in above.

​

Canceled and completed buys keep their packages

​

Mixed creative approval states at startup

​

Receivers ignore aggregated_totals in delivery webhooks

​

Brand JSON size cap rises to 2 MiB

​

Audience match counts may be absent

​

Recommended: bound agent response size

​

Client response-size default rises to 4 MiB

​

Webhook signing mode and batch bodies

• Sellers with legacy_hmac_fallback: false. Reject a registration carrying an authentication block with UNSUPPORTED_FEATURE, not request_signature_required. Point error.field at the block.
• Sellers with legacy_hmac_fallback: true. 3.2 behavior stays valid through 3.x, including the signature requirement on a registration that carries authentication (condition (b)). Condition (b) is deprecated and removed in 4.0 with the block.
• reporting_webhook and artifact_webhook. Their authentication is optional from 3.3 and still required on a request served below 3.3. These rules apply to them only on a request served at 3.3 or later; below 3.3 nothing changes. An absent block signs under the registration’s signing_profile (adcp/webhook-signing/v1 by default).
• Buyers. Send authentication only to a seller whose legacy_hmac_fallback is true. Compare a received webhook’s signing mode with the mode you registered.
• Batch bodies. A JSON array body, signed or unsigned, is rejected with request_body_malformed (SHOULD in 3.2.x, MUST from 3.3, #8064); this replaces the 3.2 interim rule that let a verifier resolve every element of a batch. A client that batches JSON-RPC messages, which older MCP protocol versions allowed, sends one message per request.

​

Recommended: bound inbound push and webhook bodies

​

Send only to 3.3 peers

​

What can fail validation

• adcp.implementation in get_adcp_capabilities: previously an open extension point, now the SDK implementation shape. Migrate to it or to a vendor-owned ext namespace.
• media_buy.features.catalog_ingestion: previously any boolean was admissible; it is now an object that requires catalog_management: true.
• dooh_placement_attributes.location and dooh_inventory_summary: previously open on product.json and placements, now strict shapes (lon, not lng).
• ext.adcp: now reserved for the AdCP working group. Vendors that used it for their own data move to their own namespace.
• reporting_webhook.operation_id: previously an open extra field, now constrained to 1–255 characters from the pattern above.
• audience_size, targetable_size, and match_rate_basis on a sync_audiences audience result, if used with a different shape.
• compact-task-submitted.json responses that break the version-envelope grammar or carry task_status / response_status (tightened in 3.2.4). Conformant sellers already satisfy both.
• validate_input warning items whose field is not a string. The schema always required field but never declared it; it is now declared as a string (#8212).

​

SDK and code-generator maintainers

• start_hour / end_hour are no longer individually required (#8025). A daypart entry carries exactly one complete pair of either start_hour / end_hour or the experimental start_time / end_time. Generated types make the stable pair optional, and readers of echoed or proposed daypart_targets must not assume start_hour is present.
• Bundled schemas hoist provenance (#7950, 3.2.4). /schemas/{version}/bundled/ carries core/provenance.json once in root $defs.Provenance and references it from each call site. Bundles shrink by about 20%. Some enclosing inlined schemas lose their deep $id, and two required_disclosures descriptions may differ. Source schemas and validation are unchanged.
• Envelope composition (#7946, 3.2.4). Nine compact and experimental request schemas and core/compact-task-submitted.json now compose core/version-envelope.json through root allOf, so generated types share envelope ancestry. Request validation is unchanged; compact-task-submitted.json response validation is tightened as listed above.
• media_buy.features is no longer boolean-only (#7927). catalog_ingestion is an object, so generators that emit a map of booleans for media_buy.features break.
• Daypart requirements (#8025). required_overlay_support.daypart_targets.timezone_modes is no longer required; a requirement carries timezone_modes, time_granularity, or both.
• Product rosters (#7948, refs #6135). publisher_properties and collections lose minItems: 1 on product.json and canonical-product.json. Generated types change for every product (a TypeScript non-empty tuple becomes T[]; a Pydantic min_length is dropped). Do not index [0] without a guard, and treat [] as undisclosed, not empty.
• Envelope on every response (#8547). Response types compose core/protocol-envelope.json: status is required on every task response and async status payload, message is bounded at 2,000 characters through core/task-message.json, task_id is core/task-id.json (minLength: 1), and replayed accepts false. Response roots and status branches are open, and 66 local copies of envelope fields are removed so the envelope’s declarations govern. Regenerate types; a hand-written response model that omitted status must add it.
• Delivery rows (#8108). impressions is optional on daily_breakdown and dimensional breakdown rows; aggregated_totals still requires it.
• Reporting issue codes (#8099, 3.2.4). The closed reporting status issue-code enum gains REVISION_UNREADABLE, with a reporting_revision_id field. Strict readers must accept it.
• Spot rows (#8017). by_spot[].aired_at is required only on aired and makegood rows and on rows without spot_status.
• Settings-update entries. The sync_accounts SettingsUpdateMode branch permits brand, operator_unit, currency, timezone, and billing, so generated settings-update types gain those five fields. operator stays forbidden.
• New shared schemas. core/audience-size.json, and the enums spot-status, daypart-time-granularity, audience-size-precision, and audience-match-rate-basis.
• Conformance vector re-code (#8066, 3.2.4). Request-signing negative/026-non-ascii-host now expects request_target_uri_malformed at step 10, not request_signature_header_malformed. Verifiers that matched the old code must update.

​

Adopt by capability

​

Production security profile (experimental)

​

Seller onboarding posture (experimental)

​

Stable creative IDs

​

Account change feed records

​

Installments on the compact product lifecycle

​

Creative seller_revision

​

Scheduled and human-gated buying

• expected_confirmation_at. Set it on a submitted response from create_media_buy, buy_products, or accept_proposal when confirmation waits on a scheduled event; on buy_products and accept_proposal, only for callers negotiating 3.3. refine_proposals can also carry it on a submitted response to a finalize-only request whose hold waits on a person’s agreement, such as a creator or host (#8104); never on a completed response, and only for callers negotiating 3.3. It is an estimate; buyers check status at that time instead of polling tightly. See Expected confirmation time.
• Vendor-metric outcome goals. Plan only (vendor, metric_id) pairs a product lists in both vendor_metric_optimization.supported_metrics[] and reporting_capabilities.vendor_metrics, answer in vendor_metric_values[], and reject anything else with INVALID_REQUEST. No new capability flag. See Vendor-metric goals.
• Governance budget periods (experimental). Governance agents that accept budget.periods[] on sync_plans declare governance.supports_budget_periods and enforce periods in check_governance. Plans without periods behave as before. See Budget periods.
• Hold policy and hold extension (experimental, media_buy.hold_policy, media_buy.hold_extension). Products and draft canonical proposals can carry hold_policy (available, min_duration, max_duration, extendable, max_total_duration); it binds on the draft proposal and carries forward to the committed successor. refine_proposals action: "extend_hold" lengthens a committed hold by returning a new committed successor with the same terms and a later expires_at; expected_confirmation_at may also accompany a submitted extension (#8203). Both are omitted for callers below 3.3. See Hold policy and Extend a hold.
• Delegated composition (experimental, media_buy.delegated_composition). A requesting platform that owns the catalog can bind criteria.product_ids_exclusive, so product_ids is the complete composable universe; sellers that do not declare media_buy.supports_exclusive_product_ids reject it with UNSUPPORTED_FEATURE. media_buy.proposal_refinement.hold_semantics: "terms_only" declares a finalize that commits terms without holding inventory; such a seller never returns committed proposals to callers below 3.3. See delegated composition.
• change_cutoff. Add it to installment deadlines where changes stop taking effect before the booking deadline passes. See Installment deadlines.

​

Delivery reporting

• Spot lifecycle and break position (experimental, media_buy.spot_lifecycle). Declare supports_spot_breakdown.available_statuses and supports_break_position before sending the fields. One spot_id tracks from scheduled to aired or preempted; a makegood row carries replaces_spot_id. Metrics on scheduled rows are expectations. See Spot lifecycle.
• Print proof of insertion (experimental). Report print_metrics per issue on by_installment rows. Sellers SHOULD populate evidence for guaranteed print products and report a gap through missing_metrics. See Delivery evidence and circulation.
• Property-grain rollups. Declaring media_buy.features.supports_property_breakdown or supports_installment_property_breakdown commits the seller to the breakdown on every product with the matching per-product flag, which stays authoritative. Under the property scenarios, the seller builds the breakdown only from rows injected through simulate_delivery.
• DOOH location and venue summary. Add dooh_placement_attributes.location (lat, lon, address) to a concrete single-screen placement and dooh_inventory_summary.venue_counts[] to a network product. Each venue_counts row requires geo_level, geo_code, and count, plus system or country as its geo_level requires. See DOOH.
• Audience size. Report audience_size and targetable_size as ranges with a precision, and omit them when status is too_small. See Audience size.

​

Creator and collection cards (experimental)

​

Assignment landing pages and trackers

​

Hosted video and audio playback trackers

{
  "asset_type": "pixel_tracker",
  "event": "first_quartile",
  "method": "img",
  "url": "https://measurement.example.com/q1?cid={CREATIVE_ID}"
}

{
  "asset_type": "pixel_tracker",
  "event": "custom",
  "custom_event_name": "first_quartile",
  "method": "img",
  "url": "https://measurement.example.com/q1?cid={CREATIVE_ID}"
}

​

Linear TV

• Minute dayparts (experimental, media_buy.daypart_granularity). Declare overlay_support.daypart_targets.time_granularity (hour, quarter_hour, minute) and reject a finer time with UNSUPPORTED_FEATURE. A seller that does not list the feature id rejects any start_time or end_time. See Minute-resolution dayparts.
• Broadcast formats and currencies. Use nmo or videoamp instead of custom in demographic_system. video_hosted accepts mxf and the mpeg2, avc_intra, and xavc codecs; the loudness object is experimental (creative.broadcast_loudness). See Broadcast creative.

​

SDK implementation metadata

​

Targeting errors

​

Open opportunities and later proposals

​

age_determination_bases on signals

{
  "$schema": "https://adcontextprotocol.org/schemas/3.3.0-beta.4/core/signal-listing.json",
  "signal_ref": { "scope": "product", "signal_id": "verified_adults_25_34" },
  "name": "Verified adults 25–34",
  "value_type": "binary",
  "restricted_attributes": ["age"],
  "demographic_predicate": {
    "age": { "min": 25, "max": 34, "include_unknown": false }
  },
  "ext": { "adcp": { "age_determination_bases": ["verified"] } }
}

​

Catalogs, signing, and extensions

• Catalog ingestion. Declare media_buy.features.catalog_ingestion with accepted_catalog_types, ingestion_modes, and item_status_reporting (required), plus supported_feed_formats whenever feed_url is listed. Declaring it requires catalog_management: true. Reject an unlisted catalog type, mode, or feed format, or an explicit content_id_type outside a declared list, with UNSUPPORTED_FEATURE before mutation, including on dry_run; inline items beyond max_inline_items_per_request fail with INVALID_REQUEST. Buyers treat an absent declaration as unknown, not unrestricted. See sync_catalogs.
• request_signing.operation_sources. List mcp_tools_call and a2a_invocation_skill only for the sources your verifier implements and passes vectors for, and list every source you support: an array without a2a_invocation_skill tells peers you do not enforce over A2A. See above.
• trust.json (experimental). trust/v1/trust.json and trust/v1/trust-acknowledgements.json are published under identity.trust_json (#8067). An agent is identified by the canonical origin of its URL, one agent per origin, and the record carries no keys (#8121). In 3.3 its reader is the experimental Web Bot Auth profile, which derives the record from the agent’s origin, and grants are read at sync_accounts. Publishers declare nothing. See trust.json and the agent identity migration guide.
• ext.adcp.opportunity. Cooperating get_products integrations can carry an opportunity binding under ext.adcp.opportunity, declared by listing adcp in extensions_supported. Durable association needs an authorized account scope, and a mismatched ID on refine is rejected with INVALID_REQUEST. The core opportunity field is still in review. See AdCP opportunity extension.

​

Live creative updates (experimental)

• list_creatives and the sync_creatives item return staged_update while a change awaits promotion; dry_run returns the exact outcome of one change. There is no per-creative policy readback: the declaration is the general floor and dry_run answers for one change.
• The new notification type creative.staged_update_changed reports a staged update’s outcome (promoted or rejected) only to subscribers that register it. creative.status_changed is unchanged, so a buyer on an earlier release never receives an approved to approved event that its closed validator would reject.
• A seller that declares the capability refuses an undeclared change with CREATIVE_LIVE_UPDATE_UNSUPPORTED (with error-details/creative-live-update-unsupported.json) in place of INVALID_STATE. A seller that doesn’t declare it keeps the original rule: creatives on active, non-paused packages cannot be updated, and the refusal is INVALID_STATE.
• comply_test_controller force_creative_status forces a staged update’s review outcome. The storyboards are media_buy_seller/creative_live_updates and media_buy_seller/creative_live_update_refusal.

​

Reporting subscriptions (experimental)

• Which periods are owed. A buy is owed every period that ends after its confirmed_at and overlaps its flight, starting at the first boundary at or after the later of the subscription version’s accepted_at and the account’s authorization.authorized_at, so the period in which a buy is confirmed is owed in full (#8593). A package added after confirmed_at carries added_at on get_media_buys, its own confirmed_at: it is owed from the period containing added_at and resolves its offerings then (beta.4). Sellers that advertise the feature populate it on every package added after confirmation; buyers stop assuming a later package resolves with the buy. The flight stops at the earliest of end_time, cancellation_effective_at (the delivery stop, later than canceled_at when the seller delivers through a notice period), and completed_at. A flight that stops at or before its start_time owes nothing.
• Cutovers and billing stubs. A change takes effect as a cutover at instant T. When a billing feed’s incoming schedule has no boundary at the handoff, the stretch to its first boundary is owed as one stub obligation (stub: true); pacing and analytics feeds leave it unowed. This covers account timezone changes and account-level sync_accounts billing configurations (#8617).
• Wire inputs. authorization.regranted_at, flight_history on media buys and get_media_buys, packages[].reporting_delivery_offering_ids fixed at confirmation, available_from and withdrawn_at on offerings, and per-version configuration in prior_versions (#8618, #8588). Offerings publish standard_dimensions so the buyer resolves match exactly as the seller does, and sellers MUST publish it on every offering (#8585).
• Determinism and scale. Resolution is per package and fixed per buy and version until the resolved offering is withdrawn. max_accounts admission is sticky, ordered by authorization.authorized_at then account_id in byte order. Billing subscriptions MUST use match: exact with dimensions. destination_overrides[] route accounts to other destinations, membership edits apply in place as excluded_by_buyer intervals without a new subscription_version, and the readback lists 16 prior versions and 1,000 accounts inline, with get_principal paging the rest through reporting_subscription_page (#8619).
• Deactivation and revocation. A deactivated subscription reads inactive with a required deactivated_at, and periods that started before deactivation stay owed (#8613). After the caller loses authority for an account, sync_reporting_receipts and sync_reporting_status treat every reference to it like an unknown identifier (#8607). A seller that wants a buyer to finish reconciling keeps a reduced grant that lists only the reconciliation tasks, and a grant that lists get_reporting_status but not the receipt or status tasks keeps the account covered and refuses the missing tasks with SCOPE_INSUFFICIENT. A grant reduced to tasks without get_reporting_status is a loss of authority at the reduction, exactly like a revocation: the seller lists the account in accounts_unauthorized[] with unauthorized_at set to the reduction and withholds its coverage, and adding get_reporting_status back is a re-grant (beta.4).
• Period arithmetic. Years, months, and days are civil time; hours, minutes, and seconds are elapsed time. Under a local alignment each local date’s first instant is a boundary, so PT24H equals P1D, and a sub-daily duration MUST divide 24 hours. billing_cycle needs a date component, a local alignment refuses a duration mixing date and time components (P1DT12H; schema validation enforces it from beta.4), weeks (P7D) under utc, account_timezone, and source_timezone start on Thursday, and status_retention_days counts exact 24-hour days (#8588, #8622).
• Delivery stays inside the flight. A seller that lists the feature id MUST NOT deliver on a buy outside its flight; to deliver later, including a make-good with remedy additional_delivery, it first extends end_time.

​

Commercial and targeting experiments

• Seller offers (media_buy.seller_offers, #8102). A seller proposes a change to an accepted buy as a committed canonical proposal with proposal_initiator: "seller" and an offer_reason (installment_postponed, installment_cancelled, preemption, under_delivery, seller_request), a media_buy_update or media_buy_cancellation that carries parent_proposal_id, media_buy_id, and base_media_buy_revision. Buyers read offers through list_proposals, announced by the identifiers-only proposal.offered notification, and accept with accept_proposal, decline with decline_proposals, or revise with refine_proposals. expires_at is the response deadline; at it the signed terms stand and accept_proposal returns PROPOSAL_EXPIRED, so silence is never acceptance. A seller that lists the feature id MUST also list media_buy.open_opportunities and advertise list_proposals. Sellers MUST NOT send offers to callers served below 3.3. Pre-agreed seller changes inside commercial_terms are not part of 3.3. See Seller offers.
• Price adjustments (media_buy.price_adjustments, #7955, #7659). A binding fixed-price pricing option (cpm, vcpm, cpc, cpcv, cpv, cpp, flat_rate) can carry an ordered table of fee and discount rows, each with a rate or a fixed amount, keyed by format_option, placement_selection (needs overlay_support.placement_selection), or always, and optionally a valid_from and valid_until window evaluated at the purchase start_time; a flight that crosses a window boundary is rejected. Selection rows fire at most once per dimension, then each firing row applies to one running total in declared order, rounding half away from zero at every step. A table is optional: without one, the price applies only to what was quoted. A seller never returns a table to a caller below 3.3. See Selection-dependent price adjustments.
• Execution readiness (media_buy.execution_readiness, #7934). For products that declare execution_requirements, a get_products request with account can set include_execution_readiness: true. The response carries an execution_readiness map keyed by product_id, versioned independently of wholesale_feed_version so public wholesale catalogs keep cache_scope: "public". Each product and requirement reports ready, setup_required, selection_required, input_required, or unknown (the seller could not check, which is not the same as the account lacking the resource), with candidates whose resource_id is directly usable in the existing binding field. See Per-account execution readiness.
• Gender targeting (media_buy.gender_targeting, #7925). Core demographics.gender predicates with female, male, and non_binary value sets and an independent unknown group, whose include_unknown covers both unavailable gender and an explicit choice not to state it. Product-scoped capabilities, exact gender-only and mixed age and gender readback, and sex_gender governance classification come with it. Demographic delivery reporting stays age-only in 3.3, so a gender-targeted package has no gendered delivery readback. Buyers MUST NOT send core gender fields on a 3.2 contract. See Core gender targeting.
• Signal pricing groups (signals.pricing_groups, #8058, #7898). An optional pricing_group on get_signals results and on Product.signal_targeting_options[], with signal_pricing_group_rules[] ({pricing_group, pricing_combination: highest | each}) on the response and on signal_targeting_rules, lets a seller price signals such as alternative age bands as one audience. A group with no rule and every ungrouped signal is charged each, and flat_fee, per_unit, custom, and percent_of_media options are always charged each. See Signal pricing groups.
• Provider-initiated signal delivery (signals.delivery_methods, #8044, #6552). A signal agent declares signals.delivery_methods[] on get_adcp_capabilities, with the same pattern vocabulary as audience activation methods read from the send side. An activate_signal agent destination may pin a delivery_method; with no pattern and vendor intersection the destination fails with UNSUPPORTED_FEATURE, and a pin sent to an agent that doesn’t list it is rejected the same way. Agent deployments gain delivery_status (awaiting_read, delivered, failed), a delivery descriptor, delivery_error, and an optional match outcome. A receiver field not yet established fails the destination with ACCOUNT_SETUP_REQUIRED. See Declaring delivery methods.
• Measurement provenance (media_buy.measurement_provenance, #7940). A shared enums/collection-mechanism.json vocabulary (set_top_box, acr, panel, server_logs, client_tracker, sdk) has two uses, both on open schemas: measurement_terms.billing_measurement.counting_mechanisms[] declares what the billing count is counted from (a seller whose own system is the named vendor SHOULD declare it; absence means undeclared), and vendor_metric_provenance[] on delivery metrics carries mechanisms[] and an optional deduplicated for a vendor_metric_values[] row, joined on (vendor, metric_id, qualifier). A collection mechanism is not measurement_source, which stays the provider slug, and broadcast as-run logs stay airing evidence in by_spot[]. Sellers serving an older pin omit both fields.
• Audience evidence targets and invoice lines. target_audiences[] (media_buy.audience_evidence_targets, #8215) names the audience a buyer wants evidence for beside audience_evidence_requirements, satisfied only by an admissible evidence item for exactly that audience; it is never a targeting predicate. lines[], invoice_kind, and adjusts_invoice_id on get_account_financials invoices (account.invoice_lines, #8207) tie an amount to the buys, packages, and reporting revisions it bills, and never settle an invoice.

​

Experimental surface notices

​

Experimental creative evaluator drops evaluator_id

​

Superseded reporting snapshots may be compacted

• the current revision of each logical slice, including every official revision;
• the snapshot it immediately supersedes;
• any superseded snapshot for automated_recovery_window_seconds or one hour, whichever is longer, after it was superseded; and
• for the requesting caller, revisions named by that caller’s own receipts or by its current received, unreadable, or content_mismatch status statement.

​

Clarifications

• Signing buyers serve get_adcp_capabilities. Request-signature discovery starts at the signer’s agent URL, so a buyer that signs requests answers get_adcp_capabilities there even if it only calls sellers. See request signing.
• A2A invocation. An A2A invocation message with more than one DataPart is rejected; the last-DataPart rule applies to responses only. See the A2A guide.

​

Already shipped in 3.2.2, 3.2.3, and 3.2.4

• 3.2.2: account references before provisioning, and the trust-docs consistency fixes (only verify_brand_claim and verify_brand_claims carry signed payloads; use agents[] instead of the deprecated brand_agent and rights_agent).
• 3.2.3: the A2A operation-resolution errata with hardening at SHOULD; authorized_agents[].url in adagents.json is the full endpoint URL including its path, one entry per agent URL; and the storyboard fixes (evaluator feature membership, wholesale and replay capability gates, the polling sales-guaranteed path, validate_input gates, and the acceptance-policy sandbox account).
• 3.2.4: the experimental REVISION_UNREADABLE reporting issue; requires: [controller] on controller-seeded storyboards, so a seller without a controller gets one storyboard-level skip; the storyboard fixes (required billing capability discovery, active non-guaranteed buys, the advanced_delivery_reporting join key, typed_proposal_negotiation seeding, the seller_optimized_budget minimum-spend fixture); request-signing vectors negative/029–031 and positive/013–015, the negative/026 re-code to request_target_uri_malformed, complete profile-3.2/ mirrors, and step-5 canonicalization vectors; envelope composition and the bundled provenance hoist; the product channel-declaration guidance; and the principal-layer buyer walkthrough (v3.2.4).

​

Deprecations

• seller_id on sync_event_sources and sync_audiences results. Use the new optional platform_id for the object’s ID in the seller’s ad platform, matching sync_creatives and sync_catalogs. Sellers reporting a platform identifier in 3.3 and later 3.x responses MUST emit both fields with identical values, including discovery responses and seller-managed event sources. Buyers MUST prefer platform_id and fall back to seller_id only when platform_id is absent. Either field may be absent in legacy responses, and both may be absent when no platform identifier is available. Continue using event_source_id and audience_id in AdCP requests. The aliases keep their object-ID semantics; they are never seller identity. adagents.json contact.seller_id and publisher identifiers of type seller_id are unchanged. Removal is no earlier than 4.0 and subject to the six-month notice policy. See event source migration and audience migration (#8290).
• principal_kind and expected_principal_kind on sync_principal and get_principal, and the enums/principal-kind.json enum. A principal is the buyer agent as the seller has bound it, so the kind is always buyer_agent and carries no information. Sellers keep returning principal_kind and honoring expected_principal_kind throughout 3.x; buyers stop reading and sending them, and don’t branch on principal_kind. Removal is no earlier than 4.0 and subject to the six-month notice policy. The task names are unchanged (#8443, #8280).
• The AdCP RFC 9421 signing profiles, for requests (adcp/request-signing/v1) and webhooks (adcp/webhook-signing/v1), with keys found through brand.json and identity.brand_json_url. They keep working throughout 3.x and are removed in AdCP 4.0, together with the brand.json trust fields (DR-0023). Their replacement is the experimental Web Bot Auth profile (Web Bot Auth identities; role-by-role steps in the agent identity migration guide): identity is the signer’s origin, keys come from that origin’s key directory, and no capabilities call is needed. Signers that serve no capabilities endpoint can move now. Verifiers keep accepting RFC 9421 signatures through 3.x, under the no-downgrade rule once an origin is bound.
• The natural key as the account reference after provisioning. Sending the natural-key AccountRef on account-scoped tasks once the account exists is deprecated and planned for removal in AdCP 4.0 (#7850). It keeps working throughout 3.x. The natural key itself stays: buyers use it to open accounts with sync_accounts and as a list_accounts filter to look up an account’s ID. Buyers store the returned ID and send it. See Account identity.
• The account identity-rekey machinery (#8474). The account.identity_updates capability is deprecated and planned for removal in AdCP 4.0, with everything it gates. That covers operator_identity and destination_billing_entity on sync_accounts, the identity_change and identity_change_preview fields, and the ACCOUNT_MOVED and ACCOUNT_IDENTITY_CONFLICT error codes. account.stable_account_id is deprecated with it. An account’s identity never changes, so no rekey or former key exists. Sellers that implement operator_identity keep it working through 3.x and SHOULD declare stable_account_id: true while the field exists. Buyers change operator_unit as an attribute and send account_id without checking stable_account_id.

​

Compliance and grading

• version_negotiation gains an optional scenario for 3.1-pinned response shapes. Its checks stay advisory until runners can validate against the served release’s schema bundle.
• sales-broadcast-tv (sales_broadcast_tv 1.1.0) now certifies one authorized TV transaction on either a guaranteed or a non-guaranteed fixed-price path (#8046). Existing claimants should expect new failures: seeded products are demo-priced cpm with Live/C3/C7 windows, creatives are assigned through sync_creatives assignment_operations, and Live and C7 reads must carry measurement_window, is_final, and finalized_at. Claims graded on 1.0.x have a grace window recorded in the compliance catalog. A spot-lifecycle phase runs only for sellers that list media_buy.spot_lifecycle.
• sales-fixed-rate is a new specialism for non-guaranteed, fixed-price sellers in any medium (#7963). Its sales_fixed_rate storyboard grades capability discovery, fixed-price product discovery, and a bid-less create_media_buy; optional hold phases run only when the seller advertises the force_media_buy_confirmation controller scenario. See Choosing a sales specialism.
• media_buy_seller/unprovisioned_account_reference is new and advisory until runner capability 14.1.0.
• media_buy_seller/stable_account_id is new and runs only for buyer-declared sellers that declare account.stable_account_id: true. That flag is deprecated in 3.3, so the gate is temporary. It addresses the account by account_id on get_media_buys and requires @adcp/sdk 15.8.0 or later, whose storyboard runner sends an authored account_id as written.
• New capability-gated scenarios: governance/budget_periods, media_buy_seller/property_delivery_reporting, media_buy_seller/installment_property_delivery_reporting, media_buy_seller/outcome_target_vendor_metric, and media_buy_seller/outcome_target_event_cost. Sellers that do not declare the capability skip them.
• New experimental scenarios: media_buy_seller/creative_live_updates and media_buy_seller/creative_live_update_refusal, the media_buy.execution_readiness scenario, a gender-targeting conformance storyboard, and a stateful package-retention scenario for canceled and completed buys. The definition_pin_drift storyboard, the definition_pin_probe controller scenario, and the definition-pins vectors are removed with definition pins.
• New controller scenario and vectors: reporting_subscription_probe on comply_test_controller (revoke_grant, regrant, reduce_grant, set_account_timezone, advance_time), and the canonical reporting-subscription coverage vectors with a reference model. Cross-SDK vectors for undisclosed rosters live under static/test-vectors/product/.
• Hosted service: grading of governance-aware sellers is covered in AAO Verified.

​

Rollback

​

Related

• What’s new in AdCP 3.3
• 3.3 beta program
• Release Notes
• Migrating from 3.1 to 3.2
• Versions & Compatibility