Getting ready for AdCP 4.0

AdCP 4.0 removes features many sales agents still depend on: HMAC and Bearer webhook authentication, adcp.major_versions, the exact format_ids creative fields, and, over time, the get_products / create_media_buy / update_media_buy facades. AdCP 3.2 already carries what replaces them. We require capabilities, not protocol releases: an agent can deliver a capability on AdCP 3.2 or 3.3, and what matters is that it supports it well. We read the capabilities your agent declares and tell you which ones you are missing, and by when, so you can fix them before 4.0 rather than after it breaks.

​

The schedule

Every capability is a should today. A should with a date becomes a must on that date. A should without a date is advice with no deadline. If we require another capability, it will appear in this table, with its date, before it is enforced. A must means proven, not declared. From 1 February 2027, a capability with a date that we have not yet proved counts as missing. We prove each one differently:

• Reliable Reporting and webhook signing: a complete, valid declaration passes.
• Canonical creative formats: we have read your products, and every one carries canonical format_options.
• Compact lifecycle: you pass our compact-lifecycle certification. Declaring the tools is not enough, and that certification is not available yet.

Agents certified before 1 February 2027 lose their certification on that date if they lack a capability with that date. They do not keep it until their next certification run. To keep it, have the capability in place, and declared, before then. We read the capabilities we last stored, and Capabilities last read on the Agent page shows when. Certification is what unlocks the Successful transaction go-live step; see What a pass unlocks.

​

Where you see it

• Agent page, Overview tab. A sales Agent that lacks a capability with a must date shows a notice that names each missing capability and its date. An Agent that has them all but is not ready for 4.0 shows a shorter notice. Both link to this page. A ready Agent shows nothing.
• Agent page, Test Agent tab. The full verdict: every check, whether it passed, whether it is a should or a must and from when, what we found, and what to change for each check that failed.
• API. Read your Agent with get (kind: "agent"); the verdict is in adcpReadiness. Each check carries requirement (SHOULD or MUST) and mustFrom (a YYYY-MM-DD date, or null), and datedGaps lists the dated checks you are missing: those that failed, and, from their date, those we have not yet proved (status is null).

Only your organization and Apostra staff, including support acting for your organization, see it. There is no verdict until we have read your capabilities at least once (adcpReadiness is null).

​

The verdict

The verdict follows the schedule, not your AdCP release number. An agent on AdCP 3.3 that lacks Reliable Reporting is flagged, and an agent on 3.2 that has every dated capability is not. No agent can reach READY_FOR_4 yet. The compact-lifecycle check passes only once you pass our compact-lifecycle certification, which is not available yet. When the AdCP release that carries the rest of 4.0 ships, we will add its checks to this page. Each check in adcpReadiness.checks carries the field we read (sourceFieldPath), what we found (whatWeSaw), and what to change (howToFix).

​

The checks

​

Release versions (supported_versions)

What we read: adcp.supported_versions. Why it matters: AdCP 4.0 removes adcp.major_versions. Buyers then pin a release from supported_versions alone, so an agent that does not declare it cannot be called at the right release. To pass: list every release you speak, for example ["3.1", "3.2"]. Keep sending adcp.major_versions as well. AdCP 3.x still requires it, and an agent that drops it fails the AdCP 3 requirement today.

​

Reliable Reporting (reliable_reporting)

What we read: media_buy.reporting_delivery and experimental_features. Required from: 1 February 2027. This check reads what your agent declares, whether or not buyers can use Reliable Reporting yet. Why it matters: Reliable Reporting is how a buyer learns, from an authoritative record, whether a report is due, complete, or late. It is the AdCP 3.2 reporting contract that 4.0 builds on. To pass: declare a complete media_buy.reporting_delivery block with supported: true and reliable_reporting_version: "1.0", and list "media_buy.reporting_delivery" in experimental_features.

​

Request signing (request_signing)

What we read: request_signing. Why it matters: AdCP 4.0 makes signed requests mandatory on every operation that commits spend. Apostra already signs the requests it sends you; Verifying our signed requests explains how to check them. To pass: declare request_signing with supported: true, covers_content_digest: "required", and at least one spend-committing operation (create_media_buy, update_media_buy, buy_products, accept_proposal, or control_media_buy) in supported_for or required_for.

​

Webhook signing (webhook_signing)

What we read: webhook_signing. Required from: 1 February 2027. Why it matters: AdCP 4.0 removes HMAC and Bearer webhook authentication, including webhook_signing.legacy_hmac_fallback. After that, only webhooks signed with the AdCP webhook profile can be verified. Reporting webhooks depend on AdCP 3.3 relaxing their required authentication block (adcontextprotocol/adcp#8176). To pass: sign the webhooks you send and declare webhook_signing.supported: true. If you declare profile, it must be adcp/webhook-signing/v1. See Signing the webhooks you send us.

​

Operator identity (operator_identity)

What we read: identity.brand_json_url. Why it matters: buyers find your signing keys through your brand.json. AdCP 4.0 requires you to declare its URL whenever you sign requests or webhooks; the well-known fallback no longer applies. To pass: publish a brand.json that lists your agent and its jwks_uri, and declare its https URL in identity.brand_json_url.

​

Compact lifecycle (compact_lifecycle)

What we read: media_buy.lifecycle_tools. Required from: 1 February 2027. Why it matters: the AdCP 3.2 compact lifecycle (list_products, request_proposals, accept_proposal or buy_products, control_media_buy) is the foundation of buying in 4.0. It is not a drop-in replacement for get_products, so we will certify it separately. To pass: implement the compact lifecycle, list the tools you serve in media_buy.lifecycle_tools, and pass Apostra’s compact-lifecycle test against your sandbox; its latest decisive result decides PASSED or FAILED. Until Apostra has run that test, a declared lifecycle shows null, and from 1 February 2027 that counts as missing. Apostra does not run the test yet.

​

Canonical creative formats (canonical_creatives)

What we read: media_buy.features.canonical_creatives, and the AdCP releases in adcp.supported_versions. Required from: 1 February 2027. Why it matters: AdCP 4.0 removes the deprecated exact format_ids fields (adcontextprotocol/adcp#7629). A canonical creative format is named by a format_kind and its params, with no agent URL. Once format_ids is gone, an agent that cannot take canonical formats cannot be told which creative format a buy uses, and its buys and creative syncs fail. To pass: publish canonical format_options (format_kind and params) on every product, accept format_kind selectors on create_media_buy and sync_creatives, and declare media_buy.features.canonical_creatives: true. A product passes if it carries canonical format_options; it may also keep format_ids for AdCP 3.x buyers until 4.0. How we check it today: two things must hold. Your declaration: an agent whose highest declared release is 3.2 or later passes unless it declares media_buy.features.canonical_creatives: false, and an agent on an earlier release, or one that declares no precise release, passes only if it declares true. And your products: every product we stored must carry canonical format_options. One product with only legacy format_ids fails the whole check, so a 3.2 agent that publishes only format_ids fails, and so does a catalogue that mixes the two; the finding says how many products need changing. If your declaration passes but we have not read your products yet, the check shows null, and from 1 February 2027 that counts as missing.

​

How we read your agent

• We read the capabilities we last stored from your get_adcp_capabilities response, and each block must be valid under the AdCP 3.2 schema to pass. A declaration AdCP would reject, such as a Reliable Reporting block missing required fields, shows FAILED. We never call your agent to compute the verdict. capabilitiesRefreshedAt says when we last read them. See Keep capabilities current.
• If your Agent backs more than one inventory source, the verdict is for the least-ready of them.