Schema access
AdCP schemas are available from two sources:
Both sources contain identical schemas. The GitHub repository includes all released versions with bundled schemas committed directly to the codebase.
One-shot protocol bundle
Syncing hundreds of individual schema files adds up. Every AdCP release also publishes a single gzipped tarball containing the complete protocol — schemas, compliance storyboards, and the OpenAPI registry — so clients can pull one artifact instead of crawling the tree.
Every tarball extracts into a single
adcp-{version}/ directory (safe extraction, no tarbomb). Inside:
@adcp/sdk sync-schemas command uses this under the hood.
Available tarballs are also listed at /protocol/.
Verifying protocol bundle signatures
The SHA-256 sidecar lives on the same origin as the tarball, so it only protects against in-transit tampering. For supply-chain protection — proving the bundle came from the AdCP release workflow and was not swapped for a malicious one even if the host were compromised — every released{version}.tgz is also published with a Sigstore detached signature.
The signature is produced by the GitHub Actions release workflow using keyless OIDC: there is no long-lived AdCP signing key to leak. The certificate binds the signature to the workflow identity that issued it.
cosign verify-blob exits non-zero if the signature was made by anything other than the AdCP release workflow, even if the SHA matches and TLS is valid. Use this in any pipeline that ingests the protocol bundle as an enforcement source. The @adcp/sdk, adcp-client-python, and adcp-go SDKs perform this verification automatically when the sidecars are present.
The refs/(heads|tags)/.* wildcard is intentional — releases sign during the push-triggered workflow run, so the cert subject names the release branch (e.g. refs/heads/3.0.x for v3.0.1+, refs/heads/main for v3.0.0). The trust gate is upstream release.yml’s on.push.branches allowlist, not the consumer’s regex. Literal-allowlist regexes ((main|2\.6\.x)-style) silently break every time a new maintenance branch is added — see Verifying protocol tarballs for the full trust model and the cert-subject-by-release lookup.
Older releases that predate signing, and versions republished out of band (bypassing the signing workflow), remain checksum-only — clients should treat missing sidecars as a “checksum-only” trust level rather than a verification failure.
Compliance storyboards
Storyboards live alongside schemas at/compliance/{version}/. They define the test scenarios AAO runs to verify an agent’s capability claims.
Declare
supported_protocols (for protocol baselines) and specialisms (for narrow capability claims) in get_adcp_capabilities — the compliance runner executes the matching bundles to verify. See the full Compliance Catalog for every protocol and specialism an agent can claim.
Common schemas
Schema versioning
AdCP uses semantic versioning. Choose the right path for your use case:
The same version semantics apply to
/schemas, /compliance, and /protocol/{version}.tgz — one release cuts all three.
Production (recommended)
Pin to an exact version for stability:Development
Use the major version alias to stay current with backward-compatible updates:SDK type generation
Bundled schemas
For tools that don’t support$ref resolution, use bundled schemas with all references resolved inline. Bundled schemas are available from both the website and GitHub:
Website access
GitHub access
Bundled schemas are committed to the repository atdist/schemas/{VERSION}/bundled/:
Directory structure
Bundled schema categories
All request/response task schemas are bundled:
See the schema registry for all available schemas.
Version discovery
Registry API
The AgenticAdvertising.org registry provides a public REST API for brand resolution, property resolution, agent discovery, and authorization validation. No authentication required.Registry API Reference
Resolve brands, discover agents, and validate authorization via REST.