Skip to main content
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:
StatusWhat it means to a buyer
pending_creativesAccepted, but no approved creative is assigned yet, so it cannot launch. The buy waits here until a creative is approved and attached.
pending_startAccepted with creatives ready, but the flight has not started. It launches automatically when the start date arrives.
activeLive and delivering against the flight.
pausedDelivery is halted and resumable — by the buyer, or because the buy was created paused.
completedThe flight finished or the budget fully delivered. Terminal.
rejectedThe source declined the buy. Terminal — resubmit only after addressing the reason.
canceledStopped 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 statusWhat you get
completedThe 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-requiredThe 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.
failedThe 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.

​
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.
SurfaceFieldValue setWhat it describes
AdCP per-buy (this page)media_buy_statuspending_creatives, pending_start, active, paused, completed, rejected, canceledOne buy’s lifecycle on the AdCP wire.
AdCP account rollupoperational_statusno_media_buys, draft, pending_creatives, pending_start, active, paused, completed, attention_requiredAn account-level rollup across all of a buyer’s buys. no_media_buys, draft, and attention_required are rollup-only.
Interchange buyer rollupstatusDRAFT, PENDING_APPROVAL, INPUT_REQUIRED, ACTIVE, PAUSED, COMPLETED, CANCELED, FAILED, REJECTED, ARCHIVEDThe 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_statusInterchange status
pending_creatives, pending_startPENDING_APPROVAL
activeACTIVE
pausedPAUSED
completedCOMPLETED
rejectedREJECTED
canceledCANCELED
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