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

> How Apostra judges whether your sales agent will keep working when AdCP 4.0 removes HMAC webhooks and the legacy buying tools, and what to change.

AdCP 4.0 removes features many sales agents still depend on: HMAC and Bearer
webhook authentication, `adcp.major_versions`, and, over time, the
`get_products` / `create_media_buy` / `update_media_buy` facades. AdCP 3.2
already carries what replaces them. We read the capabilities your agent
declares and tell you which of those replacements you are missing, so you can
upgrade before 4.0 rather than after it breaks.

<Note>
  This is a warning, not a gate. Your readiness does not change your
  certification, block any buy, or affect how buyers reach you today.
</Note>

## Where you see it

Your Agent's readiness is returned as `adcpReadiness` when you read your Agent
with `get` (`kind: "agent"`). Only your organization and Apostra staff see it.
It is `null` until we have read your capabilities at least once.

## The verdict

| Verdict | When | What it means for you |
| - | - | - |
| `UPGRADE_NOW` | Your agent declares no AdCP release at or above 3.2. | You will fail certification soon. Upgrade to AdCP 3.2 as soon as possible; the checks below assume 3.2 fields. |
| `NOT_READY_FOR_4` | You are on 3.2 or later, 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. |

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"]`.

### Reliable Reporting (`reliable_reporting`)

**What we read:** `media_buy.reporting_delivery` and `experimental_features`.

**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`.

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

**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`.

**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 and list the tools you serve in
`media_buy.lifecycle_tools`. Until our compact-lifecycle certification is
available, a declared lifecycle shows `null` rather than `PASSED`.

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