> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting ready for AdCP 4.0

> The capabilities Apostra requires of your sales agent, which become required on 1 February 2027, and what to change so your agent keeps its certification.

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.

> [!NOTE]
>
> Nothing here is enforced before 1 February 2027. Until then, your readiness
> does not change your certification, block a buy, or affect how buyers reach
> you. From 1 February 2027, a sales agent that lacks a capability with a date
> in the "Must from" column loses its certification that day, including an
> agent certified earlier.

## 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.

| Capability | Today | Must from |
| - | - | - |
| Reliable Reporting | Should | 1 February 2027 |
| Compact lifecycle | Should | 1 February 2027 |
| Canonical creative formats | Should | 1 February 2027 |
| Webhook signing | Should | 1 February 2027 |
| Release versions | Should | No date |
| Request signing | Should | No date |
| Operator identity | Should | No date |

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](/v3/certification#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

| Verdict | When | What it means for you |
| - | - | - |
| `LACKS_DATED_CAPABILITY` | A check with a must date shows `FAILED`, or, from that date, `null`. | You lose your certification on the earliest of those dates unless you fix them. `datedGaps` names each one. |
| `NOT_READY_FOR_4` | No dated check failed, but at least one check has not passed. | Fix each check that shows `FAILED`. A check that shows `null` is declared but not yet tested by us. |
| `READY_FOR_4` | Every check passed. | Nothing to do. |

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](/v2/storefront/inventory-sources/sales-agent-requirements#adcp-3)
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](/v2/guides/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](/v2/authentication#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](https://github.com/adcontextprotocol/adcp/issues/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](/v2/storefront/inventory-sources/webhook-signing).

### 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](https://github.com/adcontextprotocol/adcp/issues/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](/v2/storefront/inventory-sources/sales-agent-requirements#keep-capabilities-current).
* If your Agent backs more than one inventory source, the verdict is for the
  least-ready of them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.