Media buy lifecycle - Interchange API

A media buy carries a lifecycle status on the AdCP wire that tells a buyer whether it is delivering, waiting on something, or finished. This page defines each status, explains why a buy a source is still moderating stays pending_creatives, and shows how a buy a source accepts out-of-band resolves through a submitted task.

The AdCP wire status described here is one of three distinct status surfaces a buyer can see for the same buy. They do not replace each other — see Three status surfaces before treating any one as “the” status.

The AdCP media-buy status

When a buyer’s agent calls a storefront’s AdCP agent (create_media_buy, update_media_buy), a confirmed buy carries a per-buy media_buy_status. It is one of seven values:

Status	What it means to a buyer
`pending_creatives`	Accepted, but no approved creative is assigned yet, so it cannot launch. The buy waits here until a creative is approved and attached.
`pending_start`	Accepted with creatives ready, but the flight has not started. It launches automatically when the start date arrives.
`active`	Live and delivering against the flight.
`paused`	Delivery is halted and resumable — by the buyer, or because the buy was created paused.
`completed`	The flight finished or the budget fully delivered. Terminal.
`rejected`	The source declined the buy. Terminal — resubmit only after addressing the reason.
`canceled`	Stopped before completion, by the buyer or the source. Terminal.

There is no pending_approval value in the AdCP media-buy status. Insertion-order signing, governance review, and other pre-issuance steps are not modeled as a buy status — they happen at the task layer, before a media_buy_id exists. See Asynchronous acceptance.

Why a buy reads `pending_creatives`

pending_creatives is the default landing state for a buy that has been accepted but has nothing launch-ready attached. Two distinct situations both surface as pending_creatives:

No creative is assigned yet. The buy exists, but the buyer has not synced or assigned an approved creative to it.
The source is moderating the buy. Some sources accept a buy and then park it for manual review — checking creatives, signing an insertion order, or applying a content policy — before it is launch-eligible. While that review is outstanding the buy is accepted but not launch-ready, and reads pending_creatives.

pending_creatives is not a failure. It means “accepted, not yet launchable.” Resolve it by assigning an approved creative (and, where a source moderates, waiting for that review to clear), not by resubmitting the buy.

Asynchronous acceptance: the submitted task

A source does not always confirm a buy before the response is emitted. When a source accepts a buy out-of-band — parking it for manual moderation, queuing it for batch processing, or awaiting an insertion-order signature — the storefront returns a submitted task envelope instead of a confirmed buy:

{
  "status": "submitted",
  "task_id": "task_8f3c1a90-4d2e-4b77-9c1a-3e9b5d2f0a11",
  "message": "Awaiting manual review by the source."
}

There is no media_buy_id on this response — the buy is not confirmed yet. The buyer resolves it the same way as any async operation: poll the task (the AdCP tasks_get operation) with the task_id, or await a webhook if a push-notification config was attached to the original call. See Tasks for the concrete polling endpoint, webhook setup, and back-off mechanics. submitted and working mean the task is still processing — keep polling. Otherwise it resolves to one of three terminal task states, and the outcome lands on its completion artifact:

Task status	What you get
`completed`	The confirmed `media_buy_id` plus its `media_buy_status` — typically `pending_creatives` or `pending_start` (or `rejected` / `canceled` if the source accepted the buy and then declined or stopped it).
`input-required`	The source needs something more from you before it can finish. Inspect the response and `error.suggestion`, then resubmit the call with the correction. See Tasks.
`failed`	The operation could not complete — including a source that declined the buy outright; the `error` object explains why.

An update_media_buy edit that a source queues for moderation behaves identically: the storefront returns a submitted task envelope, and the edit’s result lands on the task’s completion artifact. The same poll-or-webhook pattern applies.

A submitted envelope is not a confirmation. Do not treat the task_id as a media_buy_id, and do not assume the buy is live until the task completes with a media_buy_status of active.

Cancellation

A buyer cancels a media buy by requesting deletion (the AdCP delete operation or update_campaign with action: delete). What happens next depends on whether the buy has been committed to a source and, if so, whether the inventory is guaranteed.

Retraction: uncommitted buys

When the buy has not been forwarded to a source (no reserved inventory, no live leg), the cancel is a retraction: the pending request is withdrawn and forwarded directly as a cancel. No operator approval is needed. The buy transitions to canceled. Non-guaranteed committed buys (buys that have been forwarded but are not guaranteed delivery) also cancel directly with no approval, following the same path as a retraction.

Cancellation approval: committed guaranteed buys

When the buy is committed and the inventory is guaranteed (the buy has been forwarded and reserved with the source as guaranteed delivery), the cancel requires seller approval. The storefront operator sees the request as an APPROVE_MEDIA_BUY_CANCELLATION item in their approvals queue, and the buy keeps delivering while the operator decides.

Decision	What happens
Approve	The cancel is forwarded to the source and the buy terminates (`canceled`).
Reject	The buy stays `active`. The buyer is notified the cancellation was declined, with the operator’s reason. The buyer may re-request.

A buy with any guaranteed leg is treated as guaranteed for cancellation purposes. There is no partial (per-leg) cancel: approval or rejection applies to the entire buy.

While a cancellation is awaiting the operator’s decision, the buy keeps its normal AdCP status and continues delivering. The wait is surfaced as a pendingReason of awaiting_cancellation_approval, not as a status change.

If the forward to the source fails when the operator approves, the buy is not marked canceled. The work item moves to BLOCKED with the failure reason, and the operator can retry. The platform never strands a live order by marking it canceled before the source confirms.

Buy state	Cancellation behavior
Not committed (no forwarded leg)	Retraction: forwarded directly as a cancel, no approval.
Committed, non-guaranteed	Direct cancel: forwarded to the source immediately, no approval.
Any guaranteed committed leg	Cancellation approval: operator decides; buy keeps delivering until approved or rejected.

`pendingReason`: whose side owns the wait

Statuses say that a buy is waiting; they do not say on whom. For storefront-routed buys the platform derives a pendingReason annotation from its forwarding records — per source leg, rolled up to the most-blocking wait — and surfaces it on the buyer’s read surfaces (GET /media-buys/:mediaBuyId, the nested media buy in GET /campaigns/:id, and the status poll as pending_reason).

pendingReason is an annotation, never a status. AdCP’s media-buy status is a closed enum and pre-issuance review is deliberately not a status value — these reasons explain a wait without changing any status field.

`pendingReason`	Who owns the wait	Meaning
`awaiting_storefront_approval`	Seller	The storefront operator has your buy in their review queue
`awaiting_cancellation_approval`	Seller	The buyer requested cancellation of a committed guaranteed buy; the storefront operator is deciding whether to approve (terminate) or reject (keep active)
`awaiting_source_moderation`	Seller	The inventory source accepted the buy asynchronously and is still moderating it — no upstream buy exists yet (task-layer wait)
`creative_processing_at_source`	Seller	The upstream buy exists; the source is processing/moderating its creatives before it is launch-eligible
`awaiting_creative_approval`	Seller / You	The upstream buy exists and waits on creative approval or assignment
`forward_failed_retrying`	Platform	Forwarding to the source failed transiently; the platform is retrying
`forward_failed_needs_correction`	Platform	Forwarding failed structurally; a correction is needed before it can be retried — see `errorCode`
`accepted_awaiting_trafficking`	Seller	Accepted end-to-end; the source has not started trafficking it yet
`scheduled_not_started`	Nobody	Everything is booked; the flight start date has not arrived

pendingSince accompanies the reason with when the current wait began. When a wait turns into a failure or rejection, the buyer-safe errorCode (and the source’s sanitized message) carries the why — see the error-code table.

Three status surfaces

The same buy can be described by three different status vocabularies depending on which surface you read. They answer different questions and use different value sets — keep them distinct.

Surface	Field	Value set	What it describes
AdCP per-buy (this page)	`media_buy_status`	`pending_creatives`, `pending_start`, `active`, `paused`, `completed`, `rejected`, `canceled`	One buy’s lifecycle on the AdCP wire.
AdCP account rollup	`operational_status`	`no_media_buys`, `draft`, `pending_creatives`, `pending_start`, `active`, `paused`, `completed`, `attention_required`	An account-level rollup across all of a buyer’s buys. `no_media_buys`, `draft`, and `attention_required` are rollup-only.
Interchange buyer rollup	`status`	`DRAFT`, `PENDING_APPROVAL`, `INPUT_REQUIRED`, `ACTIVE`, `PAUSED`, `COMPLETED`, `CANCELED`, `FAILED`, `REJECTED`, `ARCHIVED`	The higher-level Interchange campaign and media-buy rollup. See Media Buy → Status.

The Interchange buyer rollup is a coarser, derived view of the AdCP per-buy status — not an independent one. Each AdCP value maps to one Interchange value, and pending_creatives and pending_start both collapse to PENDING_APPROVAL:

AdCP `media_buy_status`	Interchange `status`
`pending_creatives`, `pending_start`	`PENDING_APPROVAL`
`active`	`ACTIVE`
`paused`	`PAUSED`
`completed`	`COMPLETED`
`rejected`	`REJECTED`
`canceled`	`CANCELED`

For a multi-agent campaign the rollup also surfaces the most restrictive value across agents (see Most-restrictive rule), so a campaign with one pending_creatives buy and one active buy reports PENDING_APPROVAL. Interchange also has states from its own flow that no AdCP wire value maps to — DRAFT (before execution), INPUT_REQUIRED, FAILED, and ARCHIVED.

For the Interchange rollup and how to poll it, read Get media buy status. The adcp_status field on that response carries the raw AdCP wire status this page defines.

Media Buy

The media-buy object and the Interchange rollup status table

Tasks

Polling, webhooks, and back-off for the submitted task envelope

Get media buy status

Poll live AdCP status across sales agents

Glossary

One-line definitions of every v2 term

​The AdCP media-buy status

​Why a buy reads pending_creatives

​Asynchronous acceptance: the submitted task

​Cancellation

​Retraction: uncommitted buys

​Cancellation approval: committed guaranteed buys

​pendingReason: whose side owns the wait

​Three status surfaces

​Related

Media Buy

Tasks

Get media buy status

Glossary

The AdCP media-buy status

Why a buy reads `pending_creatives`

Asynchronous acceptance: the submitted task

Cancellation

Retraction: uncommitted buys

Cancellation approval: committed guaranteed buys

`pendingReason`: whose side owns the wait

Three status surfaces

Related