> ## 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. # v3 Preview Limitations > Compatibility, lifecycle, and operational limits of the v3 preview. Commercial identity setup has a [text-only workflow](/v2/setup/v3/identity-setup). Public brand lookup and advertiser linking cannot create, edit or publish `brand.json`, or refresh a saved snapshot in place. Buyer AAO OAuth proof has no portable v3 initiation or callback flow; v3 can inspect its evidence or file a support ask. Seller domain review progress is available through `get({ kind: "seller", include: ["identity"] })`. Organisation names, login domains, members and roles remain outside the commercial identity tools. Identity confirmation is opt-in for operator saves and corrections to an existing advertiser's brand through `identityContract: "confirmed-v1"`. Earlier payloads retain their existing behaviour; this release does not require those clients to adopt the new confirmation exchange. ## Availability and compatibility * v3 is available to every authenticated Buyer and Seller Account. * v2 remains the stable default and is not deprecated. * v3 is intentionally an agent-facing MCP contract, not a REST-version replacement. `/api/v3/documents` is limited to authenticated exact reads and downloads of approved public immutable agreement revisions. Discovery, comparison, private documents, and governing-agreement selection are not yet REST resources; other integrations should continue to use the stable v2 REST APIs. * The unversioned buyer and seller MCP aliases continue to resolve to stable v2. * Organisation accounts currently provide navigation and shared tools, not an organisation-specific noun catalog. * The active account still determines which buyer or seller catalog appears. `get_status` and `switch_account` remain available in an unclassified account so a session can orient and move to a Buyer or Seller Account. No domain catalog is implied by a successful connection to an unclassified account. ## Buyer limitations The Buyer surface supports advertiser and campaign authoring, creative management, proposal requests, media-buy staging, and explicit campaign launch. The following gaps remain: | Capability | Current behavior | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Creative generation | v3 can save and attach a finished creative, including audio, but it does not generate or revise the content. Generate externally and hand off the approved asset. | | End-to-end workflow orchestration | v3 exposes the typed buying tools; the integrating application or its external agent owns durable workflow state, retries, and human checkpoints. There is no hosted end-to-end orchestrator in the preview. | | Buyer-agent orchestration | External buyer-agent identity, credentials, exact advertiser access, and machine-notification administration are available through the buyer console and stable v2 API. A public v3 `buyer_agent` noun and hosted runtime are not in the current v3 catalog; treat them as unavailable until advertised by `tools/list`. | | Campaign cancellation | `desiredPhase: "canceled"` requires the current `expectedRevision` and cancels only a campaign with no executable or unsettled media buys. It never cascades to children; the response names every blocker so you can explicitly cancel or settle it first. If its response is lost, re-read the campaign and retry with its committed revision to receive the terminal state. Archive remains a separate visibility operation. | | Campaign restore | `isArchived: false` restores an archived campaign as a **draft**: its media buys were retired when it was archived, so inventory must be staged again before launch | | Campaign autonomy | Accepted for forward compatibility but not persisted | | Clear campaign brief or flight | `null` is currently a no-op, not a clear operation | | Proposal evaluation policy | Instructions and policy fields are recorded but not applied to ranking | | Media-buy creation flight | `save_media_buy` accepts `flight` when staging from products or accepting a proposal. A specific `startAt` must be a future UTC-day datetime; use `"asap"` to start immediately. | | Media-buy top-level budget | `budget` is accepted when staging from products, accepting a one-allocation proposal, or updating a draft when the resulting buy has one product. Direct multi-product creation and updates use `products[].budget` per product; multi-allocation proposals retain their allocation. | | Proposal settlement and routing | One `save_media_buy` proposal acceptance creates one media buy. All proposal allocations must resolve to one settlement currency and seller route; a proposal spanning currencies or seller routes is rejected before it is claimed or staged. Request separate proposals by currency or seller route. | | Adding a product to a staged buy | Not supported by the update path; stage a new media buy (or archive the draft with `isArchived: true` and stage again) | | Same product staged twice on one buy | Each line item on a media buy read carries a `lineItemRef`; pass it as `products[].lineItemRef` to change or remove exactly that line item. Without it, an update to a repeated product is refused as ambiguous | | Changing a line item's pricing option | Draft only. `products[].pricingOptionId` must be one of the product's published options; moving to a fixed-price option clears a stale bid unless `bidPrice` is sent in the same call | | Meta Sales conversion tracking | Meta requires a Pixel/Dataset for Sales campaigns, and for some Traffic campaigns depending on optimization goal. Pass it as `products[].pixelId`. There is no auto-select, even when the connected ad account has exactly one authorized Pixel/Dataset — every such buy must name it explicitly. A missing or unauthorized ID fails with the candidate Pixel/Dataset IDs to choose from. | | Media-buy archive | `isArchived: true` archives a **draft** only; a dispatched buy is cancelled through the campaign or the v2 update contract | | Media-buy restore | `isArchived: false` is not supported; an archived buy is retired for good | | Buyer media-buy archive state | Reads currently project `isArchived: false`; use v2 when authoritative archive state is required | | Proposal evidence on media-buy reads | Preserve `proposalSource` from the acceptance response; later Buyer reads do not include it | | Tracked campaign adoption | Use the existing v2 adopt or duplicate workflow | | Tracker delivery and rendered preview | Advertiser and campaign tracking configuration, inheritance, and headless `test_creative_macros` reports are available; attaching effective trackers to outbound creatives and rendering the report inside creative review remain follow-up work | Launching is supported, but only as a separate, two-call update to an existing campaign: a preview with `desiredPhase: "active"` and no `confirmLaunch` returns the campaign revision and what would launch; the confirm call sends `confirmLaunch: true` with that `expectedRevision`. Both calls require their own `idempotencyKey`. See [Launch a campaign with explicit confirmation](/v2/setup/v3/tool-reference#launch-a-campaign-with-explicit-confirmation). A failed launch may report a partial write because downstream execution state was attempted. Re-read before retrying. ## Seller limitations * Every Media Company account can use `save_advertiser`, `save_campaign`, `save_creative`, `save_creative_collection`, `request_proposals`, and `save_media_buy` directly from its Seller account. Sandbox Advertisers are available to every Media Company. Live Advertisers and campaigns are available only to organizations enrolled in the `amc-campaign-management` rollout. Every operation is pinned server-side to that company's own Storefront. A missing, foreign, or wider Storefront, Proposal, qualified Product, or existing MediaBuy scope is rejected before dispatch. * Integrated `search`/`get` can list and read authorized sandbox or live Advertisers, scoped Campaigns, Creative, Creative Collections, Proposals, and buyer-side MediaBuys. `get(kind: "seller", id, advertiserId, include: ["products"] )` opens the company's own wholesale catalog, so callers can pass qualified Products directly to `save_media_buy` without requesting Proposals. When a Product advertises `signal_targeting_options`, its eligible Signals can be selected through `products[].targetingOverlay`. * The live rollout changes account access only. Live campaign launch still requires ordinary source currency compatibility, account mapping, publisher authorization, creative approval, funding, standing, and any seller-side approval. No sandbox or publish-validation bypass applies to live traffic. * Seller `search(kind: "media_buy", filter: { campaignId })` or `filter: { advertiserId }` selects the integrated Buyer projection. Omitting both selects the Seller inventory/execution projection. * Seller Accounts use the left rail to move between Inventory, Advertisers, Buyers, and Agents. Setup progress appears on Inventory. Advertisers lists the account's sandbox Advertisers, plus live own-supply Advertisers once the account is enrolled in `amc-campaign-management`; selecting an Advertiser opens its Campaigns, Creatives, and Reporting work. **Add advertiser** in Advertisers or Campaigns opens the shared Advertiser Setup Task. It creates through `save_advertiser`, refreshes the roster, and can switch directly into the new Advertiser. Sandbox is the only choice unless the account is enrolled for live campaign management. Campaign creation and delivery requests stay in Murph so the same V3 own-supply guards apply. Buyers lists external AdCP counterparties separately; selecting one shows media buys, synced creatives, and Delivery on your inventory for that relationship, plus its account admission case when setup needs attention. Advertisers uses the shared buyer advertiser picker and work rail for the accounts the seller operates; protected System accounts are read-only. Marketplace, Connections, Buyer Setup, and unbound production Advertisers are not part of this preview. * Shared Page hydration permits only three Seller-key Buyer REST reads: the Advertiser roster (sandbox by default; live only when enrolled in `amc-campaign-management`), Campaign listing for an explicitly bound Advertiser in either environment with wider-supply rows removed, and that Advertiser's promoted Creative list in read-only mode. Buyer REST detail, mutations, and reporting remain unavailable to Seller keys. The Advertiser Setup Task writes through the public V3 `save_advertiser` contract instead. * Portable callers can use `get_delivery({ report: "campaign_delivery" })` with explicit metrics, dimensions, a date range of at most 90 inclusive days or `range: { lifetime: true }`, and optional advertiser, campaign, or media-buy filters. A `packageId` filter requires a bounded date range (not lifetime), because the reporting operation fetches all campaign data before filtering by package. Integrated Media Companies must name an own-supply advertiser, campaign, or media buy. * Some credential, payout, approval, retry, and reassignment work intentionally remains in Pages rather than model-authored tools. * `save_media_kit` remains for compatibility but is deprecated; new clients should author Listing identity through `save_seller`'s `listing` field. `get`/`save_media_kit`'s deprecated `kind`/field is now canonically spelled `listing`, with `media_kit`/`mediaKit` accepted as deprecated aliases for the same handler. * Seller delivery is seller-reported. It is not Buyer measurement and does not establish billing eligibility by itself. ## Catalog and host differences The runtime catalog may be narrower than the tables in these docs because of account kind, permissions, feature rollout, and MCP App visibility. A principal that can reach both Buyer and Seller Accounts instead receives their deduplicated union at connection time, so hosts that cache `tools/list` retain both workflows after an account switch. Tools remain authorized only for the selected account. Always use `tools/list` and `get_status` for the active account. After `switch_account`, clients should process `notifications/tools/list_changed` and call `get_status` again. A stale tool call fails with typed wrong-account guidance rather than crossing the account boundary. ## Payload, connection, and timing limits * Structured responses over 200 KB are truncated as a safety backstop. * One MCP connection is held open for at most 30 minutes; reconnect with the existing session when the client uses sessionful MCP. * A single tool call is also limited to 30 minutes. * Deploys can close connections and eventually interrupt long in-flight calls. * `request_proposals` durably schedules the full eligible cohort. Each background seller attempt has a 30-second bound; terminal result pages carry at most 50 seller outcomes and at most five bounded product projections. Product-heavy sellers continue on the returned cursor. Diagnostic pages carry at most 100 sanitized outcomes. * A returned `productQueryId` stays stageable while the buyer deliberates. The discovery-analytics sweep marks a product query inactive after 60 minutes without activity (`DISCOVERY_SESSION_INACTIVITY_MS`, an infrastructure setting), but `save_media_buy` reopens such a query on first use, so a long deliberation does not lose the offer. A query that was already executed or replaced is refused with `PRODUCT_QUERY_EXPIRED`; call `request_proposals` again. A quoted proposal expires at the seller's own `validUntil` or after 90 days, whichever comes first; `PROPOSAL_EXPIRED` names which window lapsed. * Seller delivery ranges are inclusive and limited to 90 days. Long-running work should use an asynchronous workflow where one is available instead of holding a single MCP call open. ## Direct-client model usage Apostra can observe API calls, server-side model calls, and Murph-hosted turns. It cannot observe the input/output token usage or model cost incurred by an external MCP client's own model. Integrators remain responsible for that client-side budget and telemetry. ## Choosing v2 or v3 Use v3 when: * an account-resolved MCP surface is useful; * the required workflow appears in the current tool catalog; and * the documented preview gaps do not require a v2 continuation. Use v2 when: * the integration requires a stable production contract or REST; * the workflow is listed as incomplete above; or * migration would remove a capability the integration already depends on. No migration is required. A client may keep v2 while evaluating v3 through a separate connector.