Skip to main content

​
AdCP 3.2 beta program

Use the beta in development and staging, not production. New production integrations should remain on AdCP 3.1 until 3.2 reaches general availability. Every beta is an immutable checkpoint, but later betas may change 3.2 surfaces before GA.
The 3.2 beta cycle started with a protocol-first checkpoint. The current TypeScript SDK beta now consumes the exact signed beta.3 bundle: Earlier betas remain useful as pinned implementation checkpoints. For new TypeScript testing, pair SDK beta.4 with protocol beta.3. Do not combine a newer wire pin with an SDK generated from an older bundle unless the SDK maintainer explicitly documents forward compatibility.

​
Know which version string to use

The artifact version, wire pin, and documentation selector are related but not interchangeable: Only send a prerelease wire pin to a peer that advertises that exact value in get_adcp_capabilities.adcp.supported_versions. Prerelease pins are exact: a buyer pinned to "3.2-beta.3" must not silently negotiate to another beta, and a stable "3.2" pin must not silently negotiate to a beta.

​
Use the TypeScript SDK beta

The TypeScript SDK is the first package with exact beta.3 support. The npm latest tag remains on SDK 13, so opt into the preview explicitly:
SDK 14 includes typed caller and server support for the compact media-buy lifecycle, the beta.3 schemas and compliance assets, version-aware request signing, governance plan-adjustment reporting, and agent notification configuration. It retains 3.0 and 3.1 adaptation for mixed-version testing. See Choose your SDK for the support matrix and install guidance.

​
Use the beta.3 artifact directly

Download the signed beta.3 protocol bundle rather than copying schemas from main or from the moving /schemas/3.0.26/ path:
The extracted adcp-3.2.0-beta.3/ directory contains:
  • manifest.json — release version, bundle contents, skills, and file count;
  • schemas/ — source-shaped and bundled request/response schemas, including schemas/manifest.json for the task and capability inventory;
  • compliance/ — storyboards, test kits, vectors, and runner contracts;
  • skills/ — role guidance for coding agents;
  • openapi/ — published OpenAPI artifacts.
Verify the Sigstore signature before using the bundle as a build input. See Verifying protocol tarballs for the certificate-identity and issuer checks. Useful direct-artifact tests are:
  1. Generate or refresh types from the pinned bundled schemas.
  2. Validate representative requests and responses for the roles you implement.
  3. Compare your advertised tools with schemas/manifest.json.
  4. Exercise raw MCP or A2A calls with adcp_version: "3.2-beta.3" against a staging peer that advertises the same pin.
  5. Run the compliance assets with a source-compatible runner if you maintain one. Do not weaken production authentication to accommodate a beta runner.
No 3.2 verification badge is currently issued for beta.3. Treat it as an implementation input, not a certification target.

​
SDK support contract

An SDK support claim must name all of the following:
  • exact SDK package version;
  • exact AdCP prerelease bundle used to generate or load schemas;
  • supported roles and transports;
  • known unsupported or raw-only surfaces;
  • install command and one tested validation command.
The SDK compatibility matrix lives in Choose your SDK. Only the TypeScript row currently names exact beta.3 support. Treat generated 3.2 types and validators in every other SDK as unavailable until its row names an exact package and protocol checkpoint. Raw JSON calls may still be possible, but they are not equivalent to SDK support. SDK maintainers should report protocol ambiguities against the AdCP repository. Report SDK implementation bugs in the SDK’s own repository. Accepted protocol fixes receive a changeset and ship in a later beta; published betas are never rebuilt in place.

​
Current beta.3 checkpoint

Protocol beta.1, beta.2, and beta.3 are published, and TypeScript SDK beta.4 embeds the exact beta.3 bundle. Before treating a test result as beta.3 integration evidence, confirm that:
  • the support matrix names the exact SDK package and beta.3 protocol bundle;
  • both peers advertise "3.2-beta.3" before calls use that pin;
  • the integration scenarios below run against beta.3 and retain the exact package and bundle versions;
  • copy/paste installation and validation commands have been executed as published;
  • any unsupported Python or Go surface is reported as unavailable or raw-only, rather than inferred from TypeScript support.
Later protocol betas repeat the same protocol-tag-then-SDK-confirmation flow. The current TypeScript pairing does not make future beta ordinals compatible by default.

​
Required integration evidence

Retain the exact protocol bundle, SDK package versions, capability responses, redacted requests/responses, task IDs, proposal and MediaBuy revisions, creative IDs, warnings, and delivery readbacks for each run.

​
Buyer and seller lifecycle

  1. Discover the exact prerelease and capability gates.
  2. Use list_products or the advertised proposal flow, preserving the returned targeting and canonical format_options[] contract.
  3. Validate or preview a matching creative when the relevant capability is advertised.
  4. Commit with buy_products or accept_proposal; do not put creative bodies into either compact purchase call.
  5. Traffic and assign the creative through sync_creatives for a library-backed seller, or the seller’s advertised inline compatibility path.
  6. Exercise one revision-checked operational action with control_media_buy.
  7. Reconcile get_media_buys, get_media_buy_delivery, and, when advertised, get_creative_delivery through a non-zero delivery result or a documented no-delivery state.

​
Generative creative lifecycle

  1. Discover a build capability and, when applicable, an account-scoped transformer.
  2. Run brief → build_creative → validation → preview_creative, retaining the selected capability and generated manifest lineage.
  3. Run a pre-flight seller validation or dry-run sync, then purchase/accept and sync the materialized creative with its package assignment.
  4. Observe the live campaign readback and fetch MediaBuy delivery plus get_creative_delivery when the seller advertises it. Pass the served creatives[].variants[].manifest back to preview_creative for a post-flight re-render, retaining creative_id, variant_id, and manifest lineage. Do not claim pixel-identical replay unless the renderer explicitly guarantees it.
Run at least one context-rendered or conversational format and one multi-format, locale, or placement-eligibility mismatch. The matching path must preserve its preview-to-delivery identity; the mismatch path must reject before serve and leave auditable evidence rather than silently substituting another format.

​
What may still change

The 3.2.0 milestone is the live scope record for work that may still land during the beta cycle. Use these maintained GitHub views instead of a copied issue list: Milestone assignment means candidate for the 3.2 line, not a commitment to the next beta or GA. A change is included in a beta only when it is merged before that beta’s tag. Items may be deferred, split, or moved to a later release as working groups resolve scope and interoperability risk.

​
Known beta boundaries

  • Targeting-aware behavior may be present in schemas before every reference or training agent implements it. Capability declarations remain authoritative.
  • Experimental surfaces retain their experimental-status contract. A 3.2 beta does not graduate them to stable.
  • The 3.2-beta documentation selector moves forward; pinned semver artifacts and documentation snapshots remain immutable.
  • Stable schema aliases continue to resolve to stable releases during beta. Use pinned prerelease URLs when validating beta behavior.

​
Report useful feedback

Include this information in a beta issue:
  • protocol artifact version and wire pin;
  • SDK name/version, or raw wire;
  • buyer, seller, creative, signals, brand, measurement, or governance role;
  • transport and task name;
  • schema path or JSON Pointer involved;
  • expected and actual behavior;
  • minimal redacted payload and validation error;
  • whether the problem blocks beta.3 interoperability.
Never include credentials, signed URLs, bearer tokens, private keys, or live customer payloads.