> ## 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 beta program
> How to test AdCP 3.2 beta.0 before SDK support, prepare SDKs from the signed protocol bundle, and complete beta.1 protocol and SDK convergence.
# 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 deliberately publishes the protocol before its SDKs:
| 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 |
| SDK wave | SDKs ingest the signed beta.0 tarball and publish exact support statements | TypeScript, Python, and Go maintainers and early adopters |
| `3.2.0-beta.1` | Pull integration corrections into the protocol; a second SDK refresh then establishes exact beta.1 support | Buyer and seller teams running end-to-end integrations, followed by SDK maintainers |
Beta.0 is not waiting for the SDKs. Beta.1 is a two-stage convergence point:
publish the corrected protocol checkpoint, then have SDKs ingest that exact
bundle. Call beta.1 SDK-backed only after the matching SDK versions and
integration evidence are published.
## Know which version string to use
The artifact version, wire pin, and documentation selector are related but not
interchangeable:
| Surface | beta.0 | beta.1 |
| ----------------------- | --------------- | --------------- |
| Protocol artifact | `3.2.0-beta.0` | `3.2.0-beta.1` |
| Git tag | `v3.2.0-beta.0` | `v3.2.0-beta.1` |
| `adcp_version` wire pin | `"3.2-beta.0"` | `"3.2-beta.1"` |
| Documentation selector | `3.2-beta` | `3.2-beta` |
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.0"` must not silently negotiate to beta.1, and a
stable `"3.2"` pin must not silently negotiate to a beta.
## Test beta.0 without an SDK
Once `v3.2.0-beta.0` is published, download the signed protocol bundle rather
than copying schemas from `main` or from the moving `/schemas/3.2.0-beta.0/` path:
```bash theme={null}
curl -fLO https://adcontextprotocol.org/protocol/3.2.0-beta.0.tgz
curl -fLO https://adcontextprotocol.org/protocol/3.2.0-beta.0.tgz.sha256
shasum -a 256 -c 3.2.0-beta.0.tgz.sha256
tar -xzf 3.2.0-beta.0.tgz
```
The extracted `adcp-3.2.0-beta.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-beta.0/reference/verifying-protocol-tarballs) for
the certificate-identity and issuer checks.
At beta.0, useful 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.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 beta runner.
**No 3.2 verification badge is issued from beta.0.** The protocol-first cut is
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-beta.0/building/by-layer/L4/choose-your-sdk).
Until a row names beta.0 support, treat that SDK's generated 3.2 types and
validators as unavailable. 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 beta.1; beta.0 is never rebuilt in place.
## beta.1 convergence
The beta.1 protocol checkpoint is ready to cut when:
* every first-party SDK's beta.0 support is marked supported, partial, or
unavailable with an exact package version;
* accepted beta.0 protocol feedback is merged;
* the integration scenarios below have run against beta.0 and identify any
correction included in the beta.1 candidate;
* copy/paste installation and validation commands have been executed as
published;
* the cumulative migration guide and release notes describe any beta.0-to-beta.1
correction that requires adopter action.
After `3.2.0-beta.1` is published, SDK maintainers ingest that signed bundle and
publish an exact beta.1 support statement or an explicit unsupported/partial
result. The public compatibility matrix then names the package, supported
roles, install command, and validation command. Only after the matching
buyer/seller and generative scenarios pass is beta.1 the SDK-backed ecosystem
checkpoint.
Do not combine an SDK generated from beta.0 with a beta.1 wire pin unless that
SDK explicitly documents forward compatibility.
## 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](https://github.com/adcontextprotocol/adcp/milestone/7) 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:
* [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
beta.1 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](/dist/docs/3.2.0-beta.0/reference/experimental-status).
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.1 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-beta.0/reference/whats-new-in-3-2)
* [Migrating from 3.1 to 3.2](/dist/docs/3.2.0-beta.0/reference/migration/3-1-to-3-2)
* [Release Notes](/dist/docs/3.2.0-beta.0/reference/release-notes#version-3-2-0)
* [Versions & Compatibility](/dist/docs/3.2.0-beta.0/reference/versions)
* [Choose your SDK](/dist/docs/3.2.0-beta.0/building/by-layer/L4/choose-your-sdk)