> ## 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.
# AdCP 3.2 prerelease program
> How to test the current AdCP 3.2 release candidate with an exactly matched SDK or signed protocol bundle and report integration feedback.
# AdCP 3.2 prerelease program
**Use the release candidate in development and staging, not production.** New production
integrations should remain on AdCP 3.1 until 3.2 reaches general availability.
Every prerelease is an immutable checkpoint, but later release candidates may
change 3.2 surfaces before GA.
The 3.2 prerelease cycle started with a protocol-first beta checkpoint.
RC.0 is the current protocol checkpoint. TypeScript SDK `14.0.0-beta.31` and
Python SDK `8.0.0b13` consume the signed RC.0 bundle:
| Checkpoint | Purpose | Who should test |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `3.2.0-beta.0` | Canonical schemas, compliance assets, skills, and protocol manifest for SDK implementation | SDK maintainers, code-generator maintainers, raw-wire implementers, and agent teams that can validate without generated 3.2 SDK types |
| `3.2.0-beta.1` | First integration-correction checkpoint | Pinned adopters comparing beta.0 and beta.1 behavior |
| `3.2.0-beta.2` | Second integration-correction checkpoint | Pinned adopters comparing beta.1 and beta.2 behavior |
| `3.2.0-beta.3` | Third integration-correction checkpoint | Pinned adopters comparing beta.2 and beta.3 behavior |
| `3.2.0-beta.4` | Fourth integration checkpoint | Pinned adopters comparing beta.3 and beta.4 behavior |
| `3.2.0-beta.5` | Previous SDK-backed protocol checkpoint | Pinned adopters comparing beta.5 and beta.6 behavior |
| `3.2.0-beta.6` | Previous SDK-backed protocol checkpoint for reporting, CTV, canonical display, and request-signing integration | Pinned adopters comparing beta.6 with later checkpoints |
| `3.2.0-beta.7` | Previous protocol checkpoint for audience activation and external sources, creative delivery and tracker execution, measured-channel reporting, and expanded conformance coverage | Pinned adopters comparing beta.7 and beta.8 behavior |
| `3.2.0-beta.8` | Previous protocol checkpoint for metric-container subsumption conformance and corrected versioned documentation snapshots | Pinned adopters comparing beta.8 and beta.9 behavior |
| `3.2.0-beta.9` | Previous protocol checkpoint for the draft account change feed, inventory-list receipts, inventory delivery identity, seller policy and change rights, and broader conformance coverage | Pinned adopters comparing beta.9 and beta.10 behavior |
| `3.2.0-beta.10` | Previous protocol checkpoint for managed reporting delivery, authenticated principals, audio VAST and DOOH support, programmed channel collections, committed collection selection, and expanded conformance coverage | Pinned adopters comparing beta.10 and beta.11 behavior |
| `3.2.0-beta.11` | Previous protocol checkpoint | Pinned adopters comparing beta.11 and RC.0 behavior |
| `3.2.0-rc.0` | Current protocol checkpoint | SDK-backed, raw-wire, code-generation, and integration testing |
| SDK wave | `@adcp/sdk@14.0.0-beta.31` and Python `adcp==8.0.0b13` embed `3.2.0-rc.0`; Go remains pending | TypeScript and Python adopters, Go maintainers, and early integration teams |
Earlier betas remain useful as pinned implementation checkpoints. For
SDK-backed testing of the current checkpoint, pair TypeScript SDK beta.31 or
Python SDK beta.13 with protocol RC.0. TypeScript SDK beta.29 and Python SDK
beta.12 remain historical pairings for beta.11. Do not combine a newer wire pin
with an SDK generated from an older bundle unless the SDK maintainer documents
forward compatibility.
## Know which version string to use
The artifact version, wire pin, and documentation selector are related but not
interchangeable:
| Surface | beta.0 | beta.1 | beta.2 | beta.3 | beta.4 | beta.5 | beta.6 | beta.7 | beta.8 | beta.9 | beta.10 | beta.11 | RC.0 |
| ----------------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- | ---------------- | ---------------- | ------------- |
| Protocol artifact | `3.2.0-beta.0` | `3.2.0-beta.1` | `3.2.0-beta.2` | `3.2.0-beta.3` | `3.2.0-beta.4` | `3.2.0-beta.5` | `3.2.0-beta.6` | `3.2.0-beta.7` | `3.2.0-beta.8` | `3.2.0-beta.9` | `3.2.0-beta.10` | `3.2.0-beta.11` | `3.2.0-rc.0` |
| Git tag | `v3.2.0-beta.0` | `v3.2.0-beta.1` | `v3.2.0-beta.2` | `v3.2.0-beta.3` | `v3.2.0-beta.4` | `v3.2.0-beta.5` | `v3.2.0-beta.6` | `v3.2.0-beta.7` | `v3.2.0-beta.8` | `v3.2.0-beta.9` | `v3.2.0-beta.10` | `v3.2.0-beta.11` | `v3.2.0-rc.0` |
| `adcp_version` wire pin | `"3.2-beta.0"` | `"3.2-beta.1"` | `"3.2-beta.2"` | `"3.2-beta.3"` | `"3.2-beta.4"` | `"3.2-beta.5"` | `"3.2-beta.6"` | `"3.2-beta.7"` | `"3.2-beta.8"` | `"3.2-beta.9"` | `"3.2-beta.10"` | `"3.2-beta.11"` | `"3.2-rc.0"` |
| Documentation selector | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-beta` | `3.2-rc` |
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-rc.0"` must not silently negotiate to another prerelease,
and a stable `"3.2"` pin must not silently negotiate to a prerelease.
## Use matched SDK prereleases
The TypeScript SDK has exact RC.0 support. The npm
`latest` tag remains on SDK 13, so opt into the preview explicitly:
```bash theme={null}
npm install @adcp/sdk@14.0.0-beta.31
```
SDK 14 includes typed caller and server support for the compact media-buy
lifecycle, the RC.0 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](/dist/docs/3.2.0-rc.1/building/by-layer/L4/choose-your-sdk) for the support
matrix and install guidance.
Python `adcp==8.0.0b13` carries RC.0 schemas and generated types. Its
higher-level caller/server helpers remain role-dependent, so consult the SDK
matrix before treating schema parity as complete L1–L3 coverage.
## Use the RC.0 artifact directly
Download the signed RC.0 protocol bundle rather
than copying schemas from `main` or from the moving `/schemas/3.2.0-rc.1/` path:
```bash theme={null}
curl -fLO https://adcontextprotocol.org/protocol/3.2.0-rc.0.tgz
curl -fLO https://adcontextprotocol.org/protocol/3.2.0-rc.0.tgz.sha256
shasum -a 256 -c 3.2.0-rc.0.tgz.sha256
tar -xzf 3.2.0-rc.0.tgz
```
The extracted `adcp-3.2.0-rc.0/` 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](/dist/docs/3.2.0-rc.1/reference/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-rc.0"` 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 prerelease runner.
**No 3.2 verification badge is currently issued for RC.0.** 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](/dist/docs/3.2.0-rc.1/building/by-layer/L4/choose-your-sdk).
The TypeScript and Python rows name exact RC.0 support with different
higher-layer coverage. Neither implies support
for another checkpoint. 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](https://github.com/adcontextprotocol/adcp/issues). Report
SDK implementation bugs in the SDK's own repository. Accepted protocol fixes
receive a changeset and ship in a later prerelease; published prereleases are never rebuilt
in place.
## Current RC.0 checkpoint
Protocol beta.1 through beta.11 and RC.0 are published. TypeScript SDK beta.31
and Python SDK beta.13 embed the exact RC.0 bundle. Before treating
a test result as RC.0 protocol evidence, confirm that:
* the test uses the signed RC.0 artifact directly;
* both peers advertise `"3.2-rc.0"` before calls use that pin;
* the integration scenarios below run against RC.0 and retain the exact
bundle version;
* copy/paste installation and validation commands have been executed as
published;
* any unsupported Python helper or Go surface is reported as unavailable or
raw-only rather than inferred from schema support.
Later protocol prereleases repeat the same protocol-tag-then-SDK-confirmation flow.
The current SDK pairings do not make future prereleases 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.
Evidence claims should name their boundary. Schema validation, a storyboard
pass, sandbox interoperability, independent interoperability, a production
transaction, and reconciled production delivery are different claims. None
implies the next.
Participants are not expected to publish spend, pricing, campaigns, clients,
or confidential counterparties. A network or interchange that observes AdCP
transactions can, with participant consent, attest to the exact version,
successful task set, environment, channel, lifecycle stage, and observation
window without exposing those commercial details. The
[production-evidence workstream](https://github.com/adcontextprotocol/adcp/issues/7068)
is piloting that model and an implementation matrix that can accept evidence
from multiple independent issuers.
### 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](https://github.com/adcontextprotocol/adcp/milestone/7) is
the live scope record for work that may still land during the release-candidate cycle.
Use these maintained GitHub views instead of a copied issue list:
* [Open 3.2 issues](https://github.com/adcontextprotocol/adcp/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.2.0)
* [Open 3.2 pull requests](https://github.com/adcontextprotocol/adcp/pulls?q=is%3Aopen+milestone%3A3.2.0)
* [Closed 3.2 milestone work](https://github.com/adcontextprotocol/adcp/milestone/7?closed=1)
Milestone assignment means **candidate for the 3.2 line**, not a commitment to
the next prerelease or GA. A change is included in a prerelease only when it is merged
before that prerelease's tag. Items may be deferred, split, or moved to a later
release as working groups resolve scope and interoperability risk.
## Known prerelease 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](/dist/docs/3.2.0-rc.1/reference/experimental-status).
A 3.2 prerelease does not graduate them to stable.
* The `3.2-rc` documentation selector moves forward; `3.2-beta` remains frozen
at beta.11. Pinned semver artifacts and documentation snapshots remain immutable.
* Stable schema aliases continue to resolve to stable releases during prerelease.
Use pinned prerelease URLs when validating prerelease behavior.
## Report useful feedback
Include this information in a prerelease 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 RC.0 interoperability.
Never include credentials, signed URLs, bearer tokens, private keys, or live
customer payloads.
## Related
* [What's New in AdCP 3.2](/dist/docs/3.2.0-rc.1/reference/whats-new-in-3-2)
* [Migrating from 3.1 to 3.2](/dist/docs/3.2.0-rc.1/reference/migration/3-1-to-3-2)
* [Release Notes](/dist/docs/3.2.0-rc.1/reference/release-notes#version-3-2-0)
* [Versions & Compatibility](/dist/docs/3.2.0-rc.1/reference/versions)
* [Choose your SDK](/dist/docs/3.2.0-rc.1/building/by-layer/L4/choose-your-sdk)