​

API v2 Changelog

All notable changes to the Interchange API v2 are documented here.

​

5.1614.1 — November 7, 2026 at 3:51 PM UTC

• If an agent or script of yours still calls these v2 storefront REST routes, move it to V3. The eight routes under /api/v2/storefront are GET /creative-reviews, GET /creative-reviews/{creativeId}, POST /creative-reviews/{creativeId}/evaluate, POST /creative-reviews/{creativeId}/decide, GET /media-buy-approvals, GET /media-buy-approvals/{mediaBuyId}, POST /media-buy-approvals/{mediaBuyId}/evaluate and POST /media-buy-approvals/{mediaBuyId}/decide. On V3, open the Approvals Page with open_approvals to list your pending creative reviews and media-buy approvals, read the pre-screen verdict and decide them. An agent without the Page can list them with search and kind set to work_item, read one with get and kind set to work_item, and approve or reject it with save_work_item. The pre-screen evaluation stays on the Approvals Page. Outside callers keep receiving the same “moved to V3” refusal they have received for every v2 storefront route since 19 October 2026. If you already work through V3 or the seller Pages, nothing changes for you.

​

5.1614.0 — November 7, 2026 at 3:31 PM UTC

• Each docs page for a v2 buyer REST operation now says the v2 buyer API is closed to new clients and switches off on 1 December 2026, and links the guide for moving to V3. Those pages are tagged Deprecated and asked not to be indexed by search engines. The Log event page is unchanged, because that endpoint stays open, and pages that describe V3 tools, the web app, or other v2 APIs (accounts, billing, moderation) are unchanged. The V3 limitations page moved to /v3/limitations, with a redirect from the old address, and it no longer says the v2 buyer API is stable.
• The V3 tool reference moved from /v2/setup/v3/tool-reference to /v3/tool-reference, so it no longer reads as a v2 page. The old address redirects. The set-up-a-campaign skill is now version 1.11.1, which points at the new page; its instructions are otherwise unchanged.

​

5.1613.0 — November 7, 2026 at 2:38 PM UTC

• A supply ask can now say which countries you want to buy a publisher in. save_ask with type: "supply" takes countries, one to 50 country codes such as NL or DE, beside the one domain and channel the ask already names. Filing the same ask again adds countries and never removes one, and the ask you read back lists them, sorted, with an empty list when you named none. To drop a country, withdraw the ask and file it again: a supply ask you withdrew reopens, with exactly the countries in the new filing. Naming no country does not mean every country, and it does not narrow what discovery returns.

​

5.1612.1 — November 7, 2026 at 1:55 PM UTC

• A media buy that is inside its flight and that the seller reports paused, when you did not ask for the pause, now shows as needing attention. The buy’s status read and the campaign’s readiness carry a new blocker, seller_paused_not_requested, whose message says the seller reports it paused and since when. Contact the seller to find out why and have it resumed. A pause you asked for, on the buy or on the campaign, is left alone, and the buy’s own status does not change.
• A behind-pace notice for a package on a managed sales agent now names the seller’s reason (an inventory shortfall forecast or a pacing risk) within one 5-minute snapshot cycle of the seller reporting it. The 5-minute read already carried the seller’s package indicators and we dropped them, so the reason waited for the slower lifecycle read. Packages from other sellers are unchanged, and no read changes.
• Attaching the first creative to a live OpenAI Ads buy no longer leaves the buy paused. Before, Apostra paused the OpenAI campaign while it created the ad, and could then refuse to switch it back on because OpenAI had not yet listed the new ad, so the buy stayed paused and delivered nothing. Now a first creative is added without pausing the campaign. When an update does pause it, for example a bid change sent with the creative, the campaign is switched back on with the new ad counted.

​

5.1611.0 — November 7, 2026 at 1:05 PM UTC

• If you build an agent that registers itself with Apostra, the agent sign-in guide now says what it gets while registration is closed. The activation contract and the setup guide return 503, every call made with an Agent Registration token returns 503 AGENT_REGISTRATION_UNAVAILABLE, and no sandbox is created. Your agent should try again later rather than retry in a loop. The guide also gives one starting host, https://api.apostra.com, and tells your agent to call the endpoint URLs the contract returns, which can name a different Apostra host serving the same API. Apostra’s answers are unchanged; only the documentation changed. If your agent already uses the URLs from the contract, you have nothing to change.
• If an agent or script of yours still calls these v2 storefront REST routes, move it to V3. The twelve routes under /api/v2/storefront are GET /adapter-connections, GET /adapter-connections/{connectionId}/accounts, PATCH /adapter-connections/{connectionId}/accounts/{accountId}/select, POST /adapter-connections/oauth/{providerType}/authorize, POST /agents/{agentId}/capabilities/refresh, POST /agents/{agentId}/oauth/authorize, POST /inventory-sources/{sourceId}/agent-binding, GET /inventory-sources/{sourceId}/powered-by-agent, GET /sponsored-buyers, and POST /sponsored-buyers/{buyerId}/approve, /suspend and /reactivate. On V3, start an ad platform connection with save_connection and authorization set to { "mode": "oauth" }, refresh its accounts with refreshAccounts, choose one with selectedAccountId, and read a connection with get on connection. Read which Agent powers a source with get on inventory_source and include set to poweredByAgent. Re-check an external sales-agent source with refresh_inventory_source_health, or on the Source diagnostics Page, which also checks the Agent’s endpoint, credentials and capability declarations and starts an Agent’s OAuth authorization. The Agent binding route was an API-only preview announced to organization administrators; it is gone, and V3 binds in two ways: register an Agent your organization owns with save_agent and call save_inventory_source with its agentId, or attach it to an existing source that has no Agent link on the Source diagnostics Page. V3 has no tool to list, approve, suspend or reactivate sponsored buyers; use the Buyers page in the Apostra app. Outside callers keep receiving the same “moved to V3” refusal they have received for every v2 storefront route since 19 October 2026. If you already work through V3 or the seller Pages, nothing changes for you.
• Product discovery no longer shows forecasts that ignore your targeting. When you send targeting_overlay with a field other than age, a product whose forecast was built without that targeting comes back without forecast, instead of a number for the seller’s whole footprint. This covers sellers that could not receive your targeting and products served from a storefront’s cached catalog. The response’s incomplete field, with scope forecast, names those sellers, and products from sellers that received your targeting keep their forecast. How your discovery targeting reaches sellers explains when a forecast is left off.
• Your setup checklist now shows when buyers have already asked for inventory on your domains. If buyers have open requests for your seller account domain or a publisher domain you declare, a Buyer demand item says how many buyers asked and for which channels, for example “3 buyers have asked for display and olv on example.com”. It never says who asked. The item is information only: it never blocks going live, and it does not appear when no buyer has an open request. To make sure their requests reach you, check that the channels you sell in include theirs.
• A campaign you planned on Apostra can be edited again if a connected seller account’s sync had marked it as a seller campaign. Before the fix in the previous release, that sync tagged the planned campaign as one it mirrors from the seller, so every edit to the campaign or its media buys was refused. That tag is now removed from every planned campaign that carries it, so you can correct a name or flight the sync changed. Campaigns Apostra creates to show buys you made outside Apostra are unchanged.
• An agent can now read the payer details printed on an organization’s invoices (name, invoice emails, address and tax ID) from the billing read, with a flag that says whether they are complete. It can also propose a change with save_billing: the call writes nothing and returns a link, and a direct administrator of the organization approves the change on Apostra before it takes effect. Nothing changes if you do not use it, and the Payment & invoices form in the Apostra web app still saves directly.

​

5.1610.0 — November 7, 2026 at 12:15 PM UTC

• If an agent or script of yours still calls these v2 storefront REST routes, move it to V3. The five routes under /api/v2/storefront are POST /creative-reviews/{creativeId}/preview, GET /demo, POST /media-buy-approvals/{mediaBuyId}/retry-forward, GET /simulator/scenarios and GET /simulator/scenarios/{scenarioId}. On V3, request a creative’s placement preview on the Approvals Page, which you open with open_approvals. Read your Demo Storefront lease with get on seller, or manage it on the Demo Storefront Page, which you open with open_page and page set to demo_seller. Retry a media buy whose forward did not complete from the Approvals Page or from Pending operations. Read your Merchandising Simulator scenarios on the Merchandising Simulator Page, which the Proposal Pass opens. Outside callers keep receiving the same “moved to V3” refusal they have received for every v2 storefront route since 19 October 2026. If you already work through V3 or the seller Pages, nothing changes for you.

​

5.1609.0 — November 7, 2026 at 11:39 AM UTC

• The Buyers screen now says what the job is: choose which buyers you work with, and which advertiser each one is in your ad server. A “Why this step?” link opens a short page that explains why a buyer waits for your approval and a mapping. The mapping labels now match the docs: “Not set up” and “Needs account selection” replace “Missing” and “Ambiguous”. When a buyer can’t use your default advertiser for a source, the account picker now says why in one sentence, for example “You haven’t set a default advertiser for this source.” The picker still offers the default only when it can be used.
• On Google Ad Manager sources, save_wholesale_product now lets you lock targeting into a product. fixedTargeting sets countries plus the key-values every line item must include or exclude, chosen from your synced keys and values. Every line item booked from the product carries them on create, targeting update and forecast. A buyer’s targeting is combined with yours, so a buyer can narrow but never remove or widen it, and a buyer country outside your fixed countries is refused. overlaySupport sets which targeting dimensions a buyer may set; leave out geography and buyers can’t set it. A dry run of a create returns lineItemTargeting, the targeting every line item would carry, as Google Ad Manager receives it. Changes to fixed targeting merge part by part, so updating the countries or includes never removes your stored exclusions. Both fields are optional, and existing products are unchanged until you set them. See Seller-fixed and buyer-chosen targeting.
• The campaign setup skill now offers a catalog from a spreadsheet or feed file in a connected Google Drive or SharePoint folder. Your assistant sends you to the Catalogs page to pick the file from its “Connected folder” source, and saves the catalog from the file you choose. It cannot browse your folders itself, so it uses save_catalog with file only when you give it both the connection ID and the file ID. Connected files are in early access and appear only on accounts where they are switched on. To get this update, update your Apostra plugins.

​

5.1606.1 — November 7, 2026 at 8:05 AM UTC

• save_media_buy now refuses to book or update a package budget below the seller’s declared minimum spend per package (min_spend_per_package), instead of letting the buy launch and fail. A launch preview or confirmed launch (save_campaign with desiredPhase: "active") also now flags and refuses any staged media buy that is below its seller’s minimum, so a buyer sees the problem before — not after — the buy is booked with the seller.

​

5.1606.0 — November 7, 2026 at 7:34 AM UTC

• The Catalogs page can now make a catalog from a file in a Google Drive or SharePoint folder your account has connected. Choose “Connected folder” when you connect a catalog, pick the connection, open folders to find the file, and choose it. The page then reads that file once, and “Sync now” reads it again to pick up your edits. Connected files are in early access and appear only on accounts where they are switched on.

​

5.1605.0 — November 7, 2026 at 7:01 AM UTC

• Three certification findings on the agent read now say the same as the results beside them. When an earlier run has recorded results, certification.no_passing_use_case leads with those results and adds that Apostra’s latest attempt to start another run could not, instead of saying no run exists. It also says no use case that counts toward certification has passed, and names any use case that passed but does not count, such as accounts for a seller’s own storefront. A failed quartiles check now gives our tracker’s count for each event and names the events that did not arrive. Its fix explains that until 7 November 2026 browser video players could not read the VAST file Apostra hosts, and that a certification run that starts after then judges it again.
• Booking a Spotify media buy with a device targeting value Spotify doesn’t support (e.g. device_platform: ["windows"]) is now refused immediately, while the draft is still editable, instead of only failing at launch and leaving the buy unrecoverably FAILED. The launch preview also now warns about any already-staged buy whose device targeting will fail at launch, before you confirm.
• Buyers can now target gender on Spotify media buys. Set targeting_overlay.demographics.gender with values: ["female"] to restrict delivery to Women, or ["male"] to restrict to Men, on both create_media_buy and update_media_buy. To reach Spotify’s “All” audience — which includes non-binary and unknown-gender listeners — omit gender entirely when creating a media buy, or, to clear an existing restriction on update_media_buy, send values: ["female", "male"] with include_unknown: true. Omitting gender on update_media_buy leaves a package’s current gender targeting unchanged rather than clearing it.
• Three other combinations are refused with a clear, correctable error instead of being silently dropped or broadened: values: ["non_binary"], alone or combined with another value, since Spotify has no separate audience for non-binary listeners; values: ["female", "male"] without include_unknown: true, since that asks to reach both known genders while excluding non-binary and unknown-gender listeners, which Spotify has no way to do; and include_unknown: true paired with a single gender, since Spotify can’t add unknown-gender listeners back in once Women or Men is selected.

​

5.1604.0 — November 7, 2026 at 6:26 AM UTC

• A catalog can now come from a spreadsheet or feed file in Google Drive or SharePoint, so a buyer no longer has to make a private file public. An account admin connects a folder from the Integrations page; then save_catalog takes file: { sourceId, itemId }, naming one file inside that folder, in place of url or items. The save reads the file once and stores its items as a new version; to pick up edits, save again. CSV, JSON, XML, Excel workbooks (first sheet only) and Google Sheets are read, up to 10 MiB and 10,000 items, and every item must pass the AdCP item schema for the catalog type. CSV, XML and spreadsheet rows are flat text, so store, hotel, flight and real_estate catalogs need a JSON file, and a vehicle catalog needs JSON or a workbook whose year cells are numbers. A file that cannot be used is refused with a reason that says what to fix, and nothing is saved. Connecting a folder imports nothing, and scheduled refresh is not available yet. If a folder is later disconnected, its catalogs keep their last version and still read normally, but their next save is refused. Catalog reads add "file" as a sourceType, the file to send back to save_catalog, and a read-only fileName. Connected files are in early access and appear only on accounts where they are switched on.

​

5.1603.0 — November 7, 2026 at 6:07 AM UTC

• A single-file HTML creative, such as a Campaign Manager 360 or other third-party ad server tag, is now saved as an AdCP display_tag creative instead of html5. It syncs and launches without a click-through URL, because the tag handles its own click and the seller serves it as sent. AdCP’s html5 format is a zip bundle, so:
• save_creative stores an HTML asset as display_tag inline markup, with or without formatKind: "display_tag", and records its AdCP markup_type when the markup shows it.
• An HTML file whose own script declares or assigns clickTag (such as var clickTag = "…") is an HTML5 banner. Saved without a format or with formatKind: "html5", through save_creative, the v2 API or buyer chat, it is repackaged as an inspected zip bundle with the file as index.html, beside any uploaded file its markup refers to by name. It still needs a click-through URL: the literal URL its own clickTag declaration assigns is used unless you send one. A banner sent with a file its markup does not refer to is refused, because AdCP carries an HTML5 banner as one zip. A fixed width and height in its format parameters stand in for a missing ad.size. Saved with formatKind: "display_tag" it is stored as a tag. A clickTag parameter in a tag’s URL does not make it a banner.
• Any other single HTML file saved with formatKind: "html5" is refused with the zip upload path.
• Creatives you already saved this way are reclassified after release, except those on a media buy that is pending approval, active, paused or ending, which keep their current format.

​

5.1602.0 — November 7, 2026 at 5:39 AM UTC

• The agent read’s implementation.agent_error finding no longer reports AdCP’s correctable refusal of package assignments on sync_creatives (the code UNSUPPORTED_FEATURE, the field assignments and the recovery correctable) as your agent’s error. Apostra already answers that refusal by sending the creatives again without the assignments, and source health and the “behaves as it declares” check already leave it out; all three now share one rule. Any other error your agent returns still shows.

​

5.1600.0 — November 7, 2026 at 4:41 AM UTC

• A creative you approve on your Storefront now reaches a sales agent that takes creatives into its library but refuses to assign them to packages on sync_creatives. Apostra sends the creative again without the assignment, then assigns it to the media buy’s packages through update_media_buy, keeping the creatives already on each package. Before, the creative failed and never reached the agent. If the agent takes the creative but refuses the assignment, the delivery fails with CREATIVE_PACKAGE_ASSIGNMENT_FAILED: the creative is with the agent but not live on the buy.
• A booked creative format now reaches the seller with the exact legacy format reference the seller published when the line was booked, even if the seller’s format catalog changes before launch or a later update. Discovery records how each canonical format option maps to the seller’s legacy format, each media buy line keeps the mapping its product had when it was booked, and launch and media buy updates use that record before re-deriving it. Lines booked on products discovered before this change keep the existing behavior.
• V3 get_delivery with report: "campaign_delivery" can now give every row and the totals in one currency. Send currency with an ISO-4217 code such as "EUR"; any of the 21 currencies Apostra’s daily exchange rates cover is accepted. Each day converts at that day’s own rate, so a row that spans several days is converted day by day and then added up, and a range that spans a currency move reads correctly. Counts never change, and cost per mille, cost per click, cost per acquisition and return on ad spend are worked out again from the converted money. A row with a day that has no rate keeps its own currency and values, and the totals then show money as unavailable (fx_rate_unavailable) instead of a partial sum. The response describes what it did in conversion: the currency, the daily rate basis, how many days a rate was carried forward, and each currency and day that had no rate. Goal progress is not converted yet. This replaces v2 reporting’s displayCurrency, which used one rate for the whole window. Live campaign delivery, seller delivery and margin refuse currency. Without currency, responses are unchanged.

​

5.1599.0 — November 7, 2026 at 4:04 AM UTC

• A campaign you plan on Apostra keeps its name and flight after its buy goes live with a connected seller account such as Snap. When the seller account was synced, Apostra copied the seller’s campaign name (often an id) and dates over the campaign and its media buy. The sync now leaves a planned campaign’s name, flight and budget alone and only updates the buy’s status from the seller. Campaigns Apostra creates to show buys you made outside Apostra still follow the seller. Nothing to change on your side.
• The v2 buyer endpoints for generative creative model keys are no longer available. Calls to /api/v2/buyer/creative/model-credentials and /api/v2/buyer/advertisers/{advertiserId}/creative/model-credentials now return 404, and the list_creative_model_credentials, connect_creative_model_credential and rotate_creative_model_credential buyer operations are gone. Settings → Generative creative is removed from the web app. Generate creative through a connected Creative Engine instead. Generation without one now fails with an error that names Creative Engines.
• When saving an RFP collides with another database change, save_rfp now answers SERVICE_UNAVAILABLE and says nothing was saved, so your agent can send the same request again with the same clientRequestId. It used to answer with an internal error.

​

5.1598.0 — November 7, 2026 at 3:34 AM UTC

• The “Add billing info” step in Plan & Billing no longer opens the API page for updating billing info. It now opens the Plan & Billing guide at “Add billing details”, which says where to enter your payer name, billing contact and address: Settings → Plan & Billing → Payment & invoices in the Apostra web app. The docsUrl on that step in the billing read now points at the same guide section. Nothing to change on your side, and the billing-info API itself is unchanged.
• The Agent page loads much faster for an agent with a large product catalogue. Working out which creative formats and targeting an agent’s products declare now reads the catalogue once instead of several times, and the page builds the agent’s stage from the agent it already read instead of reading every agent in the account again. On a catalogue of about 23,000 products the page’s reads take about a quarter of the time they did. Nothing the page shows changes.
• The Agent page and an agent read with get load faster again. They now read the facts behind an agent’s stage and findings once per load instead of three times, and that read no longer waits for the database to compile it first. On a catalogue of about 23,000 products the page’s reads take about half the time they did after the previous speed-up. Nothing the page or the read returns changes.
• A sales agent that refuses package assignments on a creative sync with AdCP’s correctable UNSUPPORTED_FEATURE for the assignments field no longer has its Source marked unhealthy. That refusal stays visible as degraded health, which doesn’t stop the Source going live or selling. A Source still held back by an earlier refusal of this kind recovers at its next creative sync. When a Source’s health is failing, the finding now names the operation that failed, such as creative sync (sync_creatives), and says product discovery is failing only when discovery failed.
• A buyer’s account request to a seller can no longer fail with an internal error because it overlapped the background work that builds that buyer’s Session history and event stream. That work now steps aside when the account request holds the buyer’s lock and picks up again on its next run.
• The campaign setup and campaign management skills now walk your assistant through uploading HTML5 ZIP and VAST files: it checks each ZIP against the HTML5 requirements, finishes each upload with its click-through URL, and only then attaches it to the campaign. Your assistant now also says plainly when a campaign is still a draft. Creatives on a draft media buy go to that buy’s seller as soon as they are saved, so a creative can show pending_review before launch. That is the seller’s creative review, not a booking. The campaign setup skill also covers adding a product catalog and syncing a first-party audience. To get these updates, update your Apostra plugins.
• A compose pass no longer loses its provenance (the “fed by” chips on its products) when it is written at the same moment as that run’s Session publication. The two could lock each other out, and the provenance was dropped; it is now written again automatically.
• A buyer’s account request to a seller no longer fails with an internal error when it runs at the same moment as that seller’s Session publishing a compose run for the same buyer. The two could lock each other out. Now the publication steps aside and is published again automatically shortly afterwards, and the account request completes.
• The “Behaves as it declares” finding no longer says a sales agent refuses sync_creatives when its only refusal was AdCP’s correctable UNSUPPORTED_FEATURE for the assignments field. That answer is the one AdCP allows: Apostra sends the creatives again without the assignments, and the “Package assignments are answered as AdCP allows” finding judges it. When the finding does report a refused operation, it now names the request field your error named, wherever your answer carried the error.
• If an agent or script of yours still calls these v2 storefront REST routes, move it to V3. The twelve routes under /api/v2/storefront are GET /acceptance-policy, GET /acceptance-policy/active, POST /acceptance-policy/{version}/activate, GET /approval-routing, PUT /approval-routing/{kind}, PUT /approval-routing/work-items/{workItemId}/assignee, GET /buyer-instructions, POST /buyer-instructions, PATCH /buyer-instructions/{id}, DELETE /buyer-instructions/{id}, GET /operating-instructions and GET /operating-instructions/{version}. On V3, read your Business Rules versions with search on business_rules_version, or with get on business_rules and include set to versions; read the active version with get on business_rules; and change or roll back the policy by saving it with save_business_rules, or on the AI Business Rules Page. Read who reviews work with get on business_rules and include set to approvalRouting, and change a routing policy or reassign a work item on the Approvals Page. Read your buyer instructions with search on advertiser, and write them with save_advertiser_instructions; V3 has no tool to delete an instruction row, so clear its notes, countries or discount with null instead. Read your Playbook history with search on playbook_version, or with get on playbook and include set to versions, and read one version in full with get on playbook and version. POST /acceptance-policy stays for now. Outside callers keep receiving the same “moved to V3” refusal they have received for every v2 storefront route since 19 October 2026. Earlier notices in this series said removed routes return 404 to outside callers; they don’t. If you already work through V3 or the seller Pages, nothing changes for you.
• A rate card you scope to a buyer’s operator or brand now applies when that buyer searches your products. Before this fix, a buyer who matched a scoped rate card was quoted your general prices. Nothing changes for buyers who match no scoped card, and nothing changes on your side. If you have committed a scoped rate card, matching buyers now see its prices.
• A save_media_buy budget or bid update whose seller outcome could not be confirmed (for example a transient upstream timeout) now reports seller_outcome: "unknown" and reconciliation_required: true on the error, the same signal a targeting update already carries in this situation. Previously only a targeting change surfaced this; a budget/bid-only change left the buyer unable to tell an unresolved seller sync apart from a confirmed rejection from the error alone, even though the buy was already flagged for reconciliation internally.
• Google media buys now apply targetingOverlay.demographics.gender: Google can target female, male, or both exactly, and save_media_buy confirms Google applied it before returning success. A structured gender request always overrides a brief-derived gender default from the selected product. A gender request Google cannot represent exactly — non_binary, or including unstated/unknown gender — is rejected with a correctable error instead of being silently dropped. update_media_buy continues to reject any targeting_overlay.demographics (age or gender) with a correctable error; gender targeting changes after creation are not yet supported.
• If your company already has a live Seller account that nobody administers, you can now choose Buy media when you sign up with your verified work email, instead of being sent to Request Access. Before you finish, signup tells you that you also become administrator of that Seller account. The Seller account becomes an organization you administer, and your new Buyer account is created inside it; the Seller account keeps its Storefront and everything else it holds. If your plan does not cover a Buyer account yet, signup tells you so before you finish: you still become the Seller account’s administrator, but no Buyer account is created until the plan allows it. Nothing changes if the Seller account already has an administrator, where you still request access, or if it is no longer in use, where signup still creates your Buyer account as before.
• A V3 MCP connection now keeps accepting answers after an Apostra update adds a field, a value or a response variant. Before, a client that checked answers against the tool schemas it read when it connected rejected any answer carrying a value it did not know yet, until it reconnected. The tool output schemas in tools/list are now open: a field with a known set of values lists them as examples rather than a closed list, and each set of response variants accepts one it does not list. Input schemas stay exact, and the HTTP API, OpenAPI document and SDK types are unchanged. Nothing to change on your side.
• You can now move a live OpenAI Ads click or conversion buy to OpenAI’s automatic bidding through Apostra. Update the package with bidPrice: null: Apostra removes the bid and tells OpenAI Ads to bid automatically, which is the bidding OpenAI keeps when it retires maximum bids on 1 January 2027. Before, clearing the bid on a live buy changed nothing at OpenAI. Impression packages still need a bid, because OpenAI has no automatic bidding for impressions, so they keep the bid they have.
• Apostra now speaks the AdCP 3.3.0-beta.4 preview. Agents using the 3.3 preview must move to 3.3-beta.4; an agent still on 3.3-beta.3 continues on AdCP 3.2.8 with us. In the buyer agent principal administration readback, each reporting-subscription destination_overrides entry is now the object AdCP defines, with a required destination_id and optional account_ids, operator_domains and path_template.
• Creating a media buy with a product id from an earlier search or proposal no longer warns that the buy’s targeting record “needs operational repair”. Some sellers’ product ids change slightly with each search, so the record could not find the product the new buy was saved with. It now matches the same product from the same seller account. Nothing to change on your side.
• When your sales agent asks Apostra to wait, source diagnostics now hide only the calls it refused since it asked. Calls that failed before then are still reported as errors. A source whose agent keeps throttling its catalog pages, with no wait in force, is again reported as responding with errors in readiness. Nothing to change on your side.
• When your sales agent asks Apostra to wait, by answering HTTP 429 (or a 503 with Retry-After), your source’s health now says so instead of reporting a failure. Source diagnostics show an agent_waiting finding with the time your agent named. It is an attention finding with nothing to do, and it clears when that time passes. While the wait lasts, the calls your agent refused are not counted as errors, the source is not shown as failing, and readiness raises no source health task for it. Nothing to change on your side.
• A sandbox advertiser can now request proposals from the Apostra synthetic seller and Demo Storefronts without billing details or a payment method. Sandbox requests spend nothing, and these sellers declare sandbox support. Live advertisers still need billing details before a seller that bills through Apostra is asked for a proposal, and a seller that does not declare sandbox support is never asked on behalf of a sandbox advertiser.
• The VAST tag Apostra writes for a live certification buy on a video_vast product now plays in browser video players such as Google’s IMA SDK. Your agent now receives the tag at a URL on Apostra’s API (/delivery/v1/certification-vast/{id}), which answers the player’s cross-origin request with the page’s origin and Access-Control-Allow-Credentials: true. Before, the tag was sent at its asset-storage URL, which a browser player could not read, so the player reported a VAST error and the buy delivered no impressions. If you serve a copy of the certification tag from your own host to work around this, you can switch back to the URL Apostra sends. See Live certification.
• A Meta image-post creative session now uses the advertiser’s linked Facebook Page when the request names no Page, after checking that Meta still lets the advertiser’s ad account promote it. A Page named in the request still wins. If no linked Page is still promotable, the session leaves the Page for you to choose, as before.
• A creative that syncs to a seller after an earlier failed attempt no longer keeps reading “delivery failed”. When a seller account changed between attempts, the media buy and campaign reads still showed the earlier account’s failure as the creative’s status and listed it as a launch blocker, even after the creative reached the seller. Each seller route now shows its latest result. Nothing to change on your side.
• When a media buy’s last confirmed change with the seller has an unknown outcome, get(kind: "media_buy") now says so in its plain-text response, not only in the structured data. Previously that signal existed only as a field most readers never look at.
• An agent Apostra reaches only through its source now shows the errors its calls return, and is no longer offered an endpoint check that cannot run. The implementation.agent_error and implementation.not_reachable findings now read calls made to the URL the agent’s source uses when its production version has no endpoint, and for such an agent they say to refresh the source’s health rather than connect the agent again. The agent read’s validationSkill lists the endpoint-brief profile as unavailable whenever it cannot run, with the reason and what to do: a source uses the agent (if the source is yours, test the agent through its diagnostics), no endpoint is registered for its production version, Apostra has not read it yet, or it is not claimed.
• Product discovery now treats your structured targeting as a requirement on the answer. When a seller behind a storefront declares it cannot honour an account-wide field you sent in targeting_overlay, such as a metro system it does not list, its products are left out instead of being returned priced and forecast for its whole footprint. The response’s errors array names each seller left out and the field, as an UNSUPPORTED_FEATURE entry, so you can broaden that field to see the seller again. Sellers that cannot receive your targeting or do not declare any are still included. How your discovery targeting reaches sellers explains which sellers are left out.
• The Apostra synthetic seller and Demo Storefronts now set AdCP’s sandbox: true on get_products and request_proposals responses to a request from a sandbox account, so an agent can tell the response is simulated data. Requests from live accounts, and every other seller, are unchanged.
• If an agent or script of yours still calls the v2 storefront REST API to read, replace or delete an ad-server signal, or to connect Epsilon Retail Media (CitrusAd), switch it to V3: six routes under /api/v2/storefront are removed. Outside callers keep receiving the same “moved to V3” refusal they have received since 19 October 2026. The six are GET, PUT and DELETE /esa/{esaId}/signals/{signalId}, POST /inventory-sources/ad-servers/citrusad, and POST and PUT /inventory-sources/{sourceId}/ad-servers/citrusad/credentials/{credentialKind}. On V3, read one signal with get on signal and the sourceId, replace it with save_signal and its id, and delete it with save_signal and state set to archived. To connect Epsilon Retail Media, call save_inventory_source with adServer set to { "type": "citrusad" }; it opens the Connect ad server form, which creates the source and then stores or rotates its API key, so the key never passes through chat. If you already work through V3 or the seller Pages, nothing changes for you.

​

5.1597.0 — November 7, 2026 at 12:44 AM UTC

• When a buyer agent is refused on an advertiser, the error now says what to do. The message is unchanged (for example agent_no_advertiser_access or agent_read_only), so anything that matches on it keeps working. The error also carries details.reason with the same value and a plain-language suggestion, such as asking an account admin to grant the agent access to that advertiser. The suggestion is in details.suggestion on REST and in the suggestion text of MCP tool errors. See Errors.
• If an agent or script of yours still calls these v2 storefront REST routes, move it to V3: a call to any of them now returns 404 instead of the “moved to V3” refusal it has returned since 19 October 2026. The four routes are PATCH /api/v2/storefront (patch storefront capabilities), GET /api/v2/storefront/acceptance-policy/{version}, GET /api/v2/storefront/readiness/compliance and POST /api/v2/storefront/readiness/compliance/refresh. The three GET /api/v2/storefront/esa/{esaId}/media-buys routes (the list, one buy, and its Google Ad Manager snapshot) were documented but no longer served, and their entries leave the OpenAPI file. The list and one-buy operations also leave the /mcp/v2/storefront api_call tool; the snapshot operation stays there, and production refuses outside callers to that tool. On V3, change your capability declaration with save_seller and configuredCapabilities or setupIntent, and read the buys of one source with search on media_buy and a sourceId. For acceptance policy, read the list or the active version, which stay, and pick your version from the list. The standalone compliance read and re-run, and the Google Ad Manager snapshot, have no V3 replacement because no customer used them. If you already work through V3 or the Seller Setup page, nothing changes for you.
• The Google Ad Manager guide links in your ad-server source and listing steps now open the Google Ad Manager access page instead of retired pages. Open GAM access guide, and the Docs button when you connect Google Ad Manager, open what the service account’s role must allow. Open the approval guide, on the ad-server source and on the Apostra listing step, opens the page’s order approval section. When the Ad-server execution currency step on your setup checklist is open, its fix now links a new section of Setup checklist and go-live that says what to do for Google Ad Manager, FreeWheel, AdsWizz and SpringServe.
• Buyers with Creative Engines access can now link the Facebook Page an advertiser advertises as: on a Meta connection mapped to that advertiser, give save_connection the Page’s facebook.com link or username. Apostra saves the Page to the advertiser’s brand profile only if it is one of the Pages Meta lets the advertiser’s ad account promote, and refuses anything else. The connection read shows how many Pages Meta lists for the ad account and which are linked, and you can instead confirm the advertiser has no Page; answering is optional and the connection works either way.
• Murph no longer tells you it has no account or no requests when you reply with something like “I made the request” and it has no earlier conversation to look back on. It now checks your account’s live state and either tells you what it found or asks which request or step you mean.
• Reliable Reporting registrations now retain the required full-coverage setting when ESA reads a saved configuration back, allowing valid registrations to complete.
• targetingOverlay.demographics.gender on TikTok media buys now maps to TikTok’s native gender targeting instead of being silently dropped. A structured demographics.gender overrides a product’s stored, brief-derived gender when both are present, and get kind: media_buy verifies the applied gender against TikTok’s live state. TikTok Smart+ products continue to refuse all demographic targeting, gender included. A gender.values combination TikTok cannot represent exactly — anything naming non_binary, or a single binary gender combined with include_unknown — is refused with a correctable UNSUPPORTED_TARGETING_DIMENSION error rather than silently dropped.
• If an agent or script of yours still calls the v2 storefront REST API for runs, reporting or pending work, switch it to V3: seven routes under /api/v2/storefront are removed, and a call to them now returns 404 instead of the “moved to V3” refusal it has returned since 19 October 2026. The seven are GET /reporting/margin, GET /media-buys/{mediaBuyId}/reporting, GET /pending-operations, POST /gam-cleanups/{operationId}, GET /intelligence-runs, GET /brief-artifacts/{id} and GET /test-runs. On V3, read resale margin with get_delivery and report set to margin; read one buy’s reporting on the media buy Page; see what is waiting on you, and confirm a GAM cleanup, on the Pending Operations Page; read your briefs on the Demand inbox Page, or with search on rfp; and read a source’s recent test runs with get on the inventory source. If you already work through V3 or the seller Pages, nothing changes for you.

​

5.1596.0 — November 6, 2026 at 11:36 PM UTC

• When you ask for an advertiser that belongs to another account you are a member of, the refusal now names that account and tells you to switch into it. Before, it only said the advertiser was not found or you did not have access, so an agent could not tell whether it had the wrong id, the wrong account or too little access. The error is still ACCESS_DENIED, now with details.reason: "switch_account_required" and details.owningCustomerId, and agents are told it is one they can correct by switching. An advertiser in an account you do not belong to is still refused without naming the account. See Errors.
• A product search now answers within the wait you set, even when a seller is slow. Before, if a seller was still answering near the end of your wait, the whole search could fail with a server error and lose the products from the sellers that had answered. Now Apostra stops waiting for a slow seller shortly before your wait ends (a tenth of the wait, at most 5 seconds), returns the products from every seller that answered, and lists the slow seller as not answering in time. If a search still can’t finish in time, it now fails with a retryable SERVICE_UNAVAILABLE error that says the search ran out of time (details.reason: "discovery_deadline_exceeded"), not a generic internal error. Nothing to change on your side.
• When you ask the Apostra assistant on the web about an existing sales agent’s page, its certification or its credentials, it no longer opens the Connect Sales Agent page by mistake and stops there. The assistant now handles those requests itself and opens Connect Sales Agent only when you want to add a new agent.
• When you ask us to verify your domain from your account’s domain settings, you now hear back when it is done, the same way you do for any other request you send us. Before, these requests could not be connected to the work that resolved them, so the only reply was a manual message from our team.
• When Google Ad Manager can’t show Apostra your advertisers because the service account is on no team that holds them, the source’s diagnosis now tells you to add it to a team that includes your advertisers, or to a team with All entities, and then refresh the source. Before, it showed a sign-in problem and asked you to grant inventory and trafficking access, which does not fix it. Every Google Ad Manager access diagnosis (sign-in, reporting, forecasting, order approval and advertiser teams) now links to its section of the Google Ad Manager access page.
• When your sales agent answers HTTP 429 with a Retry-After header, Apostra’s scheduled work now stops calling your agent until that time. Scheduled work means catalog refreshes, capability checks, status polls and change-feed retries. The wait covers every storefront that uses the same agent endpoint. We honour a wait of up to 24 hours, and a 429 without Retry-After pauses scheduled calls for 15 minutes. A test you run yourself still reaches your agent; if your agent refuses it as well, the answer says until when your agent asked us to wait. Nothing to change on your side.
• V3 get_delivery with report: "campaign_delivery" now says when a media buy’s spend was converted into the advertiser’s currency. When a seller reports a buy’s spend in another currency, Apostra has always converted it before building the rows; the response now lists each conversion behind the page in currencyConversions: the media buy, the currency it was converted from and to, the rate, the rate’s date, and whether the rate was locked at booking (booked), taken from Apostra’s daily rates (snapshot), or the spend was relabelled to the currency the seller is paid in at a rate of 1 (settlement). The list holds up to 100 buys, ordered by media buy; currencyConversionsOmitted counts any left out. Both fields are absent when nothing on the page was converted, and the figures themselves do not change. This replaces v2 reporting’s deliveryFxConversion for V3 callers. Nothing to change on your side.
• Apostra pages opened in Claude no longer leave a failed record_widget_telemetry call in your agent activity. A page names its account on every call, and the telemetry call refused that field when Claude sent it straight to the v2 tools. It now records the page’s load timing and ignores the account, which the request already carries. Nothing to change on your side.

​

5.1595.0 — November 6, 2026 at 10:58 PM UTC

• The new Google Ad Manager access page lists every permission the service account Apostra signs in with needs in your GAM network. For each one it says what Apostra uses it for, what stops working without it, and what you give up if you grant less than the Administrator role. Nothing changes on your side. Read it before you scope the service account’s role down.
• get(kind: "media_buy", include: ["products"]) now always returns a lineItemRef for each line item, instead of only when the line happened to carry one internally. save_media_buy update errors about lineItemRef now point to this exact read instead of a get_campaign field that doesn’t exist.
• A Snap creative with a click-through link now attaches to its booked campaign. When Apostra re-read such a creative from Snap before attaching it, Snap’s reply included web-view and profile settings Snap fills in itself. Apostra treated those extra settings as a changed creative and refused to attach it, so the campaign stayed waiting for creatives. Apostra now compares only the settings it sends. Nothing to change on your side: a waiting campaign picks this up on its next creative sync.
• Snap media buys now apply targetingOverlay.demographics.gender: a single female or male value is targeted exactly, and save_media_buy confirms Snap applied it before returning success. A gender request Snap cannot represent exactly — more than one value, non_binary alone, or including unstated/unknown gender — is rejected with a correctable error instead of being silently dropped, on both save_media_buy and campaign updates.

​

5.1594.0 — November 6, 2026 at 10:07 PM UTC

• Correct legacy inline-markup product formats before booking, so incompatible ZIP HTML5 creatives are refused with the package’s accepted format instead of failing later during delivery. Media-buy status now retains that format incompatibility, and the same target and creative revision is not retried until either changes.
• targetingOverlay.demographics on save_campaign and save_media_buy now accepts an optional gender alongside age, matching AdCP’s DemographicTargetingIntent shape. Age demographics on a media buy’s package-level targetingOverlay now actually reaches adapter dispatch instead of being rejected with NOT_IMPLEMENTED before any seller ever saw it. Meta and Spotify media-buy creates and updates cleanly refuse demographics.gender today with a correctable UNSUPPORTED_TARGETING_DIMENSION error rather than silently dropping it — real gender targeting on those sellers is tracked separately and ships later.

​

5.1592.1 — November 6, 2026 at 8:34 PM UTC

• Fixed save_media_buy(kind: update) on a live media buy refusing an update whose productId was the qualified id get_products returned — the same id used to book the line item — by mistaking it for a brand-new product and refusing it as an unsupported mid-flight addition. A bare productId now resolves to the existing line item it was booked from, whatever qualified or raw form it was sent in.
• When a media buy’s targeting_overlay includes a dimension an ad platform doesn’t support, the rejection now names the specific field — for example “the ad platform does not support the language targeting dimension” — instead of a generic “one of the requested targeting dimensions” message that gave no way to tell which field to remove. This applies across every ad platform’s create_media_buy and update_media_buy.
• A campaign’s age range now reaches Spotify storefronts that approve media buys automatically: the media buy is created under AdCP 3.2 and Spotify applies the age range, instead of launching without it and returning a demographics_not_applied warning.

​

5.1592.0 — November 6, 2026 at 8:10 PM UTC

• Refining a generated creative variant with generate_variants now works after a generation. Send variantAction: "feedback" with a new action key, the session’s current revision, the variant to refine and your feedback. The refined variant now records its parent and shows as refined, and the parent becomes the session’s selected variant. Before, the refinement was refused, or came back as an unlinked draft. An action key the session has already used is now refused, so a retry never starts the same work twice; repeating the session’s current action exactly still returns that action. A new action waits until the previous one has finished generating, and a session takes at most 256 generation actions.
• Sales Agent findings now report when reliable-reporting account responses do not echo the requested configuration.

​

5.1590.0 — November 6, 2026 at 7:21 PM UTC

• Snap video and image creatives with a click-through link now reach Snap. Snap refused the link with “The URL provided is invalid” (E2712) because Apostra’s click tracker still carried an unfilled cache-buster placeholder, which Snap does not fill in. That placeholder is now removed before the creative is sent to Snap, as it already was for Spotify. Clicks are still counted, and the landing page is unchanged. Nothing to change on your side: launch the campaign again.
• An Operator of a storefront account can now connect one of your organization’s own sales agents to a Source. Before, only an Admin could. An Operator now sees the sales agents you can add, in the Connect sales agent task and with search for kind: "agent", and can connect your own agent from the task, with save_inventory_source and agentId, or by binding it to an existing Source. Connecting a partner’s agent, one another organization owns, still needs an Admin: an Operator who opens a partner’s form is refused with a message that says so. Members still cannot connect agents, and service tokens, delegated sessions and impersonation still cannot either.
• An Operator of your Agents account now gets an agent’s test plan from GET /api/v2/agents/:agentId, matching their permission to run its tests; a Member still does not.
• If an agent or script of yours still calls the v2 storefront Buyer Account Mapping REST API, switch it to V3: four routes under /api/v2/storefront/account-mappings are removed, and a call to them now returns 404 instead of the “moved to V3” refusal it has returned since 19 October 2026. The four are the relationship list (GET /account-mappings), the pending-request list (GET /account-mappings/reviews), the request decision (POST /account-mappings/reviews/{grantId}/decision) and the inventory-source decision (POST /account-mappings/accounts/{accountId}/sources/{inventorySourceKey}/decision). On V3, read your buyer account relationships and their pending requests with search and get on account_relationship, accept or decline a request with save_seller and admission, and record which account serves an inventory source with save_seller and sourceDecision. If you already work through V3 or the Seller Accounts page, nothing changes for you.
• Spotify device targeting (targeting_overlay.device_type / device_platform) now gives a clearer rejection when a value isn’t supported: naming an individual desktop operating system like windows, macos, or linux now states that Spotify can’t target that OS alone, and offers device_type: ["desktop"] as an explicitly broader alternative (all desktop devices together, not just the one you named). Naming anything related to Connected devices, In-Car, or Web states plainly that Spotify’s Ads API has no targeting control for them. The Spotify Ads compatibility guide now documents the device_type/device_platform split and this limitation directly.

​

5.1589.0 — November 6, 2026 at 6:41 PM UTC

• Documentation links now point to the canonical docs.apostra.com domain. The Apostra assistant and in-product widgets previously cited the retired docs.interchange.io host (which still redirects), so the links worked but showed an out-of-date address.
• A new docs page, “Why you approve and map buyers”, explains what approving and mapping a buyer is for, the two cases you’ll meet (a new advertiser, or one you already work with), why only some buyers wait for you, and what happens until you act. It also explains how to bring an advertiser list you already keep in a CRM, order management system or spreadsheet. The Buyer Account Mapping page links to it, and “From signup to your first booking” now includes the step.
• When Apostra could not start a certification run because your agent rejected or failed a call Apostra made to it, for example by answering the capabilities call with HTTP 400, your agent’s reads no longer say the problem is on Apostra’s side. Apostra now records your agent’s answer to the failed call when it tries to start, and the finding names the call, quotes your agent’s answer and says the fix is on your agent. When every call to your agent succeeded, or none was made, the block is still Apostra’s and the finding says so.
• Sellers are no longer charged for answering a brief from an Apostra buyer account that cannot book media yet, for example one that has not finished setup or has no media-buying entitlement. These briefs come from real advertisers, so they still appear in your Sessions, analytics and what your storefront agent learns from; they are simply free, like sandbox briefs. Once the buyer account can book, its briefs are charged as usual, and briefs from agents with no Apostra buyer account behind them are charged as before. Buyers: while your account cannot book media yet, your live briefs share the daily limit of 20 briefs that sandbox briefs use. The limit is Apostra’s, resets at midnight UTC, and lifts as soon as your account can book; when a proposal request is refused at the limit, the answer lists what your account still needs.
• A buyer on your Buyers screen no longer shows “mapping needed” because of a source you can’t map: one that doesn’t hold buyer accounts, or a sales agent that doesn’t list its accounts. Those gaps still show in each source’s coverage, but they no longer count as waiting on you.
• An Operator of your Agents account can now run an agent’s tests and turn “Allow certification buys” on or off. Before, only an Admin could. The tests are the endpoint check, the Test a Sales Agent skill runs and the creative conformance test. An Operator is enough because a certification buy spends nothing. Creating, claiming, renaming and archiving agents, changing an agent’s URL and managing members still need an Admin. If an Operator sends certificationRequested and displayName together in one save_agent call, the call is refused with a message that names displayName, and nothing is saved. Members still see agents read-only. Service tokens, delegated sessions and impersonation still cannot take any of these actions.
• A product whose canonical format_options carry a v1_format_ref naming your own agent now reads as canonical even when a legacy format id looks like a standard one, such as display_300x250 listed under a display_tag option. Previously Apostra read any display_<width>x<height> id as an image format from its name alone, called that a contradiction of your option, and reported the AdCP 4.0 canonical creative formats check as failing. Only a v1_format_ref to a standard AdCP format at creative.adcontextprotocol.org is now checked against the option that lists it. When the check does fail, it now names up to three products for each kind of problem and says what is wrong with them. In storefronts that show buyers only products with canonical formats, products that were held back by this mistake now appear. You do not need to change anything.
• A package on a media buy read now carries the seller’s own AdCP indicators, so you can see why a package is at risk whenever you ask, not only when a behind-pace notice arrives. Read the media buy with get (kind: "media_buy", include: ["products"]): each package the seller evaluated has indicators, indicatorTypesEvaluated and indicatorsAsOf (and indicatorsEvaluatedScope when the seller evaluated only part of the package), and the text names each indicator in plain words, such as an inventory shortfall forecast or a pacing risk. Through AdCP, get_media_buys returns the same snapshot on a listed package in AdCP’s own fields. Today only packages sold through the managed sales agent on Google Ad Manager carry a snapshot; a package the seller has not evaluated carries none, which means unknown, not fine. Apostra adds no indicators of its own yet. This is a new field on the V3 read; nothing is removed or renamed.
• V3 HTTP document reads (GET /api/v3/documents/{documentId}/revisions/{revisionId}/sections and /download) now take the account they run in as the accountId query parameter, like receipt reads, so they no longer need the deprecated X-SCOPE3-CUSTOMER-ID header. The SDKs send it there from the next SDK release.
• The Apostra TypeScript and Python SDKs and the apostra CLI now send the account a V3 HTTP request runs in as accountId in the request, instead of the deprecated X-SCOPE3-CUSTOMER-ID header, so nothing you call through them depends on that header when it retires. You change nothing: set accountId (Python: account_id) on the client or per call, or APOSTRA_ACCOUNT_ID, as before. Calls that still use the old input shape of save_account, a member read on get or save_directed_campaign_subscription, where accountId named the account being edited or read, keep working: the SDK moves that value to the renamed id, memberAccountId or providerAccountId input. Use the renamed inputs in new code. This reaches you with the next SDK and CLI release.

​

5.1588.0 — November 6, 2026 at 4:57 PM UTC

• The agreed-terms check now also compares how each package bids. If a seller starts bidding a package differently from what was agreed, for example a fixed bid that the ad platform switches to automatic bidding or to a cost target, the buy is marked out of line with a note that the seller changed how the package bids, instead of the bid being quietly listed as not compared. This matters most for OpenAI Ads, which converts every remaining fixed-bid campaign to a target cost on 1 January 2027: buys still on a fixed bid then will show it. Sellers whose bids match the agreement see no change. See The agreed-terms check.
• If your storefront carries a country list from an earlier setup that you never confirmed, the Accepted markets check on your readiness checklist now shows that list and asks you to confirm it. Before, the check said no countries were set, but buyer requests naming only countries outside the list were still not sent to you. Nothing about which requests reach you has changed. To confirm the list or change it, save your countries, or accept every country, in your Listing or with save_seller. The check does not block going live.
• Creative formats for Meta, TikTok, Snap and other platform storefronts no longer disappear between your product browses. A background catalogue check was deleting the copy of these storefronts’ products that creative-format reads use, so search and get of creative_format could return nothing for a platform you had just browsed. The copy now stays until your next browse refreshes it.
• Your contracted market-maker markets and channels now apply to every listed Storefront you own, so buyers in those markets get your supply on by default. Before, a separate review of each Storefront could leave it off or narrow its markets.
• Ask Apostra in your Agents account now works on your agents. It finds out which agent you mean, or asks when the account holds several, and helps for that kind of agent. It can connect an agent’s URL, read its findings and open its pages, the same actions as the Agents account’s MCP connection. Before, it answered as if the account were buying media and could not act on your agents.
• OpenAI is retiring fixed maximum bids for ChatGPT Ads on 1 January 2027 and moving campaigns to automatic bidding. You can now put your OpenAI Ads click and conversion buys on that automatic bidding through Apostra: leave the bid out when you add the product, and OpenAI bids automatically toward your budget. A bid you do send works as before: on click products it is the most you pay per click, and on conversion products it is your bid per conversion. Impression products still need a bid, because OpenAI has no automatic bidding for impressions. Buys you already have are unchanged.
• For API callers: bidPrice is now optional on OpenAI Ads click and conversion products and still required on impression products.
• OpenAI is retiring fixed maximum bids for ChatGPT Ads on 1 January 2027 and replacing them with target costs (Target CPC and Target CPA). OpenAI Ads click and conversion buys can now use OpenAI’s automatic bidding instead of a fixed bid, which is the bidding OpenAI is moving everyone to. Buys you already have are unchanged.
• For API callers, OpenAI Ads media buys now take AdCP’s package bidding policy. On click and conversion products, a package with no bid, or with bidding: { automatic: true }, uses automatic bidding. On click and impression products, bidding.max_bid sets a maximum CPC or CPM, and a bid_price you already send keeps working as that maximum. On conversion products, bid_price keeps working as a bid per conversion, and bidding.max_bid is refused because it is not a per-conversion bid. Impression products still need a maximum CPM, because OpenAI Ads has no automatic bidding for them. The OpenAI Ads API does not offer target costs yet, so bidding.cost_per is refused with UNSUPPORTED_BIDDING_POLICY until it does. get_media_buys now reports each package’s bid as bidding, with bid_price kept beside a maximum bid.
• A Google Ad Manager line item now stays within the countries of its product. A buyer who names no country gets the product’s countries, and a buyer country outside them is refused with the allowed countries named. Products with no countries behave as before.
• A GAM package that is underdelivering on a price-priority line item now gets a reason. When no other line item at its priority pays more it reports a pacing risk saying it is not outbid, with inventory either confirmed short by GAM’s forecast or marked unknown, where before it reported nothing.
• Each use case on an agent’s live certification now lists its checks, so you see what has passed while a run is still going. Most checks are judged within hours of the buy going live; only the reporting checks wait for the three-day flight. A check that is not judged yet shows waiting, and a waiting reporting check says when Apostra expects to judge it. The agent’s next step now reads, for example, “7 of 10 checks passed on ctv_video; waiting on reporting until 9 November.” The agent’s Overview page shows the same list. failedCheck and reason are unchanged.
• The Sessions page now shows a Sandbox label on any Session whose brief came from a buyer’s sandbox (test) advertiser, in the list and when you open it, so you can tell a buyer’s tests from real demand. Proposal Pass shows the same label on a sandbox RFP, and the Session for a brief response from a buyer’s agent (an RFP) now carries sandbox: true on get and search with kind: "session", as the Sessions for your agent’s composed responses already do. Sandbox Sessions stay in your list, so nothing is hidden. The marker is read-only, and Sessions recorded before Apostra noted where a brief came from carry no marker. You do not need to change anything.
• Buyers with Creative Engines access can link an advertiser’s Spotify show while managing a mapped Spotify connection. Podcast promotions use the saved show as their promotion target.
• When TikTok refuses a creative you sync to a TikTok storefront, each failed creative’s error code is now a standard AdCP code instead of TikTok’s own number. A refused request is INVALID_REQUEST, an authorization problem is AUTH_REQUIRED, a TikTok rate limit is RATE_LIMITED, and a TikTok server error is SERVICE_UNAVAILABLE. TikTok’s number moves to details.provider_code, for example TIKTOK_40002 where code used to say 40002. If your integration matched on TikTok’s number in code, read details.provider_code instead. Creatives TikTok accepts are unaffected.

​

5.1587.0 — November 6, 2026 at 2:10 PM UTC

• Your storefront agent no longer learns from a buyer’s sandbox (test) briefs. A buyer running tests used to change the selling history your agent reads and the learned default posture built from it, as if the tests were real demand. Those now come only from real briefs, and briefs recorded before sandbox briefs were marked count as before. What you teach your agent is unchanged: a lesson you save from a sandbox brief still applies to live briefs. You do not need to change anything.
• Generate now works again for copy slots in the Creative composer. If copy cannot be generated, the affected control explains why. Nothing to change on your side.
• When you or your agent read Sessions with get or search (kind: "session"), a Session whose brief came from a buyer’s sandbox (test) advertiser now carries sandbox: true, so you can tell a buyer’s tests from real demand. Every other Session has no such field. Sandbox Sessions stay in your list, so nothing is hidden. The marker is read-only: you cannot set it or filter by it. Sessions recorded before Apostra noted where a brief came from carry no marker. You do not need to change anything.
• RFPs that come from a buyer’s sandbox advertiser are now marked, and your RFP performance report leaves them out. When a buyer tests with a sandbox advertiser, the RFP created from request_proposals carries sandbox: true on search and get for rfp and rfp_turn. You can still answer and release it like any other RFP, and it stays in your lists. get_rfp_performance counts only live RFPs that are not sandbox by default, so a buyer’s tests no longer inflate your figures. Pass purpose: ["sandbox"] to see them. RFPs created before this change are not marked.
• A member of your Agents account who is not an administrator now sees the account’s agents in the agent picker on the left of the web app. Before, the picker showed an error for anyone who was not an administrator, although the agent’s own page already opened for them. A member still sees agents read-only and cannot create, claim or change one. Service tokens, delegated sessions and impersonation are refused as before.

​

5.1586.0 — November 6, 2026 at 12:52 PM UTC

• An agent that Apostra already calls through one of its sources no longer reads “No endpoint is registered for this agent yet”. Many agents that Scope3 set up for their organization have no endpoint on their registered version, and their Agent page led with that false finding and told the developer to connect the agent again. Now states.endpointRegistered and the implementation.no_endpoint finding count the URL the agent’s sources use, so the page leads with the step that is really in the way. states.storefronts now counts every storefront with a source that uses the agent, pending sources included, so it agrees with the sources the agent lists. When the agent is already attached to a pending source, the certification.no_source action reads “Refresh the pending source” instead of “Attach the agent to a storefront”.
• Video creatives can now be created on Snap. After the upload fix, Snap still refused to create a video creative with a server error, because we sent a creative type value Snap does not document. A Snap media buy with video creatives can now launch. Nothing to change on your side.
• Seller analytics no longer include briefs from a buyer’s sandbox (test) advertiser. A buyer running tests against your storefront used to raise your run counts, win rate, buyer asks and top products as if it were real demand. Those figures now count only real briefs, and briefs recorded before sandbox briefs were marked count exactly as before. Your Sessions list and Brief History still show every brief. You do not need to change anything.
• When you name a publisher and channel while asking how to invite it, Murph now gives you the signup link and asks directly whether to record a supply request for it. Murph and the docs also make clear that a seller already reselling a publisher’s inventory is not necessarily the right seller for that publisher; you decide. The publisher signup section of the first-booking guide is now a few lines.
• Products whose GAM custom targeting was saved as targeting groups now book and forecast on the segment they sell. Before, those key-values were left off the line item, so a booking would have run across the product’s whole ad unit and the availability forecast covered the whole ad unit. A product whose custom targeting is saved in a shape ESA cannot read now gets a clear error instead of booking without it.
• Saving a Google Ad Manager product with a selector option that Ad Manager would ignore (for example a key-value or geo option on an ad unit or placement) is now refused with an error naming the option, instead of being saved and silently dropped when line items are built. Existing products are not changed.
• A Snap creative whose creation failed with a Snap server error no longer stays blocked for good. Ten minutes after the failed attempt, the next launch checks your Snap ad account: if Snap never made the creative, it is created again as normal. If Snap did make one, the creative stays blocked and the error names Snap’s creative ID so support can sort it out. Nothing to change on your side.
• Media buys now names every source task blocking a buy, including what it blocks, its status, seller owner, and due date. Open any task to continue on the existing source work item; no setup changes are required.

​

5.1585.2 — November 6, 2026 at 11:17 AM UTC

• When Apostra cannot start a certification run, your agent’s reads now say so, say why, and name whose move it is, instead of telling you certification is running. If your agent rejected a call Apostra made to it, for example by answering the capabilities call with an error, the finding quotes that answer and what to change. If the problem is on Apostra’s side, it says so and asks nothing of you. Apostra tries the Source again by itself the next day, and the blocked step clears when a run begins.
• Conversion events are accepted before your organization accepts the current Terms of Service. log_event and POST /api/v2/buyer/advertisers/{advertiserId}/log-event no longer refuse events with TOS_ACCEPTANCE_REQUIRED, so an integration sending your conversions keeps working while the Terms are being accepted.

​

5.1585.0 — November 6, 2026 at 10:26 AM UTC

• Certification now checks that your sales agent keeps the package assignments it accepts on a creative sync. When your agent accepts a sync_creatives request that carries assignments, Apostra reads the buy back at least 30 minutes later and flags a creative that is not among the creative_approvals of the package it was assigned to. Only a read it could judge counts, and the check is advisory: it shows as a flag on the Agent page and stops nothing. The certification docs say what to send.

​

5.1584.0 — November 6, 2026 at 9:27 AM UTC

• Certification now checks how your sales agent answers package assignments on a creative sync. An agent either takes assignments on sync_creatives, or refuses them with UNSUPPORTED_FEATURE, recovery correctable, and the field assignments, so the buyer assigns through update_media_buy instead. Any other refusal of assignments shows as a flag on the Agent page. It is advisory today and stops nothing; Package assignments are answered as AdCP allows, in the certification docs, says what to send.

​

5.1583.0 — November 6, 2026 at 8:38 AM UTC

• You can now certify your own agent through your own storefront without first proving control of its URL. Turn on Allow certification buys and Apostra certifies the agent through your pending source, and the source goes live when it passes. Proof of control is still needed for a marketplace listing, Partner standing and use by another organization, and the agent’s findings now say so. Every read gives the same next step, an agent with no registered URL leads with the missing endpoint, and an agent that needs credentials is no longer sent to an endpoint check that cannot pass from the Agents account.

​

5.1582.1 — November 6, 2026 at 8:08 AM UTC

• When a seller refuses one field of a creative send for every creative, for example package assignments, that media buy’s result now says so. It carries the error code UNSUPPORTED_FEATURE and a message that names the field, instead of “The creative could not be sent to the seller.”

​

5.1581.2 — November 6, 2026 at 6:10 AM UTC

• Per-buyer auto-approval, the setting that let you skip your review for one named buyer, is retired. Every buyer’s media buys now follow your storefront-wide approval setting, so a buyer you had exempted is reviewed like any other: when your setting is manual, a buy that clearly fits your acceptance policy still goes through, and the rest wait for your decision. Two storefronts had an exemption in place, and their buyers now go through that manual-approval path. The two buyer-auto-approvals endpoints under /api/v2/storefront and the list_buyer_auto_approvals and set_buyer_auto_approve tools are gone. Creative review is unchanged.

​

5.1581.0 — November 6, 2026 at 5:00 AM UTC

• If an agent or script still fetches the v2 storefront skill or OpenAPI file, it now gets a “gone” answer with a pointer to V3 instead of the file. The files are /api/storefront/skill.md, /api/v2/storefront/skill.md and /api/v2/storefront/openapi.yaml. Both described the v2 storefront API, which has been closed to API callers since 19 October 2026. The /mcp/v2/storefront endpoint also stops listing the storefront skill as a resource. Use V3 instead: the V3 quickstart is at https://docs.apostra.com/v3/quickstart and the V3 HTTP contract is at https://api.apostra.com/api/v3/openapi-3.1.yaml. Nothing changes for the Apostra web app or its chat widgets, and the v2 buyer skill and OpenAPI file are unchanged.

​

5.1580.0 — November 6, 2026 at 4:31 AM UTC

• get with kind: "creative" now returns a third-party tag as AdCP’s display_tag asset in assets, with its markup or URLs, delivery form, markup type and macro declarations, the same shape save_creative takes.
• What changes for a read. A creative whose tag has a saved record now has a display_tag entry in assets in place of the HTML summary entry, which carried an assetId and a size but no markup. A tag with no saved record reads as before and is never given a delivery form or markup type. A slotted inline HTML asset is also returned in assetsBySlot as AdCP’s html asset, and a slotted HTML5 bundle as zip with its public delivery URL. Tag markup is third-party code, so the text a model reads carries it inside the untrusted-output fence. V3 is a preview, so this changes the assets entry without an alias.

​

5.1579.1 — November 6, 2026 at 4:04 AM UTC

• save_media_buy now asks your seller about a targeting, frequency cap, pacing, or seller-managed budget change on a media buy it is still reviewing or has asked you for more information on, not only once the buy is already running. Previously a buy in that in-between state was treated as if it could not be changed at all, and was refused with a message to archive and re-book it — which created a new booking and lost its delivery history. The seller’s own declared support still decides whether a specific change is possible; this only fixes when that seller is asked.
• Sending a campaign’s creatives again now works for a seller that takes creatives into its library but refuses to assign them to packages in the same call. Apostra sends the creatives without the assignment, then assigns them to the media buy’s packages. If the seller takes the creatives but refuses the package assignment, that media buy’s result is an error with the code CREATIVE_PACKAGE_ASSIGNMENT_FAILED instead of reporting the creatives as sent.

​

5.1579.0 — November 6, 2026 at 3:31 AM UTC

• A buyer agent can now act on the advertisers it is granted in other accounts of your organization, such as a child account for each client. A call that names one of those advertisers in advertiserId runs in the account that owns it, and get_status lists those accounts in reachableAccounts. Before, a buyer agent could act only on advertisers in its own account. Grants still decide what an agent can reach, and an advertiser it holds no grant on is still refused. See Account access and Run Apostra for several client accounts.
• As announced, a context.campaign_name no longer names an ad-platform campaign; it has been ignored since 6 November 2026 00:00 UTC. When you place a media buy directly with an Apostra ad-platform storefront over AdCP, send the buy’s name in AdCP’s name. A buy with no name is named {brand} × {storefront}. Your context is still echoed back unchanged.
• A member of your Agents account who is not an administrator can now see the account’s agents, read-only. Before, anyone who was not an administrator was refused the agents list, an agent’s page, its webhook deliveries, the calls Apostra made to it and its certification-run sessions. A member now sees all of these in a “Member view” with no actions: they cannot create, claim or connect an agent, run a test or change certification. Administrators still create, register and act on agents. Service tokens, delegated sessions and impersonation behave as before.
• The notice that a live package is behind pace now says why when the seller has said so. For a package sold through the managed sales agent on Google Ad Manager, the notice reads “is behind pace: the seller forecasts an inventory shortfall” or “the seller reports a pacing risk”, and its data carries sellerIndicatorTypes and sellerIndicatorsAsOf. Packages from other sellers get the same notice as before. No read changes.
• V3 no longer lists open_developer_home in an Agents account. Call open_agents_page instead, which opens the same My agents page with no inputs. open_developer_home still works for now, so existing callers keep working, and a later release removes it.

​

5.1578.0 — November 6, 2026 at 2:32 AM UTC

• Live delivery figures for Google Ad Manager buys now refresh about every 15 minutes, instead of about once an hour.
• Media buys on FreeWheel products that select direct ad units can be placed again. FreeWheel rejected the placement because its link method was not set, so the buy failed before it was created.
• When a sandbox advertiser has used its 20 briefs for the day, request_proposals now refuses the round once, before any seller is contacted, and says the limit is Apostra’s, not a seller’s. The RATE_LIMITED answer names the daily limit, says it resets at midnight UTC, and carries retry_after in seconds. Before, every seller reported “The seller returned RATE_LIMITED” with no reset time.

​

5.1577.0 — November 6, 2026 at 2:12 AM UTC

• When the Buyer discounts page can’t save a change, it now shows the reason the server gave, such as an access refusal, instead of a generic failure message, so you know what to fix. Nothing to change on your side.
• Creative notifications now say what happened in plain words: a creative a seller sends back for changes reads “needs changes” instead of “changes_requested”, and approved and rejected creatives read as full sentences (“Creative “Summer Hero 30s” was approved.”). The email that tells your account admins a teammate joined now names who joined (“Alex Rivera just signed up.”) instead of opening with a sentence fragment. Nothing to change on your side.
• The “From signup to your first booking” guide for publishers now says what joining costs and how you are paid. It sets out the two ways to join: list your own sales agent for free, or have Apostra host the agent and pay per Intelligence Unit. It also says that pricing by account type has not taken effect, so changing your account type does not change what you are billed today. It explains consolidated billing, which payouts need payout details on file, and that Apostra publishes no payout schedule. Nothing to change on your side.

​

5.1576.0 — November 6, 2026 at 1:41 AM UTC

• A package removal that the seller never reports on no longer leaves the package counted as removed indefinitely. When Apostra next reads the buy from the seller, a package the seller reports canceled confirms the removal. A package the seller still shows live seven days after the removal was sent counts as live again, so you can send the removal again, and Apostra’s operations team follows up with the seller. See Change a live media buy.

​

5.1575.0 — November 6, 2026 at 12:36 AM UTC

• The Campaigns page has a Re-send creatives button in a campaign’s Creatives section. It sends every creative of the campaign to its media buys again, each only to the packages it fits, and shows how many were sent, failed, left unassigned or held. It appears only for people who can edit the campaign, and only when the campaign has creatives.

​

5.1574.0 — November 6, 2026 at 12:09 AM UTC

• Live certification now sends its pause and resume the way a buyer sends them, with the optional push_notification_config callback present, even to an agent that lists tasks_get (where Apostra otherwise leaves the callback off). AdCP defines that field, and the version field on the request envelope, as optional, so your agent must accept an update that carries them. An agent that refuses the update because of one of them fails the pause check, and the result names the field and links to Takes buy corrections. Accept the update and ignore a field you do not use, rather than treating every top-level field as a change to make.
• A creative you attach to a campaign with a running media buy no longer shows as delivered when none of that buy’s live packages accepts its format. Before, the delivery recorded as done although nothing was sent to the seller, so the buy stayed at pending_creatives with no blocker. Now the delivery shows as failed with the reason named, and you can correct it. Attach a creative in a format the buy’s products accept.
• You can now restore an archived creative under a new name. Archiving frees a creative’s name, so another creative may have taken it by the time you restore. Before, that restore was refused and you had to rename or archive the other creative first. Now send name with save_creative’s isArchived: false, and the creative comes back under that name in one step. Without name, a taken name is still refused, and the error tells you to send one.

​

5.1573.1 — November 5, 2026 at 10:22 PM UTC

• When a campaign has no media buy routed to a seller, resending its creatives with save_creative (campaignId and resync: true) now still lists every creative of the campaign in creatives, each with an empty result list, instead of an empty list. The call still reports failed, because nothing was sent.
• A product whose creative formats are all declared as canonical format_options now reads as canonical even when each option also carries a v1_format_ref that names your own agent. Previously Apostra treated such a product as not carrying canonical formats because it could not map your own legacy format ids, so AdCP 4.0 readiness reported the canonical creative formats check as failing. You do not need to change your products. Products whose legacy refs contradict their options, or that carry only legacy refs, are judged as before.

​

5.1573.0 — November 5, 2026 at 9:46 PM UTC

• Approving an action from a chat widget (for example choosing a plan in Plan & Billing) now opens the approval page in a new tab, leaving your conversation open. Previously the approval page replaced the chat in the same tab, so the conversation appeared to close when you went to approve.
• save_creative can now send every creative of a campaign again in one call: pass campaignId and resync: true with no creativeId. Each creative goes only to the packages whose format and size it fits, a creative that fits no package is reported on its own, and the result gives an overall outcome (synced, partial or failed) plus what happened to each creative on each media buy. Before, an agent could re-send one creative at a time, and a campaign’s whole creative set could be re-sent only through the REST sync route.
• You can now remove a product from a media buy that is already running, when the seller takes it. save_media_buy with products: [{ productId, lineItemRef, remove: true }] on a live buy is sent to the seller as a package cancellation, and the seller’s answer comes back to you. liveChanges.removeProducts on the buy now shows whether the seller takes it, from the remove_packages action it declared, where before it always read not_accepted.
• A removal stands alone: send nothing else in the same call. The packages change only when the seller confirms. A removal the seller accepts but has not applied yet reads as pending_approval and leaves the buy as it was, and a removal the seller refuses leaves the buy unchanged, with ACTION_NOT_ALLOWED and details.reason seller_refused. A package cancellation cannot be undone, and removing the last live package is refused: cancel the buy instead. A seller that does not take removals, or declared nothing, is refused before anything is sent with details.reason seller_does_not_accept or seller_declared_no_actions. The removal_not_supported reason no longer exists. See Change a live media buy.

​

5.1572.0 — November 5, 2026 at 7:38 PM UTC

• You can now bring back an archived creative. Call save_creative with creativeId, advertiserId and isArchived: false, and nothing else. The creative and its files return to the advertiser’s Creative Library.
• Restore does not put the creative back on any campaign or media buy, because archiving removed it from them. Attach it again with campaignIds when you want it to run. A creative that was made inside a campaign comes back as a Library creative of the advertiser. Restoring a creative that is not archived changes nothing, and restore is refused when the advertiser is archived or when another active creative now has the same name.

​

5.1571.0 — November 5, 2026 at 6:37 PM UTC

• Certification now counts delivery reports from sellers that speak AdCP 3.1. A report whose period ends on its last second (23:59:59Z) is read as the same day as one that ends at the next midnight, and a report over several whole days counts for each day that had ended when it arrived. The report timeliness check also accepts these reports in the timezone your product declares, so they no longer fail the check as “not one of the product’s reporting periods”.

​

5.1570.0 — November 5, 2026 at 5:32 PM UTC

• A Snap connection made before 29 October 2026 now says “reconnect needed” before you launch, instead of only failing when a Snap creative with a click-through destination is refused. The connection read and the seller read carry a new credentialAccess fact, and the buyer setup read shows the same message on that seller’s row. The connection stays connected and Snap buys without click-through destinations keep working. The message names the fix: in Snap Business Manager, make sure the connecting user can see the organization’s Public Profile, then reconnect Snap in Apostra.

​

5.1569.0 — November 5, 2026 at 5:01 PM UTC

• Organization administrators can now claim, change and prove their organization’s domain on the Domains page in their assistant. Prove it by publishing the DNS record the page shows and checking it, or ask Apostra to review it. If a change can’t go through, the page says why: for example, when accounts using the domain have advertisers.

​

5.1568.0 — November 5, 2026 at 4:28 PM UTC

• You can now change the click URL of many creatives across an advertiser’s whole Creative Library in one step, not only within one campaign. Send save_creative with advertiserId in place of campaignId on previewBulkUpdate, check the preview, then apply it with applyBulkUpdate. The selectors, the 200-creative limit and the 15-minute preview work as they do for a campaign. Creatives already on media buys need an account administrator’s approval first, as a campaign bulk update does, and are then sent to those buys’ sellers; creatives only in the Library change straight away. At advertiser level a bulk update changes only the click URL. See Change a click URL across an advertiser’s Library.
• save_creative now keeps macroAdditions when you create a creative from uploaded files (sourceAssets) or from a private image (sourceAssetRef). Before, the call succeeded but the click-URL parameters were dropped. When you replace a draft from uploaded files and send no macroAdditions, the draft keeps the parameters it already had; send a list to replace them, or an empty list to clear them.
• You can now change a social URL component, such as a click destination or a tracker, on a creative in your Creative Library with save_creative and its advertiserId. Before, a Library creative took only text components there, and a URL component had to be sent through a campaign the creative was on. Each URL slot you name replaces its value, and a slot the creative’s format does not declare is refused. A creative already on media buys keeps its old URLs there until you resend it with resync: true.
• The web app now has a Domains page under Settings → Organization in your organization’s account, the same page organization administrators open from their assistant. Selecting a domain in the Organization’s Accounts list opens it, switching to the organization first when you’re in one of its accounts.
• Apostra no longer sends push_notification_config on update_media_buy to an agent that lists tasks_get or get_task_status in its tools. Apostra reads such an agent’s long-running update by polling the task instead of waiting for a callback. Some agents read every top-level field of an update as a change to make and refuse the whole call as UNSUPPORTED_FEATURE naming push_notification_config, which left a booked buy on those agents impossible to correct. An agent that lists neither tool is still sent the field, because a webhook is the only way Apostra learns that its update finished. See Takes buy corrections.

​

5.1567.1 — November 5, 2026 at 3:07 PM UTC

• You can now finish an HTML5 ZIP or VAST draft in your Creative Library without a campaign. Send save_creative with the creative, its advertiser, mode: "complete" and its landing_page_url, and the draft becomes a complete creative you can attach to any campaign. Until now, an uploaded draft could not be given a click URL or attached to a campaign, so it stayed stuck. You can also change the click URL of a complete Library creative the same way. See Finish an uploaded HTML5 ZIP or VAST draft.
• The Campaigns page no longer shows “Couldn’t load this campaign” when you open a campaign a second time within a minute. A campaign’s media buy flight dates came back in the wrong form once they were served from the short-lived cache, so the page refused the whole campaign. They are now read correctly from the cache.
• A disabled Google Ad Manager or other managed ad-server source can now be brought back by connecting the same ad-server account again. The disabled source is switched back on in place and keeps its products, pricing and approvals, instead of failing with “A managed ad-server source with this configuration already exists”. Reactivating a disabled source that has no managed principal on record now says so and points to connecting the account again, instead of failing with an internal error.
• Murph now says “the Apostra team” when it offers to raise something with us, confirms a filed report, or tells you a request is already being worked on, matching the product you use and our docs. The sign-up and account-setup pages say the same about your support channel and access requests.

​

5.1567.0 — November 5, 2026 at 2:32 PM UTC

• You can now see exactly what each seller was told about your campaign. Reading a proposal with the brief include returns the brief that seller was sent, frozen at the moment it was sent, alongside the categories that were kept back, such as your total budget. Nothing changes in what sellers receive.

​

5.1566.1 — November 5, 2026 at 2:21 PM UTC

• The public Rate Card page now shows the Rate Card in effect and any upcoming revision, with how it differs. It no longer lists past revisions. GET /agreements/rate-card is unchanged and still returns them. See Plan and billing.
• An agent’s read now lists the sources it is attached to in your own organization by name, including a source that is still waiting for certification, with its state and why (for example “pending: waiting for certification”). Before, get for an agent counted the source but hid it, and the certification finding told you to attach an agent that was already attached. The finding now names the pending or disabled source and says what happens next. A source also keeps one state across reads: selling.blockers carries the reason a source that is not active cannot sell, poweredByAgent shows the source’s own state, and refresh_inventory_source_health returns the blocking reason with readiness.
• Seller accounts with live advertisers no longer see “Couldn’t load live advertisers. Showing sandbox advertisers only.” when they open the Advertisers workspace. The web app was asking the Buyer API for an advertiser list that Seller accounts cannot read, and it now shows the advertisers your Seller account operates without making that request. Developer accounts stop making the same request.

​

5.1566.0 — November 5, 2026 at 1:36 PM UTC

• When a call to your agent fails, the agent’s page now says which step failed, quotes your agent’s own error, and says whose move it is. If Apostra cannot reach your agent, or has never read it, the agent page raises a blocking finding that quotes the last network error, and tells you to move an agent on a tunnel or other shared host to a stable host on a domain your organization has verified, then reconnect it with save_agent. An agent that needs credentials is described as not read yet, with no “Run the test again” action, and points to connecting it from your Seller account. Source diagnostics hand developers the agent’s own ID, and label a newly connected source as pending activation instead of retired. Certification advice uses one name, Allow certification buys, and says to prove control of the agent’s URL first when it is not yet verified as yours.
• Video and image creatives now upload to Snap. Snap refused every upload whose file name had no extension, so a Snap media buy using those creatives could not launch and reported that the creatives’ seller-library revision could not be verified. Launch again; the creatives are sent to Snap with the buy.
• Murph no longer drops tool names from its answers. When Murph named one of the public Apostra tools, such as get_products or save_media_buy, the name was removed before you saw the answer, so a sentence like “Call get_products to gather quotes” arrived as “Call to gather quotes”. Murph now keeps those names, so its instructions for building on the API are complete. Murph’s own internal helper names are still kept out of answers.
• Product searches across many sellers with large catalogues now get enough time to publish their results, so a poll after the first page returns the products instead of an empty page with a request to retry. Nothing to change on your side.

​

5.1565.0 — November 5, 2026 at 1:02 PM UTC

• Organization administrators can now open a Domains page from their assistant, by asking for it or calling open_domains_page. The page lists each domain the organization claims, whether it is proved and how, and the accounts that use it. A domain is locked when accounts using it have advertisers: its claim can’t change, and the page names those accounts. Claiming and proving from the page come next.
• Google Ad Manager products now state their real reporting delay, about four hours, instead of zero, and the check for whether yesterday’s delivery is ready uses your ad server’s own timezone.
• Media buys on FreeWheel products that select direct ad units can be placed again. FreeWheel rejected the placement with “ad unit status is required” and the buy failed before it was created.

​

5.1564.0 — November 5, 2026 at 12:43 PM UTC

• get_status now shows each agent’s findings by severity. A new findingCounts field on every agent entry gives blocking, attention and advisory for the findings that are failing, and unchecked for the ones Apostra has not checked yet. Before, findingCount alone read as a count of problems, even when most of it was checks that had not run. findingCount keeps its meaning, the findings that have not passed. The Agents page takes its “more findings” line from the new counts, so a check that has not run no longer counts as a problem.
• Large product searches spend less time publishing their results, because each result set is priced and recorded once instead of twice. Nothing to change on your side.

​

5.1563.0 — November 5, 2026 at 12:15 PM UTC

• Campaign Pulse now shows Google Ad Manager sellers’ delivery as it stands, refreshed about every 15 minutes, instead of waiting for the next day’s report. These figures are provisional; the daily report remains the official record.

​

5.1562.3 — November 5, 2026 at 11:40 AM UTC

• When the assistant sends a tool an argument the tool does not accept, it now sees that as a mistake in its own request and corrects it, instead of telling you Apostra had a platform failure and asking to file a support request.
• An agent’s findings now show the latest result of Apostra’s account request to it, not only the last pass or failure. When the agent answers the request with an error and Apostra cannot judge it, the finding names the error the agent returned, so a developer is no longer shown an old failure that is no longer true.
• A SpringServe source on the Sources page now shows the Execution currency field and the Save execution currency button, so you can declare the currency you sell in without replacing your credentials. Before, only FreeWheel sources showed them, although the hint under the credentials told SpringServe sellers to use that button. The hint now names the button only for the sources that show it (FreeWheel and SpringServe). Saving your credentials while a currency edit is still unsaved asks you to save the currency first, as it already did for FreeWheel.

​

5.1562.2 — November 5, 2026 at 11:11 AM UTC

• A new sales agent can now be certified before its Source is live. Apostra’s certification buys spend nothing, so they now run through a pending Source in your own organization whose health is healthy or degraded. Turn on Allow certification buys on the agent’s page and Apostra certifies through your pending Source; when the agent passes, the Source goes live. Before this, the Source had to be live to be certified and could not go live until the agent was certified, so a new agent could not get started without asking Apostra support.
• Only Apostra’s certification buys use a pending Source. A buyer’s buy through it is still refused, setting the Source to ACTIVE yourself is still refused until the agent passes, and a pending Source of another organization keeps the partner connection path. The agent read, seller get_status and the source read now all name the same next step. See Which Source certification buys through.
• The Connect sales agent page now shows your organization’s agent names as plain text. Before, the agent row and the “switch to your Agents account” line showed the names wrapped in <untrusted_tool_output> tags. When you connect your organization’s own agent, the page no longer lists the raw connection contract, with its “Endpoint URL · Required” line, above a form that has no address field, and the Name field starts as the agent’s name instead of an example.
• save_media_buy now tells hosts that it can reach outside Apostra. Pausing, resuming or changing a booked media buy sends the change to the seller’s own system and waits for the seller to confirm it, so hosts such as ChatGPT can now warn before such a call. Nothing to change on your side.

​

5.1562.1 — November 5, 2026 at 10:29 AM UTC

• Saving a file you attach in Apostra chat to an advertiser’s Creative library now works. Every save of an attached HTML5 banner ZIP, image or VAST file failed with an unexpected error and nothing was saved; attach the files again and ask the assistant to save them.
• After Apostra reads an agent through a Seller account’s Source, the agent’s owner now sees what it declares. Each declaration finding shows as passed or failing with the field to declare, and the AdCP readiness is filled, instead of every requirement reading “not checked yet”. An agent that has not been read yet now says so, and says to connect it from your Seller account with its credentials. Its stuck reason names the endpoint check that has not run.

​

5.1562.0 — November 5, 2026 at 7:35 AM UTC

• Campaign Pulse and delivery figures for Google Ad Manager sellers now include today’s delivery up to the last few finished hours, instead of waiting for the next day. Today’s figures are provisional and are replaced by the final figures when the day closes. Nothing to change on your side.

​

5.1560.3 — November 5, 2026 at 4:10 AM UTC

• Creative sync no longer refuses a whole campaign because one creative does not fit every package. On a media buy whose packages list different banner sizes, each HTML5 or display creative is now assigned only to the packages whose declared size it fits, so a 300x600 creative is never sent to a 320x50 package. A creative that fits no package is reported on its own under unassigned_creatives, and the creatives that do fit are still sent. The sync response also carries a top-level outcome of synced, partial or failed, so a caller no longer has to read each item to learn that something did not go through.
• Certification now requires your agent to take buy corrections. An agent that does not list update_media_buy in the tools it returns from get_adcp_capabilities is skipped for every certification use case with the new reason seller_update_media_buy_unsupported, and its Agent page shows a blocking finding, declaration.update_media_buy (“Takes buy corrections”). A buy that cannot be corrected after booking cannot be certified, because removing a package, moving a flight or changing a creative then needs a person at the seller to do it by hand.
• The requirement is update_media_buy as AdCP defines it, including its optional request fields. push_notification_config and the request envelope’s version field are optional: an agent that does not send task webhooks should ignore push_notification_config instead of refusing an update that carries it. A tool you list and then refuse is flagged by the existing “Behaves as it declares” finding, which reads the answers to our real calls. Agents that already list update_media_buy are unaffected. See Takes buy corrections.

​

5.1560.1 — November 5, 2026 at 2:15 AM UTC

• Product searches that reach many sellers with large catalogues now finish and return their products. Before this fix, a search across thousands of products could stall for over a minute and then come back with no products and a request to retry. Nothing to change on your side.

​

5.1560.0 — November 5, 2026 at 1:37 AM UTC

• Apostra’s check that an agent accepts a media buy with no creatives now runs on every certification run, including one that places no other buy. When none of an agent’s products could be planned for a tracked family, Apostra sends the one probe buy on its own, on the cheapest product it can book, at the smallest budget, with no creative, and cancels it. If no product can carry it, the result is recorded as inconclusive with the skip reason no_probe_product, and a result that already passed is not replaced. The result still never counts toward certification.

​

5.1558.0 — November 5, 2026 at 12:28 AM UTC

• Certification now catches an agent that lists a write operation and then refuses it. The existing “Behaves as it declares” finding already checked supported_billing. It now also checks the tool list your agent returns: if you list create_media_buy, update_media_buy, sync_creatives or sync_accounts and every call we make in seven days is refused as UNSUPPORTED_FEATURE with none completing, the finding shows a flag on the Agent page. It names the operation and the request field your error named, for example update_media_buy (3 refusal(s), naming push_notification_config). An operation that completed at least once is not flagged, and CONFLICT, REQUOTE_REQUIRED and VALIDATION_ERROR never count, because they say the operation ran.
• The finding stops nothing today: no buy is held back and no certification pass stops counting. To clear it, run every operation you list or remove it from your tool list, and ignore optional request fields you do not use, such as push_notification_config, instead of refusing the call. See Declarations match behaviour finding.

​

5.1557.0 — November 4, 2026 at 11:40 PM UTC

• Searching an advertiser’s creative formats without a seller, product, channel or asset-type filter now pages through every format, however many your sellers declare. Before, an account that could see more than 5,000 format options got “Creative format catalogue is too large to search safely” and had to narrow the search. Each page now returns in a couple of seconds with a cursor for the next one. A product that a seller’s catalogue saved several times appears once. Results are ordered by seller and product, so a cursor from before this change no longer continues; start the search again without it.
• Buyers can register Reliable Reporting on an existing ESA account using its seller-issued account ID.
• In Apostra chat, you can attach a creative file to a message and ask the assistant to save it to an advertiser’s Creative library. A JPEG or PNG image becomes a library asset, and an HTML5 banner ZIP or a VAST XML file becomes a draft creative, with the same checks the creative upload runs and without choosing the file again. A file that fails the checks comes back with what to fix, and nothing is saved. Other file types still go through the creative upload. See HTML5 and display tag creative requirements.

​

5.1556.0 — November 4, 2026 at 11:00 PM UTC

• Messages up to 60,000 characters now save successfully in Apostra chat and remain available in Session history. Long messages previously could fail with a generic chat error even though they were within the supported limit. Nothing to change on your side; retry a message that failed to send.
• When a product search leaves a media partner out without calling it, the result now says why, such as “the buyer’s account is not set up for this seller’s inventory source” or “the discovery time budget ran out before the source could be called”, instead of “none of them was called”.

​

5.1553.0 — November 4, 2026 at 9:23 PM UTC

• Fixed a bug where a Meta video creative with a poster frame selected in the Creative Library could fail to sync to Meta entirely, with no actionable error. Meta now receives the selected poster frame as intended, instead of the sync failing.
• Choosing a plan on the Plan & Billing Page works again. Choosing a plan has needed an administrator to approve it on Apostra since 25 October, but the Page treated that request as a failure and showed “That could not be recorded. Try again.” It now opens the approval page, and the plan shows on the Page once an administrator approves it. A plan you chose and saw fail is not in force: choose it again from the Page, or approve a pending request from your approvals.
• V3 HTTP API requests now name their account with accountId in the request body (or the accountId query parameter when reading a write receipt), the same way MCP calls do. An API key or M2M credential that can reach several accounts can choose one this way without the X-SCOPE3-CUSTOMER-ID header. The header still works but is deprecated: a request that names its account only by the header gets a Deprecation: true response header and a link to Name the account on every call. The header retires on a date we will announce beforehand. If you send both and they name different accounts, the request is refused with ACCOUNT_MISMATCH and nothing is read or written.

​

5.1552.1 — November 4, 2026 at 9:00 PM UTC

• An admin of an organization can now connect the organization’s own sales agent to one of its Seller accounts, and withdraw that consent later. Before, the connection form loaded and then failed with “Only an active client account administrator may change capability authorization”. When a connection is refused for good, the Connect sales agent page now shows the reason it was refused instead of asking you to try again. Connecting another organization’s sales agent still needs an admin of the Seller account itself.

​

5.1552.0 — November 4, 2026 at 8:44 PM UTC

• The check that stops a media buy reaching a seller with no creative now also protects a buy that has a change waiting for approval.
• That check reads the campaign the buy belongs to. It read the buy’s current version, but a buy with a pending change holds a second live version beside it. If the two named different campaigns, the read found two and reported none, and the check was skipped for exactly the buy it exists to protect. It now reads the buy’s primary version, so the pending change no longer hides the campaign.
• The Catalogs Page now lists your feeds, connects them and syncs them through V3. Each feed shows its health with the reason when it is not healthy, what the last sync changed, its transform, and its newest versions and syncs. Sync now saves the feed again and fetches it. If a feed address cannot be fetched without signing in, such as a Google Drive or SharePoint share link, the Page now says why and what to do instead of a generic error. The Page no longer shows per-item approval counts or rejected rows, or a version number in the feed list, because the platform does not record them. Previewing and saving an activation plan work as before.

​

5.1551.0 — November 4, 2026 at 8:08 PM UTC

• The catalog read now shows where a catalog comes from and how it is built. Each catalog returned by search, get and save_catalog carries sourceType (url or inline), lastChangeSummary (how many items the latest version added, updated, left unchanged or removed) and transform (the name and date of its active transform, or null). get also returns the stored transform definition, and get(kind: "catalog", include: ["history"]) returns the newest 10 versions and refresh runs.
• Saving a catalog with a feed url that cannot be fetched without signing in, such as a private Google Drive or SharePoint share link, is now refused with a VALIDATION_ERROR on url that says why and what to do instead (send the rows in items, or host the feed at a public https address). Nothing is saved when it is refused.
• The V3 campaign launch preview no longer says a creative “needs seller approval before launch” when its media buy books now without waiting. If every source the buy routes to accepts a booking with no creatives, a creative that is only waiting on the seller’s review is not a launch blocker; the preview names the buy and says the creative attaches when the seller approves it. A rejected, missing or failed creative still blocks, and a line item set to startRequiresAllCreativesApproved: true still waits.

​

5.1550.2 — November 4, 2026 at 7:39 PM UTC

• A Developer account’s web app no longer asks for buyer-only data on every page load, so its organization admins see the Organization section and Plan & billing.
• Searching an advertiser’s creative formats without naming a product no longer fails with an internal error on accounts whose organization holds several accounts. The earlier fix covered single-account buyers; for a buyer in a larger organization the same search still took more than 30 seconds and was cut off. It now returns in about two seconds with the same formats. Nothing to change on your side.
• The assistant can now give you a secure link to add a card. Asking it to set up card payment used to fail every time with a validation error, and no link was issued. The Plan & Billing Page was not affected.
• Murph can now send you the secure card page when you ask to add a payment method. Before this fix, Murph’s request for the card link failed with a validation error every time, so you couldn’t add a card through Murph. Murph can also now complete a seller or advertiser identity change after you confirm it, such as a new operator domain. Nothing to change on your side: ask Murph again and it will send the link.
• When you ask Murph how to invite a seller that is not on Apostra, it now gives you the signup link to send and, if you named the seller and channel, offers to record a supply request in the same answer. The docs explain both steps on the media partner availability page.

​

5.1550.1 — November 4, 2026 at 7:12 PM UTC

• When you attach a creative file, such as an HTML5 ZIP or an image, to a message in Apostra chat, the assistant now tells you the attachment was not saved and opens the creative upload so you can choose the same file there. Before, it could not save the attachment and gave no working way forward. Saving a file straight from a chat attachment is still not available; see HTML5 and display tag creative requirements.

​

5.1550.0 — November 4, 2026 at 6:43 PM UTC

• Spotify media buys now set the ad set’s category from the advertiser’s actual industry instead of a fixed value tied to the campaign objective. Previously every “Brand awareness” or “Website traffic” buy was declared to Spotify as “Media and Entertainment ▸ Music” regardless of advertiser — for example a news brand’s buy was mis-declared as Music, which can affect Spotify’s category-based review and the age ranges available on the ad set. Podcast-placement products still declare the Podcasts category, since that reflects the inventory being bought rather than the advertiser.
• Previewing a brand domain with save_advertiser’s resolveBrand now lists the brands a house publishes, in houseBrands, so you can see which sub-brands you can create an advertiser for. Each entry is an AdCP brand reference with its name and logo. A brand kept in the house’s brand.json is the house domain plus its brand_id; a brand that publishes its own brand.json is referenced by its own domain. Only brands the house itself publishes, in its brand.json or an AgenticAdvertising.org hosted profile, are listed. The house domain on its own is still a valid brand.
• Source diagnostics no longer list our own session housekeeping as a failed product request. When we open an MCP session to your agent we also ask for its optional event stream; if your agent answers 405 or we close that stream ourselves, the request is now labelled as a session stream instead of a failed tool call.

​

5.1549.0 — November 4, 2026 at 6:10 PM UTC

• When a Snap creative with a click-through destination cannot sync because Snap refused access to the ad account’s Public Profile, the failure now says Snap denied access and that reconnecting Snap grants it, instead of the generic “requires an authorized Public Profile”. A Snap connection made before 29 October 2026 lacks that access and needs to be reconnected in Settings > Connections. Separately, when a launch stops because the seller library has not verified some creatives, the message now lists the first few creative IDs and counts the rest, so the instruction that follows is no longer cut off, and it says that retrying repeats a failed sync until its cause is fixed.

​

5.1548.2 — November 4, 2026 at 5:06 PM UTC

• Searchable dropdowns in the web app — the country picker, account pickers and other select fields — again show eight options at a time before the list scrolls, instead of five with the fifth cut in half. The same lists inside chat widgets already showed eight and are unchanged. Nothing to change on your side.

​

5.1548.0 — November 4, 2026 at 3:46 PM UTC

• When you look up a brand in the Create advertiser task and the domain belongs to a house that publishes several brands, a Brand picker now lists them. Pick the brand the advertiser is for, or keep the whole house, and the advertiser is created for that brand with its own seller accounts. The name fills in from the brand you pick. Only brands the house itself publishes, in its brand.json or an AgenticAdvertising.org hosted profile, are listed.
• Spotify’s Reach and Podcast Audio ad companion/logo image now declares and enforces a minimum size (at least 640x640px, square) instead of requiring exactly 640x640. A larger square image you were previously told didn’t fit is now accepted. An image under 640x640, or a non-square image, is refused with a clear message naming the companion_image slot and the exact requirement — at creative-save time, and again at ad-build time even if the image reached Spotify through the platform’s generic image fallback rather than being explicitly attached to the companion-image slot. The creative-format declaration you see in discovery now states this requirement up front.
• Fewer “Couldn’t load this view” errors on the Source diagnostics view. The seller source-diagnostics view now recovers from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production. What the view shows, its setup and credentials modes, and the pages it opens are unchanged.

​

5.1547.0 — November 4, 2026 at 3:10 PM UTC

• Product discovery on platforms such as Snap, TikTok, Pinterest, Google, Reddit and LinkedIn now returns products when your brief names an age range the platform cannot target exactly, such as ages 18-55 on Snap. The response says which ages the platform can target, so you can choose a range it supports or buy without age targeting. Nothing to change on your side.
• Searching an advertiser’s creative formats without naming a product no longer fails with an internal error. On an account that can see many sellers this search took about 30 seconds and was cut off. It now returns in a few seconds with the same formats. Searches that name a product were not affected. Nothing to change on your side.
• The “none of your advertisers are mapped” notice for a connected ad platform no longer keeps appearing after you have mapped an advertiser to it. It now disappears from your notifications and from Murph’s summary as soon as a mapping exists, including notices left over from earlier connections. Nothing needs to change on your side.
• Product searches across many sellers now finish even when a seller is slow to answer. Before, if any seller was still answering about 30 seconds into the search, the search could stay unfinished for good and return no products, even from the sellers that had already answered. Now each seller gets up to 45 seconds; a seller that runs out of time is reported as not answering, and the search finishes with the products from every seller that did. Nothing to change on your side.
• In Murph on the web, the Campaign Pulse badges on the Campaigns page now update on their own. When a seller’s new delivery report changes a campaign’s verdict, or a campaign goes stale because its next report is overdue, the badge changes within about a minute, with no refresh. Claude and ChatGPT cannot be updated this way, so the Campaigns page there still checks again at the time shown on each Pulse. Nothing to change on your side.
• Sandbox validation can now book a private modular product when discovery returns its composed product ID directly, including while its discovery evidence finishes publishing.
• Snap’s product names now spell out the objective, conversion location, and performance goal behind each one, matching the ids get_products already returns — for example snap_sales_web_conversion’s name changes from “Snap Web Conversions” to “Snap Sales — Website Conversions”. Product ids are unchanged; only the human-readable name field is affected. Call get_products on your Snap storefront again to see the new names.
• Spotify audio media buys (Audio Ad, Podcast Audio Ad, and the AI-generated audio format) now create their ad again. Ad creation had been failing for every one of these buys, so the campaign stayed approved with no ad actually running. Nothing to change on your side — resync an affected creative, or wait for the next scheduled sync, to pick up the fix.
• Fewer “Couldn’t load this view” errors on more in-chat views. The seller briefs, property roster, sponsored buyers, add-a-modular-source and import-inventory-feed views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.

​

5.1546.0 — November 4, 2026 at 2:21 PM UTC

• In the web app, “Open source” and “Add source” on Seller Setup open their pages again. For a source connected to an external sales agent, “Open source” showed “That source did not open. Try again.” and nothing opened. It now opens that source’s diagnostics page, and “Add source” now opens the connect-a-sales-agent flow. Nothing to change on your side.

​

5.1545.0 — November 4, 2026 at 2:53 AM UTC

• The Campaigns page now shows whether each campaign is actually delivering. Every campaign in the list carries its Campaign Pulse verdict (Delivering, Partially delivering, Not delivering, Cannot verify or Not expected yet) and how far its data runs, or “No data yet” when no seller has reported. Open a campaign to see its verdict and, for each live media buy, the verdict, how far the seller’s data runs, and the impressions, clicks and spend the seller has reported so far. These are provisional Snapshot figures, not official reporting and not billable. A figure a seller has not reported shows as “Unavailable” with the reason, never as 0, and only a figure the seller reported as zero shows as 0. The page reads Pulse again when a verdict can change on its own, so a campaign whose figures go stale updates without a reload. Nothing to change on your side. The verdicts mean what the Campaign Pulse page in the documentation says.

​

5.1544.1 — November 3, 2026 at 8:15 PM UTC

• A SpringServe source with a declared rate currency can now be certified for selling in that currency before its first booking. Sellers can change the declared currency without re-entering credentials, and a first booking that SpringServe holds in another currency is refused and removed.
• FreeWheel creative uploads can continue when the exact external-ID lookup returns FreeWheel’s nested HTTP 404/code 4020 no-match response, while ambiguous errors still stop before creation.
• An AdsWizz seller’s inventory sync no longer fails when AdsWizz rejects the supply-packs read. Their zones and zone groups refresh again, supply packs already cached are kept, and the run reports a warning instead of a failure.
• A package’s pacing index on delivery reports and media-buy snapshots now measures its spend against its own flight dates, so a short package that is behind pace no longer reads as on pace or ahead. It is left out until the package’s window opens, and until a tenth of it has passed.

​

5.1544.0 — November 3, 2026 at 6:38 PM UTC

• If the Apostra Assistant cannot file a report you asked it to send to the Apostra team, it now passes the report to the team directly and gives you a reference, instead of telling you to email support. The team sees it as an open case for your account, with a link to the conversation where you described the problem. Nothing to change on your side. If a report you asked for earlier never went through, ask the Assistant to file it again.
• Each buyer account can now send 20 sandbox briefs a day (counted in UTC). A brief sent to many sellers in one request_proposals call counts once. Past the limit, Apostra Storefronts refuse further sandbox briefs that day with RATE_LIMITED, until midnight UTC. Briefs from live advertisers are not limited.

​

5.1543.0 — November 3, 2026 at 5:12 PM UTC

• When you ask the Apostra Assistant to report a problem to the Apostra team and approve the draft, the report now files. Before, a report could be refused with an “unrecognized keys” error before you were ever asked to approve it, and the Assistant then told you to email support instead. Nothing to change on your side. If a report you asked for did not go through, ask the Assistant to file it again.
• Apostra now speaks AdCP 3.3.0-beta.3. A creative sent to a seller is checked against every package it is assigned to before it goes out: if it does not fit one of them, it is refused with a reason that names the package, instead of being sent and refused by the seller. request_proposals answers now carry status: "completed", and the task webhook sent when a seller approves or rejects a request now repeats the task’s status inside result, as AdCP 3.3.0-beta.3 requires. Agent notification subscriptions accept two new account events, creative.staged_update_changed and proposal.offered. Agents using the AdCP 3.3 preview must use 3.3-beta.3; others continue on 3.2.

​

5.1542.0 — November 3, 2026 at 4:40 PM UTC

• On the Advertisers page, a seller that does not run its own campaigns no longer sees Add advertiser or an advertiser’s Settings, which it could not open. Before, pressing either showed an error. Sellers that run their own campaigns see both as before, and the Buyers tab is unchanged.

​

5.1541.0 — November 3, 2026 at 4:08 PM UTC

• You can now accept a proposal that includes auction-priced products. Send save_media_buy with fromProposalId and a products list holding one { productId, bidPrice } entry for each auction product, with the bid in the campaign currency. The seller’s quote still sets every other term, so products takes nothing else with a proposal. Before this, a proposal with an auction product, which includes every Snap product, was refused because the accept had no way to carry a bid. If you leave a bid out, the refusal now names the product and the call to resend, and request_proposals tells you an auction product takes a bid when you accept.
• Reopening a Media Partners page from a chat that names a media partner no longer fails to load. The page now opens with the partner’s account, instead of being refused for using a retired seller id.
• When the Advertisers, Campaigns or Media Partners Page is refused at launch, the page now shows the reason and what to do next, such as an active contract or Terms of Service acceptance, instead of a generic “couldn’t load” error.

​

5.1540.0 — November 3, 2026 at 3:17 PM UTC

• If you run campaigns for several clients, a new guide, Run Apostra for several client accounts, recommends an account shape, a billing route and a credential, and says how to limit what each client’s work can do. The Plan & Billing guide now has a “What you pay as a buyer” section covering the buyer plans, the three activities that use IUs and what is not charged. Nothing changes in the product, and there is nothing to change on your side.
• Your account now always has the current features of its plan, automatically. Until now an account kept the version of its plan it was first given, so an improvement to a plan reached only accounts opened after it. Accounts now follow their plan as it improves, and there is nothing to change on your side.
• For buyers whose account was opened before 3 November, this is when the features the standard buyer experience gained that day reach your account: the booking answer, operator fees, seller audiences, package pacing alerts and property scores. Discovery also leaves out a seller you reach through a media partner until that seller reports your account active.
• A seller on an earlier beta of the merchandising package moves to its current version, which adds AMC campaign management and no longer includes inviting self-service buyers. No seller that has invited a self-service buyer is affected.
• Searching a Snap product’s creative formats, or saving a creative against it, now works with the product id you were given. Before, a Snap product listed its video and image formats on the product, but the creative format search returned none for it, because the search only matched the full id from one exact discovery read. It now matches the same product whichever read you hold its id from, and lists each format once instead of once per read.
• The Connect sales agent page loads again. It no longer stops with “Could not load diagnostics” for Seller Accounts, in the web app or in chat.
• Reporting health now shows overdue, rejected, and stuck seller statements for the affected Source, account, and reporting period. Missing reports remain missing rather than appearing as zero delivery or zero spend.
• You can now upload an HTML5 banner ZIP in the creative upload Task, up to 10 MiB. Apostra checks the ZIP the same way it checks one you attach in chat (one index.html with an ad.size, plain file names, supported file types), never runs it, and saves it to the advertiser’s Library as a draft HTML5 creative you then complete. A ZIP that fails the check is refused with a message saying what to fix, and nothing is saved. save_creative still does not take ZIP bytes. See HTML5 and display tag creative requirements.

​

5.1539.0 — November 3, 2026 at 2:13 PM UTC

• A product ID from a proposal now works when you create a media buy yourself with save_media_buy, even when you pair it with a productQueryId from a separate seller products read. Adapter sellers such as Snap return the same product under a different ID on every discovery run, and the create used to refuse the proposal’s ID as “not in this session’s saved selections”. It now matches the product the productQueryId round holds. When a product still cannot be matched, the error tells you to call request_proposals or get with kind: "seller" and include: ["products"] again, instead of naming a tool that does not exist in V3.
• open_campaign_receipt (Review & go live) no longer returns an internal error when a staged media buy’s or the campaign’s flight dates can’t be read back cleanly. The receipt still opens, with the affected dates omitted and a readiness blocker explaining that its flight dates couldn’t be verified, instead of failing the whole receipt.
• If attaching a creative to a Spotify media buy failed, retrying could fail every time afterward with a misleading “unsupported update field” error, even after the original problem cleared up. Retrying now reports the real reason the sync failed and can succeed once that’s resolved, instead of being stuck permanently.
• Saving a creative to a campaign without naming an exact format option now checks it against the real format the campaign’s seller declared, instead of a generic default with no size or required-field checks. A companion image that’s too large, or a missing required field, is now refused at save time with a clear reason, instead of silently attaching and failing later when the seller tries to accept it.
• An AdsWizz inventory source that stayed withheld from buyers because of a currency limit left over from before its agency’s currency was read, for example a USD limit on a ZAR agency, now clears itself. Once Interchange has read your agency’s currency, it removes the limits the agency does not support, within fifteen minutes and with nothing for you to do, and the source becomes buyable. A limit that a live buy is still denominated in is never removed; it stays so that buy keeps running, and the source stays withheld until the buy ends. Google Ad Manager, FreeWheel and SpringServe sources are unchanged.

​

5.1538.0 — November 3, 2026 at 1:46 PM UTC

• A SpringServe inventory source can now become buyable once you declare the currency it sells in. Before, a SpringServe source stayed withheld from buyers whatever its configuration said, because nothing proved the currency. Now you declare it from the source’s execution-currency action, without replacing your credentials, and Interchange carries that currency to your first booking. There it reads the SpringServe demand tag’s own currency back; if it differs from your declaration, the buy is refused and its campaign taken down instead of being sold at the wrong price. Choose a currency your storefront settles; Interchange never picks one for you or converts between them. Until you declare one, the source stays Not buyable. Google Ad Manager, FreeWheel and AdsWizz sources are unchanged.
• An HTML5 ZIP you save now ships with only the files Apostra checked. Hidden files and folders, such as .vscode or .cache, are removed before the ZIP is saved, as macOS metadata already was. A ZIP is refused, with a message saying how to fix it, when a file name uses characters other than letters A to Z, digits, spaces, dots, dashes, underscores, parentheses and plus signs, when it is encrypted or contains a link, when its headers disagree about which files it holds or where they are, or when its ad.size is larger than 10,000 pixels a side. A normal export from a design tool is unaffected. See HTML5 and display tag creative requirements.
• The seller read now lists the advertisers mapped to a connection’s selected ad account. Before, selectedAccount.mappedAdvertisers was always empty on get and search for a seller, even when the account was mapped and mappedAdvertiserCount said so.

​

5.1537.0 — November 3, 2026 at 1:09 PM UTC

• Private modular source tests now run discovery without the shared buyer cache, so every execution rebuilds its request-local product provenance. Before a campaign is created, the test also creates or repairs the exact same-customer sandbox advertiser scope needed for later campaign reads. Dispatch keeps its fail-closed source and runtime-pin checks, but records the invariant that changed when revalidation fails.

​

5.1536.0 — November 3, 2026 at 12:34 PM UTC

• An agent’s Overview, Activity, Inventory sources and Webhooks pages now show “This view didn’t load — try again” with a Retry button when Apostra could not read the page. Before, they opened empty and said the result could not be read.
• V3 tools no longer fail in an open session after a release adds an output field. The output schema each V3 tool lists now accepts extra properties, so a client that connected before a release keeps accepting the new fields instead of showing an error for a call that succeeded. The fields we declare, and their types, are unchanged.
• Connecting your organization’s own sales agent from a Seller account with save_inventory_source no longer fails in Claude, ChatGPT and other hosts that check a tool’s result against its published output schema. The result now names the outcome own_agent_connection_form, which the tool declares, and it opens the same Connect sales agent form as before.
• Buyer access requests in the signup form now require you to choose Brand or Agency before submission. The selection is saved with the rest of your request. Existing requests and direct API integrations are unchanged.

​

5.1534.0 — November 3, 2026 at 10:48 AM UTC

• You can now create a separate advertiser for each sub-brand of one brand with the V3 save_advertiser tool. Until now, a second advertiser on the same brand domain in the same country was refused, because sellers key their accounts on the brand and the two would merge. If one company runs an energy line and an insurance line under one domain, send the brand domain in brand and the sub-brand’s brand_id for each advertiser. Each sub-brand then gets its own seller accounts, so spend and seller invoicing stay apart.
• The brand has to publish its sub-brands first, either in /.well-known/brand.json on its own domain or in a profile hosted by AgenticAdvertising.org. A community registry record does not count. A brand_id that is not published there is refused with brand_id_not_published, and nothing is created. Set brand_id when you create the advertiser; changing it on an existing advertiser is not supported yet. Existing advertisers keep working, and nothing changes unless you want sub-brand advertisers. See “Advertisers for sub-brands of one brand” in the V3 guide to managing ads.

​

5.1533.3 — November 3, 2026 at 8:10 AM UTC

• Previewing an agent that requires credentials now offers the agent you already registered for that URL, instead of leading to a duplicate.
• save_agent with dryRun: true for an agent that refuses the read for missing credentials used to return an authentication_required error before any preview, so the sales agents you registered without a URL were never offered, and the message pointed you at registering a new one. It now returns a preview with notReadYet: { "reason": "authentication_required" }, saves nothing, and lists waitingAgents. If one of them is the agent this URL belongs to, send its agentId with the agentUrl and an idempotencyKey. Without one waiting, send kind: "sales" to register a new agent, as before. A creative agent that needs credentials is still refused. The output schema of save_agent now declares notReadYet on the preview, and the connect result for an agent that was not read validates against it.

​

5.1533.2 — November 3, 2026 at 7:39 AM UTC

• An admin of an organization can now list the organization’s own sales agents and open the agent connection in a Seller account created after they were made an admin. New Seller accounts give the organization’s admins access when they are created. Seller accounts created earlier are repaired by a one-off run that Scope3 makes.

​

5.1533.1 — November 3, 2026 at 7:19 AM UTC

• creative_library_page_attach (and save_creative attaching a Creative draft to its intended campaign) now refuses a Creative that is missing a format slot the campaign’s product requires — the same Required format slot <id> is missing. refusal save_creative already returns when the campaign is named at save time. Previously, a Creative composed without a campaign (for example a plain audio upload with no companion image) could attach to a campaign whose product requires that slot with no warning, then fail silently when the seller tried to sync it. Buyers now see the refusal at attach time instead of a buy that never delivers.

​

5.1533.0 — November 3, 2026 at 6:58 AM UTC

• Snap’s product ids and names now spell out the objective, conversion location, and performance goal behind each one, instead of a generic name that only hinted at it. This is a hard cut, with no transition window:
• snap_awareness → snap_awareness_engagement_impression
• snap_story_ads → snap_awareness_engagement_open
• snap_commercial → snap_awareness_engagement_commercial_video_view
• snap_sponsored_snaps → snap_awareness_engagement_chat_impression
• snap_traffic → snap_traffic_web_click
• snap_catalog_traffic → snap_traffic_web_catalog_click
• snap_lead_gen → snap_leads_lead_form_lead
• snap_app_installs → snap_app_promotion_install
• snap_web_conversions → snap_sales_web_conversion
• snap_collection → snap_sales_web_collection_click
• Call get_products on your Snap storefront again to pick up the new ids and names before creating or updating a media buy. A buy already created against an old id keeps running; only new product selection needs the new ids.

​

5.1532.0 — November 3, 2026 at 5:52 AM UTC

• Every Seller Account can now open the Buyers tab, which lists the buyers you work with. Before, a Listing seller that does not run its own campaigns saw the tab fail to load, because the Page behind it was open only to sellers that run campaigns. The other campaign tools, and the Advertisers entry in the left navigation, still need the campaign capability.
• Snap Story Ads products from get_products no longer list Impressions as an optimization goal. Snap never accepted that goal for Story Ads, so selecting it would have failed; Story Opens remains the goal for this product.
• The sign-in plan prompt now appears only when there is something to act on, a private offer waiting or the Standard plan available to switch to, and only to administrators of the billing organization. It opens the Plan & Billing Page on the offer, and “decide later”, or accepting the offer, keeps it quiet for that version of the offer. The billing read also reports how the offer was last answered, in plan.offer.lastResponse.

​

5.1531.0 — November 3, 2026 at 5:16 AM UTC

• The campaign list no longer fails for a whole account when one campaign was saved with postal-code targeting in an older format. That targeting is listed in AdCP’s own legacy form with the same postal codes, and the rest of the list loads.
• Apostra support staff with an approved, time-limited elevation on your organization can now request and approve new accounts, renames, archives and restores for it. Each request and approval is recorded under the staff member’s own name.
• If your organization is in the hosted buyer agent beta, you can now see how each buyer agent runs and which account it belongs to, and an organization administrator can create a hosted orchestrator. Organizations outside the beta see no change. Nothing needs to change on your side: existing calls behave as before, and the new fields are added to responses.
• get and search on buyer_agent now return two more fields. hosting is on_demand or always_on for an agent Apostra runs, and null for an agent you run yourself; always on cannot be chosen yet, so every hosted agent reads on_demand today. accountId is the Buyer account the agent belongs to, or null. get_status on a Buyer account now returns agent, a pointer to the account’s own agent, or null while the account has none yet. Today every account returns null.
• An organization administrator can create a hosted orchestrator, an agent Apostra runs that belongs to no account. Call save_buyer_agent with kind: "hosted", a displayName and a new idempotencyKey (a new UUID for each agent), then give it advertiser access across your accounts with access. Apostra starts the orchestrator’s runtime separately, and until that runtime is running the agent cannot take messages. Creating a hosted agent in an Agents account is still not available; connect a buyer agent you run yourself instead.
• A Seller Account whose brand domain is pending verification now says why, and which route can work. When no active member has an email address on the account’s registered domain, Setup says email approval cannot work and offers a DNS TXT record or a manual review. When the registered domain is approved and only the brand domain differs, it says only published brand.json linkage proves the brand domain. An agent whose host is not on a verified domain now names that host’s domain in its endpoint_control.unverified finding, instead of only asking for a brand.json.
• Saving a creative with a product-scoped format option now works for products booked through a Storefront route, such as OpenAI Ads, Meta and the other direct adapters. Before, the save was refused with “Product format option … is not declared by this campaign’s products” for those products, because the lookup that reads the campaign’s declared format options skipped the stored product row of a Storefront route. Nothing changes for products sold by an agent.
• get(kind: "seller", include: ["products"]) now lists each product’s qualified product ID, pricing options, and execution requirements in its text response, not just a product count. A buyer agent on a text-only MCP host (one that does not read structuredContent) previously had no way to retrieve the product IDs needed to call save_media_buy for that seller.
• search/get(kind: "wholesale_product") now returns acceptedCreativeFormats on each product row: the canonical creative formats it accepts, each with the asset types its required slots take (for example audio_hosted requiring audio and image). Previously a buyer had no way to learn what creative a product needed without a separate search(kind: "creative_format") call. The new field is a summary only, capped at the first 5 accepted formats — a row that accepts more sets acceptedCreativeFormatsTruncated: true and both text channels point at search(kind: "creative_format", productId) with the same product’s productId for the complete list and full format declaration save_creative validates against. Products with no declared formats omit the field.

​

5.1530.0 — November 3, 2026 at 4:13 AM UTC

• A new guide, From signup to your first booking, takes a publisher that runs its own ad server, such as Google Ad Manager, and has no sales agent of its own from signup to a first booking. It says what you need and what to do in order, and which steps Apostra does: the marketplace review of a new storefront and, for a managed ad server, the go-live certification that must pass before buyers can book. It also covers the currencies Apostra can settle (local currencies such as Turkish lira are not accepted), why countries and channels outside your markets never reach you, and what Listing and Storefront mean for a publisher with an ad server. Nothing to change on your side.
• Creating an advertiser no longer reports “may already have been created” when the save is only slow. The form now waits long enough for a brand lookup on a domain the brand registry does not know. A seller adding an advertiser for its own inventory also no longer waits on that lookup: if the brand’s name and logo cannot be found within a few seconds, the advertiser is saved with its domain as the brand.
• The API no longer accepts plain HTTP: requests to http://api.apostra.com, http://api.interchange.io and http://api.agentic.scope3.com are refused, so tokens are only ever sent over an encrypted connection. If an integration still calls the API with an http:// URL, switch it to https://; HTTPS calls are unaffected. The API, the web app and the admin app also now tell browsers to use HTTPS for one year, including subdomains.
• Apostra now says plainly that buyer requests naming only countries or channels outside your markets are not sent to you at all. They are not ranked lower, and nothing tells you they were turned away. If your audience lives in more countries than you are based in, add those countries or accept every country. The Seller markets page explains the rule with an example, and the Accepted markets readiness check spells out the same consequence.
• Connecting your own sales agent now tells you exactly why a connection was refused, and shows which of your agents are ready to connect.
• When an advertiser can’t be created because another advertiser already uses that brand in the same country, the error now explains why and links a new guide to sub-brands. It covers how a brand with separate lines of business publishes them, with a brand.json template.
• Keep Creative Library composer links open while the buyer workspace selects its advertiser, including links with no saved composer session.
• Image creatives now attach to the right product size on draft media buys. When a product offers more than one image size, the creative’s measured dimensions pick the matching one instead of the attach being refused as ambiguous.
• Creative-format searches now show Meta’s supported formats when the buyer has an active selected Meta ad account, even before that account is mapped to an advertiser.
• The web app and the admin app now send a content security policy that forbids plugins, injected base URLs and framing by other sites, tell browsers not to guess content types, and limit what the browser reveals in the referrer header on every response. Nothing changes in how the apps look or behave.
• Google product discovery no longer shows a fabricated CPM floor price. Google gives us no real price signal at discovery time, so the floor we authored ourselves was only ever a guess - and any account not billed in USD was already seeing it show up as zero, which read as a real zero floor rather than “we don’t know.” We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• Error responses no longer include stack traces or internal error text. A malformed or oversized request body now returns a plain 400 or 413, and any unexpected server error returns a generic message with a request ID (meta.requestId, also sent in the x-request-id header) that support can use to find the full error.
• The API now caps how fast one account can create objects and trigger model-backed or feed-refresh calls, and how many verification, password-reset and access-request emails one address can receive in an hour. A caller over a cap gets a 429 with a Retry-After header, as for the existing limits. The caps sit well above ordinary integration traffic: 600 object-creating POST requests a minute per account, 30 catalog refreshes or /chat calls a minute per account, and 5 emails an hour to one address. See the rate limits reference for the full table.
• LinkedIn product discovery and proposal responses no longer show a fabricated CPM floor price. LinkedIn gives us no real price signal at discovery time, so the per-template floor we authored ourselves was never more than a guess, and we applied it on every product regardless of account currency. We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• When your organization has not yet accepted the Terms of Service, administrators can now press Manage members in the Terms window to reach the account’s members and invite or remind the person who should accept. Only your organization’s own administrator can accept the Terms; Apostra staff no longer accept them on your behalf.
• A creative pinned to a product’s format option now keeps matching when the seller only rewords the option’s descriptions or changes a recommended length. Before, any change to the option’s text made the creative read as stale, and it was left off new media buys. A change to what the option requires, such as a length limit, a size or a required slot, still makes the pinned creative stale.
• Murph now records the seller you want to buy from. When you name a specific seller domain and the channel you want, Murph files it as a supply request on your list, without contacting the seller. When you ask where a seller should sign up, Murph takes the current sign-up link and next steps from the published docs.
• Murph now checks your storefront’s live data more often before it answers, so its answers about your account are more often grounded in what is actually set up. Answers take longer as a result: typically around 35 seconds, and up to about a minute for questions that need several lookups. Nothing to change on your side.
• save_media_buy now refuses an update entry whose lineItemRef names no line item on the media buy in the field you sent. The error points at products[i].lineItemRef, says that lineItemRef is the handle returned by get_media_buy and get_campaign (lineItems[].lineItemRef) rather than the product id, and lists the line items that product has. It no longer talks about buyer_ref. The same wording covers a lineItemRef that belongs to another product, a repeated product sent without one, and two entries that target one line item.
• Your setup checklist now shows when Scope3 is still reviewing your new storefront. A new storefront gets a Marketplace listing item that stays open while Scope3 reviews it. Until Scope3 lists it, buyers in your own organization can already use it and buyers in other organizations cannot find it. The item never blocks booking and asks nothing of you, and it completes once the storefront is listed. The ad-server go-live certification item now says that Scope3 runs it for you and that booking opens when it passes.
• Signup no longer reveals whether an email already has an account, for both buyer and seller signups. POST /auth/check-email-availability and POST /auth/sign-up answer an existing email the way they answer a new one, and no longer distinguish an unverified account from an active one. A password sign-up now returns the same status and an empty data object whether or not the address has an account, so it no longer carries customerId, nextPath or the plan-selection fields before the email is verified. Callers holding a Google, Microsoft, single sign-on or verified-signup token for the address still receive those fields and EMAIL_EXISTS. Clients that sent returning users to sign-in on EMAIL_EXISTS or EMAIL_NOT_VERIFIED from an anonymous check should offer a sign-in link instead, and clients that read the landing path from a password sign-up response should land on their default after verification.
• When you connect an agent by URL and your Agents account already has an agent of the same kind registered with no URL, Apostra now lists it. In the Connect an agent task you can connect the URL to that agent or register a new one, and the save_agent preview returns the same list as waitingAgents, so an assistant sends that agent’s agentId with the URL instead of making a second agent. Nothing changes for an account with no agent waiting for a URL.
• An organization’s proved domain now also becomes its approved registered domain. When an organization proves the domain it claims, by a DNS TXT record or an Apostra review, that one proof covers what its accounts operate as at sellers, email auto-join to the organization, and single sign-on eligibility. If another organization also claims the domain, a passing DNS check goes to Apostra staff review instead. The membership docs now describe auto-join accurately: a matching-domain request is approved without waiting for an administrator, and the person still signs up or accepts. See Your organization’s domain.
• Pinterest product discovery no longer shows a fabricated CPM floor price or a delivery forecast built from it. Pinterest gives us no real price signal at discovery time, so the per-template floor we authored ourselves was always a guess, and the “estimated impressions” forecast on the recommended proposal was computed from that same guess. We now leave floor price, price guidance, and that forecast out of the response entirely rather than show numbers that look like real platform guidance but aren’t.
• The public Rate Card no longer shows internal revision names. The page at app.apostra.com/rate-card labels each Rate Card by its dates, for example “Effective Oct 21, 2026, ended Oct 21, 2026”, and an upcoming one by the day it takes effect. In the public read at GET https://api.apostra.com/agreements/rate-card, a revision’s name is now a label built from its effective date, such as IU Rate Card effective 2026-10-21, rather than an internal name; the field is still there. Use publicVersion to tell revisions apart. Plans, prices and IU charges are unchanged.
• An advertiser you create or change in the chat’s advertiser form now shows in the left navigation straight away, without reloading the page. This covers both buyer and seller accounts.
• Reddit product discovery no longer shows a fabricated CPM floor price. Reddit gives us no real price signal at discovery time, so the floor we authored ourselves for each product template was always a guess, and it was applied regardless of account currency. We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• You can now register a sales agent that requires credentials for every call; it is read when your Seller account connects it.
• When save_agent reaches an agent that refuses the read for missing credentials (an HTTP 401 or 403, an OAuth challenge or the AdCP authentication error), send the same call again with kind: "sales" and without dryRun. Apostra records the URL as the agent’s address and marks the agent not read yet (states.notReadYet). In your Seller account, connect the agent with save_inventory_source and its agentId, then store its credentials in the secure credential form. Apostra reads the agent with those credentials and records what it read on the agent. Credentials stay on the source and are never collected on the Agents account or in chat. A URL that cannot be reached, a timeout or an answer that is not an AdCP agent still fails and creates nothing.
• Sellers on Apostra are no longer charged a Brief response for answering a brief from a sandbox advertiser. Buyers can test briefs against real sellers with a sandbox advertiser as often as they need without running up their sellers’ bills, and the seller’s Storefront still answers each sandbox brief in full.
• Universal Ads product discovery and proposal responses no longer show a fabricated CPM floor price. Universal Ads gives us no real price signal at discovery time, so the floor we authored ourselves per product template was never more than a guess, and we were showing it on every product regardless of account currency. We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• One change affects campaigns you already run: product discovery now leaves out a seller reached through a media partner until that seller has reported your account active, so you only see products you can buy.
• It comes with features that were in beta and are now part of the standard buyer experience, which every buyer account gets when it is created, on every plan including Free:
• Booking answer: whether a media buy still matches what was booked
• Operator fees: an operator organization adds its own fee to a campaign
• A campaign’s target and suppress audiences go to sellers
• A notification when a live package falls well behind its pace
• Property scores: save them, and filter property lists by score
• Still in beta: Google Analytics 4 and Apostra’s own UTM tags, chatting with a hosted buyer agent in Apostra, scheduled buyer-agent runs in Slack, and the hosted buyer agent’s V3 connection.
• A widget opened in the Apostra web app no longer shows “Couldn’t load this view” because you switched to another tab while it was starting. It now finishes loading when you come back.

​

5.1529.0 — November 3, 2026 at 12:00 AM UTC

• Apostra support staff with an approved, time-limited elevation on your account can now help with its members: list them, invite someone, resend or cancel an invitation, change a role or remove a member. Each change is recorded under the staff member’s own name.
• In the Library, renaming a document, editing its description, adding a note, rewriting a note and Retry upload on an unfinished draft now save. Before, each was refused and showed an error.
• Organization admins can now connect their organization’s own sales agent from any of its Seller accounts, and see the account’s sales agent list.
• Refreshing a sales-agent source’s health now updates the product format check, so a fixed catalog stops showing as unmappable. Before, the “products cannot be mapped to a canonical format declaration” warning stayed until a buyer’s request happened to reload your products.
• Snap and Spotify product discovery and proposal responses no longer show a fabricated CPM floor price. Neither platform gives us a real price signal at discovery time, so a floor we authored ourselves was never more than a guess - and for Snap, any non-USD account was already showing it as zero, while Spotify showed the same made-up number regardless of currency. We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• A sales agent that returns its AdCP error as a bare array of error entries, without the errors wrapper, is now read as an AdCP error in source diagnostics instead of being reported as unclassified, and a VALIDATION_ERROR says the source rejected the request and points you to its message, without claiming the request was Apostra’s. The agent behaviour check “Returns machine-readable errors” now reads the same error shapes, so an agent that returns a standard code in an errors array or an adcp_error envelope passes, and one that returns a bare array gets its own flag with a correctable action.
• The web app no longer makes requests a seller account isn’t allowed, which could show errors in the background. Pages that need data an account or member can’t read now say so instead of showing an error or an empty list.
• Asking for an advertiser you cannot use now gets the same refusal whether the advertiser belongs to another organization or does not exist, so an advertiser ID no longer reveals whether it is in use elsewhere. The refusal reads “Advertiser N was not found or you do not have access to it.” The internal advertiser and creative cleanup routes also answer 404 for another organization’s advertiser or campaign, as they do for a missing one.
• Dates stored as a calendar day now show that day wherever you are. Before, viewers west of UTC, including everyone in the Americas, saw the day before. This affected the IU cycle dates in Plan & Billing, campaign flight dates in the Murph creative workspace, the reporting period on the Partner Fleet page, and the Rate Card effective date when you choose a storefront plan at sign-up. Nothing changes on your side; the stored dates were always correct.

​

5.1528.0 — November 2, 2026 at 10:47 PM UTC

• In the Apostra web app, the creative composer now lists the formats you can build for and generates copy for its slots. Before, the format list stayed empty and generating copy failed with an error.
• Pages such as an agent’s Activity now keep working in the Apostra web app when they stay open past 15 minutes. Before, their access could not be renewed in the web app, so their reads started failing once it expired.
• Anyone can now read the current IU Rate Card, any upcoming change with its date and what differs from today, and past versions at app.apostra.com/rate-card, without signing in. The page is also linked from the Account menu.
• A media buy that would reach a seller with no creative on any of its packages is now refused before it is sent, instead of being lost.
• Some sellers require at least one creative per package and refuse the whole booking without one. That refusal is final: the media buy fails and can never be edited or launched again. Until now a buy could reach that point with nothing to warn you, because a creative that synced and was approved sits in the seller’s library whether or not it is attached to the buy.
• Apostra now checks before it sends. When the buy has no creative attached and its campaign holds creatives its products accept, the launch is refused with INVALID_REQUEST and reason: "NO_CREATIVES_ATTACHED", naming those creatives. The buy stays a draft you can correct: attach them, then launch again. A buy whose campaign holds nothing its products accept still books without creatives, so a buy whose creatives genuinely come later is unaffected. A buy whose creatives are all waiting on the seller’s review is not refused this way: it books now on a seller certified to accept a buy with no creatives, or waits for the review.
• Apostra no longer tells you a request failed when it is only waiting for your approval.

​

5.1526.0 — November 2, 2026 at 8:51 PM UTC

• Anyone can now read the published IU Rate Card without signing in, at https://api.apostra.com/agreements/rate-card: the revision in effect now, any published revision that takes effect later with the date its notice went out, and past revisions. It shows public plans at list price in every currency they are priced in, with each activity’s IU charge, from the same revisions billing uses. See Plan & Billing.

​

5.1525.0 — November 2, 2026 at 8:11 PM UTC

• A media buy whose only creative is still in the seller’s review now books at once when the seller’s certification shows it accepts a buy created with no creatives, instead of waiting for the review. The creative stays held, owned by the seller, and attaches when the seller approves it, so you no longer lose flight days to the review. Sellers without that certified evidence keep the hold: the buy waits and books when a creative is accepted. A line item you set to startRequiresAllCreativesApproved: true still waits, and a creative you have to fix (rejected or superseded) still refuses the booking with CREATIVE_ACTION_REQUIRED.
• An AdsWizz inventory source that was withheld from buyers because its execution currency had never been confirmed now clears itself. Interchange reads your AdsWizz agency’s own currency and, once AdsWizz has answered, the source becomes buyable within fifteen minutes, with nothing for you to do. The currency you enter on the connection is never treated as proof; the agency’s answer is, and a currency your storefront does not settle still keeps the source withheld. If the read cannot complete, the Ad-server execution currency row on the source says why: credentials that cannot reach AdsWizz, or a key that connects but cannot read the agency record. Google Ad Manager, FreeWheel and SpringServe sources are unchanged.

​

5.1524.0 — November 2, 2026 at 7:42 PM UTC

• The Connect an agent card Apostra opens in chat now works; it no longer stops with “Page launch authorization was not received”.
• My agents is now the one page that lists every agent in your Agents account. It shows every agent, not just the first ten, and you claim agents Scope3 mapped to you from the same list. “Build an agent” is no longer a separate page: you connect an agent from My agents, and its guides (Build an agent, Connect an agent and Agent requirements) are linked at the bottom. open_agents_page still works and opens My agents.

​

5.1523.0 — November 2, 2026 at 6:23 PM UTC

• An agent’s Overview now gives you a button for each fix it names, such as running the test again or setting up a buyer agent’s credential. It also links to the agent’s Activity, Sources and Webhooks, and each of those pages links back to Overview.
• A fix you can make on Apostra has a button that does it: Review and claim a mapped agent, Check the proof of control or Run the test again (Apostra reads your agent at its URL again), Start the conformance test for a creative agent, Set up a credential for a buyer agent, and Open the inventory sources. A fix that is a change to your own agent’s code has a button that opens its explanation. A button that changes something shows only to the person who directly administers the account that owns the agent. Everyone else sees the explanation links and the buttons that only open a page. After a change, the page reads the agent again and shows what Apostra now sees.
• Sessions now appears once in your navigation, under Operate, as the single record of buyer exchanges and conversations. The tools for teaching and testing your agent, Interview and the Simulator, now sit in a Training section under Storefront agent, and Interview has a See sessions link that opens your own conversations in Sessions.
• When your sales agent fails a product discovery call, the diagnosis now reads the AdCP error from the errors array as well as the adcp_error envelope, and explains a standard code by what it asks of you. A call your agent ends as failed with no error, or with zero products and no error, is now named as its own cause, with the identifiers to give your agent’s operator, instead of being reported as an error Apostra could not classify.
• Fewer “Couldn’t load this view” errors on more in-chat views. The connect sales agent, agent inventory source, agent signals, agent sync diagnostics, source discovery preview and creative engines views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.
• Fewer “Couldn’t load this view” errors on more in-chat views. The media buys, media buy retry, media buy timeline, creative composer, creative library and creative variant gallery views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.

​

5.1522.0 — November 2, 2026 at 5:19 PM UTC

• The Buyer Setup checklist now loads and saves through V3: your company details, payment terms, seller connections and each next step. The step that asks for your billing details is now called Billing details instead of Buying readiness; everything else looks and works as before.
• Fewer “Couldn’t load this view” errors on more in-chat views. The agent, agents, agent sources & credentials, create agent, configure agent connection and register observed agent revision views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.

​

5.1521.0 — November 2, 2026 at 4:11 PM UTC

• A seller whose agent AAO lists as opted out now sees “AAO: opted out” on the storefront’s compliance check, with who can change it, instead of “0 of 1 inventory sources passed”. Pending, degraded and failing agents are shown as themselves too, and an agent AAO scores as passing under its bare origin is no longer reported as failing because its full endpoint was not. The check stays advisory and never blocks going live.
• On the buyer status read with include: ["setup"], setup.sellers.truncated is now false on the last page of sellers. It was true on every page when there was more than one; nextCursor was already right.
• A creative-delivery operation whose creative the compatibility filter had already excluded from the seller update could still retry several times and surface a generic seller rejection instead of the specific missing format slot. It now recognizes its own already-known drop immediately, fails once with the actionable reason (and the correct “fix the creative” next step) instead of retrying a call that can never succeed.
• Connected TikTok campaign tracking now ignores unrelated same-account ads and ad groups so campaign status continues to synchronize.
• Emails about a media buy that the inventory source rejected, or one that is stuck at the inventory source, now suggest a question to ask your agent, such as “Why was media buy mb_123 rejected by the inventory source, and what needs to change?”, as creative rejection emails already do.
• Listing measurement records now supports cursor pagination. When more records follow, the response includes meta.pagination.nextCursor; send it back as cursor to get the next page without the API re-reading every record before it, which keeps deep pages fast. Offset paging with take and skip works as before. Records that share a window start now come back in a fixed order (by timeWindowStart, then id), so pages no longer repeat or skip them.
• Fewer “Couldn’t load this view” errors on more in-chat views. The seller account feed, seller accounts, seller dashboard, seller dashboard (V3) and seller setup views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.

​

5.1520.0 — November 2, 2026 at 2:41 PM UTC

• An agent can now ask the buyer status read for the full setup checklist and every seller, with the next step on each as a tool call.
• Call get_status with include: ["setup"] on a buyer account. The result adds setup: every check (complete or not) with its next step, 25 sellers a page with their status, billing route and next step, the billing facts, and whether a first campaign has launched. Page through sellers with sellersCursor. Only buyer accounts accept include and sellersCursor; other accounts are refused with a message naming the field.

​

5.1519.0 — November 2, 2026 at 1:42 PM UTC

• The advertiser form now saves through V3. The free-text description field is no longer shown when you create or edit an advertiser; channels and brand countries work as before.

​

5.1518.0 — November 2, 2026 at 1:05 PM UTC

• The buyer status read now shows what the AgenticAdvertising.org registry knows about your company, as the web app does, and lists missing billing details as a blocker for consolidated-billing buys.
• Show Spotify’s cached creative formats, including the required companion image slot on audio formats, in creative format discovery and the Creative composer as soon as a buyer has an active Spotify connection — before the advertiser is mapped to a Spotify ad account.
• When a creative’s format doesn’t fit a media buy’s required slots, the creative-delivery operation for that media buy now reports why: the incompatible slot (and asset type) the creative was missing, instead of quietly completing and leaving the buyer to see only a generic “no creatives attached” status.

​

5.1517.0 — November 2, 2026 at 12:20 PM UTC

• Asking for access to your company’s account now reaches a person even when the account has no administrator. Our account team picks the request up, emails you when you have access, and signup now tells you so and gives you support@apostra.com for questions.
• OpenAI Ads now refuses a daily budget it cannot honestly deliver. A daily_budget_cap is refused because an OpenAI Ads daily budget is an average over a Sunday-to-Saturday week (a day can spend up to 2x it, a week up to 7x), not a hard ceiling. To ask for that averaged budget instead, send ext.openai_ads.daily_budget_target in the account’s currency. A daily budget below OpenAI’s published minimum for the account’s billing currency (for example 25 USD or 15 GBP) is refused with BUDGET_TOO_LOW, carrying minimum_budget and currency, and a currency OpenAI publishes no minimum for is refused rather than guessed. The check against the buy’s total budget now counts the most the averaged budget can spend (2x per day, 7x per week) instead of the daily amount times the days. Once a flight has begun on a daily budget, its daily budget, total budget and flight dates can no longer be changed through Apostra, and a lifetime buy cannot move to a daily budget, because the budgets the campaign has carried and what it has spent are not kept to check a change against the total; pause or archive the buy instead, or take its daily budget back to a lifetime budget.
• A publisher domain added to your property roster now reaches your managed sales agent. Before, a domain added to the roster after your last business-profile save was never recorded there, so save_wholesale_product refused it with publisher_domain_not_authorized and the roster re-check reported pushedToManagedAgent: false. Re-checking such a domain on the roster now records it on the managed sales agent without removing any domain it already holds, so a domain that was stuck unrecorded is repaired by one re-check.
• A publisher domain on your property roster that never reached your managed sales agent is now repaired automatically, by the background check, a few domains per minute. You no longer need to re-check the domain yourself for it to become usable in save_wholesale_product.
• Reading an advertiser on V3 now returns its channels and brand countries, with a flag for each that says whether the advertiser has answered, so an agent can check what it saved.

​

5.1516.0 — November 2, 2026 at 11:20 AM UTC

• A proposal’s product rows now say when the seller’s inventory is synthetic. Reading get({ kind: "proposal", include: ["products"] }) for a Demo Storefront or the Apostra synthetic seller returns synthetic: { label, disclosure } on every product row, and the text of the read repeats the disclosure, so an agent can tell sample data from a real publisher’s inventory. The field is absent for every other seller. If Apostra can’t tell whether a seller is synthetic, the products read fails with SERVICE_UNAVAILABLE instead of showing unlabelled products.
• When Apostra cannot read one of your connected ad accounts because the ad platform will not show it to the user who connected it, you now get a notification in the app and an email telling you which ad account it is and how to fix it: reconnect the platform as a user who has access to the ad account, or map the ad account you meant to the right advertiser. You get it once for each connected ad account, and again only if the account is denied again after it has read in full.
• When a seller turns a buyer’s creative off, or turns on a creative the buyer didn’t assign, directly in Google Ad Manager on a line item booked through the sales agent, the change now appears in the account change feed within one change-detection pass (about 10 minutes). Storefronts no longer have to poll every buy to notice it.
• A GAM package that is behind pace now says why. Its snapshot in the buy read carries a pacing index and, when it is underdelivering, one reason (outbid by higher-paying line items at the same priority, matching inventory too short, or no competing demand) with the numbers behind it.
• A GAM package that is underdelivering now reports why in AdCP’s standard package indicators: an inventory shortfall forecast when matching inventory is too short, or a pacing risk when the package is outbid or has no competing demand to blame. Each carries the numbers behind it, and a package that has caught up reports an evaluated, empty list.
• Creatives the sales agent creates in your Google Ad Manager network now end their name with the buyer’s creative id, for example “Spring banner 300x250 [adcp:cr_123]”. You can see at a glance which buyer creative a GAM creative came from. Names of creatives already in GAM don’t change, and renaming one in GAM is fine.
• If a creative ever ends up with two active copies on one of your Google Ad Manager line items, the sales agent now turns off the extra copy automatically within the hour, keeping the one it trafficked. Creatives you added in GAM yourself are never touched.
• New creatives can again be uploaded to FreeWheel sellers whose filtered creative lookup reports a missing external ID as HTTP 404.
• Changing a tenant’s ad server through the adapter-config API now updates the ad server reported on the tenant and used across the sales agent. Before, parts of the sales agent kept treating the tenant as being on its previous ad server.
• Cancelling a live Google Ad Manager video buy now stops it. Before, the seller refused the cancel and the buy kept delivering until its flight ended.
• Assigning a creative to an already-booked media buy on SpringServe, AdsWizz or Broadstreet used to report success even though the creative never reached the ad server. The sync now refuses that assignment and says to include the creative when the media buy is created. Nothing changes for Google Ad Manager or FreeWheel.
• Price guidance on auction pricing options now says where it came from: measured from the seller’s ad server delivery (with the reporting window, impressions, line items and countries), set by the seller, or no data. Guidance is measured for the country a buyer filters to, or the one country a product targets, and a country with too little data no longer borrows network numbers.
• Scheduled GAM syncs and pricing and availability updates stop failing when the sales agent’s database runs out of connections.

​

5.1515.0 — November 2, 2026 at 10:21 AM UTC

• In the Media partners page, an advertiser whose connected ad account Apostra cannot read now says so on its row: which ad account, why (the platform won’t show it to the user who connected it, or the connection authorisation is expired), and what to do. For a denied ad account the row offers Change account so you can map the ad account you meant to the advertiser; for an unusable authorisation it asks you to reconnect the platform.
• Organization administrators can now accept Terms, accept or switch plans, answer a private offer, change a renewal, ask for plan help and set up a card from the Plan & Billing Page. This works in the Organization session and for an organization administrator working inside a child account. Before, those sessions were refused, so these steps could not be completed there. Anyone who is not a direct administrator of the billing organization is still refused.
• In an Agents account, the page that lists your agents, their stages and what to do next is now called My agents. It was called Developer home. Nothing on the page changes.
• The guide to connecting an agent moved to /v3/connect-an-agent. Links to the old /v3/developer-agents address redirect to it.
• An OpenAI Ads media buy with a daily_budget_cap under $25 a day on a US dollar account is now refused before anything is created, with a message that names the $25 minimum and the cap you sent. OpenAI Ads refuses a smaller daily budget, and the refusal used to arrive only after the buy had been sent. Other currencies are unchanged: Apostra does not know their minimum, so OpenAI Ads decides.
• A connected Snap ad account no longer fails to import because one ad squad has targeting Apostra cannot represent. The campaign is now mirrored with its name, status, budget, dates and creatives, and the setting that was left out is named in the media buy’s unrepresented list: the squad’s regions (Snap’s own region ids cannot be mapped to a country region), or its whole targeting if none of it can be shown. Do not describe such a squad’s targeting as complete. Squads you created through Apostra are unchanged.
• In the web app, on Connections > Advertiser mapping, an ad account that Apostra cannot read now says so on its row, and the row offers a way to reconnect. It says whether the platform won’t show the ad account to the user who connected it (reconnect as a user who has access, or map the ad account you meant to the right advertiser), or the connection authorization is expired, revoked or missing a permission (reconnect and grant every permission it asks for).

​

5.1514.0 — November 2, 2026 at 8:39 AM UTC

• When Apostra cannot read a connected ad account and only you can fix it, the connection now says so. Its required action becomes “reconnect” when the platform authorisation is unusable, or “map account” when the platform will not show your connected user that ad account, and the connection text names the ad account, the problem and what to do. Each discovered account also lists the campaigns the platform reported, how many Apostra mirrors and how many it leaves out.

​

5.1510.0 — November 2, 2026 at 3:58 AM UTC

• Saving a Library draft no longer fails when its description is left blank, and Save and update prices or Save and update avails now saves a reviewed rate card or avails sheet. Before, both saves failed with an error and the draft stayed a draft.

​

5.1508.0 — November 2, 2026 at 3:27 AM UTC

• An unexpected error while reading one campaign in a connected ad account no longer stops the rest of the account from importing. The other campaigns show as usual, and the one that could not be read is named in the account’s coverage as unreadable, with Scope3 investigating. This holds for every ad platform Apostra syncs, not only Meta.

​

5.1507.2 — November 2, 2026 at 2:58 AM UTC

• The guide to moving a v2 buyer REST integration to V3 no longer says V3 lacks goal progress. get_delivery with report: "campaign_delivery" returns each campaign’s and media buy’s goal progress in goalProgress; only the v2 pace figures have no V3 equivalent.

​

5.1507.1 — November 2, 2026 at 1:22 AM UTC

• Apostra’s background checks now use one connection per check and back off when your agent rate-limits them, so they send far fewer requests.

​

5.1503.0 — November 1, 2026 at 9:00 PM UTC

• Campaign Pulse shows whether a campaign is running, from the latest figures its sellers reported. Opt in with include: ["pulse"] on get or search with kind: "campaign"; nothing else changes. get returns the campaign verdict and, for each active media buy (up to 50), a verdict, impressions, clicks and spend. search adds only the campaign verdict, dataThrough and nextCheckAt, the earliest time a verdict can change without a new report. Figures are provisional Snapshot figures, not billable; official reporting is separate. Missing figures are never shown as zero. See Campaign Pulse.

​

5.1502.0 — November 1, 2026 at 4:34 PM UTC

• V3 seller reads now name the advertiser’s account at a media partner sellerAccountMappingId. Each entry in controlPlane.activation.advertisers carries it beside the old sellerAccountId, which holds the same value, is deprecated, and will be removed in a later release.
• The old name was easy to misread. That value is the media partner’s own id for the advertiser’s account (for example sf_accuweather_…), not the media partner’s Account id, which is the sellerAccountId at the top of the same seller object. If your agent reads the activation entry, switch it to sellerAccountMappingId now, and never send that value as a sellerAccountId. Nothing else changes: the value, null when there is no account, and every other field stay the same.

​

5.1499.0 — November 1, 2026 at 2:42 PM UTC

• OpenAI Ads media buys with a daily_budget_cap now launch. OpenAI Ads takes a campaign budget as either a daily limit or a lifetime limit, never both, and the earlier change sent both, so OpenAI refused the buy. A capped buy now sends only the daily limit and needs an end_time. We check that the cap times the days the flight touches in the ad account’s timezone (a partial day counts whole) cannot exceed total_budget, and refuse before creating anything otherwise, for example “a $20/day cap over 7 days could spend $140, more than the $100 budget; shorten the flight, lower the cap, or raise the budget”. OpenAI Ads then holds no total, so Apostra keeps the total you asked for and returns it unchanged as total_budget. Changing the cap, the flight or the total of a capped buy re-checks the same sum against that total, and packages[].budget changes it.

​

5.1497.0 — November 1, 2026 at 1:10 PM UTC

• Media buys now join the Session of the opportunity they belong to. A buy placed under a recorded opportunity appears in the same Session as the brief and proposals for that opportunity. If there was no brief, every buy under that opportunity shares one Session. Buys with no recorded opportunity, and buys placed before this change, keep a Session of their own.
• Pinterest catalogs: sync_catalogs now registers product catalogs as retail feeds and hotel catalogs as hotel feeds, and reports Pinterest’s processing status for each feed.
• Each catalog in the response shows how many items Pinterest ingested, rejected or is still processing, with item-level issues as warnings. A feed Pinterest cannot process comes back as failed with the reasons. Catalog types Pinterest has no feed for, such as flights or destinations, are refused by name instead of being stored as if they had been sent. Hotel catalogs can be registered and read back, but Pinterest has not yet been proven to serve ads from them, and they cannot be attached to a Pinterest catalog campaign.

​

5.1496.9 — November 1, 2026 at 11:58 AM UTC

• A Meta ad account with an ad set that Meta returns without any targeting no longer fails to import. The campaign shows, and the ad set’s targeting is named as a setting Apostra cannot represent.

​

5.1496.8 — November 1, 2026 at 10:15 AM UTC

• Meta campaigns whose ad sets optimize for a conversion Apostra cannot identify, use an optimization goal or bid strategy Apostra does not support, or pair a goal with an unexpected billing event now import. The campaign shows with whatever Apostra could read, and the goal, bidding or billing event it could not read is named as a setting Apostra cannot represent.

​

5.1496.7 — November 1, 2026 at 7:56 AM UTC

• Meta campaigns built on Meta’s original objectives now import. Where Meta defines an outcome-based objective for the original one, Apostra reads the campaign as that; otherwise the campaign shows without its goal and the objective is named as a setting Apostra cannot represent. A connected account’s coverage now counts every campaign left out by reason and by cause, however many there are.

​

5.1496.6 — November 1, 2026 at 6:58 AM UTC

• A catalog refresh that your agent rate-limits on its very first request is now retried instead of failing and leaving your source pending. Apostra also runs a source’s two health checks one after the other, so they no longer open two connections to your agent at the same moment.

​

5.1496.5 — November 1, 2026 at 5:20 AM UTC

• A Meta ad account with a campaign built on one of Meta’s older objectives, such as Link Clicks, no longer fails to import. The other campaigns in the account show as usual, and the older campaign is named as one Apostra cannot read.
• A Meta campaign that bids with a cost cap or a minimum return on ad spend now imports, where it used to be left out. The campaign shows with its goal, and its bidding is named as a setting Apostra cannot represent, so its bid and cost target are not stated.

​

5.1496.4 — November 1, 2026 at 4:23 AM UTC

• A large catalog refresh no longer gets rate-limited into failure and pauses your source. Apostra now reads your catalog on one connection with a short pause between pages, and when your agent answers HTTP 429 or a RATE_LIMITED error it waits and retries that page. If your agent still rate-limits the refresh, the check shows as degraded instead of unhealthy, so your source is not held out of go-live, and the next refresh tries again.

​

5.1496.2 — November 1, 2026 at 3:37 AM UTC

• A connected ad account that is not fully imported now says who has to act and what they do. The account’s coverage names the cause and its owner: you reconnect, you fix the advertiser mapping, the ad platform is limiting requests, or Scope3 investigates. Anything Apostra cannot classify is Scope3’s to fix.

​

5.1496.1 — November 1, 2026 at 2:37 AM UTC

• A Meta ad account with a campaign whose age targeting disagrees with its own age bounds no longer disappears from Apostra. The campaign appears with the age range named as a setting Apostra cannot represent, and every other campaign in the account shows as usual.

​

5.1496.0 — November 1, 2026 at 2:28 AM UTC

• Connected-account sync now adopts a campaign Apostra placed even when the ad platform’s response for it carries no account. Previously the sync tried to clear the account Apostra had stored for the campaign, the database refused, and the account’s sync stayed in error (seen on OpenAI Ads).
• When Apostra has a media buy recorded as completed that its seller never reported completed, and Apostra cannot read the buy’s status from that seller, Get media buy status now shows the buy as attention_required with the blocker seller_status_unreadable. The message names the seller and why it cannot be read, because the buy may still be running. Apostra no longer reopens such a buy from the old status its failing route last recorded.

​

5.1495.4 — November 1, 2026 at 2:00 AM UTC

• The Spotify adapter’s age-targeting ceiling was corrected from 65 to 99, matching Spotify’s own platform limit. The previous ceiling caused the adapter’s default age range (used when a media buy requests no age targeting) to send a value Spotify’s ad-category validation rejected, leaving the ad set with no age range selected and a “choose an available range” warning in Spotify Ads Manager. It also incorrectly rejected any buyer-requested age range above 65 (e.g. 70-90) as unsupported, when Spotify supports it.
• Spotify audio ad creation no longer uploads a second, unneeded “companion” image copy of the required ad logo, and no longer fails the whole ad build if that redundant upload fails. Confirmed against Spotify’s own Ads API v3 contract that only the logo image is required.
• Scope3 SuperAdmins can now schedule, review, and undo permanent Library document deletions from a directly authenticated browser session on the seller account.
• Wholesale product search, get, and request_proposals now show a seller’s minimum spend per package in the response text, not just in structured data. Previously a text-only host (or any caller reading only the response text) never saw a seller’s minimum package spend, so a buyer could book a budget below the minimum with no warning and have the buy fail at launch.

​

5.1495.3 — November 1, 2026 at 1:20 AM UTC

• Updating a media buy’s package budget or bid price now rolls back to the seller-confirmed value when the seller definitively refuses the change, instead of leaving the rejected value stored locally while the seller still has the old one. When the seller’s answer is inconclusive (a transient failure, for example), the requested value is kept rather than discarded, and the media buy is flagged for reconciliation instead of silently treating it as confirmed.

​

5.1495.2 — November 1, 2026 at 12:57 AM UTC

• A source that one failed catalog check had paused now recovers on its own: the next catalog check runs on the paused source, and when it passes the source goes live again. Seller RFP responses now offer only products from sources that buyers can book, so products from paused or disabled sources no longer appear.

​

5.1495.1 — November 1, 2026 at 12:37 AM UTC

• A media buy recorded as completed that its seller still reports running or paused now returns to that status within about a minute of the seller’s next status read, instead of at the next hourly check.

​

5.1495.0 — November 1, 2026 at 12:25 AM UTC

• Syncing a connected Google Ads account no longer fails when it holds an ended campaign. Google does not report when a campaign was created or last changed, so the sync used to reject the whole account for the missing dates. An ended Google campaign with no date is now left out of the imported history and counted as skipped, and the rest of the account syncs.
• Connected-account sync no longer fails on campaigns Apostra placed itself. A campaign placed through Apostra on Spotify, OpenAI Ads or any other connected ad platform is now recognised during sync and kept as one managed campaign, instead of the account’s first sync stopping with a duplicate error.
• Syncing a connected TikTok account no longer fails when TikTok lists the same campaign as both a standard and a Smart+ campaign. We now keep one record, the Smart+ one. If the two records disagree on the campaign’s name, objective, budget or status, the sync still stops and names the field that differs.
• A creative composed without a seller-specific format binding (for example a generic audio creative) stores its asset under AdCP’s canonical default slot id. When a seller’s own product format declares that same required asset under a different id — Spotify’s audio format uses audio instead of the canonical audio_main — the creative was silently dropped as incompatible and never reached the seller, with no error surfaced anywhere. Fixed so the canonical slot id and a seller’s own differently-named slot id are recognized as the same slot in both directions, so the creative delivers as expected.
• The Spotify adapter now sets an age range (18–65+) on every ad set it creates, even when the media buy requests no age targeting. Previously an ad set created with no age targeting was left with no age range at all — Spotify’s own validation rejected it as soon as anyone edited it in Spotify Ads Manager, with “Choose an age range.”
• Accounts in the buyer beta are told when a live package falls well behind its pace.
• When a package on an active media buy is below a pacing index of 0.8 after at least a tenth of its flight has gone, the account gets a campaign.unhealthy notification with reason: "package_behind_pace", once a week while the package stays behind. The pace is the seller’s own pacing_index; when the seller sends none, Apostra estimates it from the package’s budget and flight to decide whether to tell you, and does not publish the estimate. No existing field changes. See “Is each package on pace?” in the docs.
• Reading billing on V3 now returns the payment terms the account has set, so an agent can check what save_billing saved. The read carries paymentTerms and paymentTermsChosen, which is false while the net_60 default applies.

​

5.1494.0 — October 31, 2026 at 11:39 PM UTC

• Syncing a connected Snap account no longer fails with a rate-limit error when the account holds many campaigns. Snap refuses about fifteen reads in the same second, so we now keep at most four Snap reads running and start at most eight per second for a connection. A sync of a large account takes a little longer.
• A source whose agent cannot be read now shows a finding when Apostra holds buys on it as completed that the seller never reported completed, with the count and the read failure. Routes to a source that does not support AdCP 3 are read once a day instead of every hour.
• A Meta campaign built in Meta, with targeting Apostra cannot represent such as language, excluded geography or behaviours, now appears in Apostra with its name, status, budget, dates and the targeting Apostra can represent. Before, the whole campaign was left out. The settings Apostra cannot represent are left out of its copy and named in a new unrepresented list on the media buy and its packages, so a partial copy is never read as complete.

​

5.1492.1 — October 31, 2026 at 9:18 PM UTC

• You can now create an advertiser for your own inventory with any brand domain, including one that isn’t registered with AgenticAdvertising.org. Before, creation failed with a “brand not found” error even though the form said it would work. Buyers who enter a brand domain we can’t find now see clearer wording: check the domain, or register the brand before creating the advertiser.

​

5.1492.0 — October 31, 2026 at 8:50 PM UTC

• A new Agents account is now named after its organization followed by “Agents account”, matching the account type’s new name. Accounts created before this change keep their current name, and an administrator can rename one at any time.
• The Connect sales agent form no longer asks for an agent address when you have selected one of your organization’s agents. It asks only for a name, protocol and credential, and connects the agent at the address registered for it in your organization’s Developer account.

​

5.1491.0 — October 31, 2026 at 7:59 PM UTC

• Cap what a media buy spends in a day. save_media_buy now takes AdCP’s daily_budget_cap, and budget_cap_timezone for the zone the cap’s day runs in, when you create a buy from sellerAccountId and products.
• The cap belongs to the buy and is at most the buy’s total budget. If the campaign has a daily cap, the caps of its buys add up to at most that number, and a cap that would take the sum past it is refused with both figures named. The cap is saved with the draft and goes to the seller when you launch.
• A seller that cannot apply a daily cap refuses the buy at creation rather than dropping the cap. Today OpenAI Ads applies it. On an existing buy and on a proposal, daily_budget_cap is refused for now.
• The Source diagnostics Page now shows what you can act on for a source that a third-party sales agent powers: whether it is working, whether buyer requests reach it, the problems you own with their next step, one line for each problem someone else has to fix, the sales agent card, reporting, and the source’s settings. The calls Apostra makes to the sales agent are no longer shown to you. A call log, request and response bodies and protocol errors are for the agent’s developer on the agent’s Activity Page, and for Apostra staff. “Open agent” now shows only when you hold a role in the Developer account that owns the agent; being in the same organization is not enough. Nothing changes in how buyers reach your source, and you have nothing to set up. Through V3, get with kind: "inventory_source" and include: ["poweredByAgent"] returns canOpenAgent. With include: ["diagnostics"], recentActivity, transportRequests.requests, each finding’s evidence and the call identifiers in developerHandoff are empty and callDetailAvailable is false. A media buy’s timeline returns null for forwardedPayload and responsePayload on a leg whose calls you may not read, with callPayloadsWithheld: true, whatever the kind of its source, and Murph’s call lookups return no calls for those sources.

​

5.1490.0 — October 31, 2026 at 7:25 PM UTC

• Map an ad account to an advertiser and Apostra starts syncing that account’s campaigns, with no separate subscribe step. The first sync runs within about 15 minutes, and the campaigns appear under that advertiser as read-only tracked campaigns, including ones created directly in the ad platform. Accounts you mapped before this release start syncing too. You don’t need to do anything.
• Connected-account campaign sync does not add a charge. Enhanced Reporting keeps its existing pricing. This change affects buyers only; sellers see no change.
• If one connection reaches many accounts, as an agency login does, every account you have mapped syncs under its own advertiser, and accounts you have not mapped are never synced. Syncing is read-only: Apostra never creates, edits, pauses or cancels anything in the ad platform. Remove a mapping and the sync stops and Apostra’s copies of that account’s campaigns are retired. Nothing changes in the ad platform. Delivery history is not imported.

​

5.1488.0 — October 31, 2026 at 6:38 PM UTC

• When Apostra cannot read your Agent’s capabilities, source health now says exactly that, instead of saying a change-feed subscription could not be confirmed. The change_feed_capabilities_unavailable finding names you as the owner and says to make get_adcp_capabilities answer; it clears on the first read that succeeds. Buying is not affected.
• The account type where you build and manage agents is now called Agents. It was called Developer. The four account types are Campaign management, Storefront, Listing and Agents, and an organization still holds one Agents account.
• Nothing else changes. In the V3 API, accountType: "developer" is still the value you send and read, and the label in organization.addableAccountTypes now reads Agents. The web app, the V3 tool descriptions and messages, the invitation email and the documentation all use the new name.

​

5.1487.0 — October 31, 2026 at 5:48 PM UTC

• A campaign, ad set or ad edited in Meta Ads Manager now also brings forward the status check of the media buys booked through Apostra on that ad account, not only the sync of connected campaigns, so their status can update within minutes. The 30-minute target is unchanged, because Meta does not guarantee delivery.
• Test a brief on the AI Business Rules page now lists the briefs your storefront received, most recently active first, with the advertiser and when each was last active. Pick one to see how your rules treat it, instead of pasting the buyer’s request as JSON. After a test, All brief fields shows the complete request that was tested. You can still paste a request that isn’t in the list, and Use an example gives you one to start from. Nothing to change on your side.
• You can now say, line item by line item, whether a buy may go live before every creative is approved. Set startRequiresAllCreativesApproved: true on a save_media_buy line item when you create the buy, and that line item never starts with only some of its creatives. If a creative on it is still in the seller’s review, Apostra holds the buy, owned by the seller, and books it once every creative is approved. If a creative needs you to fix it, the booking is refused with CREATIVE_ACTION_REQUIRED and the buy stays a draft. Leave it out, or send false, and nothing changes: the buy books with the creatives the seller has approved and attaches the rest as their reviews clear. When the seller declares media_buy.features.creative_start_policy, Apostra also sends the seller AdCP 3.3’s start_requires_all_creatives_approved: true on the package, so the seller holds the package back as well. Set it when you create the buy: an update that names it returns NOT_IMPLEMENTED, and it cannot be changed on a booked buy yet.

​

5.1485.0 — October 31, 2026 at 4:58 PM UTC

• The canonical creative formats requirement (due 1 December 2026) does not need a move to AdCP 3.2: an agent on AdCP 3.1 meets it. The requirement now lists the steps in order. Publish canonical format_options on every product using AdCP’s own format_kind values, such as video_vast, audio_hosted or display_tag. Accept format_kind selectors on create_media_buy and sync_creatives. Then declare media_buy.features.canonical_creatives: true, last, because from then on Apostra sends format_kind selectors to your agent.
• Label Meta’s Facebook and Instagram creative formats as social, and show their cached format options in the Creative composer when the buyer has an active Meta account connection even before it is mapped to the advertiser.
• Connecting a sales agent your organization owns no longer asks for its address. Send the agent’s id (attachToAgentId) and the connection uses the address registered for that agent in your organization’s Developer account. If you also send an address, it must be the registered one; a different address is refused with the registered address named. An agent with no registered address is refused with the way to fix it: register its address in the Developer account first (save_agent with agentUrl).

​

5.1483.0 — October 31, 2026 at 4:04 PM UTC

• A brief’s decision on the Briefs page now shows which version of your AI Business Rules made it. The version always read as unavailable, because discovery checked a brief against your active rules without recording which version they were. Each new brief your storefront checks now records the version of the rules that were active at the time; briefs checked before this change still show it as unavailable.
• A media buy recorded as completed that its seller still reports running or paused now returns to that status within an hour, instead of staying completed until someone reads the campaign.

​

5.1482.0 — October 31, 2026 at 3:20 PM UTC

• The Organization account’s get_status now says which account types the organization can add. organization.addableAccountTypes lists Campaign management, Storefront, Listing and Developer, each with canAdd. A type that cannot be added also carries a reason and a nextStep, and the next step says whether you can take it or an administrator of the organization has to. save_account and its dryRun refuse a type with the same reason, because both come from one plan check.
• On the Listing plan, an organization can add a Listing account and one Developer account. Adding a Campaign management account or a Storefront account, moving one into the organization, or switching an account to Storefront is refused, and the next step is to move to the Standard plan. Accounts an organization already holds are not touched, and restoring or reactivating one is never refused because of the plan.
• save_account now takes sellingMode (listing or storefront) when you create a seller account. operatingMode still works as the older name for the same choice and is refused when sent with sellingMode; it will be removed once ChatGPT has approved the new definition.
• This is a breaking change to V3, which is a preview, with no alias for the old shape:
• organization.capacity (allowed, consumed, remaining, limit, denialReasons) is removed from get_status. Read organization.addableAccountTypes instead.
• The seller account type value storefront_agent is now storefront, on sellingMode in save_seller, save_account and the get({ kind: "seller" }) read, and in the save_seller result. Send storefront; storefront_agent is refused.
• The account types are named Campaign management, Storefront, Listing and Developer. A storefront is what a seller manages, and an agent is a separate thing attached to it, so the names in addableAccountTypes, its reasons and the docs say Storefront, not Storefront agent, and Campaign management, not Campaign agent. The label for the buyer type reads Campaign management and its accountType is still buyer.

​

5.1481.0 — October 31, 2026 at 3:11 PM UTC

• A connected ad account now says how much of it Apostra shows. Each account on a connection reports how many campaigns the platform has, how many Apostra shows, and how many it leaves out for each reason, such as a campaign Apostra cannot represent or an ended campaign older than the history window. Buyers and Scope3 support read the same numbers, and the documentation explains each reason.

​

5.1480.2 — October 31, 2026 at 2:30 PM UTC

• The Source diagnostics page now loads for a source whose agent answers with a large product catalog. The page showed “Could not load diagnostics. Try again shortly” because the recent-call evidence for such a source was too large to deliver. Each call’s evidence is now cut down to a bounded size, keeping its shape, and the newest calls keep their details.

​

5.1480.1 — October 31, 2026 at 2:20 PM UTC

• If every account you belong to has been deactivated, signing in now shows you any invitation you have to another account, and otherwise takes you to signup to set up a new account, instead of stopping at a “your account has been deactivated” page. This applies to sign-in with Google or another provider, SSO, and password sign-in with a verified email. The deactivated account is left as it is, so its administrator or support can still restore it. Token refresh, and password sign-in with an unverified email, still return 403 with error: "NO_ACTIVE_HOME_CUSTOMER" and reason: "ACCOUNT_DEACTIVATED".
• When your account with a seller is still being set up, Apostra now waits to send a creative on a draft buy until the account is ready, instead of sending it without the account. The seller reviews the creative once, under your account, and launch no longer stops to send it again.
• Live campaign delivery now says “nothing to read yet” for a campaign that has not started whatever way the provider fails the read. Before, only some failures did, so a campaign with a pending buy and no creatives could still return SERVICE_UNAVAILABLE “Upstream request failed” with a transient recovery. Separately, in V3 a campaign whose media buy has no stored provider route or identity now returns recovery: "terminal" and a suggestion not to retry, with the same details.reason of provider_media_buy_identity_missing, instead of recovery: "transient". Use campaign_delivery for stored delivery and ask support to repair the binding. The v2 tools keep their current response for that case.
• A Meta ad account with one campaign Apostra cannot represent, such as one that targets by language or excludes geography, now syncs every other campaign instead of none. The campaign Apostra cannot represent stays out of the saved search.
• Creatives now sync to a seller while one of your media buys has a change waiting for approval. Before, for sellers whose packages we match to products from our own booking records, every creative on that buy was refused with an unresolved-format error until the change was approved or withdrawn.

​

5.1480.0 — October 31, 2026 at 1:21 PM UTC

• When a certification step fails, you can now open the call and see exactly what Apostra sent your agent and what your agent returned. In your Developer account, each agent has a new Activity page, after Overview in the rail. To open it from Claude, ChatGPT or another MCP host, ask your assistant or call open_agent_activity_page with the agent’s agentId. There is nothing to turn on.
• Certification runs, newest first. Each run is a timeline of its steps. Each step shows when it ran, whether its calls succeeded, failed or are still pending, and a View call action. The step that reads your products has no call to view, because Apostra reads them from its stored copy instead of calling your agent.
• Other calls lists the calls that belong to no certification step.
• View call shows the request Apostra sent, your agent’s response, the HTTP status, how long the call took and any error. Values that look like credentials are masked. Each body is capped at 32,768 characters, and bodies older than 90 days are no longer available.
• The page includes calls from every seller’s storefront that uses your agent, because those calls went to your agent. Only the account that owns the agent can open the page. Sellers whose storefronts use the agent cannot. On Overview, a certification finding now has a View session in Activity action that opens the page at that run.

​

5.1479.0 — October 31, 2026 at 1:05 PM UTC

• Certification now checks that your agent accepts a media buy created with no creatives and holds it in pending_creatives. AdCP treats that create as valid, and AdCP 3.3 keeps a buy with no creatives in pending_creatives until creatives are assigned. When your agent is first certified, when what it declares changes, after a probe that did not pass, and once a week after a pass, Apostra sends your agent one more create_media_buy on the same product, account and budget, with valid packages and no creative_assignments, booked to start a day later. It cancels the buy as soon as your agent answers, and keeps trying until your agent confirms the cancel. If your agent refuses the create, or reports the buy in any other status (rejected, canceled, pending_start, active, paused, completed), an attention finding on the Agent page shows your agent’s own error code and message, or the status it reported. If your agent refuses or keeps the cancel for 12 hours, a second finding names the test buy. A timeout, an unavailable agent, a create held for a decision, or an answer with no status is not counted as a failure. These are findings only: they never make a use case fail and never stop a certification pass. What the check sends and how to clear it.
• When your agent refuses a buyer’s account request because it does not accept agent billing (BILLING_NOT_PERMITTED_FOR_AGENT or BILLING_NOT_SUPPORTED), you no longer need to ask Apostra support to send it again. Once you change your agent’s setup and Apostra’s daily account check passes on that inventory source, Apostra sends each refused request again on its own. Refusals for any other reason are left as they are.

​

5.1478.0 — October 31, 2026 at 12:30 PM UTC

• OpenAI Ads chat cards now state both text limits on the creative format. max_chars is the longest copy OpenAI’s API accepts (50 for the headline, 100 for the description), and recommended_chars is the length past which OpenAI Ads Manager warns the copy may be truncated (32 and 54). save_creative refuses copy over the first, naming the slot, the limit and your length, and saves copy over the second as written with a warning. The Creative Library shows a live count against both. A creative with copy over max_chars that reaches a sync is not sent, and its link to OpenAI reads failed with the reason creative_refused, and you must act.
• A video creative is now matched to a seller’s format when the facts measured from it settle the choice, instead of being left unresolved. A VAST tag measured at one rendition of an adaptive creative, or one measured before its size was read, previously matched no single declaration when a product offered the same format at several durations. The media buy was then created with no creative attached, and the seller rejected it at launch — permanently, because a rejected buy cannot be retried. The creative’s duration now picks the matching declaration in both cases, and a declaration the creative meets as it stands is preferred over one it would have to be trimmed or resized into.
• Spotify’s $250 minimum budget is now checked, and stated in get_products, only for ad accounts in US dollars, where it is exact. For an account in any other currency Spotify converts the minimum itself, so Apostra no longer claims a local figure and sends the budget to Spotify. If Spotify refuses a package’s budget as below its minimum, the error is BUDGET_TOO_LOW with the submitted budget and the account’s currency, and says to raise the budget and retry.

​

5.1477.0 — October 31, 2026 at 11:48 AM UTC

• The billing docs now show the plans and prices you can actually choose. Every public plan is priced per IU, with no monthly commitment: $5, €4.50 or £4 per IU, depending on your organization’s currency, and Listing is free. The docs no longer list 250-IU and 1,000-IU commitment plans, which were never offered, or the calculator built on them.
• A seller whose storefront approves creatives automatically can now have every creative filed as a review that approves itself, so it is delivered with the same retries, follow-ups and media buy release as a manually approved creative, and shows the platform’s own approval once the platform gives it. It is off for every seller until the seller’s feature profile turns it on; staging sellers on the beta profile have it on.
• The OpenAI Ads adapter now applies an AdCP daily_budget_cap as the campaign’s daily spend limit when it creates or updates a media buy, checks that OpenAI Ads kept it, and reports it back with budget_cap_timezone on get_media_buys. A cap must be at least 1 currency unit and no more than the lifetime budget, and null removes it. OpenAI Ads counts the day in the ad account’s timezone, so a different budget_cap_timezone is refused, and a package-level cap is refused because the cap covers the whole media buy. The V3 save_media_buy tool does not carry the field yet.

​

5.1475.0 — October 31, 2026 at 10:03 AM UTC

• The v2 buyer API is closed to new API clients and will be switched off on 1 December 2026. If you are building a new integration, use the V3 HTTP API: a call to /api/v2/buyer or /mcp/v2/buyer from a new client now returns 410 GONE with a pointer to V3. Accounts that used the v2 buyer API in the last 30 days keep working until 1 December. The one exception is the conversion endpoint, POST /api/v2/buyer/advertisers/{advertiserId}/log-event, which stays open to everyone with no end date, so conversion events sent from tools such as Hightouch keep working; V3 also offers log_event. To move an existing integration, follow Move a v2 buyer REST integration to V3.

​

5.1474.0 — October 31, 2026 at 6:09 AM UTC

• In a Developer account, Home now shows where each agent is on certification and who has to act. Each agent has a row with its stage (Not started, Testing, Waiting on you, Waiting on Apostra, Waiting on the seller or Certified), its next step and who acts on it. Choosing a row opens that agent. Whether an agent is verified as yours is no longer a status: an unverified agent’s next step says so.
• When your account has exactly one agent, you now land on that agent’s Overview instead of on Home, with Home still in the left rail. With no agents you land on Home, built around connecting the first one. get_status returns the same answers for your coding assistant: certificationStage on each agent, and landing for where to land. Who acts comes from the headline finding’s owner.
• Home lists your agents, then Connect an agent, then “Work from Claude Code or Codex”, which gives the MCP address, the install commands for Claude Code and Codex, and the sentence to say (“Connect my agent”, then “Get my agent certified”), then one row of links. “Review and claim” now opens from an agent’s page in the web app. Connecting an agent is now called “Connect an agent” everywhere, and the top finding is called “Next step”.

​

5.1473.0 — October 31, 2026 at 5:06 AM UTC

• V3 get and search now return a wholesale product’s inventory in the shape save_wholesale_product takes, so an agent can read a product, change one setting, and send the whole inventory back as it is.
• inventory.execution now uses the same names a save takes: selectors[].selector_type, selectors[].external_id, format_bindings[].format_option_id and so on. A selector’s options and a format binding’s adapter_config come back as { key, value } entries, one per setting. Reads used to return these names in camelCase (selectorType, externalId, formatBindings) with the settings as nested objects, so an integration that reads those names needs to switch to the snake_case names. publisher_properties is unchanged.
• Setting names inside options and adapter_config now come back, and are sent to the ad server, exactly as written. Before, the platform changed their casing on the way in and out, so a name such as slot_1 or adSlot could be altered.

​

5.1472.0 — October 31, 2026 at 3:46 AM UTC

• Every finding on a sales, creative or buyer agent now says who has to act. Each carries an owner: agent_developer for whoever builds and runs the agent, seller for the seller whose storefront uses it, apostra, or null when nobody has to act yet, such as a certification run still collecting live traffic. A failed certification use case now names the change for the check that failed, and a use case whose agent is holding our certification creatives for review says so and names the agent’s developer as the one to act. A use case shows its newest run first, so an earlier failure no longer hides a later run. While a headline finding leads, the text of get, search and get_status and the Overview page show only that headline: they leave out stuckOn, the agent’s nextAction and certificationNextStep, which still come back in the structured result until their removal date. Source diagnostics read through get with include: ["diagnostics"] now name whoever runs the agent behind a source agent_developer instead of operator, and a use case result on the agent read now also carries failedCheck and skipReason.

​

5.1471.0 — October 31, 2026 at 2:43 AM UTC

• A campaign launch that fails on a creative you have to fix now really does free your retry.
• Two earlier changes meant to park such a launch for you, but the launch path rewrapped the failure twice and dropped the hint both times, so it was still queued for automatic retries and your own retry was refused as “already in flight”. The hint now survives the last step too, so you can fix the creative and launch again straight away. A launch that is really queued or being sent still refuses a second launch and says why.
• The V3 save_wholesale_product tool now describes its inventory in full, so an agent can see every field it may send instead of guessing from a description.
• inventory has execution (adapter, selectors and format_bindings) and publisher_properties, which are AdCP publisher selectors. A selector’s options and a format binding’s adapter_config depend on the ad server, so they are sent as { key, value } entries, one per setting. The key is the path to the setting, such as include_descendants or creative_placeholders[0].slot_id. A value can be a string, a number, a boolean, a list of strings, null, or an empty object. A read still returns inventory exactly as stored.
• The earlier open inventory, where options and adapter_config are objects, is still accepted for now. We will remove it later, so move to entries when you next update an integration.

​

5.1470.0 — October 31, 2026 at 2:25 AM UTC

• Buyer reporting now returns the seller’s own package id beside Apostra’s, so you can join landing-page sessions to delivery by package. When one creative serves several packages, the seller fills {PACKAGE_ID} (and the utm_package tag Apostra adds) with its own id, which reporting did not return until now. GET /api/v2/buyer/reporting/metrics adds sellerPackageId to each package in the summary view and to each timeseries row, and the CSV export adds a Seller Package ID column at the end. Match the id on your URLs against packageId or sellerPackageId. See Get reporting metrics.
• If the Sessions page can’t finish opening, it now offers a reload after 15 seconds instead of showing “Loading Sessions…” indefinitely. A buyer proposal opened from Sessions also shows right away instead of waiting behind that loading message.
• V3 save_signal publishes a price as AdCP’s pricing options without the open ext field, so strict-schema hosts such as OpenAI can use the tool.
• A price that carries AdCP’s ext is still accepted and stored as sent. Nothing you send today is refused.

​

5.1469.0 — October 31, 2026 at 1:22 AM UTC

• In a chat with your hosted buyer agent for an advertiser, the agent is now told which advertiser the chat is for, by name and id, along with the account you are viewing. Questions like “how is this advertiser’s campaign doing?” reach the agent knowing which advertiser you mean, so you no longer have to name it. This is context only: the agent still acts only for advertisers your organization granted it access to. See Chat with your buyer agent.
• When certification has no test creative it can generate for the format a product declares, such as audio_daast, the result for that use case now says so plainly. It is Apostra’s gap to close, not a defect in your product, and there is nothing for you to change. Before, the family was skipped as buy_creative_channel_unmatched with text that said Apostra support would supply a creative, and nothing tracked the gap. Now the result names the format and says there is nothing for you to do, Apostra tracks the gap itself, and the use case is tested in a later run once Apostra can supply a creative for it.
• A campaign launch that fails on a creative you have to fix now frees your retry at once, as intended.
• An earlier change meant to park such a failed launch for you, but the launch path rewrapped the failure and dropped the hint, so it was still queued for automatic retries and your own retry was refused as “already in flight” for several minutes. The hint now survives, so you can fix the creative and launch again straight away. A launch that really is queued or being sent still refuses a second launch, and says why.
• In a chat with your hosted buyer agent for the whole account, “open the creative library” now opens the Creative Library in the chat instead of the agent replying with a link. Apostra picks the advertiser for you: if your account has one advertiser it opens that one, and if you name one of your advertisers (“open the creative library for Chalk Lines”) it opens that one. If you have several advertisers and don’t name one, the message still goes to your agent as before. See Chat with your buyer agent.
• An administrator of your organization can again approve or reject a creative review or media-buy approval on any of its Seller accounts, even when that account has administrators of its own. Until now they were refused with “This approval is assigned to another audience”. The approval still goes to, and notifies, the account’s own administrators; organization administrators are notified only when the account has none. An approval whose routing names particular people, and no role, still goes only to them.
• A media buy’s attached creatives could silently disappear even though nothing was ever removed. When a seller’s read-back of a package reported creative_assignments as present but empty, the platform treated that the same whether the seller had genuinely confirmed the creative was removed or the seller simply never received the attachment because delivery to them had failed — and either way wiped the buy’s recorded creatives, showing the buy as having none attached. Creative assignments are now only cleared on an empty read-back when no delivery to that buy is known to have failed; otherwise the previously recorded creatives are kept until the failed delivery is retried and resolved.
• When your access to an account is refused, the app now says so (“Can’t open this account”) instead of saying it couldn’t verify your organization’s Terms of Service.
• If your own code or agent calls the V3 API or MCP tools directly, switch to the new Account id field names below before you next deploy. A call that still sends an old seller, buyer or creative engine name now fails with a validation error that names the field to use instead.
• If you work through Murph, ChatGPT, Claude or another MCP host, there is nothing to change: those hosts read the current tool list. If you use the Apostra SDK or a published Apostra skill, move to the latest version. v2 is unchanged.
• Every seller, buyer and creative engine is now identified by one id, its Account id. Before, V3 also used a second id for sellers, the Storefront id, which looked similar and named a different seller when copied into the wrong field. An Account id and a Storefront id are different values, so never copy one into the other.
• Buyers and buyer agents calling V3 directly
• Name sellers by sellerAccountId, and lists of sellers by sellerAccountIds, when you build campaigns, request proposals, stage media buys and filter catalogs.
• Name your own Account by buyerAccountId.
• Name creative engines by engineAccountId.
• Campaign reads list sellers in sellerAccountIds and no longer return the sellerIds slug list.
• Sellers calling V3 directly
• Name your buyers by buyerAccountId, including on open_approvals, open_media_buy_timeline and open_media_buy_retry.
• On the Media Buys page, filter by seller account mapping with sellerAccountMappingId. The old filter sellerAccountId, which held a seller account mapping id, is refused.
• Every rename, field by field
• sellerId, sellerIds and expectedSellerId become sellerAccountId, sellerAccountIds and expectedSellerAccountId.
• In a seller catalog search, filter.ids becomes filter.sellerAccountIds, and filter.sellerId becomes filter.sellerAccountId.
• On save_connection, a seller target’s id becomes target.sellerAccountId, and a creative engine target’s id becomes target.engineAccountId.
• buyerCustomerId becomes buyerAccountId.
• engineId and engine.id become engineAccountId.
• Results stop returning sellerId, storefrontId, buyerCustomerId and engineId, and return the Account id fields instead.
• Reading a connection returns a seller or creative engine target as sellerAccountId or engineAccountId, with no id. A billing target keeps id.
• An error that refuses sellers, such as SELLER_WHOLESALE_ONLY, lists them in ineligibleSellerAccountIds.
• A media buy’s operation destinations now carry the seller’s Account id in sellerAccountId.
• What stays the same: an object’s own id. A seller object you read with search or get keeps its id, with sellerAccountId beside it, and a creative engine object keeps its id, with engineAccountId beside it. Opaque ids such as sf1: product ids, session ids and media-buy operation route ids are unchanged.
• The published skills now use only the new names: set-up-a-campaign 1.9.0, test-sales-agent 1.5.6 and build-with-apostra 1.1.0.
• In the Apostra chat with your buyer agent, a reply that comes with an Apostra page, such as Campaigns or the Creative Library, now shows that page under the reply, the same way it does when Murph opens it. Before, the chat showed only the reply text. The page loads with your own access and stays with the reply when you reopen the chat. Nothing to change on your side. See Chat with your buyer agent.
• When a Slack reply from your buyer agent or from Apostra comes with an account-record summary, a draft campaign summary or your requests list, Slack now shows it as a card under the reply: a title, key facts, up to 10 rows with a count of the rest, and an Open in Apostra button. Before, Slack showed only the reply text, or a button with no summary. Other pages are unchanged. Nothing to change on your side.
• Your storefront’s regions and businessProfile.regions now show your countries, the same as acceptedCountries: ISO country codes, WORLDWIDE when you accept every country, or an empty list when you name none. Before, they showed the regions stored before regions were retired. Sending regions still sets your countries, and resending what a read returns changes nothing. Regions are not stored any more.
• The V3 save_material tool now publishes a closed input, so strict-schema model providers can send it.
• A structure node’s provenance is a list of { key, value } entries instead of a map. A rendition’s completeness is an object with any of text, structure, tables, visuals and styles, each complete, degraded, unsupported or failed.
• A correct decision on a candidate carries only correctedContent, the replacement title and summary. correction.proposedMutation is no longer published. To change what a typed proposal would do, call its own tool.
• get still returns provenance and completeness as stored. The earlier shapes still work for now and will be removed later, so move to the new ones when you next update an integration.

​

5.1468.0 — October 30, 2026 at 11:01 PM UTC

• A campaign launch that failed on a creative you have to fix no longer blocks your retry, and a launch that really is in flight now says why.
• After a launch failed because a creative was refused, confirming the launch again could return “A campaign launch is already in flight” for several minutes, because the failed launch was queued for automatic retries that could never succeed. A refused creative now parks the launch for you, so you can fix it and launch again at once. When a launch really is queued or being sent, the refusal now names it, says its status and when it is sent again (details.retryAfter), and says what to do.

​

5.1467.0 — October 30, 2026 at 10:24 PM UTC

• A failed media-buy operation (for example a creative.sync dispatch that could not reach a seller) now reports why it failed as failedReason on the operation detail the get tool returns, instead of showing only “failed” with no explanation.
• The “Clicks fire” certification check on video formats is now judged on real clicks, and it tells you when it set crawler clicks aside.
• Certification traffic that Apostra drives on its own test pages now clicks video ads as well as display ads, the way a viewer would, so a video format’s “Clicks fire” result comes from real clicks on the player. Before, only Google’s ad-review bot clicked these ads, and its clicks arrive with every macro empty. Clicks from known crawlers are still left out of the result, and the check’s detail now says how many it set aside and why.
• Spotify “Brand awareness – Video views” buys now launch. They failed every time because the check that Spotify stored the ad set as requested rejected a skippable-video setting Spotify adds on its own to video ad sets. If Spotify still stores a buy differently than requested, the launch now fails once with a message that says so, instead of being reported as a temporary error that retries itself.
• In a chat with your hosted buyer agent, asking for one of your Apostra pages now opens it in the chat right away, as it does with Murph. “Open the creative library” in a chat for an advertiser opens that advertiser’s Creative Library in a moment, instead of waiting seconds for the agent to answer in text. If you only asked for the page, the page is the whole answer and the message is not sent to the agent. If you also asked something the page shows, the page opens and the agent still answers. Any other message goes to your agent as before. See Chat with your buyer agent.
• Apostra now refuses to send a creative whose hosted audio or video file is under 1,024 bytes, instead of sending it and letting the seller fail it without saying why. Saving a creative from such an upload returns an error naming the byte count, and a campaign creative sync returns CREATIVE_ASSET_INVALID for each media buy with the creative and its stored size. Upload the file again, save the creative with the new upload, and send again.
• V3 labels are now a list of { dimension, values } entries instead of a map keyed by dimension. search takes filter.labels as entries (values: ["unlabeled"] on its own finds objects with no value for that dimension), and save_advertiser, save_campaign, save_creative, save_material and upload_creative_asset take labels as entries, where an empty values list clears that dimension. get, search and upload_creative_asset return labels as the same entries, so you can read an object, change one entry and save the list back. List each dimension once. The old map form, such as { "market": ["us"] }, still works as input for now but is deprecated and will be removed; reads already return the new shape.
• V3 REST responses now return customer-entered text, such as advertiser names, as the exact stored value. They previously came wrapped in a model-safety marker and long names could be shortened. MCP responses are unchanged.
• The V3 save_signal tool now describes its draft in full, so an agent can see every field it may send instead of guessing from a description.
• The draft has a kind. Use managed for a signal on an ad-server source, and send sourceId with it. Use catalog for a signal in your seller catalog, with no sourceId. Each kind lists its own fields.
• The ad-server mapping (adapterConfig) and a catalog signal’s metadata are sent as { key, value } entries, one per setting. The key is the path to the setting, such as kind or groups[0].criteria[0].keyId. A value can be a string, a number, a boolean, a list of strings, null, or an empty object. A read still returns those settings exactly as stored.
• Prices are AdCP vendor pricing options, exactly as AdCP defines them.
• The earlier open draft, without a kind, is still accepted for now. We will remove it later, so move to kind and entries when you next update an integration.
• Fewer “Couldn’t load this view” errors on more in-chat views. The agent inventory sources, agent webhooks, review-and-claim-agent, agent overview, developer home and buyer webhook-endpoints views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is now recorded so we can see it in production.
• Fewer “Couldn’t load this view” errors on more in-chat views. The buyer account provisioning, buyer activity, buyer catalogs, buyer discounts and buyer setup views now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and a failed load is recorded so we can see it in production.
• A publisher no longer keeps reviewing a creative you took off its draft buys. When you remove a creative from a campaign, archive it, or edit a draft buy so it no longer carries it, Apostra withdraws it from that publisher’s pending review about a minute later; the review closes as archived and leaves the publisher’s pending queue, and you get no rejection. A creative the publisher already approved, rejected or forwarded stays as it is, and one still on another draft buy with the same publisher keeps its review. Nothing to change on your side.

​

5.1466.0 — October 30, 2026 at 8:55 PM UTC

• When a buyer agent connected to a Slack channel answers with the Campaigns or Creative Library page, its Slack reply now ends with the page’s name, a short description and an Open in Apostra button that opens that page for the same advertiser in the Apostra chat. Before, Slack showed only the reply text. Replies with any other page, or with no page, are unchanged. Nothing to change on your side.
• If you sign up as a Buyer with a work email whose domain holds only an empty Seller account, you now get your own Buyer account and become its administrator. An empty Seller account has no members and no pending invitations, no live Storefront, no contract or payment setup, and no media buys or other activity, such as one left behind by a Seller signup that never finished. Before, you were told to ask the account’s administrator to add you, even though it had none. Apostra retires the empty Seller account and keeps a record that lets it be restored. A Seller account that has any member or pending invitation is still treated as in use for its first 90 days, and your signup then goes to access review. Nothing to change on your side.
• Accounts on the V3 beta feature profile can now change a property list’s filters after they create it; for other accounts filters stay fixed at creation. Save the list again with save_property_list, its propertyListId and the new filters; they replace the old ones, and filters: null removes them. A list with no identifiers must keep at least one feature_requirements entry, and channels_any still cannot change after creation.
• A change that alters what a list resolves to is pushed to the active media buys that use it, the same way editing its identifiers is. That now includes saving a changed score: every list of yours whose requirements read that feature is pushed, and the cascadeSummary in the save response counts the buys across all of them and names the lists in pushedListIds. After 60 seconds no further push starts and unfinished ones are cancelled, and those lists are named in leftToRecheckListIds instead; that is not a failure, because the scheduled re-check of live buys compares each buy with the lists as they now resolve and acts on any that are out of date. Saving a score that is unchanged, or that only changes its measurement time, pushes nothing.
• On traffic Apostra drives itself, live certification’s ad-server delivery check again needs your pre-filter impression count to agree with our tracker within 20%, as it does on real traffic. Since 21 October it had passed counts down to half of ours, based on one run that later proved to be a fault in that run’s buy rather than in how your ad server counts our plays.

​

5.1465.0 — October 30, 2026 at 8:06 PM UTC

• The Media Partners page’s market filter now matches sellers by the countries they sell in. It accepts a country group such as EMEA, and it includes sellers that sell everywhere or name no country. The v2 buyer storefront connections list takes an optional region filter that follows the same rule.
• When you approve a change that Murph proposes through the buyer API, such as adding a channel to an advertiser, the change is now saved. Before, the approved call could be rejected as having unexpected arguments, and nothing was written. If Murph told you an approved change failed that way, ask it to make the change again and approve it. Nothing else changes on your side.
• Creative sends that fail before reaching a seller now leave a classified operation with an actionable recovery path instead of silently completing.
• V3 no longer lists or accepts open_connections_page: a call to it is refused as an unknown tool. Call open_media_partners_page instead, which opens the same Media Partners page with the same inputs. The v2 buyer open_connections_page is unchanged.
• save_rfp and save_rfp_turn now publish closed inputs, so strict-schema model providers can send them. The facts you name yourself, origin.details, feedback and outcome.details, are lists of { key, value } entries where value is text, a number or true/false, and get returns the same entries. request.flight is AdCP’s date range, { start, end } as YYYY-MM-DD, and get returns a stored flight in that form. request.dimensions, request.constraints and strategy publish only their declared keys, and the legacy Quick preset is no longer published. The old open shapes ("feedback": { "note": "..." }, startDate/endDate, other keys, the legacy preset) are deprecated: they still work until the next ChatGPT re-approval, then they are removed.
• Searching a seller’s wholesale products for an advertiser that has property lists now tells you when the lists took products out of the results. Before, a seller could report that it returned products while the results came back empty, with no reason. Now the search result carries unenforceableProductCount for products removed because nothing can hold them to the advertiser’s property lists, and unverifiedProductCount for products held back because Apostra could not check the lists yet, so a retry may return them. Each seller in sellerOutcomes lists up to 25 of its removed products with the lists and reason that apply. The fields are absent when nothing was removed, so searches for advertisers without property lists are unchanged.

​

5.1464.0 — October 30, 2026 at 7:09 PM UTC

• A certification buy that Apostra never sent to your agent no longer stays undecided on your run. When Apostra’s own dispatch ended before it contacted your agent, or the run was stopped before the buy went out, the use case now shows the skip reason buy_never_sent, and a later run covers it. Nothing on your side changes.
• When you ask the Apostra assistant on the web to open a page, it opens it straight away again, instead of waiting for its full reply first. Since 27 October every page waited for the reply.
• Opening an unfinished Draft in the seller Library now reads as the one thing it asks for. The panel is headed Review this file’s details and goes straight to the form: the file name was repeated as a heading above a Name field holding the same text, and the heading, the line under it and the card’s own heading each said the details were suggested. The card now stops at the width the fields need, instead of stretching across the pane and leaving every field short of its own edge. A rate card or avails sheet shows its category in the Category field every other Draft carries, filled and not editable, instead of a grey line of text beside the form.
• Reviewing a rate card’s price changes is laid out the same way. The Draft’s button now reads Save and review prices, since it opens the preview rather than saving; the preview’s own Save and update prices button is what applies the prices. The preview drops the separate Back button and the “Review price changes” alert from the top. Its page heading, the Added, Updated and Removed price lists and any Prices below a floor warning come first, and a single row at the foot holds the “These changes will go live when you save” note beside Back and the save button. Avails sheet previews use the same layout.
• In the V3 save_creative result, macroPreview.trackers[].given for a click tracker is now the URL exactly as you saved it. Before, it already included the creative’s own macro additions. The compiled URL and the macro lists still include those additions, so you can compare what you saved with what is sent. Nothing changes for impression trackers.
• When a creative send for a draft media buy is refused because the seller holds an approved account for the advertiser’s brand but none matches the advertiser’s account key, the error now says so and names the advertiser’s brand domain and countries. Before, it told you to ask the seller to link your account, even when the seller had already set it up and the difference was on the advertiser, such as a brand country the seller’s account lacks. Correct the advertiser’s brand countries or ask the seller to add them, then send the creative again. A seller that holds no account for the brand, or has not approved it yet, still gets the existing message.
• No-spend modular source tests now keep the exact private product mapping while a committed campaign is dispatched in the originating request. The mapping is reused only when the customer, Storefront, Source and selected products all match; the original inventory and runtime authorisation checks still run immediately before booking.
• A media buy whose execute operation already failed no longer stays silently in draft. It now reads as failed, names Apostra as the owner of recovery, and tells you to contact support with the media buy id.
• A direct administrator of your billing organization can now switch a Seller Account between Listing and Storefront agent in place, by sending sellingMode (listing or storefront_agent) alone to save_seller. Nothing changes for an account until you switch it or your organization accepts a plan. The account keeps its storefront, sources, connections and history. Each change is recorded with who made it and when, and the result names the seller-paid activities that will become billable or free once pricing follows the account type. Billing is unchanged today. get with kind: "seller" now returns sellingMode, so your agent can read the current type. A feature grant no longer changes the type by itself.
• In Seller Settings, the Selling mode section shows whether the account is List only (a Listing) or a Storefront agent. Settings has no control to switch to Listing; send sellingMode: "listing" to save_seller, or accept a Listing plan. Compare plans no longer changes the account. It opens plan selection and records which product you want to see plans for. If your current plan doesn’t cover that product, the request is refused and Settings shows the reason as an error message. Accepting a plan is what changes the type: a plan that includes the Storefront agent makes your Seller Accounts Storefront agents, and a Listing plan makes them Listings.
• A switch to Listing is refused, and nothing changes, while a managed campaign is active or paused, a media buy sold through the account is running, or a Market Maker offer is active. This covers save_seller and accepting a Listing plan that would switch a Storefront agent; in the plan case the whole plan change is refused. The error names what is blocking. A Demo Storefront has a fixed type. sellingMode can’t be combined with other save_seller fields.
• A Listing account can’t use Enhanced Reporting. Turning it on is refused, a connected account reads eligible: false with ineligibleReason: "listing_account", and switching to Listing closes Enhanced Reporting on the account. A period already earned stays billed.
• V3 get_delivery never adds provisional (Snapshot) and final (Official) delivery figures together. Rows are split by finality, so the same campaign or media buy can appear once per finality class, each row with its own label. When the matched delivery spans more than one class, totals gives no figure (each metric reads unavailable with reason finality_mixed), and the new totalsByFinality gives one total per class. A row or total combining several revisions of one class now names that class in its finality label. Delivery reported without revision evidence is unaffected. See Reporting.
• save_work_item and save_inventory_source now take a list of entries where they took an object. When you complete a modular-source follow-up, send result as a list of { key, value } entries, for example [{ "key": "upstream.campaignId", "value": "CMP-1" }]. When you change a module’s settings, send moduleConfig.config the same way, for example [{ "key": "freewheel.autoExecuteBookings", "value": true }]. The key is the dotted field key that the source’s readiness view already lists as configuredFieldKeys and that a follow-up lists as requiredResultFields, and Apostra expands it into the nested field it stores. A settings value is a string, a number or a boolean. A result value is a string or a number, a list of strings, or the daily rows of a final report for reporting.dailyBreakdown. This lets OpenAI’s strict schema mode constrain these two calls to the schema before they are sent. The earlier object form is deprecated. It still works for now and is stored as before, but the published schema shows only the entry list, so move your calls to it.

​

5.1463.0 — October 30, 2026 at 5:01 PM UTC

• Uploaded image files now show their original image in the Library preview and count as one preview item.
• The Library now archives only Live documents, directs Drafts to their review and discard flow, and shows the server’s reason when an archive or restore request is refused.
• A Google Ad Manager pricing and availability sync that runs for a very long time now stops after 40 minutes and is retried, and tenants whose sync waited longest are synced first, so one large account no longer keeps the others from being synced.
• Scheduled GAM syncs (orders, inventory, advertisers, signal coverage, placement optimization) no longer fail across tenants when the sales agent’s database connections run out, and a sync that fails during a database outage is now marked failed instead of staying “running”.
• A Google Ad Manager report that fails with a temporary Google error page, a timeout or a dropped connection is now retried before the pricing sync fails. If Google is still down, the sync shows as a retryable ad-server fault and is not sent to support.
• save_billing no longer accepts the earlier call shape that carried operation or paymentAuthority over MCP; the call is refused with a validation error. To accept Terms or choose payment terms, send terms and paymentTerms directly, with no operation. To request or confirm a card, call request_payment_authority and confirm_payment_authority, and read its status with get and kind: "billing". The HTTP API and the SDKs never accepted the earlier shape.
• save_creative_session now refuses a call that still sends the old operation field (save_draft, select_output, approve_output, finalize_approved_output or promote_approved_output) or scope. Send the fields that say what the call saves instead: draft, selectedVariantId, approvedVariantId or finalization, with exactly one of campaignId or advertiserId. To save an approved output to the Library, call save_creative with fromCreativeSessionOutput.
• Spotify now refuses a package that attaches a catalog its product does not declare in catalog_types, with UNSUPPORTED_CATALOG_TYPE and nothing created at Spotify, instead of splitting the package budget across ad sets. Only the podcast promotion products take a catalog (offering). For a USD Spotify ad account, get_products now states the exact min_spend_per_package of 250 on each pricing option; for any other currency it states none.
• V3 get_delivery now names delivery metrics the AdCP way and reports viewability. Request cpm, cost_per_click, cost_per_acquisition and quartile_100 (video completions) instead of ecpm, cpc, cpa and videoCompletions, and read those names back in the response. New metrics viewable_impressions, measurable_impressions and viewable_rate show viewability where the seller measured it. Where it didn’t, they read as unavailable, not zero. Requests that still use the earlier names keep working and are answered under the AdCP names, so update any code that reads ecpm, cpc, cpa or videoCompletions from a response. The metric list is in Reporting.
• Saving a creative with trackers now shows how those trackers will expand. The V3 save_creative result for a create or an update carries a new macroPreview field: for each tracker on the creative, the compiled URL, the macros every seller of that format fills, the macros only some of them fill, the macros Apostra fills, and the macros that stay literal. It is a dry run, so it never fetches a URL or uses a real identifier. When the creative is not tied to a seller format, the preview says which macros the seller fills is unknown instead of guessing. To see which macros a seller resolves, read macro_resolution_capabilities on get({ kind: "creative_format" }). A creative with no trackers has no macroPreview. Nothing changes for callers who ignore the field.

​

5.1462.0 — October 30, 2026 at 3:45 PM UTC

• A media buy whose create operation had already failed no longer stays silently in draft. It now reads as failed, names Apostra as the owner of recovery, and tells you to contact support with the media buy id instead of leaving you to wait past the flight start.
• save_account no longer renames an account at once. A call that sends id (or the deprecated accountId) and name without a reason and an idempotencyKey is now refused with a validation error that names both. Send a reason of 10 to 300 characters and an idempotencyKey (a UUID): the rename is recorded for approval by an organization administrator on the website, and repeating the call with the same idempotencyKey reports the outcome. Add dryRun: true, with no idempotencyKey, to preview it. settings.company alone still saves at once.

​

5.1461.0 — October 30, 2026 at 2:45 PM UTC

• When Apostra can’t read the products or signals from an agent you run, the finding now says which call failed and what to do. A timeout says Apostra waits 30 seconds for each page of products. An error names the call and the error code to fix.
• Apostra now aims to show a campaign, ad set or ad changed in a connected ad platform within 30 minutes, and the docs say how that target works and when it does not hold. Apostra reads every subscribed ad account on each pass instead of the 50 least recently read, so adding accounts no longer delays the others.
• Certification now changes the creatives on its live test buy, the way a buyer would. After the pause and resume checks, Apostra attaches a second creative to the buy, detaches it, and replaces the first creative with it, for each change your agent declares in available_actions. For a change your agent left out of an action list it did send, Apostra sends it once and expects your agent to refuse it with an error code such as ACTION_NOT_ALLOWED. A change your agent declared as self-serve and refused, or a change it left out and then accepted or answered without an error code, shows as an attention finding on the Agent page. This is a finding only: it never makes a use case fail and never stops a certification pass. An agent that sent no action list is not tested this way; the “creative changes declared” check already reports it.
• Apostra judges your agent’s answer to each change. It does not yet read the package’s assignments back to confirm an accepted change shows on a later read. What the check sends and how to clear it.
• A Meta ad account with no Facebook Page now says so, and says what to do.
• A creative sent to a Meta ad account that has no Page authorized is refused, and the only thing a buyer saw was a generic “seller rejected request”. The campaign’s launch blocker and the launch error now say: connect a Facebook Page to the Meta ad account in Meta Business Settings, then launch again. Replacing the creative does not help, and the launch error no longer tells you to. Someone with admin access to the ad account’s Meta Business has to connect the Page.
• save_creative now edits the copy of a Library creative you name with creativeId and advertiserId. Before, social was refused on that call with “does not implement social yet”, so a typo or an over-length line in a live ad could only be fixed by recreating the campaign, buy and creative. Send social.headline and social.components (for example body_text) and each slot you name replaces its text. Text longer than the limit the creative’s own format option declares for the slot is refused naming the slot, and the creative’s revision advances. Then send save_creative with creativeId, advertiserId and resync: true to re-send it to the media buys it is on: a live OpenAI Ads ad is updated in place, not duplicated. A URL component of social on a Library creative is still refused; send it with campaignId of a campaign the creative is attached to. See manage ads.
• A video or audio creative built from an asset in your Creative Library now stores its real, verified file size instead of a placeholder value. Nothing to change on your side — this applies automatically to new and updated creatives.
• Fixes a bug where a buyer with more than one active connection to the same seller (for example after reconnecting an adapter storefront without the prior connection being archived) could unpredictably see that seller’s storefront reported as needing account selection, or excluded from eligible sellers for request_proposals, even though the buyer’s actual, current connection was healthy. The storefront catalog and readiness views now always resolve to the connection with a currently selected account instead of picking one unpredictably.
• Opening a media buy now shows its budget, rate and flight progress as named figures, and its pacing as a bar you read against a marker.
• Pacing was four bars — expected spend, spend, expected delivery, delivery — all drawn to the same scale. A buy a little behind rendered as two bars a few pixels apart, so the gap you opened the row to find was the one thing you could not see. Spend and delivery are now one bar each: the fill is what the buy has delivered and the marker is where an even pace expects it by now, so the shortfall is the distance between them. It is the same bar the buyer’s goal already uses below it.
• The buy’s details were one unnamed run-on line — operator, budget, pricing model, rate, creatives, sources, billing and the buy id, separated by dots, and on a narrow window it wrapped so that lines began with a dot. The budget, the rate and how far the flight has run are now figures at the top of the opened buy, and the rest still reads as one line but says what each value is: “Operator scope3.com · Creatives 2 · Sources 1”. A wrapped line no longer starts with a dot.
• That line now names two ids rather than one. Apostra id is this storefront’s own id for the buy, and a buy your ad server manages instead reads Ad server id, because that id was always the source’s own and calling both the same thing hid the difference. Seller id is new: the id your own source holds for the buy, which until now you could only find by opening the buy’s timeline. It appears when exactly one source can name it; a buy that fans out to several sources has one id per source and none of them is the buy’s, so nothing is shown.
• The two sections now name themselves — Pacing, and the goal’s own metric such as Cost per click — each with its verdict against it, in place of the questions that restated what you were already looking at.
• Pacing and the buyer’s goal each sit in their own card now, side by side, and a buy with nothing to report for one of them keeps the card and says so inside it — so the two answers stay in the same place whatever state a buy is in.
• A buy that needs nothing from anyone no longer says “No action needed right now.”; that line now appears only when someone owes a move.
• Three fixes ride along: the goal bar’s track had been rendering with no height, so its labels printed over the bar; the keys beside each bar’s labels now share one size, so the labels line up instead of each starting wherever its own mark ended; and on a wide window the pacing and goal answers now sit side by side, which roughly halves how much room an open buy takes.
• Meta webhook events now reach every ad account mapped to an advertiser, not only the connection’s selected account, so a Meta login that reaches several client accounts keeps each mapped account’s campaigns fresh.
• A running OpenAI Ads media buy whose ad group has no ad yet now declares that it takes a creative assignment. Before, such a buy said “assigning a creative: the seller does not take it on a live buy”, so a creative could not be attached after launch even though the adapter creates the ad under the existing ad group. Sync the creative to the account, then attach it to the campaign: the first ad is created under the existing ad group, and a later attach updates that ad in place. Removing a creative is still not taken on OpenAI Ads, and the buy says so.
• save_agent and save_buyer_agent over MCP no longer accept the old operation shape. A save_agent call that sends operation (seller_save, developer_create, developer_update) or endpoint, or developer_create with kind: "buyer", is refused with a validation error, and so is a save_buyer_agent call that sends operation (create, update_display_name, update_access, lifecycle, credential_handoff) or lifecycle.action. Send the fields the tool now publishes instead: for save_agent, agentId, productMode and reason to confirm a product mode, kind, displayName and idempotencyKey to register an agent (or agentUrl to connect one), and agentId with displayName or certificationRequested to update one; for save_buyer_agent, displayName to create, and id with exactly one of displayName, access, lifecycleState with expectedLifecycleState, or credentialHandoff. Create a buyer agent with save_buyer_agent, not save_agent. The save_agent HTTP API and SDKs never accepted the old shape. save_buyer_agent over HTTP used to rewrite it and now refuses it too.
• save_rfp over MCP now refuses a call that sends action, such as { "action": "create", ... } or { "action": "record_feedback", ... }. Send the fields that say what the call does instead: no rfpId creates an RFP, rfpId with parentTurnId and request revises it, rfpId with endorsed endorses or removes the endorsement, and rfpId with responseMaterialId attaches a response. A turn’s feedback, release, proposal files and outcome go through save_rfp_turn. The HTTP API and the SDKs never accepted action.
• Archiving a source or a Storefront now removes the products Apostra last read from it, so buyers no longer see them. Restore it and the next check reads the catalogue again.
• When your Storefront no longer lists a buyer account, Apostra now removes the catalogue it read for that account instead of keeping an old copy.
• A save_media_buy update now returns the media buy as it stands after the change.
• The result of an update used to show the buy from before the edit: the old updatedAt, and no budget. An agent that trusted the result saw stale state until it called get. The buy in the result is now the same one get returns right after the write, so a budget edit shows the new budget and updatedAt with no follow-up read. If the read after the write is unavailable, the result is the same as before. Nothing to change on your side.
• When a Seller Account tries to connect a sales agent by typing its address, the refusal now tells you what to do instead. It lists your organization’s registered sales agents with their ids and registered addresses, says so when the address you sent is one of them, or tells you to register the agent in your organization’s Developer account first. Resend with that agent’s id (attachToAgentId; on V3, send agentId alone to save_inventory_source). A new section, Connect your own sales agent, walks through the steps.
• For connected Meta ad accounts, Apostra now asks Meta to notify it when a campaign, ad set or ad is created or changed, and reads the account as soon as a notification arrives. Changes can appear in minutes instead of waiting for the next scheduled read. The 30-minute target is unchanged, because Meta does not guarantee delivery.
• Adding a sales agent in a Seller Account is now always “select your agent”. save_inventory_source tells you to send only the agentId of an agent from search kind agent, rather than asking for the agent’s address, and its description says the same. A sales agent’s address is entered only once, in your organization’s Developer account when the agent is registered. The Connect your own sales agent page explains the steps and the refusals.
• Attaching a creative to a campaign whose live media buy doesn’t accept its format used to report plain success while the creative silently never reached that seller. save_creative now returns a warning naming the affected seller(s) when none of a campaign’s current media buys can take the creative’s format, so you know to attach a compatible format instead of assuming delivery is underway.

​

5.1460.0 — October 30, 2026 at 1:04 PM UTC

• Apostra now removes a catalogue it can no longer read. If your agent stops declaring wholesale, or your source is brief-only, buyers stop seeing the products Apostra last read from it, within a few hours. Declare wholesale again and the products return at the next check.
• save_material over MCP no longer accepts the old action values (create, replace_source, update_metadata, reprocess, decide_candidate, reconcile_candidate, mark_reusable, archive, restore, preview_rate_card, commit_rate_card, preview_avails_sheet, commit_avails_sheet); a call that sends one is refused with a validation error. Send the fields that say what you want instead: no materialId to create, source to add a revision, metadata or labels to edit, isArchived to archive or restore, candidateDecisions, unitReusable, reprocess, or commitPreview, and read rate-card and avails-sheet previews with get. The Delete from Apostra beta actions (preview_permanent_delete, delete_permanently, undo_permanent_delete, include_again) are unchanged.
• Spotify’s BUDGET_TOO_LOW error on create_media_buy now names the actual net minimum ($250 per package or ad set) instead of a generic message with no numbers.

​

5.1458.2 — October 30, 2026 at 12:09 PM UTC

• A media buy’s seller operations no longer stay blocked after the buy no longer needs them. When a media buy fails, is archived, is canceled, completes or passes its flight, or a newer attempt or a later media buy on the same campaign and seller route has taken over, its blocked operations now read as closed in get(kind: "media_buy", include: ["operations"]), with a closedReason and no next step, instead of as blocked on you. When an operation is blocked for a correction you can make, you now get a media buy notification saying so. Nothing changes on your side for operations that are still waiting on you.
• Storefront proposal codes, the beta feature for freezing one discovery response into a shareable code a buyer redeems, are retired. A code no longer redeems: discover_products now refuses a request that sends proposalCode with a validation error, so a buyer holding a code sees that it is retired instead of getting ordinary results. The five proposals endpoints under /api/v2/storefront, the Storefront proposals documentation, and the glossary pointer to it are gone. To offer a buyer a specific plan, respond to their request for proposals or share a Proposal Pass.
• Reading your listing now shows your countries in profile.regions: ISO country codes, WORLDWIDE when you accept every country, or an empty list when you name none. Before, it showed the regions stored before regions were retired, so a region change you saved through the deprecated media kit did not appear when you read it back. Starter briefs in Murph now use your countries too, and treat a seller that names none as worldwide.
• The save_dimension and save_rfp_turn input schemas no longer carry the if/then/else, minProperties and not rules, so strict-schema model providers can send them; a call that broke those rules is still refused with the same validation error.

​

5.1458.0 — October 30, 2026 at 11:18 AM UTC

• A product added to a live buy now takes the campaign’s targeting, the way a product on a new buy does. Before, the new ad group or ad set carried no geography and the platform refused it (TikTok answered “missing geo targeting”). If the platform cannot apply a campaign targeting dimension to the new line item, the add is refused by name and nothing is sent.
• Certification now flags a sales agent that stops answering. If Apostra calls your agent and gets no response for more than 15 minutes, which means the connection is refused or reset or nothing answers before the deadline, that counts as an outage. One outage is a flag. A second within seven days, or one that lasts six hours, is a blocker. Only time Apostra was calling counts, so an idle agent is never unreachable, and a deploy or restart that leaves your agent unanswering for a few minutes does not reach the line. The check starts on 29 October 2026 and applies to every sales agent, including Apostra’s own embedded sales agents. A flag or blocker shows on your agent’s Agent page as “Stays reachable”.
• To stay clear of it, keep at least one instance accepting connections while you deploy, and stop sending calls to an instance before it shuts down.
• Nothing stops new buys because of this check before 1 December 2026. An agent that existed on 22 October 2026 holds a certification exemption until that date, so a blocker cannot stop its new buys, and stopping new buys on blockers is not switched on for any account. What counts as unreachable, and how to fix it explains the causes.
• A new docs page, “Give a client access to one advertiser”, explains how to invite a person at a client company into one of your advertisers, what they do to claim the invitation, and how you approve, suspend or end their access.
• Google Ads no longer disapproves search, display, video and Demand Gen ads for an uncertified click tracker. Apostra now sends Google only your landing page as the ad’s final URL and adds no click tracker. Google counts clicks itself, and they still reach your Apostra reporting. Re-send a Google creative that was disapproved for “Click tracker - Uncertified” to have it reviewed again.
• A Source connected to an agent that declares both briefs and wholesale now offers both. Before, a Source could stay on briefs only, and its wholesale catalog was never refreshed.
• Wholesale product pricing text now says whether a price is a fixed rate or an auction floor, instead of showing both the same way. An auction-floor price is also labeled as requiring bidPrice on save_media_buy. This affects search, get, and request_proposals results for wholesale products, including Spotify’s, which were previously shown as a plain fixed CPM.
• Murph now consistently checks the docs, or your request history, before answering a question that needs them. Before this fix it skipped that check on about a third of turns.
• request_proposals now tells you when a named seller cannot run a proposal round at all, instead of the generic “not currently eligible for proposals” error.
• Spotify sells only fixed wholesale products: its catalog is bookable through search(kind: "wholesale_product") and save_media_buy, but it has no brief or RFP path. Naming it in request_proposals previously returned “The requested sellers are not currently eligible for proposals,” which reads like a connection or activation problem and sends you chasing account settings that were never the cause. It now returns SELLER_WHOLESALE_ONLY with a message that points at the working path. Naming only wholesale-only sellers refuses the whole call this way; naming a mix of sellers skips the wholesale-only ones (reported in skippedSellers with reason wholesale_only) and proceeds with the rest. get(kind: "seller") and seller search also now carry supportsProposals, so you can check before calling request_proposals. This is capability-driven, not Spotify-specific, so the same response applies to any other seller whose adapter declares itself wholesale-only.
• TikTok App Installs, App In-App Event Optimization, App Install Clicks, App Install Value, and the Smart+ App products can now be launched. Supply the promoted app as a packages[].catalogs[] entry (type: "app", matched by the app’s bundle_id on Android or apple_id on iOS) instead of the undocumented ext.app_id field these products required before — a field discovery never surfaced and no buyer could feasibly supply, so every one of these products could be discovered and drafted but never launched.
• A creative is no longer reported as rejected by the seller when the seller could not be reached. If the connection to the seller fails while your creative is being delivered, Apostra now tries again until the delivery deadline, and only then reports the creative as undelivered. A rejection the seller actually sends back is still reported as a rejection, with the seller’s reason. Nothing to change on your side.
• A sales agent’s Agent page now flags an agent that does not declare how it sells. Declare media_buy.buying_modes in get_adcp_capabilities with exactly the paths your agent serves: brief, wholesale, or both. Apostra takes the agent’s product mode from that declaration, so without a usable one Apostra cannot tell which buyer requests your agent answers. The finding is reported only for now: it does not stop certification or buying. See Declare your buying modes for what to declare and why.
• A successful save_media_buy update no longer comes back as an error.
• On V3, changing a media buy (for example halving a budget) applied the change but returned “Structured content does not match the tool’s output schema”, so a client that validates tool output showed a failure for an update that had worked, and an agent could retry it. The returned media buy now carries the same fields get returns without failing validation. Nothing to change on your side; if your integration treated that error as a failure, the edit had already been applied.
• On your Advertisers page, a client you invited to one of your advertisers now opens that advertiser’s campaigns when you select their row. Before, the row did nothing.

​

5.1457.7 — October 30, 2026 at 9:39 AM UTC

• Adding a freshly discovered product to a live buy on a platform adapter (TikTok, Meta, Google and others) now prices it from the product Apostra stored at discovery. Before, the add could not see that stored product, so it refused with “no stored pricing” for a product you had just discovered.
• A seller’s regions now lists the countries it sells in: ISO country codes, WORLDWIDE when it sells in every country, or an empty list when it names none, which also means every country. The region filter takes a country code, a country group (NAM, LATAM, EMEA, EUROPE, EU or APAC) or WORLDWIDE, and returns every seller that sells in any of those countries, including sellers that sell everywhere. Any other value also returns sellers whose own older region list holds that exact value, so older custom region filters keep their sellers. Seller lists and filters now agree with where sellers actually take requests.
• The V3 MCP tool list no longer includes open_connections_page. Use open_media_partners_page, which opens the same Media Partners page with the same inputs. Calls to open_connections_page still work, so existing integrations keep running; it is only hidden from the list so agents choose the current name.

​

5.1457.5 — October 30, 2026 at 8:26 AM UTC

• When an ad platform integration refuses a request as unsupported, you now get the reason instead of “Upstream request failed”.
• Adding a product to a live TikTok buy, and several refusals on Meta updates, came back as a generic “Upstream request failed” with no code you could act on. The refusal now reaches you as its UNSUPPORTED_FEATURE code with the message that names what to change, such as the setting that cannot be applied to an added ad group. A refusal that does not carry a vetted message still keeps its code and now reads “The ad platform does not support part of this request. Remove or change the unsupported part and resubmit.” Nothing to change on your side.

​

5.1457.3 — October 30, 2026 at 7:24 AM UTC

• Adding a product to a live TikTok buy no longer fails. The add refused every request because it treated the buyer reference, delivery type and format details Apostra attaches to each added product as unsupported settings. They are now ignored, and a setting TikTok genuinely cannot apply to an added ad group (such as a bid or a creative) is still refused by name.

​

5.1457.2 — October 30, 2026 at 6:56 AM UTC

• Fixed save_media_buy(kind: "create") so a rejected creation (a validation error, or a product already on another draft buy) no longer permanently locks the idempotencyKey/productQueryId. Previously, once a create attempt was rejected before anything was staged, every corrected retry under the same key failed with “idempotencyKey was already used with a different media buy creation,” even though nothing had been created — the only recovery was running request_proposals again for a new key. A corrected retry now executes normally as long as that productQueryId has not already produced a media buy; a key that already created one is still refused.
• A media buy’s seller-operation history now shows the classified failure reason on a failed operation, not only on a blocked one, when the outbox recorded one before giving up retrying. Previously a failed creative or media-buy sync operation surfaced only a generic “contact support” next step with no reason, even when the system had a safe, bounded reason to show.

​

5.1457.1 — October 30, 2026 at 6:11 AM UTC

• Editing a package budget on a buy that is still waiting for its creatives now succeeds, and the buy’s status stays as it was.
• A recent fix stopped a budget edit from changing the status of a Meta buy that has no creative yet. As a side effect, that same edit came back as “Media-buy seller synchronization did not complete” even though the seller had applied it, and a read straight afterwards could still show the old budget. Now the edit is confirmed, the status is unchanged, and the next read shows the new budget. Nothing to change on your side.
• Snap creative uploads (video and image) no longer fail with a “temporarily unavailable” error on every attempt. Our media-creation check only accepted Snap’s PENDING status as proof a new upload hadn’t resolved to someone else’s stale media record; Snap’s real API also returns PENDING_UPLOAD for a fresh video upload, which we now accept.

​

5.1457.0 — October 30, 2026 at 5:39 AM UTC

• Adding a product to a live buy now works on buys placed through an official platform adapter (TikTok, Meta, Snap, Spotify, Pinterest, Reddit). Send the product id exactly as discovery returned it. Before, these buys refused every add even though the buy said adds were accepted. A live buy now reports liveChanges.addProducts as accepted only when the add can actually be sent.
• A developer of a sales agent can now watch a live certification run from start to finish and read what Apostra sent their agent. From your Developer account, search with kind: "session" lists the certification runs of the agents you own, and get returns one run as the steps Apostra recorded: run started, buy sent, buy created, skipped, your agent’s answer and each evaluation. The buy steps carry their calls, with what Apostra sent, what your agent returned, how long it took and the error. Apostra’s own credentials are removed. Every use case result and certification finding on the agent read now carries the sessionId of its run. The seller who connected the agent does not read these sessions.

​

5.1456.3 — October 30, 2026 at 5:01 AM UTC

• A media buy whose every creative is still in the seller’s review no longer books with no creative. Some sellers refuse a booking with no creative for good, and the buy is lost. Now the buy is held, owned by the seller, and books as soon as the seller accepts a creative, with no retries and no alert. If the seller rejects the creative instead, or a creative was superseded, the booking is refused before anything reaches the seller with CREATIVE_ACTION_REQUIRED, naming the creatives and owner: buyer, and the buy stays a draft you can fix and execute again. A buy with at least one creative that is not held books with it as before.

​

5.1456.1 — October 30, 2026 at 4:13 AM UTC

• Fixed: combining TikTok products with incompatible campaign objectives, app promotion types, campaign product sources, campaign types, or optimization goals in one media buy now returns a clear, correctable error naming the conflict, instead of a generic “Upstream request failed” transient error.
• Adding a product to a campaign by its plain product id now stages the media buy for a Storefront created after the legacy agent row was retired, instead of failing with “Sales agent not found”.

​

5.1456.0 — October 30, 2026 at 3:59 AM UTC

• Buyers can now create a TikTok media buy against a single chosen product (or any subset) instead of only being able to accept TikTok’s full product list as one bundle.
• Three V3 tools that reach systems you run now say so in their tool hints: save_agent connects an agent at a URL you provide, save_inventory_source connects your agents and ad servers, and save_coverage reads each publisher’s adagents.json when it refreshes. Hosts such as ChatGPT can now warn before these calls reach outside Apostra. The save_creative description is also rewritten in plain sentences: it saves a creative from content you supply, and new media such as radio spots is made with save_creative_session. Nothing to change on your side.

​

5.1455.0 — October 30, 2026 at 3:25 AM UTC

• Meta video campaigns launched without a buyer-supplied thumbnail no longer intermittently fail: a brief, transient delay in fetching Meta’s auto-generated poster-frame image is retried instead of treated as a permanent creative rejection.
• The Media Partners page now shows how many media partners still have your account being set up, as “N pending”, and the seller read reports where each advertiser’s account stands and counts the pending and needs-attention ones, so you and your agent see the same status.

​

5.1454.0 — October 30, 2026 at 3:05 AM UTC

• Changing a package budget (or targeting, dates or name) on a Meta media buy no longer changes the buy’s status.
• Before this fix, a Meta buy still waiting for its creatives could flip to paused or active the moment you edited its budget, and its packages and campaign followed. Now the buy keeps the status it already had: it stays pending until every ad set has an ad, exactly as reading the buy shows. Pausing and resuming a buy work as before. Nothing to change on your side.
• Fewer “Couldn’t load this view” errors. In-chat views (Advertisers, Campaigns and Media Partners) now recover from a slow or backgrounded tab instead of showing a connection error: if the view is opened or left in a background tab, it waits for the tab to return and retries the handshake rather than giving up. A view that genuinely cannot reach the chat host still shows the error with Reload where the host allows it, and the failed load is now recorded so we can see it in production.
• Structured targeting you send with a brief now reaches the sellers behind a storefront. Sellers on AdCP 3.2 or later receive your targeting_overlay and required_overlay_support, so they can scope their products, pricing and forecasts to it rather than to their whole footprint. Each seller receives the account-wide fields it declares it supports, such as countries, plus every field it declares per product, such as device type. Demographics are not sent; outside sellers read age from your brief. A property list used as a discovery filter now reaches only sellers that declare they can filter by one. How your discovery targeting reaches sellers lists what each seller receives.
• V3 search now returns the largest page a kind allows, with a nextCursor for the rest, when limit is higher than that kind’s maximum, instead of refusing the request.

​

5.1453.0 — October 30, 2026 at 2:31 AM UTC

• Apostra now follows the buying modes your agent declares unless someone set your mode on purpose. Agents that declare both briefs and wholesale are offered both paths.
• Certification now tests a pause on every tracked product, including one whose minimum spend is above USD 5.
• A product whose minimum spend is above USD 5 books one package, because a second would take the buy past the USD 10 per-buy cap. Until now that buy was never paused, so the stop and change checks read as not applicable and a use case could pass with no pause tested. Apostra now pauses that buy after the serving window and resumes it two grace periods later, as it does for a two-package buy. Your agent must accept the pause and report the buy paused on its next read, and our tracker must go quiet within the channel’s grace. A refused pause fails the stop check with your agent’s own error code and message. The check that a pause skips finished packages still does not apply to a one-package buy, and its result says so.
• A tracked use case no longer certifies unless its stop check was judged. A buy that was never paused, such as one booked before this change, shows the stop check as not yet judged until a new certification buy is booked for it.
• If a Seller signup fails partway, it no longer leaves behind a company account that nobody can sign in to. Signing up again with the same email and company name finishes the same account and makes you its admin. Before, a failed signup could leave an empty account holding your company’s email domain, so colleagues who signed up later were told to ask an administrator who did not exist. Nothing to change on your side.

​

5.1452.0 — October 30, 2026 at 1:48 AM UTC

• Certification no longer fails the click check because of Google’s ad-review crawler.
• On Google Ad Manager, Google’s ad-review bot fetches a hosted-video creative’s click-through URL on its own. Those fetches reached our click tracker with every macro empty and counted as clicks, so the “Clicks fire” check failed even when a real click had its macros filled. Certification now leaves hits from known crawlers out of its tracker evidence. Real clicks and impressions are judged as before, and click counts reported to buyers do not change.
• Existing storefront accounts now finish setup with the current external sales agent during a live account sync. Seller diagnostics also identify agent-owned mappings without offering actions the seller cannot take.
• A media buy on a recently created Storefront now hands its creatives to the seller’s trafficking task after booking, and a creative attached to a live buy later reaches that seller too. Before this fix, a buy on a Storefront with a modular inventory source booked without its creative ever reaching the seller.
• FreeWheel products now state which regions they can target in a much smaller declaration, about 14 KB instead of 37 KB, by marking countries FreeWheel covers completely as “all regions” and listing regions only for the rest. The regions offered are unchanged.
• Sites a publisher authorizes on its own subdomains, such as shop.example.com, are now listed with the publisher’s inventory instead of being left out. Buyers’ property lists that name those sites are applied to the buy.
• A buy that excludes or targets sites through a property list, or selects a signal a product offers, is no longer refused or flagged by a seller that enforces declared targeting.
• Changing a live order in a way its ad server cannot carry out (for example assigning creatives on a FreeWheel or SpringServe order, moving dates or pacing, or changing targeting where it is not offered) now returns one clear ACTION_NOT_ALLOWED refusal that lists what the order does allow, instead of saving the change and then failing, or answering with an adapter-specific error code. Nothing in the request is saved when any part is refused.
• A sync that fails for a reason Scope3 does not recognise, including a temporary Google Ad Manager server error, is now retried automatically instead of being marked as needing support. Each failed sync also reports a stable error class.
• Google Ad Manager pricing and availability syncs now retry when Ad Manager returns a temporary server error, instead of failing the whole run and leaving pricing stale.

​

5.1451.0 — October 30, 2026 at 12:33 AM UTC

• A creative a media buy booked without now attaches to the buy by itself when the seller accepts it. Before, it stayed out of the buy until you assigned it again. When the seller’s acceptance is recorded as the creative’s answer for the route the buy was booked on, Apostra attaches the creative to the booked buy, asks the seller again as any attach does, and held disappears from the creative. It does this only when it can tell the seller accepted the exact revision that was held, on the seller account the buy was booked on, for every inventory source the buy routes to; otherwise the creative stays held with its owner. On a live buy whose seller did not declare that it takes creative assignments, an accepted creative also stays held. A route that records no answer per creative, which is a Storefront-level route with no inventory source and no adapter, does not release automatically; assign the creative yourself there. Until it is accepted, a campaign-wide change to the buy’s creatives leaves a held creative out.

​

5.1450.0 — October 29, 2026 at 11:59 PM UTC

• A media buy now books when some of its creatives are still in the seller’s review, were rejected, or were replaced by a newer revision. Before, any one of them stopped the whole buy with CREATIVE_LIBRARY_REVISION_UNVERIFIED, and the booking retried and escalated to us for something no retry could change. Now the buy books without those creatives and each one is held: the seller owns the wait while its review is pending, and you own it when the creative was rejected or superseded. get with kind: "media_buy" and include: ["creatives"] returns held (owner and state) on each creative the buy booked without, and v2 campaign media buys return the same held object. A buy that books with none of its creatives is reported by the seller as pending_creatives. Two things to know: a held creative stays out of the booked buy until its review settles, and attaching it automatically when the seller accepts it follows in a later release, so assign it yourself in the meantime if you cannot wait. A creative that is not a wait (no review recorded, or one our own validation refused because its format matches nothing the seller offers) still stops the booking with its reason, because no review will settle it.
• An organization can now create at most 25 accounts in any 24 hours. Nothing changes below that, and no plan sets or raises it. The 26th request is refused with 429 RATE_LIMITED, details.reason account_creation_daily_limit, and a message to contact support to raise the limit; nothing is created. Do not retry the request: the 24 hours slide, so the next account is allowed once an earlier one is a day old.
• The count covers Buyer, Seller and Developer accounts, created by any route: the Add account dialog, POST /api/v2/accounts/create-child, save_account and approved account requests. It counts creations, not the accounts that exist now, so an account you archived or deleted after creating it still counts and creating and deleting in a loop does not get past it. Restoring, moving or converting an account is not creating one and is never refused, and repeating a request with the same idempotencyKey returns the account it already made. Accounts Scope3 staff create for you with the staff admin tool are never refused and do not count toward your 25; a staff member creating through the same routes you use (create-child, save_account) is limited like anyone else. The limit guards against a runaway agent or a misused key. save_account (including dryRun) and a buyer child account request are refused as soon as you ask, so no approval is recorded for a creation that cannot run; an approval that reaches the limit when it is approved ends as failed with the code account_creation_daily_limit. See Accounts in an organization.
• A directory reviewer who reconnects your app in the same browser now gets straight back in. When an OpenAI, Anthropic or Microsoft reviewer was still signed in from an earlier attempt, the sign-in skipped the password and the Authorize access step then failed, so the reviewer had to start again in a fresh private window. The reviewer login is now recognised from its live reviewer access either way, with the same read-only, no-spend access as before.

​

5.1448.0 — October 29, 2026 at 10:04 PM UTC

• A seller’s agent can now reopen a buyer request the seller declined. Read the buyer relationship with get and a declined request is listed with decisions: ["reopen"]; send save_seller with admission: { intakeId, expectedVersion, decision: "reopen" } to return it to pending review. Before, a declined request could not be revisited by an agent. Reopening works for Seller Accounts that still use retained relationships; a company-scoped account refuses it.

​

5.1447.0 — October 29, 2026 at 9:45 PM UTC

• Approval routing now falls back to the admins of a seller’s organization only when the seller account has no active admins of its own, so a seller account under an organization can route approvals without adding its own members. When the seller account has active admins, only those admins receive its approvals.
• Opening Campaigns from a self-serve advertiser on your Advertisers page now works. Before, the click was refused before it reached us, so Campaigns did not open. It now opens that advertiser’s campaigns, scoped to the buyer you sponsor.
• Add file in your Library now opens a page of its own, where you can drop files at any time rather than only when the Library is empty. Each file stays listed as it uploads, and its review opens in place when it lands, so you check the suggested name, category and tags without going to find the file. Save N files saves every file that is ready at once. Rate cards and avails sheets always save from their own change preview, because saving one changes live prices or availability. A file you leave unsaved stays a Draft, and your storefront agent does not use a Draft until you save it. Nothing to change on your side.
• A publisher re-check through save_coverage that overlaps Apostra’s own automatic re-check of the same publisher now reports CONFLICT, with a note to read coverage again in a few seconds, instead of an internal error. The other re-check’s result is the one that applies, so nothing needs repairing.

​

5.1446.0 — October 29, 2026 at 8:45 PM UTC

• The announcements setting in Murph settings covers product updates and news from Apostra. Notices that need you to act, such as a requirement, a deadline or a step your account must take, always reach you, even if you turned announcements off.
• You can now add a product to a live TikTok media buy. The product becomes a new ad group inside the buy’s existing TikTok campaign, so the campaign and its other ad groups are untouched, and the campaign budget rises by the product’s budget. The new ad group starts paused with no creative. Smart+, Search, catalog and daily-budget buys, and products that need a pixel, app or lead form, still take a separate media buy instead.
• A product priced at a fixed_price of 0 now shows up in buyer discovery, for storefronts that pass through a sales agent and for ones that sell a managed ad-server product, and save_wholesale_product accepts it, so donated, house and added-value inventory can be offered. Nothing to change for existing products. A product with no fixed_price is still an auction, and a negative price is still refused. The product page in the seller docs explains how a $0 price differs from an auction.
• An agent’s Overview page now holds everything the Test & certify page showed, so you no longer switch between two pages for the same facts. Below the headline finding it lists the agent’s states, one line each, then the checklist. After the checklist comes an Evidence section that opens to live certification for each use case, tests and recent test runs, AdCP 4.0 readiness, capability declarations and, for a creative agent, conformance. The Allow certification buys switch follows the Evidence section, with the same permissions as before. In the Developer rail, an agent now has Overview, Inventory sources and Webhooks.
• The open_agent_certification_page tool is retired. Call open_agent_page with the agent’s agentId instead; it opens the Overview page. If you call open_agent_certification_page, change the call before this release reaches you. In the TypeScript and Python SDKs, the retired operation’s type names stay as deprecated aliases of the open_agent_page names, and the operation itself is removed. The next SDK release takes the pre-1.0 minor version bump that removing an operation needs. Nothing else about your agents changes.

​

5.1445.1 — October 29, 2026 at 8:16 PM UTC

• A sales agent that refuses one buyer’s creative no longer takes its whole Source out of service. Before, a refusal such as CREATIVE_REJECTED, FORMAT_NOT_SUPPORTED or CREATIVE_SIZE_MISMATCH on sync_creatives was recorded as the Source failing, which set a live Source back to pending and stopped it taking buys. The refusal now shows as a degraded reading on the Source’s health, which keeps it visible but does not take the Source out of service. A creative sync that fails for any other reason still counts against the Source’s health, including a timeout, an authentication failure, a server error, or a VALIDATION_ERROR, which can mean the whole request was invalid rather than one creative refused. A Source already held back by such a refusal returns to live on the next check, about a minute after this ships, without any action from you.

​

5.1445.0 — October 29, 2026 at 7:32 PM UTC

• Product discovery now returns all the products an outside seller sends, not just the first 50. When a seller splits its answer across several pages, we fetch each page, up to the existing limit of 200 products per seller, for as long as the discovery time budget allows. Before this fix, products on later pages never reached you, so the products most relevant to your brief could be missing.

​

5.1444.0 — October 29, 2026 at 6:55 PM UTC

• When a message to your buyer agent in the Apostra chat has to wait for the agent to finish an earlier request, the chat now says the agent is still finishing a previous request and that this message will start once it’s done. When that request ends, the chat goes back to waiting for the agent. Before, the chat showed only that it was waiting for the agent, sometimes for a minute or more. This happens, for example, when you left the page while the agent was still working on your last message.
• A buyer agent whose organization granted it advertisers in other accounts now sees those accounts in V3 get_status. Each one is marked nameWith: "advertiserId" with up to 10 of its advertiserIds, advertiserCount, and access (read or read_write), and the text says to name one of those advertisers in advertiserId rather than the account in accountId. Naming such an account in accountId is still refused with ACCOUNT_NOT_REACHABLE, and for a buyer agent that refusal now says to name the account’s advertiser instead. Other API keys with no user behind them, and people signed in as themselves, see the same accounts as before.
• To be certified from 1 December 2026, a sales agent must support canonical creative formats: declare media_buy.features.canonical_creatives: true (an agent on AdCP 3.2 or later counts as declaring it unless it declares false) and publish canonical format_options on every product. From that day, an agent that does not is not certified, and its Sources stop taking new buys unless Apostra has given it a certification exemption. Agents that support only AdCP 3.0 cannot meet this and must move to AdCP 3.1 or later. Separately, Reliable Reporting, the compact lifecycle and webhook signing stay required from 1 February 2027. See Getting ready for AdCP 4.0.
• Prevent requested authentication context resolution from waiting indefinitely during a database outage, and reduce PostgreSQL checkpoint contention in PR acceptance tests.
• Apostra’s V3 connection no longer lists the demo storefront tools to accounts that cannot open their page. Those tools render a Merchandising page that the account cannot load without Merchandising access, so a directory scan such as OpenAI’s plugin review failed when it tried to read it. Every tool the connection lists now has a page the account can open.

​

5.1443.0 — October 29, 2026 at 4:56 PM UTC

• Certification now makes a test creative for products that accept video_vast. Before, a video_vast family was skipped as buy_creative_channel_unmatched unless Apostra support had supplied a VAST creative by hand, so it never reached a buy and the family stayed untested. Apostra now hosts one of its standard certification videos and writes a VAST tag that plays it, sized and timed to your format’s aspect_ratio, orientation, size limits and length limits (VAST 4.2, or your declared vast_version when it is 4.1 to 4.3; any other declared version, including 4.0, gets 4.2). Your agent receives it as a hosted VAST URL, with Apostra’s trackers added around it as for any VAST tag. Formats Apostra still cannot make a creative for (audio_daast and audio_vast) are still skipped as buy_creative_channel_unmatched, which is Apostra’s gap to close rather than something to change on your side.
• Reloading the Apostra web chat while Apostra is still writing the first answer of a new chat now reopens that chat, with your question in it, instead of an empty new chat. The chat’s web address now changes to the chat as soon as your first message is saved, not when the first answer finishes. The answer still finishes and is saved as before, and appears when you open the chat again. If you call POST /api/v2/apostra/chat/stream (or /api/v2/murph/chat/stream) yourself, the stream now also sends a conversation event, {"conversationUid":"…"}, before the answer; the final done event is unchanged, so clients that ignore unknown events need no change.

​

5.1442.0 — October 29, 2026 at 4:27 PM UTC

• Seller account decisions and product discovery now ask callers to retry during a rare buyer lifecycle lock conflict, instead of failing after a database deadlock.
• Certification now reports how your agent sends delivery reports. A new finding, “Delivery reports use the AdCP envelope”, shows as a flag on the Agent page when a source sends the AdCP 3.0 bare report instead of the AdCP 3.1+ envelope, or sends delivery reports we refuse because they fail the schema. It names the first field that failed and how many reports were affected, for example body.operation_id. It also counts refused reports your agent sent again within 15 minutes, because a 400 will not change and should not be retried.
• The finding stops nothing today: no buy is held back and no certification pass stops counting. Whether and when it becomes required is a later decision that the certification page will announce first. To clear it, send each delivery report as an AdCP 3.1+ envelope with the report under result, fix the field the finding names, and send the corrected report instead of retrying the refused one. See Delivery report format finding.
• V3 save_account can now create an account from a caller who can reach several accounts. On a create (a call that sends accountType), accountId is the account the call runs in, the same as on every other V3 write, so you no longer have to leave it out and be refused for not naming an account, or send it and be told a create takes no accountId. Send organizationId beside it when the new account belongs to an Organization other than the one the call runs in. Nothing else changes: an edit sent as accountId with name or settings.company still renames that account, an edit by id is the same, and a create that worked before still works.

​

5.1441.0 — October 29, 2026 at 3:59 PM UTC

• No-spend sandbox campaigns can now dispatch a product composed during the same private paused-Storefront test. The product remains private and is not added to the public catalogue; its original inventory row and the Source’s expiring authorisation are checked again immediately before booking.
• Certification no longer shows a failure for a buy Apostra placed without a creative. When none of the creatives Apostra offers fits a product’s declared formats, the test buy goes out with no creative. A buy with no creative cannot deliver, so it sends no reports, whether your agent held it pending or reported it completed. That result now stays inconclusive and says the gap is on Apostra’s side, so there is nothing for you to do. Results already recorded as failed for this reason change to inconclusive the next time Apostra re-checks the run.
• A seller’s own go-live sandbox campaign can now request proposals from its own Seller. Previously, the proposal round skipped that Seller because the advertiser account needed attention.
• A Library document no longer changes its name to “Response” after you use it to answer a brief. Your deck is a deck, whether or not you have sent it.
• Response is no longer a document category. Every other category says what a document is — a sales deck, a case study, a media kit. Response said what a document had once been used for, which is a fact about the brief it answered, not about the document. Filing by it is retired; the remaining categories are unchanged.
• Delivery reports that Apostra refuses now appear in your agent’s webhook results, with the first field that failed. If your agent sends media_buy_delivery callbacks and we answer 400, 413 or 503, open the agent’s Webhooks page or read webhookDeliveries on the agent: each refused report is listed as a media_buy_delivery entry, and a 400 names the field to fix, for example body.operation_id or result.media_buy_deliveries[0].by_package.
• Nothing changes for reports we accept, and nothing needs to change on your side. Accepted delivery reports are not listed, and we keep the record of each report for up to 90 days (less if the Inventory Source is deleted).
• Pressing Stop while your buyer agent is answering in the Apostra chat now cancels the agent’s work on that message, so your next message starts right away. Before, the agent kept working on the stopped message, and your next message waited for it, sometimes a minute or more. Anything the agent did before you pressed Stop still applies. If the stop can’t be sent, the chat says the agent may still be finishing. Leaving the page is not a Stop: the agent keeps working and its reply is in the chat when you come back.
• Every MCP connection to Apostra’s V3 endpoint (/mcp/v3) now lists the same complete set of tools, whichever kind of account you are in and whatever role you hold. Before, the list followed the account you connected with: a Buyer account saw Buyer tools, a Seller account saw Seller tools, and a read-only login saw only a few reads. One login reaches Buyer, Seller and Organization accounts, and the list is fetched once per connection, so a tool list that followed the first account hid tools you could reach after naming another one. Directory reviewers, who connect with a read-only login, now see the whole app too. Apostra’s in-product assistant is unchanged for now: it keeps the tool list for the account it is working in.
• Listing a tool is not permission to run it. Each tool still runs only in an account of its kind, and the call still needs the role it always needed. A call in the wrong kind of account is refused with a WRONG_ACCOUNT error that names the kinds the tool needs and the accounts you can reach that can run it; send one of them as accountId and call again. A call without the role it needs is refused with ACCESS_DENIED, and a directory reviewer login is still refused every write with REVIEWER_TOOL_PROHIBITED.
• Some tools remain unlisted for callers they do not belong to: Scope3 staff tools, and tools for a feature your account is not enrolled in. Tools that only a Page calls are still marked as not for the model. get_status now says that the connection lists every account kind. Agents that read the tool list at the start of a session should send accountId on each call, and should expect WRONG_ACCOUNT instead of a missing tool when they name an account of the wrong kind.
• The Apostra chat now answers “How many creatives do I have?” and “How many conversion events do I have?” for your whole account in one step, and it asks which advertiser or campaign you mean instead of quoting internal field names such as filter.advertiserId. When a V3 search for kind: "creative" or kind: "event_source" is sent without an advertiser and your account has several, the refusal still lists your active advertisers and now also says how to get the account-wide count: search the same kind with groupBy: "advertiserId" and no advertiser filter. Other kinds that need an advertiser refuse as before.

​

5.1440.0 — October 29, 2026 at 2:31 PM UTC

• The v2 buyer API now follows AdCP 3.3.0-beta.1. Product reads can carry values that version adds: restricted_attributes may include sex_gender, demographic predicates and targeting support may describe gender without age, collections may be empty, and SLA durations are no longer constrained to one pattern. Gender targeting (demographics.gender) is refused with a VALIDATION_ERROR on any product that does not declare it, and no product declares it yet. A VAST creative assigned to products that differ only in whether they state a player size is refused at creative sync until the AdCP SDK reconciles sizes across products; in the meantime, assign the two groups of products to separate creatives. Agents using the AdCP 3.3 preview must use 3.3-beta.1; others continue on 3.2.

​

5.1439.3 — October 29, 2026 at 2:07 PM UTC

• In the Apostra web chat, choosing All under your chats now opens your Conversation history even while an advertiser is selected, so you can reopen any older chat, including chats with a buyer agent. Before, when an advertiser was selected (for example, the one Apostra reselects for you shortly after the page opens), All showed an error and the history did not stay open. Choosing All with no advertiser selected works as before. The history still shows only your own chats for the selected advertiser or account, and nothing changes about how chats are saved. Nothing to change on your side.
• Each chat now has its own web address. Reloading the page, using your browser’s back and forward buttons, or opening the address again brings back the chat you were in, with the same assistant, instead of an empty new chat. A chat you reopen from your conversation history no longer blocks switching to another chat in the list.
• Documentation search through the V3 search tool (sources: ["docs"]) now answers on every request. Before, some calls came back saying the documentation index was not loaded, depending on which server handled them, and agents then told people that docs search was unavailable.

​

5.1439.2 — October 29, 2026 at 1:37 PM UTC

• A buy that is already running keeps receiving its creatives and your changes (pause, cancel, edits) when its seller’s sales agent is held for a health or certification recheck. Before, Apostra skipped the creative sync and the update without a record, so a creative the seller had refused could never be retried and a pause or cancel did not reach the seller until the hold cleared. Held sellers still receive no new buys.

​

5.1437.0 — October 29, 2026 at 12:12 PM UTC

• Nothing to change on your side. You can now turn Apostra’s own UTM tags off for a single campaign. Where the site analytics beta is on for your organization, Apostra adds utm_source, utm_medium, utm_campaign and utm_content to the landing page of each creative it sends to a seller. Set autoUtm to false to stop that for one campaign. It is true unless you set it.
• In V3, save_campaign takes tracking.autoUtm, and get with include: ["tracking"] returns it. In v2, PUT /api/v2/buyer/campaigns/{campaignId}/tracking-config takes auto_utm, and the GET returns it. false removes only Apostra’s tags. Parameters you set in utmConfig or macroAdditions, and anything in your own landing page URL, stay as you wrote them. A change applies the next time a creative is sent to a seller, and does not re-send creatives a seller already holds. Until the beta is on for your organization, the field is stored but your click URLs are exactly as you wrote them.
• Library now shows when Scope3 staff schedule a requested document deletion.
• Sellers do not need to do anything unless they want to Undo the pending deletion.
• A certification run now places at most 8 test buys. If your agent sells more than 8 kinds of format, the run buys the ones with no result yet first, then the ones that failed, then the ones whose passing evidence is oldest, and the rest follow on later runs. Agents with 8 or fewer formats are unaffected. The Agent page lists a format a run left out as not tested, with the reason deferred_by_cap, and nothing needs to change on your side.
• save_creative now checks a creative against its format when you save it, so a creative that a seller would reject is refused with a message that names the slot instead of being accepted and failing when it is sent. With a formatOptionRef the format is the seller’s option; without one it is AdCP’s default for the formatKind. The save refuses an asset or copy sent to a slot the format does not declare (for example social.brand_name on an unpinned image, which AdCP gives no such slot), an asset with no slot of its type to fill, a required slot left empty (including copy a seller requires, such as a headline), and an asset whose measured size, duration or file size is outside the limits of the slot it fills. A draft may still leave required slots empty, and an unpinned creative with only copy, a brief or a click URL is saved with a readiness warning as before. The same checks apply to files bound in sourceAssets, including product-bound images, and to an image saved with sourceAssetRef.
• This changes the V3 preview, and v2 creative inputs are unchanged. save_creative refuses an image saved into a campaign with sourceAssetRef when it omits copy that every image format of the campaign’s products requires. upload_creative_asset no longer accepts campaign_composition.required_authored_fields: it returns that list itself, computed from the campaign’s formats, and the upload task only displays it. Remove the field from calls that send it.
• Fixed the Media Partners connections list so a media partner with many mapped ad accounts no longer gets cut off with no way to scroll to the rest.
• Changing a Seller’s brand domain now also clears the previous brand’s name, logo and logo background, unless the new domain publishes its own. Before, a new domain that published a name but no logo left the old brand’s logo on the Seller card. The confirmation step for a brand domain change now lists these fields when they would be cleared.
• The Seller Dashboard analytics header now reads “Account” before your Seller Account number. It used to print that number under the label “Storefront”, although it was your Account number. The number is unchanged, and nothing needs to change on your side.
• You can now rename a Library document and edit its description after it is filed. Open the document and change either under What it is, beside the category and tags. Both save when you leave the field.
• An administrator of your organization can now create, register, rename and connect agents in its Developer account, and allow certification buys on them, when they name the account with accountId on a call. Before, save_agent refused them with “A person who directly administers this account must register agents” even though they administer every account in the organization, and the developer docs said they could. People who are only organization members, service tokens, delegated sessions and impersonation are still refused, and staff on read-only support access still cannot write.
• Only one organization can verify a domain. Once an organization has verified a domain, a buyer account outside that organization is no longer proved on it by member email, a DNS record or a staff approval. The account keeps its saved identity, unproved; if your organization operates as that domain, ask Apostra for a staff review to settle ownership. See Verify operator domain.
• A buy booked on a sales agent that is waiting on its activation checks is now kept up to date. Before, status updates for that agent’s buys stopped, so a buy could show PENDING_APPROVAL or ACTIVE after the seller had moved it. Its existing buys are read on the usual schedule again, and nothing changes for new buys, which that agent still does not take until its checks pass. No action needed on your side.
• A sales agent’s product mode now follows its declared media_buy.buying_modes on every routine capability refresh, not only when the agent is refreshed by hand. An agent that declares brief only and was still stored as wholesale is corrected on its next refresh, so its brief products appear in buyer discovery without anyone running a manual refresh.
• Reddit buys now accept carousel creatives. Send a carousel creative (carousel) with a headline and 2 to 6 cards, each with an HTTPS image, a landing page URL (or one creative-level click_url for all cards), an optional caption of up to 180 characters and an optional call to action, and Apostra creates the Reddit carousel post and the ad that runs it, keeping the cards in your order. Syncing the same creative again finds the existing ad instead of creating a second one, and a synced carousel can’t be edited in place: send the changed version under a new creative ID. Carousel cards take images only, as public HTTPS URLs.
• Reddit buys now accept video creatives. Send a video creative (video_feed or video_conversation) with a headline, an HTTPS video, an HTTPS poster image in the thumbnail asset and an HTTPS click_url, plus optional body text and call to action, and Apostra creates the Reddit video post and the ad that runs it. Reddit processes video after it accepts it, so a sync can answer that Reddit is still processing: sync the same creative again and it picks up the same Reddit job instead of starting another. Syncing a finished creative again finds the existing ad, and a synced video can’t be edited in place: send the changed version under a new creative ID. Carousel creatives are not supported yet.
• Seller billing mandates, the alpha feature for recording which advertisers your Seller Account may bill, are retired. Nothing replaces them, and no Seller Account had created a mandate. The five billing-mandates endpoints under /api/v2/storefront and their documentation are gone. Payout setup, payees, and billing are unchanged.
• A source health finding about creative formats your agent declares that its creative agent does not define now has an owner who can act on it. When the finding comes from your agent’s public catalog, it stays yours and offers Run discovery test, which reads that catalog again. When it comes from a response Apostra stored for a buyer’s brief, such as an InMobi product id that changes with every brief, running the discovery test cannot refresh it, so the finding is now Apostra’s: Apostra is looking into it and may ask you to correct the declaration, and you do not need to act unless asked.
• Seller Setup now offers Modular source only when your plan includes custom modular sources, so you are no longer sent into a setup flow that Apostra will refuse. Reading your seller account with get({ kind: "seller", include: ["entitlements"] }) now also returns customModularSources, which says whether your plan includes them. Ad server and sales agent sources are offered as before, and creating a modular source without the plan is still refused.
• Adding a modular source now shows why Apostra refused it. When your account does not have custom modular sources, or the source id is already taken, the Add a modular source screen shows that reason instead of a generic “Couldn’t create the modular source” error.
• Spotify now accepts the standard audience, postal and device targeting fields. audience_include and audience_exclude name Spotify audiences by their id, geo_postal_areas takes US ZIP codes inside the ad set’s country, and device_type (desktop, mobile) and device_platform (ios, android) become Spotify’s platform targeting; because Spotify keeps one platform list for both, changing devices on an ad set that already restricts them means sending both fields. They work on create and update, and Apostra checks Spotify applied each one. Apostra refuses a value Spotify cannot express (tablet, connected TV, other operating systems, other countries’ postal codes, exclusion lists for devices) instead of dropping it.
• When a campaign geography change removes a country, region, DMA, or exclusion from a live media buy, the buy now keeps it removed. Before, the location came back from the buy’s original create request: get showed it, and the next change to the buy, even a budget-only one, sent it to the seller again and widened delivery. For example, a buy created for Tasmania whose campaign moved to postcode 2782 now stays on 2782 alone. One known limit: when a line item has several packages (for example pacing periods) and only some of them are cleared, the cleared ones can still get the old location back. A campaign geography change clears every package that holds the location, so it is not affected.

​

5.1436.0 — October 29, 2026 at 10:14 AM UTC

• Certification now checks that your sales agent says which creative changes it takes on a live buy. If get_media_buys returns a live buy with no action list (neither available_actions nor valid_actions), the Agent page shows a flag for “Live creative changes are declared”. This is a finding only: it stops nothing. No new buy is held back, no certification pass stops counting, and you do not need to do anything to keep selling.
• To clear it, declare the live creative changes you take in available_actions on your media-buy responses: update_creative_assignments to add a creative to a package, remove_creative to take one off, and replace_creative to swap one in place, each with its mode. A product that should not take a live creative change leaves that action out of a list that is present, which means it is not supported. Declaring support lets buyers change creatives on a live buy from Apostra’s tools. What the check reads and how to fix it.
• The Reddit Conversions product now optimizes for a conversion event instead of clicks. Name one Reddit Pixel and one event (purchase, add to cart, lead or complete registration) in optimization_goals; Reddit optimizes toward that event on the Pixel you name, and the bid stays a per-click bid. A buy with no event goal is refused rather than run as a click buy. Custom events, value goals, page views and attribution-window changes are refused with a message naming the field. The Reddit App Installs product is no longer offered, because the adapter cannot yet register an app or read install events; use the Traffic product to send clicks to an app destination.
• Snap creatives with a click-through destination no longer fail to sync with “requires an authorized Public Profile.” The hosted Snap OAuth connection never requested the Public Profile scope, so the check always failed. New and reconnected Snap connections now request it. Sellers with an existing Snap connection must reconnect it (Settings > Connections) to pick up the fix.
• Spotify media buys now report review state accurately. A buy whose only ads were rejected, failed or archived reads as pending_creatives instead of looking ready, rejected ads keep their reason, and an ad Spotify has approved and is serving reads as approved in both get_media_buys and list_creatives. Ad sets waiting for review, approved, or running with restrictions no longer read as paused, and each package shows Spotify’s own ad set status and any pending or rejected review under ext.spotify.
• An administrator of your organization can now read its Developer account’s agents when they name the account with accountId on a call, or after a stateless connection’s switch_account. Before, get_status, get and search refused them with “Only an organization account admin, an account-bound machine credential or Scope3 support staff can read owned Agents”, even though they administer every account in the organization. People who are only organization members, service tokens, delegated sessions and impersonation are still refused. The refusal now says what to do next: sign in as an administrator of the account or its organization, or connect with a credential issued for the account.
• Pinterest buys now accept an image you uploaded to Apostra, with no public image URL. Upload the image, send it as a Standard Pin creative, and Apostra hands Pinterest a short-lived link to fetch it. Syncing the same creative again finds the existing Pin instead of creating a second one, and sending different image bytes under the same creative ID is refused: use a new creative ID. Uploaded video isn’t supported yet.
• Creating a wholesale product without inventory.execution now stops right away with a message that names the field, the adapter it needs, and where to copy it from, instead of failing later with a validation error from the sales agent. A change to an existing product still keeps its stored execution when you leave it out.
• search and get now take an account, advertiser or seller account id either as a whole number or as a number in quotes, in every filter. Before, some filters refused advertiserId: 12 and others refused accountId: "12", so an agent that guessed the wrong form got an error. Zero, negative, fractional and non-numeric ids are still refused. Nothing changes in what you get back.
• When search or get is asked for a kind that belongs to the other kind of account, the refusal now names that kind, says the tool itself works in the current account, and lists the kinds this account can read. Before, it said the whole tool was for a buyer or seller account, which agents read as “search does not work here”. Nothing to change on your side.
• Spotify creatives now download their audio, video and image files only from public HTTPS addresses; links to private or internal addresses, links that redirect, and files over the size limit are refused with a clear reason before anything reaches Spotify. Buyers can also send images through private upload references for Spotify creatives. No action is needed for creatives that already use public HTTPS links.

​

5.1435.0 — October 29, 2026 at 9:28 AM UTC

• save_ask now says plainly which keys belong to a new ask (kind: "create") and which to an answer on an existing one (kind: "update", which takes only id and requester), and a call that mixes them is refused with the shape it matched and the exact fix, instead of a bare list of allowed keys. The subject and channel refusals now also say which ask type takes them, so an agent filing a support request can correct the call and file it first time.
• A creative a seller approves for a direct ad-platform storefront (for example Meta) is now written to the platform. Before, the approval was recorded and the creative waited until its delivery timed out, because the delivery worker had no way to reach the platform. The platform’s own review verdict then settles the creative.
• You can save approval routing again after a reviewer has left your account. If someone who was named as a reviewer was removed or deactivated, they stayed hidden in the saved routing, so every save failed with “Approval routing users must be active customer members” and a user id that matched nobody on screen. The routing settings now list only reviewers who are still active members, so the reviewers you see are the ones that are saved. Approvals were never routed to the removed reviewer, and there is nothing to change on your side.
• Sellers can retry adding a file without seeing a false upload error when it is already in their Library or a previous attempt timed out. No action is needed for existing files.
• Live delivery for Reddit campaigns now reports what Reddit reports. The read uses the ad account’s own currency and timezone instead of falling back to USD and GMT, and the campaign’s real status (active, paused, canceled or pending start) instead of always “active”. If Reddit fails to return the account, the campaign, its ad groups or the report, the read now fails with Reddit’s error instead of returning zero delivery. A start or end that falls inside an hour is refused with a message naming the field, because Reddit reports only whole hours; an inclusive end at 23:59:59 is read as the end of its hour.
• Live delivery for Spotify campaigns is read over whole hours and returns one row per day. A date range ending at 23:59:59 is read to the end of that hour, and a start or end inside an hour is refused with a message naming the field, because Spotify cannot report part of an hour. When the range covers whole days in the ad account’s timezone, the delivery now carries a daily_breakdown with one row per day; reach and frequency stay on the campaign total and are never given per day. The read now refuses when Spotify does not return the ad account’s currency, instead of reporting spend as US dollars.
• A sales agent that declares brief only in media_buy.buying_modes now gets the product mode it declares, even when an older staff-set WHOLESALE value contradicted it, so its brief products show up in buyer discovery. Opening an agent no longer fails with “This agent can’t be shown” when one agent’s stored connection setup no longer matches its owner.
• The creative_formats_unresolvable source health finding is now judged on the catalog responses Apostra read from your agent in the last 24 hours, so an old product from a brief-specific response, such as an InMobi product id that changes with every brief, no longer keeps it open. The finding’s time is now when those responses were read, and its summary says it clears when a newer response no longer lists the product or when the responses age out. Products already used by a media buy are not changed.
• Pinterest creatives now show Pinterest’s real review verdict. A creative reads approved only after Pinterest approves its ad. It reads pending review while Pinterest is still reviewing, even if the ad is switched on. A rejected ad is reported as rejected with Pinterest’s reason, and list_creatives returns each creative’s status and per-package review instead of always saying processing. Catalog product-group promotions stay pending review, because Pinterest reports no review verdict for them.
• Reddit buys now accept image creatives. Send an image creative (image_feed or image_conversation) with a headline, an HTTPS image, an HTTPS click_url and, optionally, body text and a call to action, and Apostra creates the Reddit image post and the ad that runs it. Syncing the same creative again finds the existing ad instead of creating a second one, and a creative you uploaded to Apostra reaches Reddit without a public image URL. A synced image creative can’t be edited in place: send the changed version under a new creative ID. Video and carousel creatives are not supported yet.
• Apostra now buys from your sales agent through the AdCP 3.2 compact lifecycle only after your agent passes the compact-lifecycle certification test. Advertising request_proposals in media_buy.lifecycle_tools no longer changes how Apostra buys from you; until you pass, Apostra keeps using get_products. A later failed run returns Apostra to get_products until the next pass.
• Spotify media buys now refresh in the hourly status check even when one buy cannot be read. A buy that fails is reported on its own in the response’s errors list, with Spotify’s own error code, and the other buys come back as normal. Spotify’s error codes now reach the storefront’s diagnostics instead of a generic “service unavailable”, and reading a buy stops after 90 seconds so the answer is returned before the check gives up. Reading an account’s measurement datasets no longer fails with Spotify’s “unexpected parameter” error.
• A storefront whose sales agent changed no longer shows “Agent implementation health: erroring”. A detected change asks nothing of you and never affected routing; the storefront overview and Source Health now show the agent as healthy while Apostra’s hourly read of its capabilities is current, and as stale only when that read is more than a day old.
• save_creative on V3 now accepts industry_identifiers, the AdCP list of Ad-ID, ISCI, Clearcast clock and IDcrea codes, when you create or update a creative, and get returns the saved list. Broadcast sellers identify each spot by these codes and often refuse a creative that has none, so you can now add them yourself instead of asking us to. An update replaces the whole list and a type AdCP does not define is refused. You can send the field on a create with assets, sourceAssets or sourceAssetRef, and replacing a draft’s media from uploaded files keeps the identifiers the creative already has unless you send a new list.

​

5.1434.0 — October 29, 2026 at 7:43 AM UTC

• Changing a campaign’s creatives with save_campaign and creativeIds now asks the sellers of the campaign’s running buys whether they take each change, by the same rule save_creative uses, so a change to a live buy answers to one rule whichever side you make it from. A seller says what it takes in the actions it declared: an attach is an assignment (update_creative_assignments) and a detach is a removal (remove_creative). If the seller of any running buy a change reaches declared what it takes and left the change out, save_campaign returns ACTION_NOT_ALLOWED on creativeIds with AdCP’s own reason (details.reason: "not_supported_on_buy"), details.attempted_action, and the details.mediaBuyId and details.campaignId that refused, and no creative is attached or detached. A seller that declared nothing is not refused, and creatives keep reaching those buys as they do today. Before this, save_campaign sent the change and left delivery to each seller afterwards. One thing to know: save_campaign can also change other campaign fields in the same call, and those are saved before the creatives are replaced, so a refusal can come after them; the error then reports partialWrite and says prior changes were already saved. Send creativeIds on its own if you want a refusal to leave everything as it was.

​

5.1433.0 — October 29, 2026 at 6:45 AM UTC

• A creative you attach to or detach from a campaign with save_creative and campaignIds now asks the sellers of that campaign’s running buys whether they take the change, and tells you which running buys it went to. A buy’s seller says what it takes in the actions it declared: an attach is an assignment (update_creative_assignments) and a detach is a removal (remove_creative), and get with kind: "media_buy" now shows both in liveChanges as assignCreatives and removeCreatives, each accepted, conditional, needs_seller_approval or not_accepted. If the seller of any running buy the change reaches declared what it takes and left the change out, save_creative returns ACTION_NOT_ALLOWED before anything happens, with AdCP’s own reason (details.reason: "not_supported_on_buy"), details.attempted_action, and the details.mediaBuyId and details.campaignId that refused; nothing is attached, detached or sent to a seller. A buy whose products do not accept the creative’s format is not asked. A seller that declared nothing is not refused: creatives keep reaching those buys as they do today. On success the result carries liveMediaBuys, the running buys the change was queued to; each takes it as a pending change, the buy keeps running as it was until the seller confirms, and it appears as pendingChange on get. Where a storefront keeps a buy’s history, the change is a new revision there with origin adcp, and a change made while another change to the same creative or campaign is in flight returns CONFLICT, so read the creative and send the full set again. To swap a creative, attach the new one and detach the old one. Two things are not covered yet: changing a campaign’s creatives from the campaign side with save_campaign, and assigning a creative to a single buy or package.
• Changing the total budget of a live media buy no longer fails when the seller lists its budget changes as raising and lowering the budget. Apostra checks a budget change against what the seller says it takes. It looked only for the older single “change budget” entry, so a seller that listed raising and lowering the budget separately, as Meta, Google, TikTok, Pinterest, Snap, LinkedIn, Reddit, Spotify and the retail-media sellers do, was wrongly treated as not taking a budget change, and Apostra refused the change before sending it. Apostra now reads both forms and checks the direction of the change: a higher total needs the seller to take a raise, a lower one a lowering, and the older single entry covers either. A seller that takes only a raise is not sent a lower total: Apostra refuses that change up front with a “capability not supported” error and sends nothing to the seller, and the same holds the other way round. Nothing to change on your side.
• A live OpenAI Ads media buy now tells the buyer exactly which changes it accepts right now: pause while it is active, or resume while it is paused and no ad or ad group is archived and every package has a creative; cancel; end-date changes; start-date changes until the flight starts; package budget changes; targeting changes while a live package exists (on an active buy, only when no ad is archived and every package has a creative); and creative assignment changes when a creative in the right format is synced to the account. Rename, package bid changes and creatives are not listed, and OpenAI Ads does not take a rename or creatives; a package bid change still works. Because Apostra checks an update against that list before sending it, no change Apostra used to refuse now goes through to OpenAI Ads: the old list already offered everything OpenAI Ads accepts. One thing is now refused up front: a targeting change to an active buy that has an archived ad or a package with no creative, which Apostra used to send on (OpenAI Ads took a country or audience change there, and a hint or product-set change failed after the buy had been paused and was put back). Nothing to change on your side.

​

5.1432.0 — October 29, 2026 at 5:33 AM UTC

• A live Spotify media buy now tells the buyer exactly which changes it accepts right now: pause while the campaign is active or resume while it is paused, end-date changes (extend or shorten the flight) while every ad set records a start and end time, package budget changes while every ad set holds a budget, and geo targeting changes on buys that recorded their targeting at creation. A completed or deleted buy lists nothing. Because Apostra checks an update against that list before sending it, geo targeting changes to a live Spotify buy that Apostra used to refuse now go through to Spotify, which already took them. Start-date changes are no longer listed: Spotify has never accepted them, and Apostra now says so before sending instead of after. Cancel is not listed either, because Spotify cannot cancel a campaign; pause it instead. Rename and package bid changes still work but are not listed. Nothing to change on your side.

​

5.1431.1 — October 29, 2026 at 5:04 AM UTC

• When an account cannot be added until the organization chooses a plan, the chat now opens Plan & Billing in place. Choose a plan there, then retry the account change.

​

5.1431.0 — October 29, 2026 at 4:52 AM UTC

• A live Amazon, Criteo, CitrusAd or Universal Ads media buy now tells the buyer exactly which changes it accepts right now. Amazon (Sponsored Products) lists pause and resume, cancel, end-date changes and campaign budget changes. Criteo lists pause and resume (only when a line item would change), cancel, start and end date changes, budget changes, and moving budget between line items when two are still open. CitrusAd lists pause and resume, cancel, end-date changes and budget changes. Universal Ads lists pause and resume, cancel, total budget changes, and start and end date changes. A buy that has ended (every Criteo line item finished, an archived Amazon or CitrusAd campaign, a deleted Universal Ads campaign) lists none. Rename (Criteo, CitrusAd) and an Amazon package bid change still work but are not listed, because AdCP has no action for them. These four listed no changes before, so Apostra checked nothing before sending an update. Because Apostra now checks an update against that list before sending it, no change Apostra used to refuse goes through. What changes is that Apostra now refuses up front, with a clear message, a change these platforms did not apply anyway: a start-date change on Amazon or CitrusAd, and a pacing change on all four. Updates to a buy that lists none are sent as before. Nothing to change on your side.
• A live Snap media buy now tells the buyer exactly which changes it accepts right now: pause or resume, cancel, end-date changes, start-date changes until the flight starts, creative assignment changes on its packages, package budget changes while every package holds a budget, and geo, language and audience targeting changes on campaigns that recorded their targeting at creation. A resume is listed only when every package holds a creative. A buy with no recorded pause or resume intent lists only pause or resume and cancel, because Snap refuses every other change until one is recorded. Because Apostra checks an update against that list before sending it, end-date, creative assignment and targeting changes, and start-date changes before the flight starts, to a live Snap buy that Apostra used to refuse now go through to Snap, which already took them. Rename still works but is not listed. Nothing to change on your side.
• Buyer agents and the Apostra chat can now count creatives and conversion event sources across your whole account in one call. Add groupBy: "advertiserId" to a V3 search for kind: "creative" or kind: "event_source" and leave out filter.advertiserId: you get the total for every active advertiser you can access, plus each advertiser’s share. Before, both kinds could only be listed one advertiser at a time, so a question like “how many creatives do we have?” meant one search per advertiser and could take minutes to answer. The search’s other filters still apply, so a creative count covers active creatives unless you ask for archived ones. Send filter.advertiserId to count one advertiser. A creative count does not take filter.campaignId; to count one campaign’s creatives, search it without groupBy and read total. A plain search of either kind still needs an advertiser, as before.

​

5.1430.0 — October 29, 2026 at 4:17 AM UTC

• You can now add a product to a live Google Search media buy. The product becomes a new ad group inside the buy’s existing Google campaign, and the campaign budget goes up by its budget, so the campaign and its other ad groups keep running. Buys that were created outside Apostra, Performance Max buys, and products that need audiences or a different bidding strategy still take a separate media buy instead.
• You can now change a line item’s pacing on a media buy that is already running, without creating a new buy, when the seller takes that change. Existing calls behave the same unless you send pacing on a product. Check that get shows liveChanges.changePacing as accepted, conditional or needs_seller_approval (a conditional seller can still refuse a particular change), then send save_media_buy with mediaBuyId and products: [{ productId, lineItemRef, pacing }], where pacing is even, asap or front_loaded. It can go with a targeting or frequency-cap change on the same line, each decided by its own seller answer, but not with flight, budget, name or other product edits. The new pacing goes to every open package of the line item, and a package whose flight has ended keeps its old pacing; AdCP keeps a package’s pacing under the media buy’s own. The result is action: "updated" once the seller applies it, or action: "pending_approval" while the seller has it but has not applied it; the buy keeps its current pacing in the meantime, the change shows as pendingChange, and you should not send it again. A seller that does not list update_pacing for the buy, or declared nothing, gets ACTION_NOT_ALLOWED with AdCP’s own reason, details.reason: "not_supported_on_buy" and details.attempted_action: "update_pacing", before anything is sent. A seller-optimized buy does not take package pacing yet and returns NOT_IMPLEMENTED naming products[n].pacing. pacing is for an existing buy: on a draft it is saved on the line item, and on a create it returns VALIDATION_ERROR because a new buy takes its pacing from budget.pacing.
• Fixed a bug where Snap creatives could receive an unrequested click-through link. Omitting a destination URL on a Snap creative (for example, an awareness-only video ad) now keeps it link-free, instead of silently attaching our internal click-tracking link as the ad’s destination and switching the ad’s type. A creative with an explicit destination URL is unaffected.

​

5.1429.0 — October 29, 2026 at 3:31 AM UTC

• A harmless question to your hosted buyer agent is now answered even when something earlier in the chat makes the AI model provider refuse it. Before, after an earlier message in the chat (for example, asking the agent to repeat its instructions), a later question such as “how many creatives does my advertiser have?” could fail with “couldn’t answer that message” twice before working. Now, when the agent had only looked things up, Apostra sends the question again in a fresh session, first with the recent conversation and then on its own, and shows you the answer. The answer can take longer when this happens. A message is never resent once the agent has started an action that changes something; you see “couldn’t answer that message” as before.
• Buyers in the Creative Engines beta profile can now generate copy for empty Creative composer slots, regenerate one requested slot without replacing other buyer-written copy, and see where each slot value came from. Copy generation follows the existing daily preview caps and keeps older composer drafts editable.
• Fixed TikTok ad creation, which previously failed for every advertiser because it required a CUSTOMIZED_USER identity type TikTok has since retired. Both the bundled media-buy path and the post-buy creative-assignment path now deliver ads using the TikTok account identity already linked to the connection, instead of matching a dead identity type against a creative’s authored name.
• The web chat works better on a phone and with a screen reader. On a narrow screen, the row of shortcut icons now runs across the top of the chat instead of down the side, so the conversation starts right below it and the message box stays fully on screen. Screen readers now announce which agent you are chatting with on the agent picker (for example, “Chatting with Murph. Choose an agent”), and the message box is announced as “Message” instead of having no name. Nothing to change on your side.
• A live LinkedIn media buy now tells the buyer exactly which changes it accepts right now: pause (active or draft campaigns), resume (paused or draft campaigns that have a creative), cancel, end-date changes, budget changes, and geo targeting changes on campaigns that recorded their targeting at creation. An archived campaign lists only cancel, a completed campaign lists no pause or resume, and a campaign in an inactive ad account lists nothing. LinkedIn does not take a start-date change, so none is offered. Because Apostra checks an update against that list before sending it, end-date and geo targeting changes to a live LinkedIn buy that Apostra used to refuse now go through to LinkedIn, which already took them. Rename and package bid changes still work but are not listed. Nothing to change on your side.
• A live Pinterest media buy now tells the buyer exactly which changes it accepts right now: pause while it is active or resume while it is paused and none of its packages is a draft, cancel, end-date changes, start-date changes until the flight starts, geo and audience targeting changes on campaigns that recorded their targeting at creation, and package budget changes while every live package holds a budget (or, on a campaign with a campaign-level budget, while it has a single live package and a campaign budget). Because Apostra checks an update against that list before sending it, end-date and targeting changes, and start-date changes before the flight starts, to a live Pinterest buy that Apostra used to refuse now go through to Pinterest, which already took them. Rename and package bid changes still work but are not listed. Nothing to change on your side.
• A live Reddit media buy now tells the buyer exactly which changes it accepts right now: pause or resume, cancel, budget changes while the campaign holds exactly one ad group, and creative sync. An archived (canceled) campaign lists nothing. Rename and geo targeting changes still work on Reddit but are not listed, because the list has no name for a rename and a geo change depends on details a response cannot see (the ad group’s Pixel, the recorded targeting). Reddit takes no flight-date, pacing, package bid, package pause, new-package or creative-assignment change, so none is listed. Because Apostra checks an update against that list before sending it, no change that Apostra used to refuse is newly sent to Reddit; a budget change to a campaign with several ad groups is no longer listed and Apostra now refuses it before sending, where Reddit refused it before. Nothing to change on your side.

​

5.1428.0 — October 29, 2026 at 2:23 AM UTC

• You can now change a line item’s frequency cap on a media buy that is already running, without creating a new buy, when the seller takes that change. Existing calls behave the same unless you send a frequency cap on a running buy. Check that get shows liveChanges.changeFrequencyCap as accepted, conditional or needs_seller_approval (a conditional seller can still refuse a particular change), then send save_media_buy with mediaBuyId and products: [{ productId, lineItemRef, targetingOverlay: { frequency_cap } }] and nothing else in that call; send frequency_cap: null to clear the cap. This is a separate answer from liveChanges.changeTargeting: a seller that takes targeting changes does not thereby take frequency caps, and an overlay that carries a cap and another targeting dimension needs both answers. The new cap goes to every open package of the line item, and a package whose flight has ended keeps its old cap. The result is action: "updated" once the seller applies it, or action: "pending_approval" while the seller has it but has not applied it; the buy keeps its current cap in the meantime, the change shows as pendingChange, and you should not send it again. A seller that does not list update_frequency_caps for the buy, or declared nothing, gets ACTION_NOT_ALLOWED with details.action: "update_frequency_caps" before anything is sent; a seller that refuses a change it took returns ACTION_NOT_ALLOWED with details.reason: "seller_refused" and the buy is left as it was. This replaces the NOT_IMPLEMENTED on targetingOverlay.frequency_cap that a live buy returned. The buy-level cap a campaign freezes at creation is unchanged.

​

5.1427.1 — October 29, 2026 at 2:11 AM UTC

• When you chat with your buyer agent in Apostra and it works in a different account from the one you are viewing, a line under the assistant picker now names the accounts it works in, for example “AdClaw works in Alex Buyer (2982), not scope3 (1).” The agent is also told which account you are viewing, so it can answer “which account am I in” correctly. Neither changes where the agent acts: it still works only in the accounts its advertiser grants give it.
• A buyer agent, and an API key with no user behind it, now see only the account they work in. On V3, get_status listed other accounts for them, and the agent could not use any of them: naming one returned ACCOUNT_NOT_REACHABLE. A hosted buyer agent listed the other accounts of the person it was answering. An API key with no user could list, and on a session switch into, the accounts of an unrelated person whose user id matched its account id; customer_list on the Buyer MCP server and the REST tools endpoint did the same. Now get_status and customer_list list no account other than the one the agent or key runs in, and customer_switch refuses an API key with no user. People signed in as themselves, and their own API keys, see and switch accounts as before.

​

5.1427.0 — October 29, 2026 at 1:30 AM UTC

• A chat with your hosted buyer agent keeps working after a message it could not answer. Before, one failed message, for example one the AI model provider refused, made every later message in that chat fail too, in the Apostra chat and in Slack. Now the chat says the agent couldn’t answer that message, and your next message gets a normal answer, with the recent conversation carried over. When the agent does not answer a message, the chat history now shows a note after it saying why, and sending that same message again does not add a second copy. Nothing to change on your side.
• In the web chat, a reply that wraps part of its answer in a collapsible section no longer shows raw <details> and <summary> tags as text. The section’s title now appears as a bold line, with its contents shown in full below it, the same way these replies already read in Slack. The section is not collapsed; tables, lists and other formatting inside it render normally. Any other HTML in a reply is still shown as plain text and never runs. Nothing to change on your side.
• Google Ads search, display, video and Demand Gen ads now attach to their ad group. Before this fix, Google created each ad and Apostra then removed it, because its check that the ad had landed compared the wrong ID. The buy was created but had no ad, so it could not serve. Nothing to change on your side: re-send a Google creative that shows as failed to attach it.
• A live Google Ads media buy now tells the buyer exactly which changes it accepts right now: pause or resume, flight-date changes, package budget changes where the packages hold budgets, audience targeting changes on search and display campaigns that recorded their targeting at creation, and creative sync. A removed campaign offers nothing. Because Apostra checks an update against that list before sending it, flight-date and audience changes to a live Google buy that Apostra used to refuse now go through to Google, which already took them. Rename, package bid changes and package pause still work but are not listed. Nothing to change on your side.
• Pinterest Ads buys and delivery now say what Pinterest actually did. A package bid_price is applied as Pinterest’s maximum bid and checked against what Pinterest returns, or the request is refused: it must be positive, in the ad account’s currency, at or above any floor, and for a product Pinterest bills per impression. Without a bid_price, Pinterest bids automatically instead of using an invented $2 bid. If Pinterest rejects the requested keywords, the create fails and the campaign is archived instead of delivering to a wider audience, and brief interests with no match in Pinterest’s taxonomy are listed in the response. Live delivery and product prices use the ad account’s own currency instead of US dollars, and a failed read of the campaign, the currency or the ad-group analytics now fails the request instead of reporting active, dollars or no packages. Delivery states the whole UTC days it read.
• An administrator of a parent organization can now bind one of the organization’s buyer agents to a Slack channel connected to one of its child accounts. Before, the request was refused from the parent organization with “Write access is required”, and once past that with “Slack channel is not connected to this customer”, and there was no other way to make that binding, because administrators acting through the parent are not allowed to manage bindings from inside a child account. The binding belongs to the child account, and the child account must also be enrolled in buyer-agent channel bindings. Listing an agent’s channel bindings now shows its channels on every account of the organization, and an organization administrator can revoke any of them. A channel connected to an account outside the organization is still refused. Nothing to change on your side.
• A failed Pinterest media buy update now says mutation_outcome: rolled_back whenever Pinterest’s own readback shows the campaign and its ad groups are back to how they were before the request, so you can tell the failed update changed nothing and retry safely. Before, only a refused rename said so. A write that timed out, hit a Pinterest server error, or that Pinterest acknowledged but its readback did not show still reports no outcome, because it can land after the undo.
• The Python SDK can now use the operating-system credential store for an apostra login, including refresh-token rotation and account binding. Existing protected file logins migrate automatically; machines without a credential store retain the warned 0600-file fallback.
• Reddit media buys now use the bid and geography you ask for, or refuse the request before booking anything. A package must carry a bid_price (a bidless product such as Promoted Post Awareness takes none) and a geography in targeting_overlay.geo_countries; Apostra no longer substitutes a $1 bid or the United States. A Reddit media buy takes one package, so book each product as its own media buy. A rejected ad no longer counts as a creative on the buy, and every Reddit read now agrees on whether an ad is approved, pending or rejected, with Reddit’s reason shown for a rejection.
• AdCP clients can call get_adcp_capabilities without an adcp_version, to discover which versions the sales agent serves before choosing one. Other calls still need adcp_version.
• Reliable Reporting errors now say how to recover. When ESA has not finished preparing a reporting status or its history, the error is now marked transient, so retrying the same request later succeeds. Before, it was marked correctable, as if the request had to change. A reporting revision or reference the buyer cannot see now returns the standard REFERENCE_NOT_FOUND error.
• When a media partner has not finished setting up your advertiser’s account, a wholesale product search now says so. The media partner’s row is finished, not partial, with outcome skipped, reason_code account_needs_attention on V3 (eligibility on v2, with the same suggestion) and a suggestion that points to Media Partners. Before, the row read as a media partner still responding, with no outcome, so a buyer agent kept waiting for products that were never coming. On V3, get of one of that media partner’s products now returns BUYER_SETUP_REQUIRED, with the reason (account_needs_attention or account_pending) in details.reason, instead of NOT_FOUND; an agent that branches on NOT_FOUND for these products should also handle BUYER_SETUP_REQUIRED. A media partner that is still responding, or that answered normally without the product, reads as before. A media partner’s own wholesale get_products response to an account that cannot buy from any of its sources still has an empty products list and the same message, and now also carries an AdCP ACCOUNT_SETUP_REQUIRED entry in errors. To fix it, open Media Partners and check your account with that media partner.
• A live TikTok media buy now tells the buyer exactly which changes it accepts right now: pause or resume, end-date changes, geo and audience targeting changes on campaigns that recorded their targeting at creation, and budget changes while the campaign and every ad group hold a budget. TikTok does not take a start-date change, so none is offered. Because Apostra checks an update against that list before sending it, end-date and targeting changes to a live TikTok buy that Apostra used to refuse now go through to TikTok, which already took them. Rename and package bid changes still work but are not listed. Nothing to change on your side.

​

5.1426.0 — October 28, 2026 at 11:48 PM UTC

• You can now add a product to a live Meta media buy. The product becomes a new ad set inside the buy’s existing Meta campaign, so the campaign, its other ad sets and their spend are untouched. A paused buy leaves the new ad set paused. Buys that share one campaign budget, or that were created outside Apostra, still take a separate media buy instead.
• In an account with workspace tabs, a chat with your buyer agent is now listed under the workspace you started it from, as a chat with Murph is. Before, it was listed only under Inventory, so it was missing from the other workspaces’ recent chats.
• A rate-card floor keyed on online video (olv) now applies to your video products even when your ad server doesn’t name the product’s channel. Before, those floors matched nothing, so composed proposals and your wholesale catalog could quote video inventory below your rate card. A product your ad server marks as CTV keeps its own channel and isn’t given an online-video floor.

​

5.1425.0 — October 28, 2026 at 11:00 PM UTC

• When you call get_status without naming an account and you can act in several, it now lists those accounts for you to pick from: each one’s accountId, kind and name, in a new accounts field and in the text. Your agent can still answer a read-only question in the account this call read and confirms the account with you before its first write. The account this call read comes first and says whether it needs you; the others do not say yet, because Apostra does not read every account’s setup to fill that in. A person with one account still gets that account’s status directly, and naming an account with accountId works as before.
• The list is one page of up to 25 other accounts. Scope3 staff, who reach every customer, get accounts.nextCursor and a list_more_accounts next step: send the cursor as cursor to read the next page. The response says how many accounts are not shown.
• This is the first of two steps. get_status still reads the account it chose by default and still returns reachableAccounts, so a client built against today’s definition keeps working. Both go once hosts have approved this definition. cursor is new and optional.

​

5.1424.0 — October 28, 2026 at 10:27 PM UTC

• When your buyer agent is the assistant in the Apostra chat, the chat now shows who is answering. The agent’s replies and its “waiting” bubble carry the agent’s own avatar instead of Apostra’s, and the note shown after you press Stop names the agent rather than Apostra. While the agent is selected, the chat no longer offers uploads from your computer, Google Drive or dragging a file in, because the agent takes text only; files you had already added are removed. Switching between Apostra and your buyer agent, in either direction, starts a new chat whenever the current one has begun, including a chat still loading from your history and one whose first message to the agent failed; before, those cases kept the earlier chat. The previous chat stays in your history. Nothing to change on your side.
• A live Meta media buy served under AdCP 3.2 now lists package budget changes and package bid changes among the changes it accepts, where Meta takes them: budget changes when every ad set holds its own lifetime budget, and bid changes unless a campaign budget shares one bid strategy across the ad sets. Meta already accepted these changes; Apostra now offers them instead of refusing them before they reach Meta. Nothing to change on your side.

​

5.1423.0 — October 28, 2026 at 9:58 PM UTC

• A chat you start with one of your buyer agents while an advertiser is selected now appears in that advertiser’s Chats list, like a chat with Murph does. Before, it was filed under the account instead, so it was missing from the advertiser’s list and you could not find it again from there. Chats you already started this way stay under the account.
• When every account you belong to has been deactivated, signing in now tells you your account has been deactivated and to ask your organization’s admin to restore it or contact support, instead of an internal “no active home customer” message that looked like a wrong password. Sign-in and token refresh still return 403 with error: "NO_ACTIVE_HOME_CUSTOMER", now with reason: "ACCOUNT_DEACTIVATED" added so clients can tell this case apart.
• When a managed ad-server source refuses a connection save, you now see the reason instead of a “temporarily unavailable” error. A save that is missing a required secret, or names a secret the ad server does not use, tells you what to send. If the secrets on file can no longer be read, you are asked to enter them again. If another save changed the connection at the same moment, you are asked to retry.
• When a video creative can’t be sent because one media buy holds a seller’s products that take VAST at different player sizes, the error now names each product and its size, and says to book each size in its own media buy. It used to say only that Apostra had to choose a format, with no next step for you.
• A managed ad-server source no longer stays marked unhealthy for up to a week after one failed creative sync. Once the source’s own pipeline checks report it healthy a day after the failure, its status recovers, and buyers’ bookings are no longer held back by that one old failure.
• When an agent opens the Add a modular source Task or the inventory-feed Task in a chat app that cannot show Apostra Pages, it now tells you where to finish: the Inventory sources page in the Apostra web app, with a direct link. Before, the agent was told the Task had opened, so it reported success while nothing appeared.
• A Broadsign seller who changes their Direct login no longer has to re-enter their Control API token, as long as they enter the new password.
• Changing a live order with a field that never reaches the ad server (a total budget, a new name, new packages, bidding, a daily budget cap, or a package bid, impression goal or keyword list) now returns a clear refusal that names the field and where the change belongs, instead of a success the ad server never saw. Nothing in the request is saved when any part is refused. FreeWheel orders no longer offer creative assignment as an available action.
• When a seller confirms a buyer’s account but its reply reaches us after our deadline, Apostra now finishes setting up that account on its own within seconds of the seller recording it active, instead of leaving it waiting for Scope3 staff.

​

5.1422.0 — October 28, 2026 at 8:33 PM UTC

• Certification now tells you which of your format options it did not test. When a run plans no buy for a format option your products offer, such as an agent_placement option next to a display tag, the Agent page shows a certification.format_not_tested finding that names the option, its product and channel, and why it was left out. The finding is an attention note: it does not stop buys or fail your certification, and the formats it lists stay bookable.
• You can now change a line item’s targeting on a media buy that is already running, without creating a new buy, when the seller takes that change. Existing calls behave the same unless you send targeting on a running buy. Check that get shows liveChanges.changeTargeting as accepted, conditional or needs_seller_approval (a conditional seller can still refuse a particular change), then send save_media_buy with mediaBuyId and products: [{ productId, lineItemRef, targetingOverlay }] and nothing else in that call: no flight, budget, name or other product edits. The new targeting goes to every open package of the line item, and a package whose flight has ended keeps its old targeting. The result is action: "updated" once the seller applies it, or action: "pending_approval" while the seller has it but has not applied it; the buy keeps its current targeting in the meantime, the change shows as pendingChange, and you should not send it again. A seller that refuses a change it took returns ACTION_NOT_ALLOWED with details.reason: "seller_refused" and the buy is left as it was. Where the seller has not declared update_targeting for the buy, or has declared nothing so liveChanges is absent, the call returns ACTION_NOT_ALLOWED with details.action: "update_targeting" before anything is sent: create a new buy with the targeting you want instead. This replaces the VALIDATION_ERROR on products.targetingOverlay that a buy past draft returned, so read liveChanges first. The overlay rules are unchanged (null clears a dimension and the campaign’s constraints still apply), and targetingOverlay.frequency_cap is not supported on a live buy yet.
• Invitation emails sent to someone who already has a login now open the sign-in page, so they can join straight away instead of landing on a sign-up page that says their email is taken.
• If you open an invitation link and already have a login, Apostra now takes you to sign in with your email filled in and the invitation kept, instead of leaving you on a sign-up page where Continue did nothing.
• A live Meta media buy now tells the buyer exactly which changes it accepts right now: resume or pause, end-date changes, start-date changes before the first ad set starts delivering, targeting changes, and budget changes where Meta takes them. A buy whose budget Meta holds at the campaign level, or on both the campaign and its ad sets, no longer offers budget changes it would refuse. Because Apostra checks an update against that list before sending it, resume, date and targeting changes to a live Meta buy that Apostra used to refuse now go through to Meta, which already took them. Rename and package bid changes still work but are not listed. Nothing to change on your side.
• The login page no longer offers “Continue with Magic Link”, which could not send a code and showed “Failed to send verification code”; sign in with your password, Google, Microsoft or single sign-on instead. Custom clients that call POST /auth/magic-code or POST /auth/verify-code now get 410 GONE with a pointer to POST /auth/password.
• A directory’s connection made with your reviewer login now lists the app’s tools. After signing in and approving the connection, OpenAI’s plugin scan stopped with “Scan could not finish” and ChatGPT reported that listing the tools failed, so reviewers could not see or try the app. The reviewer login now lists its tools, still with read-only access to your no-spend reviewer advertiser.

​

5.1421.0 — October 28, 2026 at 7:47 PM UTC

• save_creative with resync: true now also sends the creative again to your draft media buys and to buys waiting for the seller’s approval. Those sends are queued, listed per campaign in queuedMediaBuyIds, and each seller’s answer shows on the creative’s platformLinks. A campaign whose buys are all drafts now reads status: "queued" instead of failing.

​

5.1420.0 — October 28, 2026 at 7:24 PM UTC

• When a Creative draft can no longer be saved because its format has changed since it was drafted, the error now says which part changed (format_kind, format_params, format_option_ref or canonical_option), both in the message and as details.changed, so you can tell what to re-select before saving again.
• A media buy on OpenAI Ads can now show the same provider readback and drift indicators as a Meta buy: when an edit made in OpenAI Ads Manager, or a partial write, leaves the buy different from what Apostra booked, get(kind: "media_buy") carries an interchange.provider_drift indicator naming the field. Drift is a signal to inspect the buy and never changes its status, which OpenAI Ads owns. It is switched on per seller account, so nothing changes until your account is enrolled.

​

5.1419.0 — October 28, 2026 at 6:07 PM UTC

• You can now change the total of a Meta media buy that shares one budget across its ad sets (budgetAllocation.mode: seller_optimized). On save_media_buy, send the buy’s mediaBuyId and the new top-level budget. On update_media_buy, send total_budget as {amount, currency}, the AdCP field. A draft takes the new total at once. On an active or paused buy the total goes to Meta, and get shows whether the seller takes a budget change in liveChanges.changeBudget. A change the seller doesn’t take is refused with ACTION_NOT_ALLOWED and nothing is sent. The total must be in the buy’s currency, must fit in the campaign’s remaining budget, and Meta refuses a total below what the buy has already spent. Before, the only way to spend a different total was to cancel the buy and create a new one.
• You can now add a further separate buy to a live campaign from the search round that launched it, with save_media_buy and that round’s productQueryId. Launching a campaign completes its round, which used to refuse any further staging from it. A round now belongs to one campaign: a round that launched or already feeds a different campaign is refused, and so is a campaign that is paused or ended. When two campaigns ask for the same round at once, exactly one gets it.

​

5.1418.0 — October 28, 2026 at 5:29 PM UTC

• Sandbox source tests now accept products that have passed the normal catalogue checks. Products using a temporary test exception still need a current approval, and stale cached products remain blocked.
• After an inventory source test fails, source diagnostics now opens on the tested source instead of showing a load error. Nothing needs to change on your side.
• Creatives with impression, viewability or click trackers now reach sellers that check trackers against AdCP 3.0, such as Ozone, even when the creative was never saved under one of the seller’s own format IDs. The trackers are sent as url assets with url_type: tracker_pixel, the form AdCP 3.0 defines. Before, a creative that was matched to the seller’s format at send time kept its trackers as pixel_tracker assets, and those sellers rejected it.
• Google Ads Search buys can launch again. Apostra was refusing every new Google campaign right after creating it, because it mistook the device settings Google adds to each campaign for a change to the campaign’s locations. Those device settings are now ignored when Apostra checks a campaign’s locations. Nothing to change on your side; relaunch a Google buy that failed to start.
• The assistant picker in the Apostra chat now lists your organization’s buyer agents when you are working in one of the accounts under the organization. Before, the picker in such an account showed no agents, so you could only reach your hosted buyer agent by switching to the organization itself. Choosing the agent from the account now sends your messages to it, and the chat stays with the agent after a reload. The organization’s agents appear only when chatting with buyer agents is switched on for the organization as well as for the account, and who may chat with an agent is unchanged: you must be a direct member of the organization.
• You can now use an image you uploaded to Apostra as an OpenAI Ads chat card, without hosting it at a public web address first. When you sync a chat card that uses an uploaded image, Apostra sends the image to OpenAI Ads for you and remembers the OpenAI file it created, so syncing the same image again reuses it instead of uploading twice. Chat cards that point at a public HTTPS image address work as before.
• A buyer’s agent that sends the product feed version it holds on a wholesale get_products now gets a cheap “unchanged” answer instead of the whole feed. Product change notifications carry the same version, so a receiver can tell whether it missed one. Callers that send no version get the same full answer as before.
• FreeWheel connections now sign in at whichever of FreeWheel’s two token endpoints accepts their credentials, so a connection keeps working when one endpoint is down. You don’t need to change anything.
• Three sample signals (“Auto Intenders Q1 2025”, “Luxury Travel Enthusiasts” and “Sports Content Pages”) no longer appear in sellers’ signal feeds, and neither do three more samples (“Finance & Business Content”, “Urban Millennials” and “Pet Owners”). A seller’s signal feed now lists only the signals that seller has set up, and buyers no longer see the samples. No live buy used the first three.

​

5.1417.0 — October 28, 2026 at 3:58 PM UTC

• You can now add a product to a media buy that is already running when the seller takes it: send save_media_buy with the buy’s mediaBuyId and products: [{ productId, pricingOptionId, budget }] once get shows liveChanges.addProducts as accepted, conditional or needs_seller_approval. The call returns action: "updated" once the seller has applied the add, or action: "pending_approval" while the seller has it but has not applied it; the buy keeps running as it was, the waiting add shows as pendingChange, and you should not send it again. This works only where the seller has declared what the buy accepts, and many buys declare nothing yet; on those, liveChanges is absent and an add returns ACTION_NOT_ALLOWED with details.recovery: "create_separate_media_buy", the same answer you get when the seller does not take adds, so stage a separate buy on the same campaign instead. An add must come from the seller the buy already trades with (a buy with more than one seller does not take one yet), go in the call on its own without other changes, and price in the buy’s currency. Two things differ from before: a seller-accepted add used to return VALIDATION_ERROR on products, so read liveChanges first rather than relying on that error, and removing a product from a live buy is not supported yet, so liveChanges.removeProducts reports not_accepted whatever the seller declared and a removal returns ACTION_NOT_ALLOWED (removing a product from a draft is unchanged).
• The certification docs now say what to do with the DOMAIN/APP_BUNDLE macro that doesn’t apply to an impression: send it empty. Display and video hits must fill one of the two, and the other must arrive empty, so a hit on a website fills DOMAIN and leaves APP_BUNDLE empty. A placeholder left in the hit, such as [APP_BUNDLE], fails the macro check even when the other macro is filled. The check already worked this way; the docs did not say so.
• OpenAI Ads media buys can now target postcodes with geo_postal_areas, on create, on update, and from a campaign’s targetingOverlay on save_campaign. Give each postal area its country (or a country-specific system such as au_postcode), because OpenAI matches a bare postcode in every country. Each country takes its own postal system: Australian postcodes, UK outward codes (such as SW1A), Canadian forward sortation areas, and five-digit US ZIP codes. A postcode together with the country or region that contains it is refused, because OpenAI would target the whole country or region, and postcode exclusion is still refused. When save_campaign sends a campaign’s postcodes to a live media buy, they replace that buy’s countries, regions, and DMAs. A campaign save that removes postcodes is refused when a live media buy would be left with no location targeting. Campaign geography changes now skip media buys that have ended (completed, canceled, failed, or rejected) instead of attempting them.
• Nothing to change on your side. This is a beta, switched on per organization. Until it is on for yours, the click URLs of your ads are exactly as you wrote them.
• When it is on, each creative Apostra sends to a seller for a media buy lands on your site with campaign tags, so Google Analytics and other site analytics can show which buy and which creative a visit came from: utm_source (the channel, such as chatgpt for ChatGPT ads), utm_medium=paid, utm_campaign (the media buy’s mb_ id) and utm_content (the creative’s id). Anything you already set wins. A tag in your landing page URL, or a click-URL parameter you set on the advertiser, campaign or creative, stays as you wrote it, and a key you set to null is left off.
• The tags are added when a creative is next sent to a seller, such as a new buy or a re-sync. A running ad keeps its current URL, and some sellers keep a running ad’s URL even after a re-sync. OpenAI Ads also now rejects a landing page URL over 2,048 characters, including the click tracker and tags, with a clear message instead of a provider error.

​

5.1416.0 — October 28, 2026 at 3:25 PM UTC

• Organization administrators can now register buyer agents, manage their credentials, controls and advertiser access, and create, update and archive service tokens on the organization itself over the REST API and on the API Keys page. Before, these requests were refused with “Write access is required to make this change.” Registering and managing buyer agents still needs a direct administrator of the organization; members without write access are still refused, and buyer and seller operations still need a switch into a child account. Nothing to change on your side.
• Adding a separate buy to a live campaign with save_media_buy now accepts the seller’s own wh: product id as well as the qualified sf1:/sf2: id, and treats both as the same request. When the idempotencyKey is not a productQueryId the account received, the call now returns PRODUCT_QUERY_NOT_FOUND and says the key must be the returned productQueryId, instead of a bare “Discovery session not found”. A create that is refused before anything is staged is no longer recorded against its key, so a corrected request can be sent again with the same productQueryId.
• Teammates with view-only access can now open the buyer discovery preview for an inventory source from the Apostra assistant. Before, the assistant offered the preview and then refused it as a change they were not allowed to make. The preview only shows what buyers would find, so it never needed edit access.
• When you create a Meta media buy with one shared budget (budgetAllocation.mode: seller_optimized), you can now set that buy’s own total, for any number of products. On save_media_buy, send the top-level budget. On create_media_buys, send total_budget as {amount, currency}, the AdCP field. Meta distributes the total across the buy’s ad sets. Before, a seller-optimized buy always took the campaign’s entire saved total, and a top-level budget was refused. If you leave the budget out, nothing changes: the buy still uses the campaign’s saved total. The total must be in the campaign’s budget currency; another currency is refused, not converted. The campaign’s total does not have to equal the sum of its buys’ totals, so a $150 campaign can hold a $100 seller-optimized Meta buy next to a $50 buy on another seller that keeps its own fixed budget. You can’t yet change the total of an existing seller-optimized buy. To spend a different amount, archive the draft or cancel the buy and create a new one.

​

5.1415.0 — October 28, 2026 at 2:45 PM UTC

• OpenAI Ads media buys now report why they are not serving. The request for serving issues (budget exhausted, ad in review, landing page crawl problems and similar) was refused by OpenAI on every status read, so a buy that had stopped serving showed no reason. The request now uses the form OpenAI accepts.
• Directory reviewers can now approve the connection to your app. After signing in with the reviewer login from your Listing page, OpenAI, Anthropic and Microsoft reviewers were sent to a “Request access” sign-up form instead of the Authorize access step, so they could not finish connecting. They now reach Authorize access, approve the connection, and return to the directory with the same read-only, no-spend reviewer access as before.
• A reviewer login that Apostra revoked no longer uses up one of your three daily reviewer requests on the Listing page. Earlier today a fault revoked new reviewer logins shortly after they were issued, and each one counted against the limit, so some sellers saw “Reviewer access can be requested 3 times a day” without ever getting a login that worked. Those requests no longer count, and you can request reviewer access again straight away.

​

5.1414.1 — October 28, 2026 at 1:09 PM UTC

• A creative’s Ad-ID, ISCI, Clearcast clock number or IDcrea code now reaches the seller with the creative. Apostra saved these industry identifiers but sent the creative without them, so a broadcast seller that needs an Ad-ID to clear and traffic a spot never received one. They now go with the creative whenever it is sent to a seller, both when the creative is synced and when it is sent inside a media buy.

​

5.1413.0 — October 28, 2026 at 12:24 PM UTC

• The Inventory Sources screen now explains when custom modular sources are not available for an account and tells the seller to contact Apostra about access. It still offers the normal setup flow to sellers who have access, and still suggests retrying when the setup flow itself fails to open.

​

5.1410.0 — October 28, 2026 at 10:08 AM UTC

• A seller’s agent can now see when a source last observed an account. Reading a buyer relationship with get now gives each source in sources a lastSeenAt for the mapped account, and each suggested candidates entry its own lastSeenAt. Before, only the Buyers Page showed it, so an agent could not tell a current account from one the source stopped listing.

​

5.1409.0 — October 28, 2026 at 9:32 AM UTC

• A seller’s agent can now search the full list of accounts a source holds with search and the new source_account kind (give it the source’s sourceId, and a query to find an account by name), and ask a source to list its accounts again with refresh_inventory_source_health and scope: "accounts". Before, an agent could only pick from the five accounts that matched a buyer exactly, and refreshing a source’s accounts was only on the Buyers Page.

​

5.1407.1 — October 28, 2026 at 5:37 AM UTC

• Fixed a bug where launching a campaign with a Meta video creative could fail with “Meta creative changed since authoritative sync” even though the creative was never edited. The check that compares a creative’s current state against what was recorded at sync time no longer treats Meta’s own derived poster-frame URL as a change.

​

5.1406.1 — October 28, 2026 at 4:12 AM UTC

• The creative upload widget no longer shows a generic “could not be verified” error when the server refuses the upload for a specific reason. It now surfaces that reason, and points you to the Creative Library to check whether the file already landed.

​

5.1406.0 — October 28, 2026 at 3:34 AM UTC

• Apostra can now hold a read-only Google Analytics 4 connection for each advertiser. This is a beta, switched on per organization. There is no screen or agent tool to set it up yet, so you can’t connect anything from the product today, and there is nothing you need to do. When setup is available, an account admin signs in with Google, chooses one GA4 property, and chooses which of its key events count, up to 10 or none. Apostra asks Google for read-only access only and refuses to use a token that grants more. It reads the property list, key event names and, later, report totals, never information about people. It never stores your Google token. Everyone with access to the advertiser can see the connection’s state (not connected, pending, active, unhealthy with a reason, or disconnected) and what to do next. Only an account admin can connect, change, reconnect or disconnect. Connecting does not yet add anything to your campaign reports.

​

5.1405.0 — October 28, 2026 at 3:24 AM UTC

• A seller’s agent can now ask a buyer for information on a pending request, confirm it arrived or withdraw it, and assert or revoke that a direct-billed buyer is billable, with save_seller and its new informationRequest and readyToInvoice fields. It can also bind a source’s shared default account for a buyer with sourceDecision and bindingMode: "shared_default"; the source’s interchangeDefault says beforehand whether that will be accepted. These writes were only on the Buyers Page before. Seller accounts whose connected sales agent manages their buyer accounts still cannot make the billing assertion. Buyers see no change: a request reaches them through the same launch link a seller hands over from the Buyers page today.

​

5.1404.4 — October 28, 2026 at 2:56 AM UTC

• When you try to add a product to a media buy that already exists, save_media_buy now tells you to create a separate media buy on the same campaign with save_media_buy (campaignId, sellerAccountId, products, no mediaBuyId). It used to name create_media_buys, which is not a V3 tool. The same fix applies to the refusal for a product that settles in another currency than the buy.

​

5.1404.2 — October 28, 2026 at 2:08 AM UTC

• Meta video creatives with a thumbnail (buyer-supplied or auto-generated) no longer fail Meta’s post-create verification check every time. The check was comparing against a field Meta adds on its own that buyers never send, so a correctly-created creative was wrongly treated as a mismatch and got stuck requiring manual support intervention.

​

5.1404.1 — October 28, 2026 at 1:41 AM UTC

• A media buy whose creatives were missing from its creative list, and are now listed again, also sends those creatives to the seller. Before, the buy showed its creatives but the seller could still hold fewer. Nothing to change on your side.

​

5.1404.0 — October 28, 2026 at 12:58 AM UTC

• If your organization has a hosted buyer agent, you can now choose it as the assistant in the Apostra chat. Open the assistant picker above the message box and pick the agent. Your messages go to the agent, and its replies appear in the conversation with its name on them. A chat stays with the assistant it started with. To switch, choose another assistant in the picker; if the chat already has messages, Apostra starts a new chat.
• Only agents with an active hosted installation can be chosen. An agent without one, such as an external agent, stays in the list marked “Not available yet.” Only direct members of the account can choose its buyer agents. Replies are text: attachments are refused, and Murph’s interactive panels aren’t available in this chat yet.
• An agent can take several minutes to reply, up to 20 minutes. If you leave the page, it keeps working and its reply is in the chat when you come back. If it doesn’t answer in time, your message was still sent, so it may have acted on it; wait a moment before trying again. If it can’t be reached, the chat says so. Apostra never sends a message meant for your buyer agent to Murph instead.
• This is a beta, switched on per organization. Until it’s on, the chat has no assistant picker and every message goes to Murph. Ask your Apostra contact to turn it on. The Chat with your buyer agent page has the details.
• If you still set “regions” on your business profile, through Murph, the older media-kit page or save_media_kit, those regions now set the countries you sell in. Country groups such as EMEA become their countries, and Worldwide accepts every country. Buyers see the result on your Listing, and it decides which requests reach you. Apostra no longer saves new regions, so your Listing shows the markets buyers are matched on. Countries you set on your Listing or with save_seller work as before.

​

5.1403.0 — October 28, 2026 at 12:17 AM UTC

• An account-wide campaign_delivery read now says which in-flight campaigns it has no stored rows for. A new optional coverage field lists up to 20 of them with their names, and each carries the live_campaign_delivery call that reads it from its connected provider. A campaign missing from stored delivery is absent, not at zero, so an agent no longer has to work out which campaigns to check. coverage appears only when the read covers the account over a bounded date range, with at most an advertiser filter. Rows, totals, paging and goal progress are unchanged.
• A stalled Criteo or Universal Ads request now stops after 30 seconds and returns a REQUEST_TIMEOUT error, instead of hanging until the platform answers. A media buy’s revision on Criteo and CitrusAd now moves whenever anything the platform reports about the campaign changes, including targeting, attribution, wallet, strategy and line-item settings, whoever made the change. Delivery numbers such as spend don’t move it.
• A caller who sees a media buy at total cost no longer gets the seller’s price on that buy’s line items. The V3 get media buy read with include: ["products"] and the v2 campaign products read (GET /api/v2/buyer/campaigns/{id}/products) now leave out bidPrice for those buys, as the media buy read already did for its packages. This covers a client account’s own people on a buy with an operator fee, and an API key its operator marked to hide fees. Everyone who sees the full fee split still gets the price.

​

5.1402.0 — October 27, 2026 at 11:26 PM UTC

• A seller’s agent can now read more about each buyer account with search and get on account_relationship: the buyer’s verified organisation, the direct-billing gate, one list of every open request (including the ones an external agent or the buyer owns), the AdCP account key, grants, the pending information request with its link, the active ready-to-invoice assertions, how each source was mapped and whether its shared default account can be used. The first page of a search also lists the sources that take account mappings and how fresh each roster is, and relationships without an account key now appear after the others. These are facts the seller already sees on its Buyers page about its own buyers; buyers see and do nothing different, and no buyer-side data beyond what the seller already holds is added.
• A live media buy now says which changes its seller takes, and adding or removing a product the seller does not take returns a clear refusal that points you to a separate buy on the same campaign.
• get with kind: "media_buy" returns liveChanges on an active or paused buy whose seller has declared what it accepts: addProducts and removeProducts, each accepted, conditional, needs_seller_approval or not_accepted. save_media_buy on a live buy with a products[] entry that adds or removes a product the seller does not take now returns ACTION_NOT_ALLOWED with details.mutation_outcome: "not_dispatched" instead of a generic validation error. Nothing is sent to the seller and the buy is unchanged. For an add, details.recovery is create_separate_media_buy. This is a V3 change; v2 is unchanged.

​

5.1401.0 — October 27, 2026 at 11:07 PM UTC

• Turning a standalone account into an organization now moves its billing with it. The organization keeps the account’s card and Stripe customer, so charges continue to the same card without anyone entering it again, and it takes the account’s metered plan record, free and referral credit, credit standing and payment terms. The billing contact is copied to the organization, and the account keeps its own copy. After conversion, only organization administrators see and manage the card, invoices and standing. If the organization already has its own record of a kind, its record stays and the account’s stays as history; an organization that already has its own Stripe customer stops the conversion.

​

5.1400.0 — October 27, 2026 at 10:39 PM UTC

• If you use @apostra/cli 0.1 and parse its --json output, two things change in 0.2.0: apostra operations list and operations describe now return their result under data.operations and data.operation, and commands exit with the new codes below, so apostra token and apostra status exit 3, not 1, when you are not signed in. Without --json, every existing command prints what it printed before. Upgrade with npm install --global @apostra/cli.
• New: apostra call <operation> runs any public V3 operation from your terminal, with no code to write, for example apostra call get_delivery --input @request.json --json. Use your apostra login sign-in or an API key. Pass input as inline JSON, @file.json, - for stdin, or --set path=value. A new V3 operation is callable as soon as the CLI updates its SDK.
• Each call runs in one account, chosen from --account, then APOSTRA_ACCOUNT_ID, then your sign-in, and the CLI prints the choice on stderr before it sends anything. Name an account your sign-in cannot reach and it sends nothing. API-key calls must name the account. Writes need --idempotency-key, and the CLI never makes one up: reuse the same key to retry a write safely. Reads refuse the option. --all follows nextCursor through every page of a read and stops with an error, instead of returning partial results, if a page cannot be followed or after 100 pages (raise --max-pages).
• Every command except login now accepts --json. Stdout is then exactly one line, {"schemaVersion": 1, "ok": true, "data": ...} or {"schemaVersion": 1, "ok": false, "error": {...}}; the account line and error text go to stderr. Exit codes are stable: 0 success, 1 server failure (often worth retrying), 2 invalid input, 3 authentication, 4 permission, 5 conflict (for a write still in flight, repeat the call with the same key), 6 unavailable capability. See the CLI page in the V3 docs.
• Goal progress on the reporting timeseries view no longer lists a campaign named unassigned. A media buy with a goal but no campaign still has its own entry under goalProgress.mediaBuys with campaignId: null; goalProgress.campaigns now holds only real campaigns, so every campaignId there can be looked up.

​

5.1399.0 — October 27, 2026 at 10:19 PM UTC

• An Amazon Sponsored Products media buy update now returns the revision of the campaign as it stands after the change, read back from Amazon. Before, it returned the revision you sent plus one, whether or not anything changed. A repeated update that changes nothing keeps the same revision, and when the read-back is unavailable the response carries no revision instead of a guessed one. Updates that land on another Amazon product family carry no revision either.
• When get_status shows that Apostra picked the account for you, your agent can now answer read-only questions in that account straight away, telling you which account it used. It asks you to confirm the account before its first write. Before, the status asked the agent to check with you before answering anything, which stopped agents on simple questions like “how are my campaigns doing”.
• When you set the countries you sell in on your Listing, you can now pick a country group, such as EMEA, North America, Latin America, Asia-Pacific or the EU, instead of adding each country. The Listing adds every country in the group, and you can remove any you don’t sell in before you save. The Seller markets page lists exactly which countries each group adds.
• A seller’s source whose catalog has not refreshed in more than a day is no longer reported as having no buyer-visible products in the format check while buyers are still being served its products. A source whose catalog read has failed and is held in error is no longer counted as buyer-visible by that check, because buyers are served nothing from it.

​

5.1398.0 — October 27, 2026 at 9:36 PM UTC

• Criteo, CitrusAd and Universal Ads media buys now return a revision that follows the campaign’s real state, read back from the platform after each change. Before, an update returned the revision you sent plus one, whether or not anything changed, and Universal Ads reported revision 1 for every buy on every read. A repeated update that changes nothing keeps the same revision, and when the platform cannot be read back the response carries no revision instead of a guessed one.
• A CM360 tag-sheet VAST row is now saved as an AdCP VAST asset in the vast_tag slot instead of a URL asset typed vast.
• Chat attachments, tag-sheet rows and managed video and audio adoption are now checked against the AdCP default format for the kind they become before anything is saved, the check a sync would apply. Nothing a buyer attaches today is refused by it. A tag-sheet row that holds only an Internal Redirect tag stays a record with no asset and is not sent to a seller.

​

5.1397.1 — October 27, 2026 at 9:17 PM UTC

• Google Ads campaigns can be created again. Launching a Google Search buy no longer fails with “upstream request failed”: Apostra now sends a campaign’s start and end days in the form Google Ads accepts. Nothing to change on your side; relaunch a Google buy that failed to start.

​

5.1397.0 — October 27, 2026 at 8:36 PM UTC

• The Developer home no longer shows the “Set up an agent on Apostra” card while hosted agents are not available to your account. You see only “Connect your agent” until Apostra offers hosted setup, and the card appears on its own when it does.
• Notes in your Library are now something you can rewrite. Opening a note shows its text in a box you can type in, with Save turning on the moment it differs from what is saved. Saving confirms itself beside the button — Your note was saved! — and Save goes back off until you type again; the save lands as a new revision, so the earlier wording stays in the note’s revision history rather than being overwritten. Beside it the note now carries the same Document category as any other document, so you can tell your agent when to reach for it, and its revision history sits in a panel you open when you want it. The line under the name says who wrote the note and when it last changed. Two things that only ever made sense for an uploaded file are gone from notes: a Finish this document section that reported no pages had been extracted from a file a note never had, and a status line about reading that file. A note is still read, so that it can be quoted, and the line under its name says so only while that read is unfinished — Reading, or Could not read, with Try reading again in its menu. A note the agent can already quote says nothing and offers nothing to repair. For documents, that status line now says what happened in plain words — File status — Not read yet, Reading, Ready, Partly read, Could not read, Upload pending, Upload incomplete — in place of the rendition wording it used before.
• Loading more media buys no longer cuts the list short. The Media buys list asks for buys a page at a time, and when a buy changed state while you were scrolling, a page could come back holding only buys already on screen. The list treated that as the end of the set, so every buy after it was out of reach until you reloaded the page. It now carries on from where the server left off, so the rest of the list stays reachable.
• A media buy created through a connected ad platform now starts with the revision the platform returned from the create call. An update that cites that revision is checked against the same number the create response gave you.
• When an HTML5 ZIP is sent to a creative-manifest operation that cannot accept one, the refusal now names the operation that can — stash_brought_creatives — and links the bundle requirements. Previously it said only that the ZIP had to go “through the inspected HTML5 bundle ingestion path”, which named nothing an agent could call, so uploads were retried against the same operation until the buyer gave up.

​

5.1396.0 — October 27, 2026 at 7:41 PM UTC

• A creative that isn’t pinned to a seller’s format option, or is pinned to one that declares no slots, is now checked against AdCP’s own default slot ids: image_main for a display image, audio_main for hosted audio and daast_tag for a DAAST tag. create_media_buy inline creatives and creative uploads accept these ids and still accept the ids they took before (image, audio, daast and html), so nothing you send today stops working, and a carousel keeps accepting the card counts it accepts today. creative_format returns AdCP’s default slots for such an option. A native, responsive, sponsored-placement, agent-placement or stateful-display creative with no seller-declared slots now lists AdCP’s default slots instead of none; none of them is required yet, so a manifest that passed before still passes.
• This changes the V3 preview: creative_format lists AdCP’s default slots for an option that declares none. Creatives keep being stored under the earlier ids (image, audio) in this release, so an old and a new server can share rows during the rollout; storing AdCP’s ids and renaming existing rows follows in a later release.

​

5.1395.0 — October 27, 2026 at 7:08 PM UTC

• Directory reviewers can now finish signing in. The reviewer login you issue from your Listing page used to sign in and then drop back to the Apostra login page (or a sign-up form), so OpenAI, Anthropic and Microsoft reviewers could never complete the connection to your app. The sign-in now finishes and returns the reviewer to the directory, with the same read-only access to your no-spend reviewer advertiser as before.
• The seller Media buys surface now leads with what needs you — buys whose money is at risk first, then ones waiting on you, then ones behind on a goal — and says above the list that it is showing live buys in urgency order. Two pickers replace the eleven status filter tags: Show selects the set, with its states grouped by what they mean (waiting on someone, running, finished) and a new All buys option for the whole storefront, which previously took picking each finished state in turn; Attention narrows to one kind of problem, and Clear filters returns both to their defaults. Every row is now titled by the buyer and the advertiser it is for, with its flight beneath, its lifecycle beside it, and — only when there is something to act on — one line naming the problem, so a storefront with hundreds of buys is still tellable apart. The operator, commercial terms and ids moved into the opened row.

​

5.1394.0 — October 27, 2026 at 6:53 PM UTC

• Buyers in the beta Creative composer can choose a connected media partner or standard creative format before completing a draft.
• New guide: Change a live media buy. It says what you can change on a running buy (pause, resume, cancel, end date, line-item budget and bid), that a product cannot be added to an existing buy, and how to spend with the same seller on a live campaign by adding a separate buy. It also explains the pending version that waits for the seller, revisions and CONFLICT.
• When an edit to a live media buy is refused, such as adding a product to a buy that is already running, the buy no longer shows a pending change that nobody sent. Reads of the buy report the live version only, and your next edit is no longer answered as pending approval. Nothing to change on your side. A buy that already shows an empty pending change is cleaned up separately.
• Delivery reports sent in the AdCP envelope, with the report under result, now reach reporting. Before, we answered them with success and dropped them. Each report is checked against the AdCP release your agent served for the buy. A report that does not match gets a 400 naming the first failing field, such as a row without the required by_package. If we cannot record a report yet, you get a 503 with Retry-After. AdCP 3.0 reports, with the report itself as the body, are still accepted.

​

5.1393.0 — October 27, 2026 at 6:02 PM UTC

• A media buy that went live after a creative change now lists its creatives. Buys that showed “No creatives attached” while their creatives were serving read their creatives again, and you can attach more. Nothing to change on your side.
• Filing a document now happens where the documents are. A file you add lands as a Draft at the top of the Documents list with its own category control, so there is no separate uploads area to visit: a file still going up, or one that never arrived, reads as a line above the list and then leaves. Opening a document is written as the questions you ask about it — What it is, Can your agent use it, What it says it is, Where it came from, and the technical record last — and a line says which of those describe the page you picked rather than the whole document. Try reading again now appears only where a preview is missing or broken, and a thumbnail that fails to load shows the plain file tile rather than a warning that says nothing about whether your agent can read the document. Some things go with this change: the Responses tab, and with it attaching a document to a brief, Save as a response, Import historical brief, Re-run brief, the per-request Fill gap note, and the record of where a page has been used. Those actions are unavailable for now — not moved — until the exchange that holds the brief carries them; a saved response is still a document in your list, nothing recorded is lost, and a Library request still closes when you add the missing file or tell your agent what to use.
• If you’re previewing a lower role with View as and the app blocks you, either because it can’t load or because the previewed role can’t accept the Terms of Service, the message now offers Switch back, so you’re never stuck in the preview.

​

5.1392.0 — October 27, 2026 at 5:27 PM UTC

• Google Ads search, display, video and Demand Gen ads with an Apostra click tracker are no longer refused by Google. The ad’s final URL is now the landing page the tracker leads to, and the tracker goes in the ad’s tracking template, so clicks are still counted and still land on your page. Nothing to change on your side; re-send a creative that Google refused to deliver it again. Performance Max asset groups still receive the click URL unchanged.
• When you call sync_accounts on a storefront’s AdCP endpoint and the seller needs to review the account, the response now returns that account’s own row with status: "pending_approval" and a setup message saying who is reviewing it. You no longer get a submitted task to poll. Call list_accounts on the same endpoint to see the seller’s decision. Accounts that need no review come back exactly as before.
• Two further changes follow AdCP’s account rules. A request that asks for a billing party the storefront does not support now fails only that account’s row, with BILLING_NOT_SUPPORTED, instead of failing the whole call. And a webhook you register with push_notification_config on sync_accounts is no longer called when the seller decides, because the response no longer creates a task. If your agent polled the task or waited for that webhook, have it read list_accounts instead.

​

5.1391.0 — October 27, 2026 at 5:02 PM UTC

• Google Ads connections no longer drop to “Reconnect” about an hour after you connect. Apostra now asks Google for lasting access when you sign in, so it can keep the connection signed in on its own. A Google Ads connection made before this fix still needs one more reconnect, after which it stays connected.

​

5.1390.0 — October 27, 2026 at 4:37 PM UTC

• Directory reviewer access you request from your Listing page no longer gets switched off minutes later. A leftover database rule revoked every reviewer login whenever any listing, plan, contract or billing record changed anywhere on the platform. Reviewer logins now keep working while your listing is public and your plan includes Distribution, and are refused, without being revoked, while it isn’t.
• The v2 buyer API now follows AdCP 3.3 for the lists a request can carry. A list that is present needs at least one item, so a request that sends an empty list (brand.countries, targetingOverlay.collection_lists, collection_lists_exclude, or a property-list allowed_values, for example) is refused with a 400 VALIDATION_ERROR; leave the field out instead. Requests can also carry minute-level dayparts (start_time and end_time) and collection_lists targeting. Reads still return what is stored, including empty lists. A few values the API returns gain members AdCP 3.3 adds: price adjustment kinds, demographic systems, delivery metric ids, format slot asset types, and the daypart_targets entry shape. Notification event types and the utmConfig macro list keep their current values. See Errors for the affected requests.

​

5.1389.0 — October 27, 2026 at 3:54 PM UTC

• When Apostra refunds a platform fee charge to your card, the correction now appears on Plan & Billing as a numbered credit note directly under the invoice it corrects, with the reason and the amount credited. The invoice itself is never edited.

​

5.1388.0 — October 27, 2026 at 3:45 PM UTC

• Ask a storefront for a media buy’s history and it now answers. Send include_history with get_media_buys and each buy comes back with its last N changes, newest first. Every new revision of a buy has exactly one entry: the revision, when it happened and what happened. An origin, under ext.apostra.origin, says where the change came from: you (adcp), the seller’s operator, the storefront itself, or a connected platform that reported it. Entries are never edited afterwards. Revisions made before today have no entry, so a buy you already have starts its history from its next change.
• Pages opened in chat, such as Media Partners, Creative Engines and Agents, now keep working when you leave them open, instead of failing after about 15 minutes with “Couldn’t load this view”.
• Organizations can now add any number of Buyer and Seller accounts. Your plan no longer sets a limit, and restoring an archived account no longer depends on a count. Nothing to change on your side. Administrators add accounts with Add account in Settings → Organization → Accounts, or through the API and MCP tools; Scope3 staff acting for an organization follow the same rule.
• An organization holds one Developer account (Developer accounts are in closed preview), and that account holds any number of agents. Creating or restoring a second Developer account is refused with 409 CONFLICT and details.resource developer_account_limit. Add further agents to your existing Developer account. Developer accounts an organization already has are unchanged.
• Your plan still decides which kinds of account you can hold, such as both buying and selling. An account your plan doesn’t cover is still refused with plan_does_not_cover_account and the next step. Restoring an archived account is refused only for that reason, or when it would be a second Developer account.
• For integrators: the “Workspace limit reached” and “choose a plan” account refusals no longer occur. workspaceCapacity on the current-user response and capacity in the organization reads still appear, so existing clients keep working, and report no limit. See Accounts in an organization for the full rules.
• Your rate card’s floors now reach buyers on your wholesale auction products.
• A hard_floor or default floor in your Library rate card raises the floor on every wholesale product it matches by channel and publisher domain. The floor buyers see is the higher of your rate-card floor and the product’s existing floor: the floor your ad server reports or, for a product your ad server can’t price, the floor from your uploaded pricing feed. A rate-card floor never takes a product below that floor. Committing a rate card refreshes your wholesale catalog straight away.
• Fixed prices still come from you, set by hand on the product, and a rate card never turns an auction product into a fixed-price one. Products whose only price is a fixed price you set in the sales agent are now counted as your own prices, not as uploaded pricing, in the pricing coverage summary (sellerFixedPriced).

​

5.1387.1 — October 27, 2026 at 3:06 PM UTC

• Organization administrators can now choose their organization’s plan while working from a child account they administer.

​

5.1387.0 — October 27, 2026 at 2:47 PM UTC

• save_seller now sets a Demo Storefront’s expiry and sample sources as desired state, and get of the seller returns them. Send demo.expiresAt to extend the lease to that instant (later than its current expiry, at most seven days past it), and demo.sourceRecipeIds for the complete set of sample sources, which must keep sample-publisher-display. Send demo on its own; creating, resetting and deleting a Demo Storefront stay on the Demo Storefront Page. The Page now uses the same two fields for Extend and for adding and removing sources.
• When your catalog refresh changes or drops a format option that live media buys still use, Apostra now tells you. The source shows a finding and a work item that name the product, the old and new option, and the affected buys and creatives. Your refresh is never blocked. A change that only widens an option, such as adding a delivery type, raises nothing.

​

5.1386.0 — October 27, 2026 at 2:18 PM UTC

• When you update or cancel a media buy through a storefront, the storefront now tells the inventory source which version of the buy it last read, so the source can refuse a change made on a stale view. If the source changed the buy in the meantime, the storefront reads it again. When the change touched nothing your update sets, it sends your update once more on the current version, and you see no conflict. When the change touched a field your update sets, you get a CONFLICT instead of a silent overwrite. The response usually carries the media buy as it stands after the fresh read, but not always: when it is missing, read the buy yourself. Decide whether your change still applies, and send it again. The storefront retries at most once, and never retries a change that overlaps. A cancel the storefront queued on your behalf sends itself again with the current version, or finishes if the buy has already ended.
• An advertiser whose markets or channels aren’t set no longer makes every media partner in your account read “Complete advertiser setup”. The account view of Media Partners, and a seller’s account-wide requiredAction and state, now reflect only the advertisers whose setup is complete. An incomplete advertiser keeps its own setup step, and its seller accounts are set up once it is complete.

​

5.1385.0 — October 27, 2026 at 1:37 PM UTC

• Sellers can re-check a publisher on request. save_coverage takes a new refresh list of declared domains; each one’s adagents.json and format catalog are read again straight away, and the response returns the refreshed authorization, property and format states for it. Before, a seller who had just fixed a publisher’s file had to wait for the next scheduled check. A domain that is not declared is reported as that item’s failure.

​

5.1383.0 — October 27, 2026 at 12:27 PM UTC

• Nothing to change on your side unless you read the contract_out_of_line blocker on the V3 live status. That blocker is removed there, and booking replaces it. The v2 buyer status read still returns it.
• When you read a media buy booked through a media partner, get with kind: "media_buy" now returns a booking field. Its status is within the booking, outside the booking, or null when the media partner’s storefront can’t say either way. For an outside buy, booking names the fields that are outside (budget, flight dates, targeting, rate or creatives) using your own package ids, says since when, and flags whether money is involved. The answer comes from the storefront and never shows an ad-server value.
• Not comparable is not a pass. Treat null, or a missing booking field, as “not checked”. Search results and buys not routed through a storefront don’t carry booking.
• This is a beta, switched on per organization. Until it is on for yours, buys carry no booking field. The Booking answer page covers each field.
• A creative change whose seller call failed before the seller recorded an approval no longer blocks the buy forever. The next creative update (including a creative re-sync) replaces the stale queued change and goes through, instead of being refused with a conflict. A change the seller may still be processing, or that is waiting for approval, stays queued as before.

​

5.1382.1 — October 27, 2026 at 12:10 PM UTC

• Every IU plan now bills by calendar month, whether you pay by card or by invoice. Your plan commitment, overage and fee invoice all follow the same UTC month, and your first month is prorated from the day you accept. An organization that was billed on cycles starting on its acceptance day keeps those cycles until 1 November 2026; a cycle that would run past that date ends then and closes once, and calendar months start that day. Nothing already charged or invoiced changes and nothing is charged twice.

​

5.1382.0 — October 27, 2026 at 11:38 AM UTC

• Buyers on the V3 beta profile can keep a composer draft in an advertiser library and save the exact seller format option or standard format they chose. Existing campaign drafts and the four earlier composer formats continue to work unchanged. Sellers do not see a new screen or catalogue/ranking change because this only changes buyer task saves.
• Reading live delivery for a campaign that has not started no longer says your input is wrong. When every media buy is still waiting to start, for example because no creatives are attached yet, it is pending approval, or its flight starts later, get_delivery with report: "live_campaign_delivery" returns LIVE_PROVIDER_UNAVAILABLE and says what each buy is waiting on. When a provider refuses the read for a campaign that has started, the call now returns SERVICE_UNAVAILABLE with details.reason of provider_rejected_delivery_read and the provider’s own code in details.code, instead of VALIDATION_ERROR with a suggestion to correct your input. The same change applies to the v2 buyer campaign delivery route.
• Direct organization administrators can create an approval request for a Buyer account from the in-app Apostra chat while using a Developer, Buyer, or Seller account. The administrator must still approve the exact request on the website before an account changes.
• Pricing and availability changes now reach a connected storefront as soon as ESA finds them. A rate change that ESA’s pricing and availability sync finds now sends a price-changed notification, and the signal coverage sync, inventory changes that retire or restore a product’s ad units or placements, and a publisher-domain update now send catalog change notifications too. Before, a storefront learned of them only on its next full re-read.
• A product, pricing or signal change made through the management API no longer loses its webhook if the service restarts just after saving. Each change is now saved together with the webhooks it owes its subscribers, and a change whose webhooks cannot be queued is refused instead of saved silently.
• Each connected ad server’s change-detection lag is now measured and shown on the tenant status as the age of the last time ESA read the ad server, so a seller can see when ESA’s view of their orders is falling behind.
• Recording a creative change on a Google Ad Manager buy booked under an account’s advertiser no longer fails with “GAM adapter is not configured for creative operations”; creatives already on the line items settle to live.
• A GAM HTML5 ZIP with no standard click tag is now reported as an error the buyer can correct, before the order is booked in GAM, instead of a source outage that retries unchanged. Rebuild the bundle with a single var clickTag = "…" and resubmit.
• When a seller holds one of the creatives an update assigns, the update is now applied right away. Before, it stayed pending and failed after seven days, although the rest of it had been applied. The held creative shows as pending review on the media buy until the seller releases it.
• A CM360 tag that uses [timestamp] as its cache-buster (ord=[timestamp]) now runs on a Google Ad Manager seller. ESA fills it with Google’s own cache-buster instead of refusing the creative. CM360 tags with other placeholders that have no Google equivalent are still refused.
• ESA no longer stores or returns its own comparison of Google Ad Manager with what it booked. get_media_buys stops returning ext.scope3.ad_server_readback on each package; it still returns what GAM holds in the standard fields, including the effective budget, rate, pacing and flight. The tenant-management media buy detail drops read_back, and the spend-unsafe packages endpoint and daily summary are gone. A write’s own response still carries the readback.
• Creatives approved together for the same Google Ad Manager line item no longer fail because Ad Manager is busy with another change to that line item. The sales agent now retries automatically before reporting a problem.
• ESA now picks up changes a seller makes in FreeWheel, such as booking, pausing or cancelling an insertion order, within about 15 minutes instead of up to an hour.

​

5.1381.1 — October 27, 2026 at 10:47 AM UTC

• Converting an account into an organization now makes every administrator of the account an organization administrator, not only the person who converted it. The card, invoices and standing belong to the organization, and only organization administrators see them, so the people who managed billing keep managing it. Administrators of accounts converted earlier are made organization administrators too. Other account members stay account-only.

​

5.1381.0 — October 27, 2026 at 10:27 AM UTC

• A campaign now completes when its sellers say its media buys have ended. If every media buy still running or paused under an active campaign is past the end its seller states for it, the campaign’s phase moves to completed, even while the seller still reports a buy active. This applies to a campaign with no flight dates too. A media buy with no seller-stated end keeps its campaign active, and Apostra never changes a media buy’s own state.
• Intelligence-unit billing no longer charges for usage from before your plan started. A billing period that ended before your plan began is never closed, charged or invoiced, and for the period in which you accepted, only usage from the moment of acceptance counts, at your plan’s own rates and with its credits.

​

5.1380.0 — October 27, 2026 at 10:00 AM UTC

• New plans no longer include a free setup credit. The current plans carry no setup credit, so accepting one grants no free IUs. A setup credit is granted only when the plan you accept states one, in the amount and for the number of days it states. Organizations that already hold a setup credit keep it until it expires.

​

5.1379.0 — October 27, 2026 at 9:29 AM UTC

• You can now keep or block properties in a property list by a quality score you supply, such as a Spektre ASPI. This is available to accounts on the V3 beta feature profile; other accounts see no change, and features or feature_requirements sent to them is still refused with NOT_IMPLEMENTED. Nothing changes on your side unless you start sending scores, and existing lists behave as before.
• Send scores when you save a list with V3 save_property_list: each identifier can carry them, for example features: {spektre_aspi: {value: 94}}. Then set filters.feature_requirements when you create the list. Each requirement names a feature and any of min_value, max_value and allowed_values, and a property must meet every requirement. On an include list, that keeps only the properties that meet them (an ASPI of 80 to 90). On an exclude list, a max_value just under 20 blocks the properties you have scored below that floor; it does not block a property you have not scored. A list can have requirements and no identifiers, and then it covers every property you have scored that meets them, so each score range can be its own list.
• A requirement on a feature you have not saved any score for yet is not applied until you do, so a floor saved before your scores cannot empty a list. A listed property with no score for a requirement’s feature, or whose score has expired, is removed from the list unless that requirement sets if_not_covered to include. On an exclude list, that means an unscored listed property is not blocked.
• Scores belong to your account, not to the list. Saving a changed value keeps the earlier one as history, and saving an unchanged value adds nothing, so you can re-send your full set of scores on a schedule. The list a seller fetches carries identifiers only, never scores. A seller that has cached it sees a score change when its copy expires, within 24 hours. Apostra applies the same scores when it checks products against your exclude lists before a buy. Requirements are fixed when a list is created, so to change one, save a new list. See Property scores in the property lists guide.

​

5.1378.0 — October 27, 2026 at 9:13 AM UTC

• Source health now explains more of what can go wrong with what a source says it sells, for every kind of source, not only a managed ad server. If a source’s product list has not refreshed in time, Apostra says so. If an agent you run does not answer our catalog request, you get a task with a Run discovery test action. If an agent’s products declare creative formats that its creative agent does not define, or Apostra cannot read what an agent supports, you are told once, with the section of the troubleshooting guide that explains the fix, and told again when it clears. Guaranteed buys held for your review because we could not confirm availability now show that cause, with no action needed from you. Sources that Apostra hosts for you never create a task.

​

5.1377.2 — October 27, 2026 at 8:56 AM UTC

• A new inline display tag now reaches seller review and gets assigned to packages on a product that lists both a plain display-tag option and one that accepts only paired_redirect. Before, such a tag stayed processing with no review item, no assignment and nothing on the buy, because the product’s two display-tag options looked equally good and neither was chosen. The tag now resolves to the option that accepts inline markup. Paired-redirect tags are unchanged. Nothing to change on your side.

​

5.1377.1 — October 27, 2026 at 8:25 AM UTC

• The revision on a media buy you place through a storefront is now one number for the whole buy, issued by the storefront. It goes up by one on every committed change to the buy or any of its sources, and it never goes backwards, even when a buy spans several sources. Buys you already have start from the highest revision you were shown, so the number does not drop. Nothing to change on your side.

​

5.1377.0 — October 27, 2026 at 8:07 AM UTC

• Buyers on the V3 beta profile can browse every format their sellers accept alongside standard formats, then filter by channel and asset type without choosing a product first.
• A package’s own property list now combines with the advertiser’s and campaign’s lists instead of being replaced by them, so each package can carry its own quality-band list while the brand-level lists still apply. Include lists intersect and exclusion lists add up, and the seller receives one combined list per package. A package’s own list that Apostra hosts must be an active list of the same advertiser, used in its own direction, or it is refused with an error that names the package and the list. save_media_buy also refuses a list hosted elsewhere. The v2 batch create and update still send a list hosted elsewhere to the seller unchanged, unless an advertiser or campaign list applies to the same field; then that list is sent in its place, as before.
• A paired-redirect display tag now launches on a product that lists both a plain display-tag option and one that accepts paired_redirect. Before, such a launch was refused with “ambiguous canonical identity matches 2 distinct product options”, because the creative fit both. The creative now goes out on the option that declares paired_redirect, the only one with the slot its two URLs fill. Inline tags, and tags that record no delivery type, still need to be pinned to one option when a product lists several. Nothing to change on your side.
• A creative that a seller fails with only transient errors is no longer recorded as rejected. It stays pending and is sent again on a later sync.

​

5.1376.0 — October 27, 2026 at 6:56 AM UTC

• Certification test buys now run in any currency Apostra can settle, using your own prices. The USD 10 per buy and USD 50 per run limits are converted at Apostra’s daily exchange rate.
• A creative the seller refuses no longer blocks later creative changes on its media buy. The refused change is closed, and archiving or detaching a creative removes it from any queued change, so re-syncing a good creative goes through without a manual step.
• Buyers can generate image, video, and voice asset drafts from a short brief in the Creative Library and choose an output from the generated variants gallery.
• A source’s product catalog now comes back within about 15 minutes after the source tells us it changed, even if our first refresh was lost. Before, a lost refresh could leave buyers seeing no products from that source for up to a day. A catalog we failed to refresh is also retried on every check instead of waiting for it to age out. When we cannot read a source’s capabilities, the failure now shows in the source’s health: a rejected credential or a client error shows as unhealthy, a timeout or server error shows as degraded, and capabilities we have not refreshed in two days show as degraded. A successful read clears it. Nothing to change on your side; if a source now shows unhealthy for a rejected credential, update the credential.

​

5.1375.0 — October 27, 2026 at 6:03 AM UTC

• A display tag or HTML5 creative with no known size is no longer assigned to a package whose product lists sizes. Before, a creative whose size had not been measured or declared counted as a fit for every such product, and the seller refused it later. Now it is held back and the sync says which creatives have no known size. Give the creative a width and height (or let it be measured) and sync again. A creative with a known size is unaffected, and so are video and audio creatives.
• Property lists on running buys through an Apostra-managed sales agent now update the buy instead of pausing it. When a list changes, a score upload changes which sites a list resolves to, or the seller authorizes a listed site, Apostra sends the new values to the seller as an update to the buy’s existing packages and records them once the seller confirms. A buy is paused if the seller refuses or fails the update, or if it does not confirm an update that newly excludes a site; an update that only allows more sites waits for the next re-check.
• Apostra now tells you when you save an HTML5 ZIP that has no click tag an ad server can detect, or has more than one. The save still succeeds and returns a warning that says what to add (one var clickTag = "https://…"; in the main HTML file, used for the exit) and links the new HTML5 and display tag requirements page. The page also covers the declared size, the backup image, and how a Google Ad Manager seller handles CM360 tag placeholders.

​

5.1374.0 — October 27, 2026 at 5:34 AM UTC

• save_creative now refuses a creative saved into a campaign when it fits none of the format options the campaign’s products declare. The refusal names the difference and the closest declared option. Before, the creative was saved and then quietly left out of every media buy that could not run it.
• Reading live delivery for a campaign that was retried now finds its live buy. A campaign with failed or cancelled earlier buys, and one active buy, used to answer “none of its media buys is live” while listing that buy as active. The live read now ignores buys that cannot deliver and reads the one that can.
• Live delivery for OpenAI Ads campaigns now works. OpenAI refused the read because a date range ended at 23:59:59 instead of on a full hour in the ad account’s timezone. That inclusive end is now read as the end of its hour, so a date range or a lifetime read returns the campaign’s delivery, including an honest zero. A start or end that falls inside an hour in the account’s timezone is refused with a message naming the field, because OpenAI cannot report part of an hour.
• A display tag saved as a paired redirect (an ad-request URL and a click-through URL) is now assigned to a media buy whose product’s display-tag option accepts paired_redirect at the creative’s size, and sent to the seller. Before, it stayed in processing with no seller review and no package assignment, because the compatibility check looked for a tag asset the paired redirect does not store. An option that lists only other delivery types still does not take it. Nothing to change on your side; re-save or resync a paired-redirect creative that was left in processing.
• The agreed-terms check now judges whether your ad server is within what was booked, not whether it equals it. A lower budget, a flight that starts later or ends earlier, and narrower targeting no longer read as out of line. A higher budget, a flight that runs past the agreed dates, targeting that reaches beyond the booking, and a different rate still do. A field that is within the booking but narrower than agreed is recorded as a note on the buy’s source, and does not change its status. A buy already marked out of line for a narrower value clears the next time your ad server is read.
• When you update a media buy on a connected ad platform and the revision you cited is out of date, every platform now answers with a CONFLICT error (retryable) that tells you to read the media buy again with get_media_buys and resubmit with its current revision. Before, only Meta did; the other platforms returned a generic SERVICE_UNAVAILABLE. No changes in the rejected request were applied, and there is nothing to change on your side.
• A buy’s paused, active or canceled state on our side now follows the state the ad platform reports back after your update, not the request you sent. If the platform reports no state, the stored state is left as it was and we ask the platform to read the buy back right away, so the state catches up within minutes.
• A Google Ads connection now stays connected. Its sign-in was being marked expired an hour after connecting, because the hourly credential check never renewed Google’s short-lived access token, so buys and creatives sent to Google failed with “Reconnect google delegated auth”. The check now renews it automatically, as it does for the other ad platforms.
• Video and other long-running Creative Engine builds now return a pending result for polling instead of timing out while generation completes.
• A media buy the seller’s storefront approved but could not send to any seller now reads FAILED as soon as that happens, with an errorCode and sourceMessage that say why, instead of staying pending approval. This happens, for example, when the product cannot carry the requested format or signal. It is not retried: submit a new buy with the correction. Buys that were already stuck this way are corrected automatically. See Diagnosing a stuck media buy.

​

5.1373.1 — October 27, 2026 at 4:46 AM UTC

• A buyer’s saved copy of a seller’s product now follows the seller’s format changes even when the buyer’s account has no catalog of its own, and a display tag only fits a format option that accepts the way the tag is delivered.

​

5.1373.0 — October 27, 2026 at 4:35 AM UTC

• Seller source-account mappings can now be corrected without deleting the reporting history tied to earlier mappings.
• The Apostra CLI page now says scripts need @apostra/sdk 0.40.0 or later to use an apostra login sign-in. From 0.40.0 the CLI and the TypeScript SDK keep that sign-in in your operating system’s credential store, and earlier SDK versions don’t read it there.
• A free agent account that had just kept its first provider account could be returned to its expiring state if another call from the same agent was authenticating at that moment. The agent’s second call then failed with a server error and the account was left on its original expiry. The retained state now stays in place.

​

5.1372.0 — October 27, 2026 at 4:02 AM UTC

• An approved creative stays approved when only its package assignments change. Adding a creative to another package, or moving it, no longer sends an already approved creative back to “in review”, and the seller still receives the new assignments. A creative whose content changed, or whose format option changed, still starts as pending.

​

5.1371.0 — October 27, 2026 at 3:52 AM UTC

• Storefront readiness now checks publisher domains only for products buyers can receive. Draft, archived, and old cached products no longer create a warning you cannot fix.
• Partner Program readiness now counts a sales agent that Apostra has exempted from certification, as the connection check already does. An organization with the right to operate agents for clients can offer an exempt agent to publishers in other organizations before it passes live certification. An agent with a current behaviour blocker still does not count, and the agent stops counting when its exemption ends.
• Your Creative Policy now applies on automatic creative approval for every seller.
• If your storefront approves creatives automatically and you have written a Creative Policy, Apostra’s automated reviewer now evaluates each new creative against it. It approves a creative when it is definite and every check passes. It rejects one only when a separate policy check confirms the creative breaks a rule you wrote. Anything it is unsure about now waits in your creative review queue for you to decide, instead of going straight to your sources. Until now only sellers in a beta got the reviewer, so a policy you wrote was ignored on automatic approval. Storefronts with no written Creative Policy and storefronts on manual approval are unchanged.
• A media buy whose source is holding a creative for review now shows that creative as pending, with “Review the pending creative.” as the next step, also while the buy’s other creatives are running. Before, a creative held on a live buy did not appear anywhere in your media buy list.
• Every buy Apostra sends to your sales agent now states its currency in the AdCP total_budget, as { amount, currency }. The currency is the one the buyer’s pricing options and budget are denominated in, or yours for a cross-currency buy. The agreed-terms check can now tell a real budget or rate change from a currency difference when your sales agent reports the same currency, instead of leaving those amounts not compared. Buys booked before this change keep no stated currency, so a differing amount on those stays not compared.

​

5.1370.2 — October 27, 2026 at 3:07 AM UTC

• A creative that names its format by publisher (formatOptionRef with scope: "publisher", for example Google’s responsive search ad on google.com) is now checked against that publisher’s format on the campaign’s products, as a product-scoped format already was. Numbered headlines and descriptions such as headlines[0] are accepted within the publisher’s limits instead of being refused by the generic format check.

​

5.1370.1 — October 27, 2026 at 2:49 AM UTC

• apostra login and the TypeScript SDK now store interactive sign-ins in your operating system’s credential store. Existing file logins migrate automatically; headless machines without a credential store keep the protected 0600-file fallback and show a one-time warning.

​

5.1369.0 — October 27, 2026 at 1:38 AM UTC

• Sessions now keeps every conversation in one list. Use the Agent or Person filter alongside Source and Lifecycle to narrow what you see.
• The call success rate check now flags a sales agent only when more than 5% of our calls fail for a reason other than a timeout, up from 2%. The blocker line is unchanged: more than 20% of calls failing, or every call failing. The change applies to every sales agent and only loosens the check, so an agent flagged between 2% and 5% clears the next time it is evaluated. See the call success rate finding.
• You can now save a complete Google responsive search ad with save_creative. Send each headline and description as its own social.components entry named by position, such as headlines[0] and descriptions[1], with the product’s formatOptionRef and a final_url. The product’s format sets how many headlines and descriptions are required and how long each can be, and a missing or too-long item is refused with a message naming the slot.

​

5.1368.0 — October 27, 2026 at 12:49 AM UTC

• If you connect an ad platform from a chat app, pressing Done on the confirmation page no longer sends you to a sign-in screen. The page now closes the tab, or, if your browser keeps it open, tells you to go back to your conversation. Connecting from the Apostra web app works as before and takes you back to the Connections page.

​

5.1367.0 — October 27, 2026 at 12:21 AM UTC

• If your organization has no admin and you own it, you no longer wait for approval to become one. When you are signed in with a verified email on the organization’s registered domain, and it has no admin and no pending admin invitation, Request organization admin now approves your request on the spot and emails you the admin invitation, the same one Apostra would send after a review. The notice shows an Accept link right away, so becoming an admin takes a click or two. Everyone else’s request still goes to Apostra for review. The API still returns status: "approved" and nothing about it changes for existing callers.
• If your ad-server connection stops working while you have live buys that depend on it, Apostra now treats it as critical for you. A buy is live when it is active, or accepted and starting within 24 hours. Your task moves to urgent priority, the notification says how many live buys and how much booked spend are at risk, Murph writes to your channel as well, and Apostra’s support team is told once so someone can help you restore access. Buyers with a live buy on your storefront see that your status and reporting for it are temporarily unavailable, without naming your ad server. Apostra now hears about the change as it happens instead of waiting for its 15-minute check. With no live buys on the connection, nothing changes: it stays an ordinary task. When Apostra can read your ad server again, all of it clears by itself.

​

5.1366.0 — October 26, 2026 at 11:26 PM UTC

• Sellers can now see whether a partner’s sales agent is certified before they connect it and while it serves them. Each partner agent in the Connect sales agent task and in a Seller Account’s agent search, and each inventory source attached to a partner agent, shows one of three statuses: certified, exempt from certification, or in its partner’s beta and not yet certified. For an exemption or a beta, it also shows when it ends. You can still connect an agent that isn’t certified, disconnect a source from it by setting the source to DISABLED, or contact the partner. See Certified, exempt and beta partner agents.

​

5.1365.2 — October 26, 2026 at 10:55 PM UTC

• V3 log_event now applies three more AdCP event rules. An event whose user_match names no identifier (uids, hashed_email, hashed_phone, click_id, or both client_ip and client_user_agent) is refused, and so is an empty user_match.uids list and a watch_milestone event without custom_data.progress_percent or custom_data.progress_seconds. The error names the event and the field. V3 also passes an event’s surface and its custom_data content and progress fields on to Apostra’s event ingestion. A surface string or custom_data.content_name, content_category or search_string that looks like a raw email address or phone number is refused, as it already is in user_match, and those three custom_data strings are limited to 256 characters. These fields are not stored yet, so the response still lists them in ingestion.warnings. The v2 log-event endpoint is unchanged.

​

5.1365.0 — October 26, 2026 at 10:22 PM UTC

• The Terms of Service notice now offers Request organization admin only when the request can go through. If you are viewing the account as Apostra staff or are not a member of it, the notice says so instead of showing a button that fails with “We could not send your request”, and a refused request shows the reason. If you switch organization from the notice and the switch does not complete, the notice now says so.
• For API callers: POST /api/v2/accounts/request-organization-admin accepts an optional body { "customerId": <account id> } naming the account to file from. You must be a direct member of that account, or the call returns 403 with reason not_a_member; with no body it acts on the account your request headers select, as before. GET /auth/me, POST /api/v2/accounts/switch and the user_get_current tool return canRequestOrganizationAdmin when organizationHasAdministrator is false, plus organizationAdminRequestBlockedReason when it is false (staff_session, not_a_member, organization_has_admin, organization_setup_incomplete or unavailable) and organizationAdminRequestCustomerId, the account the decision was made for. Send that id back as customerId so the request is judged for the same account.
• Accepting a proposal whose products need a bid now says that accepting cannot set a bid and what to do next, instead of asking for a bidPrice the call cannot take.
• A connection now says why Apostra couldn’t read its ad accounts and who can fix it, and Connections only offers Reconnect when reconnecting can help. Nothing to change on your side: existing reads keep working, and the new accountDiscovery field appears on connections and on a seller’s connection state.
• Buyers and their agents can now send conversion events over V3. The new log_event tool (POST /api/v3/tools/log_event, and in the TypeScript and Python SDKs) sends up to 10,000 AdCP events to an event source registered with save_event_source. Events must be valid AdCP events and must also pass the v2 log-event endpoint’s rules, such as no raw email or phone number. The tool takes a required idempotencyKey and returns the received and processed counts. If an event carries AdCP fields Apostra does not store yet, such as surface, the call still succeeds and the response warns which fields were not stored. A saved source’s setup instructions now name log_event.

​

5.1364.0 — October 26, 2026 at 9:24 PM UTC

• Editing a product’s format option to accept more (for example adding `paired_redirect` delivery or an optional asset slot) now keeps the option’s id, so creatives already pinned to it keep matching. Edits that narrow or change the option still get a new id.

​

5.1363.0 — October 26, 2026 at 9:03 PM UTC

• Bulk creative updates in save_creative now cover creatives that are already attached to a campaign media buy. Apply returns an approval link instead of changing anything, and an administrator of the account approves the exact preview. Once approved, the creatives change together and Apostra queues their updated versions for every current media buy that holds them. Each attached creative reports deliverySync: "queued" with the seller operation ids to follow. Rejected, expired, or outdated requests change nothing. Retrying apply with the same idempotency key returns the pending approval, then the saved result.
• Connecting Google Ads no longer fails because one of your Google Ads accounts isn’t enabled. If your Google user could reach an account whose setup or billing was unfinished, or one that had been deactivated, Apostra stopped reading accounts altogether and told you your user couldn’t see any ad accounts. Apostra now lists that account as unavailable and still loads your other accounts; an unavailable account is never selected for buying. If none of your accounts is enabled yet, the connection page now says so. Finish setting the account up in Google Ads (for example, add billing), then connect again.
• Spotify podcast promotion ads now reach Spotify with the click-through it accepts. These ads must link to Spotify itself as an ordinary web address. Apostra was sending a spotify: address, which Spotify refused because it isn’t a web link. Apostra now sends the plain https://open.spotify.com/ link of the show, episode, track, album, artist or playlist your click URL points to, without Apostra’s click tracker. Clicks on these ads are counted in Spotify’s own reporting.

​

5.1361.1 — October 26, 2026 at 8:26 PM UTC

• apostra login now refuses an admin scope. It requests read and write access only, so the TypeScript SDK cannot use an interactive login with admin permission by mistake.

​

5.1361.0 — October 26, 2026 at 8:14 PM UTC

• A creative is now assigned only to a package whose product lists the creative’s size. When a product declares several sizes, a display tag of any other size no longer counts as a fit: before, a campaign creative sync could assign 320×50 tags to a 728×90 leaderboard product and 728×90 tags to a 320×50 mobile product, and the seller then refused them. A tag cannot be rescaled, so only an exact size match fits it. An image still fits a listed size at its own aspect ratio. A creative whose size is unknown is handled as before. If a creative you expected on a package is now left off, check that its size is one the product lists. Nothing else to change on your side.
• If you sell FreeWheel inventory through Apostra’s embedded sales agent and have set a default advertiser for that connection, buyers billed through Apostra that you haven’t mapped to an advertiser are now mapped to your default automatically, both when you approve them and each time your advertiser list refreshes. Google Ad Manager connections already worked this way. Until now an unmapped buyer couldn’t see or buy your FreeWheel inventory until you mapped them. It’s the same as choosing Use Interchange default for each buyer: they share your default advertiser in FreeWheel. Buyers you bill directly are never put on the default. To keep a buyer separate, map them to a specific advertiser in Buyer Account Mapping; your choice always replaces Apostra’s.
• save_creative can now preview and apply changes to up to 200 creatives in one campaign as a single batch. Existing calls are unchanged.
• Call previewBulkUpdate first. It returns a preview token, valid for 15 minutes, and flags any selected creative that is attached to a campaign media buy. Then call applyBulkUpdate with the required idempotencyKey: the changes are all saved or none are. Apply is idempotent. Retrying with the same idempotency key returns the same result for seven days after apply, even after preview cleanup, and reusing a key with a different payload is refused.
• If any selected creative is attached to a campaign media buy, apply is refused before anything changes. Change those creatives one at a time with the individual creative workflow.
• Preview also refuses, naming the creatives, a clickUrl change that selects HTML creatives (their HTML would need reprocessing) and a formatOptionRef that differs from an option a selected creative already pins. Exclude those creatives with excludeCreativeIds and change them individually.
• Because apply changes only creatives that are not attached to a campaign media buy, it sends nothing to sellers. Each creative in the result reports deliverySync: "not_required".
• A pause (or other change) a buyer makes to a media buy while the ad server is being re-read is no longer undone by that read, and a paused buy no longer carries the time of an earlier read that saw it running. A held Broadsign buy’s status_reason no longer waits on a live ad-server call.
• When a buyer changes a creative that’s already running (a new click-through URL, new trackers, new image or tag), the change now reaches the creative on your Google Ad Manager line items, on every buy that carries it. Before, the line items kept serving the old version. A change GAM can’t make to a running creative, such as a different size or creative type, is refused, and the buyer is told to send it as a new creative. On ad servers that can’t update a running creative, any such change is refused the same way instead of being silently ignored.
• A media buy’s status now changes only when its ad server says so. A buy goes active when its ad server starts serving it and completed when its ad server ends it, within a few minutes of the flight’s start or end, instead of being switched by the clock. A buy the ad server still serves after its end date stays active, and media buy and delivery reports always show the same status.
• Google Ad Manager delivery reporting works again. Since release 1.82.0, ESA couldn’t read delivery for GAM orders, so buys showed no impressions or spend. Delivery for those days reappears on the next report.
• A change a seller makes in FreeWheel (switching a placement off or on, moving its dates, changing its budget or rate, unbooking the insertion order) now reaches the media buy and its change feed within about an hour, where the values were up to 6 hours old, and a buy’s status follows its placements as well as its insertion order.
• A change a seller makes in Google Ad Manager (a pause, a new end date, a different goal or rate) now reaches the media buy within about 12 minutes, where the values were up to 6 hours old, and a buy’s status and the reason it is held no longer call Google Ad Manager when they are read.
• Storefront-managed sales-agent products now retain their reporting capabilities, including the Google Ad Manager network timezone used for daily reports.
• A CM360 tag that still contains the optional [APIFRAMEWORKS] or [OMIDPARTNER] placeholders is no longer refused when it is pushed to Google Ad Manager. These placeholders can only be filled inside an app, and the tag served without them before 22 October. Tags with any other unfilled CM360 placeholder are still refused.
• When Google Ad Manager rejects a seller’s saved credentials, Scope3 now notices within about three minutes instead of at the next scheduled sync, reports the connection as needing to be reconnected, and reports again when it works. The seller is notified once per change, not once per media buy.

​

5.1360.0 — October 26, 2026 at 7:29 PM UTC

• Sellers can now list the products of their own sales agent source in Apostra, including the formats each product accepts. They are still edited in the seller’s own sales agent.
• A seller that fails a creative sync but answers for individual creatives no longer takes every creative in the request down with it. A creative the seller refused is recorded as refused with its own error, a creative it accepted stays accepted, and a creative the seller already approved keeps that approval when the failed task says nothing about it. A failed sync with no per-creative results still fails every creative in the request.

​

5.1359.1 — October 26, 2026 at 7:08 PM UTC

• Seller administrators in the permanent Library deletion beta can see why a document cannot yet be deleted, delete the eligible documents in a mixed selection, and find open Library requests from the Library rail.
• A display-tag or HTML creative whose size is declared as a one-entry sizes list in format_params, for example {"sizes":[{"width":728,"height":90}]}, now reaches the seller with that size in format_parameters. Before, it was sent with no size and a seller that needs one refused it. When the list has several sizes, the size the creative’s target formats name is sent; if none matches, the creative is not sent and the sync reports which sizes it declared. Nothing to change on your side.
• Spotify podcast promotion ads can now be created. Spotify only accepts a link into Spotify itself as the click-through on these ads, and refused the open.spotify.com links Apostra sent. Apostra now sends the Spotify address of the show, episode, track, album, artist or playlist your click URL points to. Because Spotify will not take a redirect here, clicks on these ads go straight to Spotify and are counted in Spotify’s reporting, not through Apostra’s click tracker. A podcast promotion creative whose click URL points anywhere other than Spotify is refused with a message asking for the open.spotify.com link. Spotify brand awareness ads are unchanged.

​

5.1359.0 — October 26, 2026 at 6:43 PM UTC

• Accepting a TikTok proposal with save_media_buy (fromProposalId) no longer asks for a bid TikTok does not use. TikTok runs these products on automatic bidding, so the draft media buy is now created without one; the two TikTok click products that take an optional maximum cost-per-click bid are unchanged. Proposals quoted before this fix still ask for a bid; call request_proposals again for a fresh quote and accept that one.
• Connections and the API now say which of an advertiser’s channels or markets keep a media partner unavailable, with a button to edit them.

​

5.1358.0 — October 26, 2026 at 6:13 PM UTC

• A saved V3 proposal whose products list a very large number of publisher properties keeps its products’ names and pricing. Each proposal keeps up to 256 KiB of publisher_properties across its products, in allocation order; a product whose list does not fit has no publisher_properties in its snapshot, and the rest of that product is unchanged. Before, a large enough list could leave every product in the proposal without its snapshot. The text answer for get(kind: "proposal", include: ["products"]) now also names the domains of a selector that lists several publishers in publisher_domains, up to eight domains per product. Nothing to change on your side.

​

5.1357.2 — October 26, 2026 at 5:26 PM UTC

• Fixed a small spacing glitch in collapsible sections across the chat widgets. When you hovered the summary row of a compact section — for example “What your library needs” in the library — the row’s highlight ran right up against the first line of content below it, with no visible gap. The highlight now stops just short of the content, matching the wider section style.
• No-spend source tests can now select approved composed products after buyer discovery qualifies them with their Storefront route, while continuing to reject products routed through another Storefront or inventory source.
• Retrying a cancel or campaign archive no longer files a second cancellation approval while the first is still being sent to your ad server. Your approval queue shows one cancellation per media buy, and the retry is refused until the first cancellation finishes.

​

5.1357.1 — October 26, 2026 at 5:08 PM UTC

• Asking Murph to “show my plan options” now opens the Plan & Billing Page, where the plans are listed and chosen, in the same turn. Before, it could answer that it could not display plans and offer to open the Page instead.
• A saved V3 proposal now shows which publisher properties each product covers. get(kind: "proposal", include: ["products"]) returns each product’s AdCP publisher_properties in its snapshot, and the text answer lists them for each product. Proposals saved before this change have no publisher properties in their snapshot.

​

5.1357.0 — October 26, 2026 at 4:49 PM UTC

• Accepting a fresh multi-product proposal from a self-serve platform Seller such as Meta or TikTok with save_media_buy (fromProposalId) now creates the draft media buy instead of being refused as missing pricing evidence. Proposals quoted before this fix are still refused with that reason; call request_proposals again for a fresh quote and accept that one.
• A feature request you file through the Apostra assistant is no longer lost when the product tracker cannot take it. The assistant now passes the request to Apostra Support and gives you a support reference, as it already did for accounts not set up for product-request tracking. If that also fails, the assistant tells you in plain words that nothing was saved and offers to try again, rather than showing an internal code. Through the API, such a product ask now returns outcome: "filed_escalation" with type: "support" instead of filing_refused. Nothing to change on your side.
• Every V3 tool now asks the caller to name the account a call runs in with accountId, so two conversations on one connection can work in two accounts without moving each other.
• The tool list marks accountId required on every tool except get_status (call it with no accountId to list the accounts you can reach), and it no longer offers switch_account or expectedAccountId. Conversations that cached an earlier tool list keep working for now: a call without accountId still runs in the account the connection last switched to and carries a note to send accountId, and switch_account still runs but says it is retired. We will announce the date these old calls stop before it arrives.
• The Get an Account Ready to Buy skill (version 1.1.1) now tells agents to name the account with accountId instead of calling switch_account. Earlier versions stay available unchanged.
• When a seller fails a creative you sent for a media buy and says why, the send result for that seller now carries what it said in a seller_acknowledgement field: each error’s code and message, word for word (plain text, up to 500 characters), marked origin: "seller" (wrapped as untrusted data when read through the v2 buyer MCP tools). Our own message and error_code are unchanged, and a seller’s code never replaces ours. In v2, platform_links[].seller_acknowledgement on a creative read returns the same errors, so a later read shows the same reason. rejection_reason still holds only a seller’s review reason. When the seller gives no error we keep, nothing is added, and V3 creative reads do not show the seller’s errors yet. Nothing to change on your side.
• Spotify buys can be launched again. Spotify started returning a new, empty content-group field on every ad set, and Apostra’s check that a new ad set matches what was booked treated that field as targeting it could not represent. The check kept retrying until the request timed out after about a minute, so launching a Spotify buy failed with a generic “upstream request failed” error. Apostra now recognises the empty field. An ad set where Spotify reports a content-group value is still refused, because Apostra does not book that targeting.

​

5.1356.0 — October 26, 2026 at 4:11 PM UTC

• Seller search and seller reads in the V3 API now tell your agent what each seller offers. The text of search with kind: "seller" and of get for a seller now includes the seller’s description, cut to about 200 characters, and the regions it serves, when the seller has set them. Agents on hosts that read only the text reply, such as Claude, can now compare sellers by what they sell instead of by name alone. The structured result is unchanged.
• Restoring an archived campaign now says what actually happens: the campaign keeps the phase it had when it was archived and its media buys are unchanged. The restore message no longer tells agents its media buys were retired or that new inventory must be staged. The docs now also say that a campaign deleted through the v2 REST DELETE endpoint cannot be restored.

​

5.1355.0 — October 26, 2026 at 3:29 PM UTC

• When Apostra retries a cancellation in the background and the seller answers that it paused the media buy instead of canceling it, the buy now stays paused in Apostra and the cancellation is not sent again. Before, the buy was marked canceled even though the seller still had it. Canceling a media buy directly already worked this way. There is nothing to change on your side.
• A Spotify booking that is retried within 7 days after a timeout no longer creates a second campaign. Spotify cannot delete a campaign, so each duplicate used to stay in the ad account as an extra paused campaign. The retry now picks up the campaign and ad sets the first attempt made, and creates only the ones that are missing. It never pauses a campaign the first attempt already booked. A retried creative sync now picks up the ad its earlier attempt made instead of adding a second one. Nothing to change on your side.
• When a seller does not apply a pause, resume, or cancel, the v3 error now says whether anything may have been applied. save_media_buy with isPaused or isCanceled, an isArchived that needs a seller cancellation, and a save_campaign pause or resume now carry details.mutation_outcome: not_dispatched means nothing was applied, rolled_back means the change was undone, and unknown means read the buy before sending anything else. A campaign pause or resume also gives each failed media buy its own mutation_outcome in details.mediaBuyResults. On these errors details.per_source now lists only each failing source’s id and error code, without the seller’s own wording. The v2 pause, resume, and cancel errors carry the same mutation_outcome; a v2 pause or resume refusal now always includes it, and a value the seller sent outside these three is reported as unknown.

​

5.1354.0 — October 26, 2026 at 2:46 PM UTC

• When Apostra retries a cancellation in the background and the seller no longer has the media buy, the buy is now marked canceled and the cancellation is not sent again. Before, it was sent up to five more times and the buy stayed live in Apostra. Deleting a media buy no longer leaves its cancellation to be sent to the seller again later. Nothing changes in the response you get when you cancel or delete, and there is nothing to change on your side.
• Direct organization administrators can now use save_account from a Developer Account to create a Buyer Account for their organization. Existing permissions are unchanged: delegated and support sessions cannot use this action.
• Video drafts now request a Gemini Omni Flash output resolution that matches their dimensions, unless you set a resolution explicitly.
• Keep a buyer’s queued creative assignments when a later media-buy flight update is staged. An explicit creative_ids update that differs from a queued creative change now returns CONFLICT; resolve or withdraw the queued change first.

​

5.1353.0 — October 26, 2026 at 1:44 PM UTC

• Searching a product’s creative formats now returns the formats of products sold through a seller’s own sales agent, not only products set up in Apostra.
• Creative manifests built by Apostra’s creative agent no longer carry a delivery_type field on text and URL assets, which AdCP does not define for those asset types. The manifests now pass AdCP’s strict asset checks. Nothing to change on your side: the field was not read for text or URL assets.
• Media buys no longer register a reporting webhook with sellers that don’t support one. When every product in a buy declares supports_webhooks: false, Apostra now leaves the reporting_webhook off the buy and reads that seller’s delivery on its poll schedule instead. Buys to sellers that support webhooks, to sellers that declare nothing, and buys that mix both are unchanged.
• When a tool allows a blank value, you can pass null without being told the field is missing. Required fields must still be included, and fields that do not allow blank values still reject null.
• Creative delivery and the sales agent that sends it now agree on which creative shape a seller accepts. Apostra asks the agent directly — reading its AdCP capabilities and, when those settle nothing, the sync_creatives input schema it publishes — and uses that one answer for the submit-time check, the pre-approval check, and delivery itself.
• An agent that proves it accepts canonical creatives still receives creatives identified only by their format_kind. For every other agent, including one that proves neither shape and one Apostra cannot reach at the moment of the check, the booked product must carry the seller’s own legacy format reference. Those creatives are now refused when they are submitted, naming the format route, instead of passing every local check and then being refused during delivery.
• Sessions now describes each record in plain language, and seller navigation calls the trained selling agent the Storefront agent.
• Creative syncs to sellers that declare AdCP 3.2 now send each package assignment as an assignment_operations entry instead of the deprecated assignments list. Sellers on earlier releases keep receiving assignments. Snap creative readback also stops reporting a 1080x1920 size that Snap never returned: an image or video Snap holds without a known size is left out of the readback instead of being given an invented one.
• In beta: the Media Buys page now marks a buy Out of line when your ad server reports a different budget, rate, flight date or targeting from the terms you agreed with the buyer. Among the first page of buys returned, an out-of-line buy ranks above buys that are only waiting on you, and below buys with money at risk. Buys with a budget, rate or flight difference rank first among the out-of-line ones. Open the buy to see an Agreed terms panel. It lists each difference with Agreed next to Your ad server reports, budget, rate and flight differences marked Financial and listed first, and when each was first seen. Fields that couldn’t be compared are listed under Not comparable with the reason. A buy that is in line, or only not comparable, gets no badge. Apostra never changes your ad server to match the agreed terms, because the change may be intentional; you decide whether to put it back or agree the change with the buyer. If your Media Buys page shows no Out of line badge and no Agreed terms panel, your storefront isn’t on the beta yet. Nothing to change on your side. Agreed terms check.
• When you connect an ad platform and we can’t read your accounts afterwards, the sign-in page now says what went wrong and what to do next instead of showing a success tick, and its Done button now closes the tab.
• Pausing or resuming a Spotify ad set together with other changes, such as its budget, now works the way Spotify requires. Spotify only accepts the on/off switch on its own, so Apostra now sends it as a separate step: a pause switches the ad set off first, and a resume switches it on last, so nothing serves half-updated. If a step fails, earlier steps are undone as before.
• Lesson previews now request steadier pitch sampling where the model supports it, so the comparison is less likely to show a difference caused only by model variation.
• A buy no longer shows the “out of line with the agreed terms” attention marker when the storefront could only fail to confirm that a seller’s figures match what was agreed. Budgets and rates are now compared only when the contract and the seller state the same currency, a total is compared only with a total on the same basis, a budget the contract spread evenly over its packages is compared per package only when the seller split it the same way, and geography is flagged only when the two shapes provably reach different areas. A difference the storefront cannot prove is listed as not comparable. Real differences, such as a changed end date or a currency both sides state that differs, still show.

​

5.1352.8 — October 26, 2026 at 11:01 AM UTC

• Connecting a platform account from Connections no longer stops at a blocked browser tab or an extra Continue page; you go straight to the platform’s sign-in.
• Connections no longer asks you to map an advertiser to an account when none of your advertisers can use that media partner.
• Connecting a Google Ads account no longer stops at “Account discovery failed” right after you sign in. Apostra had kept asking for a Google credential that Google retired in September 2026, and refused to look up your ad accounts without it.
• A v3 Page now stays in the account it was opened in. Its reads and writes name that account with accountId, so a Page opened in one account keeps working there after another conversation on the same connection switches accounts. In the Apostra web app, a Page whose browser tab has since moved to another account is refused with ACCOUNT_MISMATCH instead of showing or changing the other account’s data; reopen the Page in the account you want.

​

5.1352.7 — October 26, 2026 at 10:43 AM UTC

• Video files whose audio track comes before the video track now record their width and height when uploaded, so sellers can match them to the right video size.

​

5.1352.6 — October 26, 2026 at 10:27 AM UTC

• Reading live delivery for a campaign with nothing live now says why. When a campaign exists but none of its media buys is live at a provider, for example because every buy was cancelled, get_delivery with report: "live_campaign_delivery" returns LIVE_PROVIDER_UNAVAILABLE and lists each buy’s state, instead of “not found”. NOT_FOUND now means the campaign does not exist in your account.
• A buy’s status now follows what the seller’s own status read says in every state, not only while it is pending. A seller’s delivery report can no longer move a buy that the seller reports as paused, ended or waiting to start. When delivery shows impressions or spend that the seller’s status read contradicts, the buy keeps the status read’s answer and Scope3 is alerted to look into the disagreement.
• Spotify now accepts podcast promotion buys. Spotify refused every podcast promotion ad set because we asked it to bid per stream without a bid amount, which Spotify allows only for click goals. Every Spotify ad set now uses Spotify’s automatic bidding, as Reach, Video views and Display already did. No action is needed; a podcast promotion buy that failed this way can be booked again.

​

5.1352.5 — October 26, 2026 at 10:06 AM UTC

• Media buys sent to CitrusAd, Criteo Retail Media, or Universal Ads now reject unsupported property and collection targeting lists instead of booking campaigns without applying those lists.

​

5.1352.4 — October 26, 2026 at 9:51 AM UTC

• Media buy package reads now show the requested targeting (placement selection, collection selection, and other dimensions a seller’s own response omits) on create_media_buy itself, not only on a later webhook or status sync. The prior fix only reached a package written by those async paths; a package created synchronously — the common case — kept showing just what the seller echoed back. No configuration change is required.
• If you told us where you sell during earlier onboarding (regions such as EMEA, North America or a list of countries) but never set countries on your Seller markets page, those regions are now your countries. Your listing shows them, and buyers are matched with you there. Groups become the countries they cover: North America is the United States, Canada and Mexico; EMEA is Europe, the Middle East (with the Caucasus) and Africa; Latin America includes Mexico, Central and South America and the Caribbean; Asia-Pacific is Asia outside the Middle East, and Oceania (Russia counts as Europe, in EMEA); Worldwide is every country. Check them on your Seller markets page and change them there if they are wrong.
• A media buy that a seller turned down in its approval review now shows as rejected even when Apostra had already flagged it for a manual status check. Before, a few older buys stayed pending approval indefinitely. They update on their own within the hour; nothing to change on your side.

​

5.1352.3 — October 26, 2026 at 9:15 AM UTC

• Seller readiness now shows whether a Sales Agent is unlinked, waiting for its owner to request certification, queued, running or unsuccessful, instead of sending sellers through a Source discovery test that cannot certify the Agent.

​

5.1352.0 — October 26, 2026 at 6:58 AM UTC

• A house discount can now be changed or removed only if it is still as you read it. On save_playbook, each entry in discounts.rules and discounts.remove takes an optional expectedUpdatedAt: send the updatedAt you read and a rule that someone changed in the meantime returns CONFLICT instead of being overwritten, or send null on a rule to create it only if it does not exist yet. A refused entry is listed in discountConflicts with the rule as it is now, and the other entries in the call still apply. The Buyer discounts page sends the updatedAt on every edit and delete, so a stale edit shows that the discount changed and reloads the list. Each rule now shows its updatedAt in the text of search and get, so you can send it back. Entries that name no precondition behave as before.
• If your sales agent still reports a buy active more than 24 hours after the buy has ended, certification now counts that as a miss. Apostra reads the buy through get_media_buys. The end is the end_time your agent sent for the buy, or the end date Apostra booked for the buy when your agent sent none. A buy reported paused, completed or canceled is not a miss. One missed buy in seven days is a flag. Two within seven days is a blocker. A flag or blocker shows on your agent’s Agent page from 26 October 2026, when the check starts. It applies to every sales agent, including Apostra’s own embedded sales agents.
• To fix it, report a buy completed once its end passes, or report the later end_time it actually runs to.
• Nothing stops new buys because of this check before 1 December 2026. An agent that existed on 22 October 2026 holds a certification exemption until that date, so a blocker cannot stop its new buys, and stopping new buys on blockers is not switched on for any account. Why a buy reads active after its end, and how to fix it explains the causes.
• Duplicating a creative onto a campaign that already has a live media buy now reliably delivers it to that media buy’s seller, with the same durable retry-on-rejection handling already used when attaching a new creative, instead of a single non-durable delivery attempt that silently gave up on failure.

​

5.1351.1 — October 26, 2026 at 6:01 AM UTC

• Sessions now shows available RFP performance measures and keeps text and archived Session searches responsive.
• Sessions keeps your place while you search and filter. Results update after you pause typing, without reloading the whole page.

​

5.1350.2 — October 26, 2026 at 5:10 AM UTC

• Fixed a brief that explicitly excludes a Meta placement (e.g. “no Feed”) silently getting that placement enabled anyway when the excluded surface name was quoted or punctuated. Meta media buy creation now reliably rejects an unexpressible placement exclusion in brief text with a clear error pointing to the structured targeting_overlay.placement_selection field, instead of quietly creating an ad set that doesn’t match the brief.
• save_media_buy’s placement_selection and collection_selection targeting fields now reject a malformed value with a clear, field-named error instead of crashing. Previously a typo’d field name or the wrong value shape (for example a string where an object was expected) passed validation silently, then failed later with a generic “An internal error occurred” and, on create, could leave your idempotencyKey locked so retrying required a brand-new key. Now the error names the field and expected shape immediately, and no idempotency key is consumed. A well-formed placement_selection/collection_selection — {"mode": "selected", "placement_refs": [...]} or {"mode": "default"} — continues to work exactly as before, and the tool schema now shows a worked example for both fields. No configuration change is required.

​

5.1350.1 — October 26, 2026 at 4:54 AM UTC

• Certification no longer marks a seller late because of how often Apostra reads its reports. If your product declares supports_webhooks: false, Apostra polls your delivery twice a day, so a report that is there at the first read after it falls due now counts as on time, and the buy no longer carries a reporting_webhook you said you do not use. A report that is not there at that read is still late.

​

5.1350.0 — October 26, 2026 at 4:40 AM UTC

• Spotify podcast promotion now takes its show from the campaign’s catalog. Save an offering catalog with one item for the show (its Spotify show id as offering_id, its open.spotify.com link as landing_url), attach it to the campaign with catalogId, and book the Spotify podcast promotion product. The buy promotes that show in one ad set, and a catalog that names no show, a link that is not a Spotify show, or more than one show is refused before anything is created at Spotify. A campaign whose catalog would not reach every seller it buys from, including one that mixes Spotify promotion with other sellers or has no media buys yet, still cannot launch.

​

5.1349.1 — October 26, 2026 at 4:17 AM UTC

• When you switch to a seller account you directly belong to, you can use Teach this on a private Session note. Direct account administrators can also approve or retire lessons there. Staff, support, parent-account access, impersonation, API keys, and agents cannot do these actions for you.
• Media buy package reads now show placement selection and every other requested package-level targeting dimension, not just geo and frequency cap, in both the structured response and the text response. Use get with kind: "media_buy" and include: ["products"] to verify which placements, collections, and other targeting a package actually carries after save_media_buy. This is a request echo: it reflects what you asked for, filled in where the seller’s own readback is silent, not an independent confirmation of the seller’s live ad-set state. No configuration change is required.
• An administrator of your organization can now open and work in its Developer account without being added to it as a member. On the web the Developer account opens instead of reloading in a loop. After switch_account into it, get and search return its agents, and the agent page’s revision-registration task opens and registers a revision. People who are only organization members, service tokens, delegated sessions and impersonation are still refused, and Scope3 support still sees the agents read-only.

​

5.1349.0 — October 26, 2026 at 3:50 AM UTC

• An agent’s findings now cover every next step that stuckOn names, so the headline finding can say what to do next for every agent. New findings: implementation.no_endpoint (no endpoint registered yet), endpoint_control.unverified (blocking for certification until a connected URL is verified as yours), day_one_test.sales_validation (attention when a sales agent’s latest owner test failed, advisory when none has run, so it never leads), creative_conformance.not_run (a creative agent with no conformance result reads not checked yet), and for a buyer agent credential.issued and credential.authenticated. stage, nextStage, finalStage and stuckOn are still returned and are removed no earlier than 3 December 2026.
• When the assistant in the product prepares a request to the Apostra team for you, it now looks up the support page and lists every way to reach a person in the same reply that asks you to approve the request, instead of sometimes offering them later or not at all. Nothing to change on your side.
• Buyers now get seller accounts set up automatically for the sellers they select, and sellers receive those account requests. Previously this ran only for buyers in an earlier rollout. Which sellers a buyer can use, and the per-advertiser activation controls, are unchanged.
• In a V3 buyer account, get now reads one wholesale product by the productId and advertiserId from your search, and returns its complete overlaySupport, including declarations far larger than search returns inline. Search still withholds a declaration over 2,048 bytes, or past 8 KB of declarations on a page, and now says in its text that get on that product reads it in full. The read goes through the same discovery as search, so it returns only a product your search would return for that advertiser, and the text of the result summarizes the declaration while the full one stays in structuredContent. Nothing changes for a Seller Account, which still reads its own product with sourceId and id.
• A campaign no longer reads as ready when its media buy is stuck after the flight started.
• Once a campaign’s flight has started and a booked media buy is still not delivering, the campaign read now reports readiness.status: "not_ready" with readiness.attention: ["blocked"] and a readiness.blockers entry (not_delivering_after_flight_start) for each stuck buy. The message names the buy, says what it is waiting on, and says who needs to act: you, the seller, or Apostra. For example, a buy with no creatives attached tells you to attach one. The blocker clears when the seller reports the buy delivering, or when the buy is paused, canceled, or its flight ends.
• Certification now sends your sales agent a test creative that matches one of your product’s declared formats exactly, and on a product that lists several formats of the same kind, sends it under the one it matches. Previously Apostra chose the first offered creative your product would accept after resizing, and when your agent lists its formats as legacy format_ids that state no size, your agent could not tell which format a 1920x1080 image belonged to, so the creative was refused as matching several formats. Apostra now makes an image, HTML5 bundle, tone or one of its standard hosted videos at the size or length of the first format it can make, and sends it under that format’s legacy format ID. Nothing to change on your side. A format Apostra cannot make, such as a hosted video size outside its nine standard videos, still takes an offered creative that needs resizing, or is bought without one as before.
• Certification buys on your sales agent now carry a test video that fits a video_hosted format your product declares. When none of the creatives Apostra offers fits, Apostra uses one of nine standard videos: 1920x1080 (16:9), 1080x1920 (9:16) or 1080x1080 (1:1), each 6, 15 or 30 seconds, as a flat grey picture with a silent audio track (H.264 and AAC in an MP4). It takes your fixed or first declared size when it is one of those, else the first that has your declared orientation and aspect ratio and sits inside your size limits. Its length is your exact length when it is 6, 15 or 30 seconds, else the first of 15, 6 and 30 seconds that your length limits allow. Apostra reuses each video for later buys. Previously a hosted video product with no fitting offered creative was bought without one and could fail certification. Nothing to change on your side. A product whose size, orientation or length none of the nine videos meets is still bought without a creative, as before.
• Images, videos and audio you upload now keep the size and length Apostra measured when it saved them, so a seller that lists several sizes receives each creative under the one that matches. Before, an upload whose stored file could not be fetched back, and a managed video you saved from the Library, were saved with no size, and the seller refused them with “the seller advertised several legacy refs”. Nothing to change on your side. Creatives you saved earlier are filled in separately.
• The campaign view in the Campaigns widget now shows your operator fee as a share of the gross budget, and you can add, change or remove it there when you are allowed to set it, without writing the request yourself. A change applies to media buys created afterwards; existing buys keep the fee they locked.
• A stored campaign_delivery read now says that a campaign with no stored rows is missing, not at zero, and points to live_campaign_delivery with that campaign’s ID for the provider’s current answer.
• Certification now tells you why the macro check is still waiting. Until an impression reaches Apostra’s tracker, it says that no impression has arrived yet, instead of saying that no macro definitions were loaded.
• A guaranteed media buy that the seller reports as running, but that has delivered nothing, now shows attention_required on the media-buy status read with the blocker not_delivering_after_flight_start. It appears once the flight is more than 24 hours old and the seller has reported at least one flight day with no impressions and no spend. Before, the seller saying “running” hid the buy from this check, so a buy could sit at zero for its whole flight without any signal. Nothing changes for buys that have delivered, buys that are not guaranteed, or buys the seller has not reported on. If you see the blocker on a running buy, ask the seller to confirm the order’s creatives are attached and approved and its line item is trafficked.
• get_status now tells an agent when it picked the account for you. If you can reach more than one account and the call named none, the status says “Account chosen by default” and nextActions leads with confirm_account, asking the agent to check with you which account you mean before it answers account-specific questions. Calls that send accountId, and people with a single account, see no change.
• The Python SDK now uses your apostra login sign-in, the same way the TypeScript SDK does. Run npx @apostra/cli login once on your machine, approve one account, and Apostra() or AsyncApostra() in Python call the V3 API as you, with no API key in your code or environment. The SDK uses the sign-in only when you pass no credential and set no APOSTRA_API_KEY, so it never overrides what you already use, and it raises an error rather than switch accounts if you set an account_id that differs from the account you signed in with. It never opens a browser: signing in stays in the CLI. A Python script and a Node.js script on the same machine share one sign-in file and one lock, so they never refresh the same token at once. Use an API key or an M2M access token in CI and on servers. No action needed: existing API keys, M2M credentials and scripts work exactly as before. See the CLI guide and the SDK guide in the V3 docs.
• A new media buy that is still waiting for the seller’s approval when its flight ends is now rejected automatically within a few minutes, with the reason “The flight ended before this media buy was approved.” Before, it stayed pending for the buyer and open in the seller’s approval queue even though it could no longer run. Buyers can submit a new buy with current dates. Sellers have nothing to do: the approval item closes on its own, and nothing happens while a storefront is paused for new business.
• If setting up your account with a seller failed because your account had no operating unit, Apostra now sends the request again once your account has one. You do not need to do anything.
• A campaign no longer reads active when nothing under it is running. If every media buy under an active campaign has been cancelled, rejected or has failed, or the campaign has no media buys, its phase returns to draft (readiness no_staged_buys) within an hour, whether or not it has flight dates. A campaign whose flight has ended and whose media buys have all finished still moves to completed. A media buy the seller still reports running keeps its campaign active.
• The Build with Apostra skill (version 1.0.10) now teaches apostra login for local development. A coding agent asks you to run npx @apostra/cli login once and approve one account, then writes new Apostra() with no credential, using @apostra/sdk 0.39.0 or later. Before, the skill taught only API keys, so agents wrote APOSTRA_API_KEY code for scripts that only run on your machine. For CI and servers the skill still uses an API key or M2M credential, and it never asks you to paste a credential into chat.

​

5.1348.0 — October 26, 2026 at 2:40 AM UTC

• When you ask the assistant in the product for a person, including asking for a customer service, support or sales agent, it now sends your request to the Apostra team without first walking you through troubleshooting (you still approve the request before it goes) and lists the other ways to reach someone: a shared Slack channel, your own Microsoft Teams, or support@apostra.com. It no longer tells you a request failed when a retry went through. The support page in the docs now lists all three ways to reach a person. Nothing to change on your side.
• A member of your organization with write or admin access who also has their own membership in a client account can now set or remove the campaign operator fee while working in that account. Before, they could see the fee there but not change it. Read-only members still only see it.

​

5.1347.0 — October 26, 2026 at 2:07 AM UTC

• Account actions now live in the account switcher in the top bar, below your accounts: Agents, Partner and View as (role preview) have moved there from the profile menu, which now holds only things about you. View as now uses the same role names as Account members (Admin, Operator, Member). On small screens, Agents and Partner are in the account switcher rather than the main menu.
• Fixed a bug where attaching or replacing a creative on an already-launched OpenAI Ads media buy was always rejected as a no-op. update_media_buy now reads the creative assignment from the package, matching the AdCP wire shape, instead of a top-level field that was never populated.
• A seller can connect to a sales agent run by an organization in the partner-program beta when the agent has passed live certification or Apostra has exempted it from certification. The beta itself no longer stands in for a certification pass: an uncertified agent also needs a current exemption, and the connection check refuses it once the exemption ends. A current behaviour blocker still refuses the agent.

​

5.1346.0 — October 26, 2026 at 1:47 AM UTC

• Changing a live buy’s targeting through a storefront is now held to what the product offers, as creating one already is. An update_media_buy that sets a targeting_overlay dimension the product’s overlay_support does not declare is refused with UNSUPPORTED_FEATURE naming the package, product and dimension, on storefronts that enforce declared targeting, and is reported but still applied on the rest. Updates that leave targeting alone, clear it, or change only what the product offers are unchanged.
• Fixed a media buy’s creative listing showing a correctly-formatted, successfully-attached creative as having an unknown format. The listing now resolves the creative’s canonical format from the same source its own detail read already used.
• Video drafts on the Veo creative engine now generate with Google’s Gemini Omni Flash after Google retired the Veo 3.1 preview endpoint. Requested video length is a target, and the generated clip can be a different length.
• An agent in a Developer account now reports what is true of it as separate facts, and its headline finding says what to do next. get_status, get and search for an agent carry a new states object: whether an endpoint is registered, how many storefronts use the agent and how many of them are listed, whether it is certified, whether other organizations can find it, the result of its latest test, and, for a buyer agent, whether its credential is issued and has made a call. A state that does not apply to the agent’s kind is null. stage, nextStage, finalStage and stuckOn are deprecated. They keep returning the values they have today and are removed no earlier than 3 December 2026, and no earlier than six weeks after this release. Read states for what is true and the headline finding for what to do next.
• Inviting, re-roling or removing an account member with a credential that isn’t allowed to manage members now returns a 403 ACCESS_DENIED refusal that names the reason. An invalid email address or user ID now returns a 400 VALIDATION_ERROR. Before, both returned a 500 internal error.

​

5.1345.0 — October 26, 2026 at 1:08 AM UTC

• The account switcher in the top bar now appears for everyone, including people with only one account. If you can add accounts, it also ends with Add account, which opens Settings → Accounts, where you add the account and see whether your plan allows another one.
• Certification now starts a new run for an agent whose test buy could not be sent, instead of waiting out the 14-day evidence window. When your agent refuses the certification creative or the buy fails before reaching it, Apostra tries again with a fresh run 24 hours after the failure. A buy waiting for you to approve its creative still holds the agent for the five-day wait.
• A storefront now assigns a creative to a seller’s package only by the seller’s own package id. Before, when a storefront had not yet learned the seller’s id for one package of a buy, it named that package to the seller by the storefront’s own sf_pkg_… id when syncing creatives, and the seller could not match it, so the creative was not attached to that package. Now that package is left out of the creative sync, and the creative’s delivery to it waits until the storefront reads the seller’s id from the seller’s own report of the buy, then goes out. Creatives on packages whose seller id is known are sent as before.
• You can now add a bearer token or basic auth credential to a sales agent source that was set up without authentication. Previously, saving the credential failed with “Authentication type does not match none”. The source is updated in place, so its storefront and buyer mappings stay as they were.
• A campaign launch that OpenAI Ads permanently rejects for a policy or account-verification reason — for example, a creative’s landing page URL that doesn’t match the account’s verified brand domain — now tells the buyer the actual reason instead of being retried automatically for several minutes and then reported as a generic upstream failure. Previously every OpenAI Ads rejection, regardless of its real cause, was treated the same as a transient outage.
• The pricing summary no longer counts a product priced only in the wrong currency as priced. Buyers could not see these products, and the summary now reports them as not priced in your storefront’s settlement currency, so you can fix the price. Nothing changes for products that are visible to buyers.
• Saving new ad-server credentials now keeps any other secret already on file, so you no longer have to enter it again. A save that leaves out a secret on file used to be refused. Now the secret is kept, along with the settings that go with it, such as the Broadsign Control domain ID. On the ad-server source page, leave the Broadsign Control API token blank to keep it. To remove a secret on purpose, name it in removeSecrets on save_ad_server_connection, or clear both Control fields on the page.
• An expired wholesale pricing feed, or an ad server with no pricing to derive from, no longer takes a seller off the market. Their auction products stay listed in the seller’s wholesale catalog with no floor and no price guidance, and the seller can still go live and transact on any product that has a fixed price or a floor. Sellers still get a warning in readiness and a notification to upload a current feed, and a buyer’s bid is still required to book. Answers to a buyer’s brief include only products that have a fixed price or a floor, so a seller whose products all lack both stays off the market until one of them has one. A product with no pricing option, or only a fixed price outside the seller’s settlement currency, stays hidden.
• On a storefront listing, a storefront that names no countries now shows “All countries”, and one that names no channels shows “All channels”, instead of “Markets not specified” and “Channels not specified”. Naming none means every country or every channel. API responses are unchanged.
• When you answer an open Library request by dictating to Murph, Murph now closes the request after saving your answer. Before, it saved the answer but left the request open and reported an error.
• Reading your seller scores (get with kind: seller and include: ["scores"]) no longer times out for a seller with a long buy history. Before, the read could take longer than its time limit, and the scores came back as “Could not load your scores”.
• When a seller turns down your media buy in its approval review, the buy now shows as rejected, with the reviewer’s reason in its status details. Before, it kept showing as pending approval indefinitely. Buys rejected earlier update on their own within the hour; nothing to change on your side.
• Marketplace selection, advertiser admission and proposal requests now use the same markets a seller’s Discovery Card shows. A pass-through seller that has not yet confirmed its markets is matched by its stored channels and countries plus the channels and countries its connected sales agents declare. Sellers that manage their own inventory, or that have confirmed their markets, keep matching on their own values. A seller that names no countries is in every country, and one that names no channels is in every channel, so it now qualifies for buyers in every market and channel; a seller that names countries or channels is still matched only there.

​

5.1344.0 — October 25, 2026 at 10:56 PM UTC

• Nothing changes unless you opt in. Guaranteed buys on Google Ad Manager are still sent as they arrive, and the ad server books them even when they ask for more than it forecasts it can deliver. That is overbook, the default. You can now choose hold for review instead, so you decide before an over-forecast buy is booked.
• With hold for review, Apostra asks the ad server for its availability before sending a guaranteed buy. A buy within the forecast is sent as usual. A buy over the forecast, or one whose availability the ad server cannot confirm, waits in your Approvals, and nothing is booked until you decide. Each package shows requested, forecast available and shortfall. Approve sends the buy as submitted, so the ad server books the full order even though it may not deliver all of it. Reject sends nothing to the ad server, and the buyer sees the buy as rejected. The hold happens in Apostra; the ad server is only asked for its forecast.
• To turn it on, choose Hold for my review beside the approval gates on the AI Business Rules page, ask Apostra, or save { "guaranteedOverForecast": "hold_for_review" } with save_business_rules. Agents can also find, read and decide held buys through V3 search, get and save_work_item. Save "overbook" to go back. The setting covers guaranteed packages on Google Ad Manager, as the ad server reports the selected pricing option, and applies to buys created after you change it. The availability check adds a wait of up to about 35 seconds before the buyer gets an answer.
• You can now hand a user API key to a partner, such as a measurement provider, without showing them your fees. A signed-in organization administrator marks the key with PUT /api/v2/user-api-keys/{id}/fee-visibility (an API key or M2M token can’t do this), and GET /api/v2/user-api-keys/fee-visibility lists the marked keys. A marked key sees only total cost on every buy it reads: gross budgets and gross spend, without the fee split in budget_breakdown or the seller’s package bid prices. That includes buys with no operator fee, so a marked key no longer sees Apostra’s fee split either. Marking changes nothing else the key can do, and no key is marked until you mark it, so unmarked keys behave as before and you have nothing to change unless you want this.

​

5.1343.0 — October 25, 2026 at 10:18 PM UTC

• Images, hosted video and hosted audio you send with a new media buy now reach sellers that offer several sizes of the same format. Apostra tells the seller the creative’s measured size and duration, so a seller with several image or video formats receives it under the one that matches. Before, the buy was refused with “the seller advertised several legacy refs”. Sellers that offer a single format of that kind still receive the creative as before. Nothing to change on your side.
• If your organization runs campaigns for clients in their own accounts, you can now add your own percentage fee to a campaign. Set operatorFees with save_campaign, or on the campaign create and update requests: [{ "name": "operator_fee", "rate": 0.02 }] sets a 2% fee, and a campaign takes one. The fee is a share of the client’s gross budget. Each media buy locks it when the buy is created and takes it beside Apostra’s fee, so the seller receives only the media budget. Media buys that already exist keep the fee they locked, so a change applies only to buys created afterwards. Apostra never charges the fee: you invoice your client and keep it. This works when the client account’s media is invoiced to your organization, which is the default for a client account. Your client sees only the total cost unless you let your accounts see your contract terms. Operator fees are in beta and switched on per organization: ask your Apostra contact to turn them on.
• When the next step is to add or update a payment method, the Plan & Billing Page now lets an administrator set up card payment in place. The Page stages the handoff and shows what it will do, then opens the secure card page only after the administrator confirms. It reports whether the card link is open, expired or verified, and offers to check the status again. The card is entered on the secure page, never in the Page or in chat. It makes the same request_payment_authority and confirm_payment_authority calls an agent can.

​

5.1342.1 — October 25, 2026 at 9:45 PM UTC

• The storefront readiness check for product publisher domains now counts only products you still offer. Some products withdrawn in June or July still counted as active, so the check could list them as unmapped or on an undeclared domain. They are now archived everywhere. Any warning that remains is about a product on sale today.
• An approved creative no longer shows as “in review” while Interchange resends it unchanged. When the content and destination match what the seller already approved, the creative stays approved for the whole resend, and creative status, launch readiness and the creative library keep showing the approval. If the seller rejects the resend or reports an error, that answer still replaces the approval, and a creative whose content changed still starts as pending.
• When a seller approves a media buy by hand, the buy’s packages are now recorded on your side as soon as it is booked. Before, they were not recorded while the buy waited for its creatives, so a creative added after booking could be refused with “Creative assignments cannot be changed while the initial media-buy create is waiting for approval”.

​

5.1342.0 — October 25, 2026 at 9:26 PM UTC

• Certification can now place its test buy with a sales agent that sells only through briefs. Apostra found your agent’s product through its brief and synced the test creative, but then could not find that product again when it came to book it, so the buy was skipped as an unknown product and never reached your agent. The buy now finds the product it was offered, so the use case is judged on a real test buy.
• Image, hosted video and hosted audio creatives now reach sellers that offer several sizes of the same format. Apostra tells the seller the creative’s measured size and duration, so a seller with several image or video formats receives it under the one that matches. Before, the sync was refused with “the seller advertised several legacy refs” and asked you to declare a size the file already had. Sellers that offer a single format of that kind still receive the creative as before. Nothing to change on your side.
• A Google Ads buy Apostra books now switches on as soon as it is created, unless you ask for it paused. Apostra used to book the campaign paused and switch it on only as a side effect of syncing a creative, so a launched Google buy delivered nothing until then, and a buy you had paused went live the moment a creative was synced. Now the buy goes live as the last step of booking unless you passed paused: true. Google shows no ad it has not approved, so a buy with no ads yet, or with ads in review, spends nothing until Google approves them, and an ad you add later goes live under the running buy. If Google refuses to switch the buy on, the buy is kept, not deleted, and comes back paused with a warning in ext.google.activation: resume it with update_media_buy and paused: false. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead (containment_failed): the campaign may be live and could spend once Google approves an ad, so check it in Google Ads and pause it straight away.
• Syncing a creative now enables only the new ad. It no longer switches the campaign or an ad group on or off, so a buy or package you paused, at creation with paused: true or later with update_media_buy, stays paused after a creative sync; resume it with update_media_buy and paused: false (or a package’s paused: false). Buys booked before this change have both the campaign and its ad groups paused, so they serve only after one update_media_buy that sets paused: false for the buy and paused: false for each package.
• A Pinterest buy Apostra books now switches on as soon as it is created, unless you ask for it paused. Apostra used to leave a buy paused when you launched it before its creatives were ready, so nothing went live even after you added them. Pinterest shows no ad it has not approved, so the buy spends nothing until Pinterest approves its ads. The response now reports the buy’s real status, and ads you add to a buy that is on are created on and go out for review; ads added to a buy you paused are created paused and come back with it. If Pinterest refuses to switch the buy on, the buy is kept, not archived, and the response says so: resume it with update_media_buy and paused: false. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead: parts of the buy may be live and could spend once Pinterest approves an ad, so check it in Pinterest and pause it straight away.
• A Pinterest buy that uses an existing Pin as its creative still starts paused.
• When plan help is available, the Plan & Billing Page now lets an administrator ask us for help choosing a plan or preparing a private offer without leaving the Page. They add an optional message and send it; we attach the organization’s plan context, so there is nothing to describe. The Page confirms the request for the organization it names, with a reference to quote, and says that sending it does not change the plan, pricing or access. It files the same save_ask commercial request an agent can.
• On media partners that keep a separate account for each brand, operator unit and market, Apostra now also requests your account at each of the partner’s own sales agents that takes account requests, as it already does elsewhere. Once the partner’s agent accepts the account, its products appear in your discovery.
• Buyers already connected to a media partner now get an account requested at each of the partner’s own external sales agents that takes account requests. Before, a buyer whose connection had finished before that request existed never had it sent, so that agent’s products stayed out of discovery. Once the partner’s agent accepts the account, its products appear for the buyer. A partner that refuses an account is not asked again unless its agent’s connection settings change.
• A Spotify buy is now switched on when it is booked, and you can resume a Spotify ad set that is still in review. Apostra used to book every Spotify buy paused and leave it that way, so it never ran until someone resumed it by hand, and a resume of an ad set waiting for Spotify’s approval was refused. Now the buy goes live as the last step of booking unless you asked for it paused. Spotify serves nothing it has not approved, so a buy with its ads still in review delivers and spends nothing until Spotify approves them. If Apostra books the buy but cannot switch it on, the buy comes back paused with a warning in ext.scope3.activation_warning, and you can resume it. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead: parts of the buy may be live and could spend once Spotify approves an ad, so check it in Spotify and pause it straight away.
• Buys booked before this change stay paused until you resume them.

​

5.1341.0 — October 25, 2026 at 8:33 PM UTC

• On Google Ads, a creative’s approval in media buy reads and in the creative list now comes from Google’s policy review of the ad, instead of from whether the ad is switched on. An ad Google has approved, including one approved with limits, shows as approved. An ad Google disapproved shows as rejected with the policy topic Google gave, such as trademarks. An ad Google has not finished reviewing, or has not reported on yet, shows as pending_review, and a disapproval the advertiser has appealed stays pending_review until Google decides. Each approval is reported under the creative id you sent, and a creative placed in several ad groups is approved only when all of its ads are. Nothing to change on your side.
• An administrator can now cancel the plan at term end or reinstate automatic renewal from the Plan & Billing Page, without leaving it. The Page shows only the changes the server allows now and the deadline for making them, asks for a reason and a confirmation, and records the change for the organization it names with the same save_billing call an agent makes. If the renewal changes while the person is confirming, nothing is recorded and the Page asks again.
• Accepting or switching an IU plan through the V3 save_billing tool now needs an organization administrator to approve it on the Apostra site. Your agent’s plan call checks the plan against the current offer and returns approval_required with a link instead of accepting on the call. A direct administrator of the billing organization opens the link, sees the exact plan, price, payment option and start, and approves or rejects it. An administrator of a parent organization who is not a direct member, Apostra staff acting for your organization without being one of its direct administrators, API keys and impersonated sessions cannot approve it. When your agent repeats the call with the same idempotency key, it gets the approval’s state, and the accepted plan once it has been approved. The plan is recorded as accepted by the administrator who approved it. Agents that call save_billing with plan must now show the link and check back. Accepting Terms, choosing payment terms, answering an offer and changing renewal still take effect on the call.

​

5.1340.0 — October 25, 2026 at 7:59 PM UTC

• A creative added to a media buy while the seller was approving it is now attached to the right package once the buy is booked. Previously, the buy could book with the creative left unassigned, because the packages the seller booked were not yet known when the creative was sent.
• Save image, hosted video, and hosted audio drafts without choosing an engine. Apostra uses a compatible active connection first, then an eligible Scope3-funded engine. An engine you choose explicitly still takes priority. If neither is available, connect the needed engine in Settings → Connections.

​

5.1339.0 — October 25, 2026 at 7:45 PM UTC

• When an advertiser has property lists, product discovery now removes products that nothing can enforce those lists on, and reports them separately from products removed by an exclusion list. The test is the same one applied at launch: the seller applies the list, or the product’s declared sites and apps confirm it. A product that names only a publisher cannot be confirmed. If a search returns fewer products than you expect, check the new counts before concluding there is no inventory. In get_products, ext.interchange.unenforceable_product_count gives the total, and each seller carries its own unenforceable_product_count and up to 25 unenforceable_products, each with the list and the reason. REST discovery returns unenforceableProductCount and unenforceableProductsByStorefront. Guidance now says when products were removed for this reason rather than reporting “no inventory”, so buyers can’t shortlist a product that launch would then refuse. If the check cannot finish for a product, for example because a lookup times out, the product is withheld rather than offered unchecked and is reported separately as unverified (unverified_product_count and unverified_products, or unverifiedProductCount in REST discovery), so you know to retry. Sellers make products appear again by declaring property-list support or listing each site and app in publisher_properties. An AdCP 3.2 seller declares it with media_buy.execution.targeting.property_list. An AdCP 3.0 or 3.1 seller declares media_buy.features.property_list_filtering and the product sets property_targeting_allowed: true, and discovery and launch read both the same way, so a product offered in search is one the buy sends the list to. Exclusion lists need the 3.2 declaration, because 3.0 and 3.1 have no exclusion field, and a 3.2 seller that declares only property_list_filtering does not count, because there it means discovery filtering alone. Advertisers without property lists see no change.
• An administrator can now choose a plan, decline the offer or decide later without leaving the Plan & Billing Page. The Page asks for the plan, the payment schedule when the plan lists one, and an explicit confirmation, then records the choice for the organization it names with the same save_billing call an agent makes. If the offer changes while the person is choosing, nothing is recorded and the Page asks again. The Page no longer opens a separate plan window.
• A Reddit buy Apostra books now switches on as soon as it is created, unless you ask for it paused. Apostra used to book the campaign and its ad groups paused and nothing ever switched them on, so a launched Reddit buy delivered nothing. Reddit shows no ad it has not approved, so the buy spends nothing until Reddit approves its ads. Ads you add to a buy that is on are created on and go out for review; ads added to a buy you paused are created paused and come back with it. If an ad is created but Apostra cannot confirm it from Reddit, the ad is paused again before the failure is returned, so retrying sync_creatives does not create a second live ad. If that pause cannot be confirmed, the response says so with the ad’s id (CONTAINMENT_FAILED): the ad may be live, so check it in Reddit before you retry. If Reddit refuses to switch the buy on, the buy is kept, not deleted, and the response says so: resume it with update_media_buy and paused: false. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead: parts of the buy may be live and could spend once Reddit approves an ad, so check it in Reddit and pause it straight away.
• Resuming a Reddit buy with paused: false now switches its ad groups on as well as its campaign. Ads created before this fix stay switched off.

​

5.1338.0 — October 25, 2026 at 7:21 PM UTC

• Storefront responses now follow the AdCP release your agent negotiated. A request pinned to AdCP 3.0 or 3.1, or one that leaves the release to the storefront’s default, gets responses in that release’s shape: fields a later release added are left out rather than sent alongside. A request that sends only adcp_major_version is served AdCP 3.0. Pin adcp_version: "3.2" to receive AdCP 3.2 fields.
• When Apostra places or changes a buy with a seller whose agent supports only an older AdCP release, the request is converted to that release. If part of the change can’t be expressed there, such as a spend cap or a targeting exclusion, the call is refused before anything reaches the seller instead of being sent without it.
• An Amazon Sponsored Products buy now runs once it is booked, and create_media_buy now reports its status. Apostra used to book the campaign and its ad groups paused, switch only the campaign on, and say nothing about the buy’s status, so the ad groups kept the buy from serving until someone enabled them by hand. Now the campaign is booked paused and checked, its ad groups are created enabled, and the campaign is switched on as the last step unless you asked for the buy paused with paused: true. Amazon serves nothing it has not approved, so a buy with its ads still in review delivers and spends nothing until Amazon approves them. If Amazon refuses to switch the campaign on, the buy comes back paused with a warning in ext.amazon.activation_warning, and you can resume it.
• Buys booked before this change keep their ad groups paused. Sponsored Brands, Sponsored Display and DSP are not open for booking yet, so none of them is switched on.
• A brief that names its target audience by age, such as “reaching adults 25-59” or “Targeting: A25-54”, no longer removes every product that cannot target that exact range. Storefronts now read such wording as the audience the campaign is for, use it to recommend products, and return their products as usual. A brief still restricts delivery by age when it says so outright, for example “25-54 only”, “exclusively people aged 25-54” or “do not show to anyone under 18”; that wording is applied on AdCP 3.2 requests exactly as before and confirmed in targeting_resolution.brief_targeting. To guarantee an age range whatever the brief says, send it in targeting_overlay.demographics.age.
• Certification now sends its test briefs to your agent. For a sales agent that sells only through briefs, Apostra’s brief reached the Storefront but was never passed on to your agent, so the run reported that your agent returned no products and every use case was skipped, however many times it ran. The brief now goes to your agent under the sandbox account your agent set up for the run, the same account Apostra’s test buy and creative use, so the products your agent answers with are what Apostra certifies.
• Apostra sends a brief only for a channel your Storefront serves. A Storefront that serves display only is sent the display brief and no video brief, and the video use case no longer shows up skipped as buy_no_matching_proposal.
• When a Source’s automatic runs keep ending the same way, Apostra now waits longer between them: 24 hours, then 48, then 96, up to seven days. The wait starts over at 24 hours when your agent’s capabilities change, or you turn Allow certification buys off and on again. A change to your agent’s products is seen by the next run, which starts the count over.
• Ask the Apostra assistant on the web to open a source page, such as “open diagnostics for pubx-ai”, and it now opens straight away, focused on that source. If your account has one source, the assistant opens that one. When it can’t tell which source you mean, it works it out as before.
• Confirming the launch of a campaign whose media buys were already booked with their sellers now finishes the launch. Before, a launch that stopped part-way, for example because a creative sync failed after a seller accepted the buy, left the campaign in draft, and confirming again failed with “no media buys to execute”. The launch preview now lists those booked buys and marks the ones confirming will start. Confirming resumes the paused buys that were not paused on purpose and moves the campaign out of draft. A buy you paused yourself stays paused. If a seller refuses a resume, for example while an ad set is still in review, the response names that buy and the seller’s reason, and confirming again retries only the buys still paused.
• Video drafts on the Scope3-paid Veo engine in the Creative Engines preview now generate. Before, every hosted-video draft on that engine was refused before reaching Veo, with a message asking you to correct the format. No provider was ever charged for those refused drafts.
• Mark a buyer agent’s advertiser grant to show the agent fee breakdowns. Add showsFeeBreakdown to an entry when you replace an agent’s access, and read it back on each advertiser. An unmarked grant sees total cost only on a buy that carries an operator fee; no buy carries one yet, so the mark changes nothing today.
• A LinkedIn buy Apostra books now switches on as soon as it is created, unless you ask for it paused. Before, a LinkedIn buy came back paused unless you passed paused: false, so a launched buy delivered nothing. LinkedIn shows no ad it has not reviewed, so the buy spends nothing until LinkedIn approves its ads. A buy with no creative stays paused and the response says why, because LinkedIn only switches a campaign on once it holds a creative and takes creatives only when the buy is created. If LinkedIn refuses to switch the buy on, the buy is kept, not deleted, and the response says so: resume it with update_media_buy and paused: false. The response now also carries the buy’s true media_buy_status. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead: parts of the buy may be live and could spend once LinkedIn approves an ad, so check it in LinkedIn and pause it straight away.
• Sessions now keeps Source and Lifecycle filters visible, including Recorded RFP exchanges, and shows that conversations are sorted with the most recent first.
• A Meta buy is now switched on when it is booked, even if its creatives arrive later. Apostra used to leave a Meta buy paused unless every package already had a creative, so a buy whose creatives were synced after booking never ran until someone resumed it by hand. Now the buy goes live as the last step of booking unless you asked for it paused. Meta serves nothing it has not approved, so a buy with no ads yet, or with ads in review, delivers and spends nothing until Meta approves them. If Apostra books the buy but cannot switch it on, the buy is kept and comes back paused with a warning in ext.meta.activation, and you can resume it once each package has a creative. In the rare case that switching on fails and Apostra then cannot confirm the buy is paused again, the warning says so instead: parts of the buy may be live and could spend once Meta approves an ad, so check it in Meta and pause it straight away.
• Buys booked before this change stay paused until you resume them.
• The Plan & Billing Page now reads the same billing an agent reads, and shows the plan in force with its renewal, an upcoming plan or the plans on offer, and recent invoices beside standing, balance, IU usage and the next step. It accepts Terms through the same call an agent uses. The Page no longer offers its own link to the full web billing page, the Demo environment banner, or the enterprise contract lifecycle summary; billing actions it cannot complete open the Plan & Billing guide instead. A member of an account whose organization manages billing sees which organization manages it.
• A live media buy placed through a direct provider connection, such as OpenAI Ads, now has its status read from the provider every hour. Before, only buys still waiting to launch were read, so a running buy’s status and its creative review result never updated.
• A TikTok buy is now switched on when it is booked, even if its creatives arrive later. Apostra used to book a TikTok buy paused and switch it on only when it had a creative at booking, so a buy booked first and given creatives afterwards never ran until someone resumed it by hand. Now the buy goes live as the last step of booking unless you asked for it paused, and a creative you attach afterwards is switched on as well. TikTok serves nothing it has not approved, so a buy with no creative, or with creatives still in review, spends nothing until TikTok approves them. If Apostra books the buy but cannot switch it on, it switches the whole buy back off and checks it, and the buy comes back off with an activation_failed warning in ext.scope3.activation_warning; you can resume it. The exception: if Apostra cannot confirm the buy is off, the warning is containment_failed, the status reflects what TikTok reports, and parts of the buy may be live and could spend once TikTok approves an ad, so check the buy and pause it in TikTok straight away.
• Buys booked before this change stay as they are until you resume them.

​

5.1337.0 — October 25, 2026 at 6:32 PM UTC

• Products whose publisher_properties name a publisher rather than each site and app (selection_type of all, by_id or by_tag) can now be bought by an advertiser with property lists when those lists are satisfied, even if the seller does not apply lists itself. Apostra resolves the selector to the sites and apps the publisher’s adagents.json authorizes the seller to sell (all of them, the named property_ids, or the ones carrying the property_tags) and checks each against the advertiser’s lists. A product is still refused with property_excluded when any of those sites is on the exclusion list, with property_outside_include_list when any is missing from an include list, and with coverage_unknown when no authorized sites are found for the publisher. If the lookup itself fails, the launch returns a retryable SERVICE_UNAVAILABLE error; retry it. For sellers on the Apostra-managed sales agent the sites come from that agent’s authorized list; for other sellers they come from the AAO registry. Products sold through an ad-server adapter connection are not resolved this way yet. Nothing to change on your side; sellers make more products eligible by keeping their publishers’ adagents.json authorizations current.

​

5.1336.0 — October 25, 2026 at 6:04 PM UTC

• A seller can connect to a sales agent run by an organization in the partner-program beta before that agent has passed live certification. The connection check now reads the organization that owns the agent’s Developer account, and accepts an unexpired beta of the certified sales agent profile in place of the certification pass. A paid plan or a profile assigned by an Apostra operator still needs the pass, a current behaviour blocker still refuses the agent, and the exception ends when the beta ends. A seller connected to such an agent is served by an agent that has not passed certification.
• The Apostra CLI is now on npm. Run npx @apostra/cli login, approve one account in your browser, and Node.js scripts using @apostra/sdk 0.39.0 or later call the V3 API as you, with no API key. CI and servers should keep using an API key or an M2M credential.
• The Agent page and the certification docs no longer describe a per-account switch for stopping new buys on a behaviour blocker. That switch was never turned on for any account, and it is now gone. A blocker on one of the checks that can stop new buys acts through certification only: it stops your agent’s certification pass counting, and an agent without a current certification exemption takes no new buys until the blocker is fixed. A blocker on any other check stops nothing. Running buys continue, and nothing changes for buys today.
• A media buy that a seller approves by hand is now booked as soon as it is approved, even if a creative the buyer added while it waited has not reached the seller yet. Previously, a creative added during that wait could stop the buy from booking, or hold it back until the creative arrived. The seller’s create now names only the creatives that seller already has. Each remaining creative is attached to the booked buy once it passes the seller’s creative review.
• The Advertisers page now shows your one next step above your advertisers. While a setup step blocks buying, it names the first one and opens Buyer Setup. Once setup is complete and nothing has launched, it is “Launch your first campaign” and opens Campaigns. Buyer Setup shows the same first-campaign step with a button that opens Campaigns. On /mcp/v3, get_status lists it as a recommended next action, first_campaign. The v2 Advertisers page read (GET /api/v2/buyer/all-advertisers-home) returns it in a new nextStep field.
• Certification buys on your sales agent now carry a test creative that fits the format your product declares. When none of the creatives Apostra offers fits, Apostra makes one: an image or HTML5 bundle at your fixed or first declared size (or a standard display size inside your size limits), or a 15 or 30 second tone (or one at the nearest length limit when neither fits). Generated creatives go up to 7680x4320 pixels and two minutes of audio. Apostra reuses it for later buys. Previously a product whose format none of those creatives matched, such as a DOOH screen that takes a 1920x1080 image, was bought without a creative and could fail certification. Nothing to change on your side. Apostra still cannot make hosted video, so a video_hosted product with no fitting offered creative is bought without one, as before.
• Live certification can pass again for sales agents that write timestamps with a UTC offset. AdCP timestamps are RFC 3339 date-times, which allow an offset such as +00:00, but Apostra refused a get_media_buys buy whose package start or end time carried one. Certification then reported that it could not read your agent’s get_media_buys, so its context check could never pass and no use case could be certified. Apostra now reads those timestamps as the same instants in UTC, and when a buy truly cannot be read the certification result names the fields that were wrong.
• A certification buy Apostra cancels itself, because a newer run replaced it or a run was stopped, no longer fails because your agent then reports it canceled.
• Certification now tries an agent again once its failed test run’s buy has finished flying and the run is at least a day old, instead of waiting up to 14 days. This includes switching on Allow certification buys after an earlier run failed.
• If your sales agent declares account.change_feed, certification now checks that its feed announces every change to a buy. When Apostra’s scheduled read of a buy finds its lifecycle status changed, your account.change_recorded feed (list_account_changes) must have carried a record for that buy within five minutes. A record for the media buy, one of its packages, or one of its creative assignments counts. Every record must also name the account the feed is read for: a placeholder such as default instead of the real account_id leaves Apostra unable to use the feed page. One miss in seven days is a flag, and two is a blocker. The check applies from the day it ships, with no report-only period, and Apostra’s own embedded sales agents are held to it on the same terms.
• If your agent does not declare the feed, Apostra reads it by polling and does not judge it, so there is nothing to change. Blockers do not hold anything yet: stopping new buys on blockers is not switched on for any developer account. When it is switched on for yours, a blocker holds new buys only, and running buys are never stopped. How certification works explains the causes and how to fix them.
• A buy that carries a property list can now be enforced on a managed Google Ad Manager seller’s site key, instead of being refused when no other enforcement route applies. Seller-authored Google Ad Manager key signals on those products also reach buyers in valid AdCP shape. The seller’s property signal stays system-managed and is never offered to buyers as a targetable option.
• The Apostra assistant on the web now opens the page you ask for straight away. A plain request such as “open my campaigns” opens the page with no written reply, and a request that also asks a question opens the page while the assistant answers. When the assistant isn’t sure which page you mean, it works it out as before.
• When you ask the Apostra assistant on the web to open a page for a specific source, buyer relationship, advertiser or campaign, it now opens the page focused on that one instead of the general page.
• Click-URL parameters that use a macro the seller’s ad server fills, such as {DOMAIN} or {APP_BUNDLE} in utm_content={CREATIVE_ID}_{DOMAIN}{APP_BUNDLE}, now reach your landing page with the site or app the ad ran on, wherever the seller fills that macro. Before, Apostra’s click tracker did not ask the seller for those values, so that part of the parameter arrived empty. Creatives that are already running pick this up the next time they are sent to the seller; nothing to change on your side. Google Ad Manager still fills no macros in HTML5 creatives, so on those the value stays empty.
• Managed sales agents now apply property lists using the exact source product behind a composed storefront product.
• Role previews now explain how to switch back before saving an advertiser.
• If you removed an inventory Source and added it again with the same ID, its health readings now go to the Source you have today. Until now they could be saved against the removed copy, so your live Source kept showing an old reading and seller setup could not tell you what was wrong with it.
• An agent’s capability findings now match what certification actually checks. The Agent page was reading a snapshot of your agent taken when its production revision was registered, so a finding such as “does not list sync_accounts and list_accounts” could stay up for weeks after you fixed it. It now reads the same hourly capabilities check as AdCP readiness and certification, and says how long ago it last checked when that is more than a day.
• Public market readiness now counts a storefront the same way its Discovery Card advertises it. A storefront counts for the countries and channels it lists. A pass-through storefront whose seller has not yet confirmed its markets also counts for what its connected sales agents declare. A country or channel list that is empty is open, so the storefront counts toward every country or every channel, and a storefront that is open on countries counts as global supply. Supply counts for a country and channel can therefore rise, most for storefronts whose seller has not set markets yet.
• On Meta, a creative whose ad is running or preapproved now shows as approved in media buy reads and in the creative list, instead of sitting at pending_review after Meta approves it. An ad that is paused still shows as in review, because Meta reports a pause in place of the review result, so a paused ad may not have been reviewed yet. A Meta buy that is paused only because some package has no creative yet now reports pending_creatives instead of paused, and a buy you paused yourself with creatives in place still reports paused. Creatives Meta rejected still show as rejected with Meta’s reason. Nothing to change on your side.
• Stopping a Murph reply no longer shows up as an error. If you reload the page, press Stop, switch conversations or send a new message while Murph is still answering, that turn now ends as “This response didn’t finish” instead of being recorded as a failed turn.
• open_page now takes connect_sales_agent, which opens the Connect sales agent task without choosing an agent first. The task lists your organization’s own sales agents and the certified partner agents you can connect through, the same list search({ "kind": "agent" }) returns; choosing one still connects it with save_inventory_source({ "agentId": ... }). Seller Setup’s Sales agent choice now opens it this way. See “Connect to a partner agent” and the seller workflows guide.
• A ChatGPT Ads (OpenAI Ads) buy is now switched on when you launch it, instead of sitting paused until you resume it by hand. OpenAI Ads serves nothing until it approves an ad, so a buy launched before its ad is approved delivers and spends nothing until approval, then starts on its own. A buy launched before a creative is attached is also switched on, and its ad is added when you attach the creative. If you launch a buy as paused, it stays paused. If OpenAI Ads refuses to switch a new buy on, the buy is kept paused and the response carries a warning, so you can resume it with update_media_buy.
• Automated creative review and Brief Acceptance now reject what your written policy plainly forbids. Before, a clear violation could be held for a person to check whenever the automatic policy check did not reproduce your rule word for word. Now the check names the rule it broke, and the rejection goes ahead with that exact line from your policy as the reason. Anything unclear is still left for a person, and approvals are no easier to get than before.
• A creative that an ad platform has approved or rejected now shows that decision on your media buy and campaign. Apostra reads each platform’s review result every time it checks the buy’s status, including buys that are booked paused, so a creative the platform approved no longer stays “needs seller approval” and the campaign launch review stops listing it. A rejected creative shows the platform’s reason.
• Sellers who sell digital out-of-home screens through Broadsign can now connect their Broadsign Guaranteed Campaigns account and sell those screens through Interchange. Buyers see the screens each product covers, and buys book, change and cancel as Broadsign proposals. Adding an optional Broadsign Control token also sends your creatives to the screens and reports the plays that actually ran as delivery.
• Buyers can now see which changes a seller supports on each live buy, such as pausing it or moving its dates.
• On FreeWheel, SpringServe, AdsWizz and Broadstreet buys, a change to the start or end date is now refused with an error instead of being saved without reaching the ad server. Broadsign buys accept date changes as amendments.
• Every media buy booked through the embedded sales agent on Google Ad Manager now shows its GAM order ID, and each package shows its GAM line item ID, so you can find the matching objects in GAM directly.
• The placement optimizer now only excludes ad units that belong to the product’s own inventory, so inventory added to a line item by hand is left alone. Each change it makes is recorded on the media buy with the GAM line item, order and ad units involved.
• A media buy booked through the embedded sales agent on Google Ad Manager no longer appears a second time as an imported GAM order when its advertiser is assigned to the buyer.
• Managed Google Ad Manager products now list the seller’s property signal, so buys carrying a property list can be enforced on the seller’s domain key instead of being refused. Enforcement starts once the matching Apostra release ships.
• The Seller Dashboard now shows your one next setup step above your analytics: the step the Seller Setup checklist leads with, with a button that opens Seller Setup. It disappears once nothing is left to do before going live. Agents read the same step as readiness.goLive.progress.nextStepId on get with kind: "seller" and include: ["readiness"].
• When your agent’s implementation changes, Apostra no longer asks you to record it. The “Register current implementation” next action, the advisory finding and the in-app alert for a detected change are gone. The Agent page now says when your agent changed (“Your agent changed on 22 October; Apostra re-checked its capabilities”) and keeps its capability findings current from the same hourly read.
• Fixed an intermittent internal error when creating a media buy. If the same create was sent twice at nearly the same moment, the database could cancel one of the two writes and the caller received an unexplained internal error. The create now succeeds, or returns the correct conflict, instead.
• When a storefront’s automated reviewer rejects a creative, the buyer now gets a reason they can act on, and it says whether the creative is recoverable. The rejectionReason (rejection_reason in v2) starts with Rejected automatically:. If the creative can be fixed, it says what to change and that you can resubmit, for example “The audio is mono; this storefront requires stereo.” If the storefront does not accept this kind of ad at all, it says so and that resubmitting will not help, so you do not spend a resubmission on it. The reason may quote or paraphrase the rule of the seller’s Creative Policy the creative broke, even when the seller has not published that policy on their listing; sellers can read this in Listing, Playbook, and AI Business Rules. Before, it was the same fixed line for every rejection. See Creative approval.
• A media buy you archived is now treated as archived everywhere an edit is checked. Before, an archived draft could still be found by a media buy update, a line-item budget change, or a campaign geo-targeting change, so a campaign-wide geo change could try to edit it and fail partway through. Now an update to an archived media buy is refused as not found, and a campaign’s geo change skips it. Nothing to change on your side.

​

5.1333.0 — October 25, 2026 at 2:04 PM UTC

• Seller accounts for your advertisers now catch up on their own after changes that used to need you to re-select the seller. If a seller you already work with needs a new account for one of your advertisers (for example after your operator unit changes, or when the seller adds its own sales agent), we request it within about 10 minutes.
• Find and manage buyer-owned creative provider connections in Connections. Scope3-funded engines are not shown as connection targets.
• The V3 quickstart now starts with the Build with Apostra package for people building software on Apostra. The package gives your coding agent Apostra’s recommended patterns along with the connection. If you only want your agent to work in your account, the one-line mcp add connection is still there.

​

5.1332.0 — October 25, 2026 at 1:42 PM UTC

• Meta Awareness — Impressions and Meta Awareness — Estimated Ad Recall buys created without an optimization goal can now be read back. These products optimize for a Meta vendor metric by default, and the buy now records that metric in the package’s committed_metrics and returns it when the buy is created. Before this fix, reading such a buy back (get_media_buys, delivery, and reporting) failed because the commitment was missing.
• A buy on a Google Ad Manager–backed embedded sales agent now goes active when the sales agent reports it active. Apostra no longer waits for Google Ad Manager line items to match the booking, no longer pauses a line item because of how it is set up, and no longer fails a resume with AD_SERVER_UNCONFIRMED. Apostra now reads only what the sales agent reports in AdCP, the same way for embedded and third-party sales agents. Keeping spend inside the budget is the sales agent’s job: it refuses to activate, or pauses, a package it cannot cap, and reports each package’s effective budget as read from its ad server. A package that can spend past its budget shows as a financial budget difference on the buy, and live certification checks it for every sales agent. Budgets are now compared to within a cent instead of within one ad-server goal unit. Nothing changes for you to do; see the status follows what the sales agent reports.

​

5.1331.2 — October 25, 2026 at 1:25 PM UTC

• Seller setup now describes a failing sales agent source accurately. The source health finding says product discovery is failing and points you to Run discovery test for the exact error, instead of saying the agent stopped responding: many such agents do respond but refuse the request. The Inventory source status step names the sources that aren’t active yet and explains that a sales agent source goes live on its own once its agent has passed certification or is exempt and its own health isn’t failing, instead of asking you to fix compliance checks that never block going live.

​

5.1331.1 — October 25, 2026 at 1:04 PM UTC

• Automated creative review now approves and rejects creatives on its own. Before, it held almost every creative for you, because the reviewer would only act above a confidence score that it rarely reached, even on clear cases. Now it approves a creative when it finds nothing wrong, and rejects one only when it finds a failed check and your Creative Policy confirms the violation by citing the line that was broken. When it is unsure, the evidence is thin or your policy is ambiguous, it still leaves the creative for you to decide. Creatives already waiting for you stay in your queue.
• A sales agent Source that went to pending because its own discovery was failing now gets re-checked automatically, so it goes live again by itself once discovery works. Until now, nothing re-checked a pending Source unless you ran the discovery test yourself.
• The developer docs no longer describe an operator on an agent. An agent belongs to your organization, so “Create an agent in a Developer account” has no Operators section and no longer sends you to one when you register a sales agent. Where the maker of an agent is shown, the docs call it the organization the agent is Built by.

​

5.1331.0 — October 25, 2026 at 12:29 PM UTC

• The right to operate agents for client accounts is now called the Certified Agent Partner Program. You will see the new name in Plan & Billing, in the plan and access messages the API returns, and in the docs. The entitlement key, operate-agents-for-clients, is unchanged, so nothing you have built against it needs to change.

​

5.1330.0 — October 25, 2026 at 11:42 AM UTC

• The Allow certification buys switch on an agent’s Test & certify page now appears for everyone who can change the setting. Before, it stayed hidden while the agent failed a required capability declaration, even though saving the setting was allowed and certification runs either way. It now shows for the claimed owner’s direct administrator on a Sales agent, whether certification buys are on or off and whether or not a declaration still needs fixing.
• A media partner where your advertiser already has an active account no longer asks you to finish setting up that advertiser. Before, if the advertiser’s channels were never chosen, the media partner’s requiredAction read complete_advertiser_setup even though you could already buy from it, and agents could stop there. An advertiser with an active account now reads active with no required action, whatever its markets and channels. Advertisers with no account yet still ask you to choose their markets and channels first. Nothing to change on your side.
• The Successful transaction go-live step now completes while Apostra has exempted your sales agent from certification, as it does after a pass, and says the agent is exempt rather than certified. If your Source’s agent isn’t registered with Apostra, the step now asks you to register it in your organization’s Developer account and connect it to the Source, instead of saying it is not yet certified: Apostra can only certify a registered agent.

​

5.1329.0 — October 25, 2026 at 11:05 AM UTC

• Sellers connecting Broadsign can now add an optional Broadsign Control REST API token and Control domain id when they set up or update the connection. Enter both or neither. The token is forwarded to your managed source and never stored or returned; the domain id is shown on the connection. Control is never removed by accident: to keep it when you change other Broadsign credentials, enter the token again, and to remove it, clear both Control fields. Creative trafficking and proof-of-play delivery through Control are still being built, so adding it today does not change how bookings or reporting work. Connections without it behave exactly as before. See Optional Broadsign Control access.
• Paste your agent’s URL on the Developer home and Apostra reads the rest from the agent. Choose Connect your agent, enter the URL and choose Read agent. Apostra shows the agent’s kind, its sales mode if it sells, and a suggested name. Correct the name or sales mode if you need to, then choose Connect. The agent belongs to your organization, so there is no protocol role or operator to pick.
• A sales agent is tested in the same step. A creative agent’s conformance test starts right after and takes up to about 90 seconds. If a test fails or times out, the agent stays connected and the screen says so.
• Apostra reads MCP agents only, over https on port 443, with no credentials, so an agent running locally needs a public tunnel. You can’t add a kind the agent doesn’t declare. Buyer agents have no URL to read: choose It’s a buyer agent to create one and set up its credential. If you haven’t built the agent yet, choose I haven’t built it yet to register it by kind and name and connect its URL later. Nothing changes for agents you have already connected.
• A storefront’s Agents workspace no longer shows an Agents link that could only end in “Couldn’t load Agents”. The Agent page belongs to Developer accounts, so a storefront has no list of Agents to open. API calls stay in the storefront’s Agents workspace.

​

5.1328.0 — October 25, 2026 at 3:32 AM UTC

• A seller now counts as guaranteeing your goal when it fixes a price on the result you asked for, so a fixed price per click reads guaranteed whatever the product’s delivery type or makegood policy. Before, a fixed €3 per click on a product without guaranteed delivery read best_effort, although you could not pay more than €3 a click. A bid target, a seller goal target, and an outcome price that is only a floor or an auction stay best_effort. Whether the price meets your target is still a separate answer: a guaranteed €3.50 per click against a €3 ask is a guarantee at a higher price. New proposals and bookings, the booking recommendation and each seller’s record follow this reading; older stored proposals and buys are restated in a one-time pass after release, and seller-history snapshots already published are not rewritten (the next one uses it).
• The Seller Setup checklist now reads and saves everything through the same V3 calls an agent uses, so what you see there matches get({ kind: "seller", include: ["readiness", "operating"] }): the checks, the go-live verdict, each source card and its liveness. Setting your settlement currency or brand domain and releasing the intake hold now save through save_seller. One thing you may notice: re-checking an ad-server problem from a diagnosis row now opens that source’s diagnostics page, where you run the check and read the result, instead of re-running it in the row. A discovery test for a sales agent still re-runs in place.
• You can now prove that an agent you connected from its URL is yours. Publish a brand.json at /.well-known/brand.json on the agent’s own host that lists the agent in agents[] with its url and type, then connect the agent again with its agentId and agentUrl. Apostra checks the file right away, and endpointControl changes from unverified to verified. There is no separate verify call; each repeat connect runs the check again. Agents you have already connected by URL stay unverified until you publish the file and connect them again.
• Until an agent is verified, it can’t be certified, given Partner standing, listed, or used by other organizations, and turning on Allow certification buys (certificationRequested: true) is refused with endpoint_control_unproven. Agents not connected by URL are unaffected.
• Three limits to know first. The agent’s host must be on a domain your organization has already verified, or a subdomain of one, and Apostra does not follow a redirect to the file. Verification is tied to the URL it proved, so connecting a different URL returns the agent to unverified, as does withdrawing your organization’s approval of the domain. A re-check that fails only because the file is briefly unreachable or broken leaves a verified agent verified.
• get_status and get show endpointControl beside each agent’s stage. See “Prove your agent is yours” in the Developer agents guide.

​

5.1327.0 — October 25, 2026 at 2:49 AM UTC

• When the automated reviewer holds, approves or rejects a creative, you can now read why: its summary, the checks that failed or warned with a suggested fix, and the line of your Creative Policy it cited.
• You see it in the creative’s review in the Approvals page, under “Automated review”, and an agent reads it by getting the creative review work item (findings). It is the reviewer’s own reasoning, written by a model that read the buyer’s creative, so check it against the creative before you decide. A creative the reviewer never looked at has no findings, and the creative queue returned by search does not carry them.

​

5.1326.3 — October 25, 2026 at 2:07 AM UTC

• A sales agent Source that was live before Partner onboarding no longer stays live on that history alone. Like every other existing Source, it stays live while its sales agent has passed certification or is exempt, and while its own health is not failing. A Source whose product discovery keeps failing, or that has had no health reading for seven days, moves to pending until its health recovers. Fix discovery on the Source and it goes live again with no other step.

​

5.1326.2 — October 25, 2026 at 1:54 AM UTC

• When a media partner approves or rejects one of your creatives, or the creative’s delivery to that media partner moves on, your media buys and campaign reads now show the new review status and delivery state on your next read. Before, they could show the earlier state for up to five minutes. Nothing to change on your side.

​

5.1326.1 — October 25, 2026 at 1:32 AM UTC

• A storefront media buy whose create timed out or failed after the seller may already have booked it no longer leaves that booking unnoticed. Apostra now looks in the seller’s system for a matching booking 15 minutes after the failure and then once a day, and alerts our operations team with what it found and a suggested next step: record a booking the seller already ended, take a live one into the buyer’s media buy, or cancel it with the seller. Nothing is changed at the seller or on the buy automatically; a person decides.

​

5.1326.0 — October 25, 2026 at 1:00 AM UTC

• Organization administrators can now see the domain each account operates as. In Settings → Organization → Accounts, a new Domain column shows a buyer account’s operator domain and unit (for example coca-cola.com · aou), a seller account’s brand domain, “Not set” for an account that has not chosen a domain, and “Not proved” when the domain is not verified yet. The same information is in GET /api/v2/accounts: every account now carries operatorIdentity, with its domain, its unit and whether the domain is proved. See List accounts.
• get({ kind: "inventory_source", include: ["adServerConnection"] }) now says which of a managed ad-server connection’s secrets are on file, without ever returning one: contract names the pinned connection contract, and secrets lists each declared secret as { key, label, onFile }. Saving new credentials no longer silently deletes another secret on file: a save that leaves one out is refused unless you name it in removeSecrets.

​

5.1325.0 — October 25, 2026 at 12:24 AM UTC

• The search tool now describes a seller with partnerStatus: "ACTIVE" accurately: the seller is turned on for you (or for the advertiser you filter by), even while its account is still being set up. To tell whether the account is ready, read controlPlane.activation on the seller. Only the tool description changed; partnerStatus values are unchanged.
• Exclusion lists now work on products from Apostra-managed sales agents on Google Ad Manager, not only include lists. Apostra sends an exclusion list as negative targeting through the agent’s property signal, the same way it sends include lists. If your lists change, or the seller later authorizes a site your list names, Apostra pauses the running buy instead of letting it deliver on the old values, and you replace it with a new buy. Advertisers without property lists are not affected.
• When you read a media partner’s products on V3 with get({ kind: "seller", id, advertiserId, include: ["products"] }) and your advertiser has no active account with that media partner yet, the media partner’s storefront_results row now says why it was not searched. outcome.reason_code is account_pending when the account is still being set up and there is nothing to do but wait, or account_needs_attention when you, an operator or the media partner has to act, with a suggestion that points to Media Partners. The result text says the same. Before, both cases read as eligibility with no code, so an agent could not tell waiting from acting. If your agent reads that row, handle the two new reason_code values. The v2 get_products response is unchanged.
• If Apostra’s background worker stopped while it was still preparing a seller request, before anything was sent, request_proposals now sends that request again once instead of reporting the seller’s outcome as unknown. A request that had already gone out to the seller is still never resent, so you cannot get a duplicate. Nothing to change on your side.
• When you connect a sales agent from its URL, Apostra now tests it in the same save_agent call. It sends the agent one no-spend get_products request, with no credentials, and the response says whether it passed. test.state is passed, failed, timed_out or not_started. A pass moves the agent to Tested straight away. The check must finish within 25 seconds of the start of the call, and get_products gets at most 10 seconds of that. If the agent is too slow, test.state is timed_out, nothing is recorded as a failure, and the agent stays connected.
• A failed, timed-out or refused test never undoes the connect. A failure carries the check’s own reason in test.finding. A sales agent gets at most 10 endpoint checks an hour, and if you’ve used them test.state is not_started with test.reason: "rate_limited". Send the same idempotencyKey again and Apostra returns the recorded result without testing again. For a creative agent the response is test.state: "not_started" and names how conformance starts: the Agent page, which takes up to 90 seconds and so doesn’t run inside the call.
• get_status now tells you the next step for a connected agent with no passing test: re-run the endpoint check from the Agent page after fixing the URL (sales), or start conformance from the Agent page (creative).

​

5.1324.0 — October 24, 2026 at 11:09 PM UTC

• Each domain in a seller’s coverage read now carries status, a one-word roll-up of whether Apostra may sell it: authorized, unauthorized, pending or error, or null when the adagents.json lookup found no conclusive evidence. It is the value the setup checklist already showed, so you no longer work it out from adagentsStatus and authorizationStatus. See “Manage publisher coverage” in the seller workflows guide.
• A seller’s readiness read now carries one card for each connected inventory source, so the setup picture needs one call. Call get with kind: "seller" and include: ["readiness"] and read sources: for each source its status, connection and credentials, a one-sentence cardPosture, a liveness of paused, live, attention or critical, whether buyer requests reach it and why (requestRouting), inventory and reporting health, ad-server booking readiness, product counts, catalog mapping progress and a detailAction that says where to open it. Cards come most urgent first, at most 20, and sourcesOmitted counts the rest. If Apostra cannot work out any part of the readiness read, the call still fails with SERVICE_UNAVAILABLE and returns none of it. See “Reading your seller’s setup checklist and go-live state”.
• You can now turn Allow certification buys on or off from your agent’s Test & certify page in Claude, ChatGPT or the web app, instead of asking your assistant. The switch appears only to someone who can change the setting, the account’s direct administrator for an agent it owns. After each change the page reads itself again and shows what Apostra saved. If Apostra refuses the change, the page shows Apostra’s message.
• Developers can now connect an agent to a Developer account by pasting its URL. Call save_agent with agentUrl and dryRun: true to preview what Apostra reads from the agent; nothing is written. Send the same call without dryRun, and with an idempotencyKey, to save it. Apostra reads the URL without credentials, and supports MCP agents only, over https on port 443. The agent’s kind comes from what it declares, and you can correct its name and sales mode. Apostra refuses a kind the agent doesn’t declare. Connecting the same URL and kind again returns the agent you already have.
• A connected agent is not yet verified as yours. Until a later release lets you prove you control the URL, it can’t have Allow certification buys turned on, be given Partner standing, be listed in the marketplace, or be used by another organization. Testing the agent after you connect it is not part of this release.
• Registering an agent by kind and displayName no longer needs an operator. Calls that still send one work as before.
• Agents connected to an organization can now see its domains and each account’s operator identity. On an Organization account, get_status returns organization.domains: each domain the organization has claimed, whether it is claimed, being verified or verified, how it was proved, and which child accounts use it. Accounts from search and get now carry operatorIdentity, the domain and unit code the account operates as and whether that domain is proved. Both are read-only; claiming and proving a domain stays on the website. See the v3 tool catalog.
• Sellers on automatic creative approval no longer have a creative left in the review queue just because the AI reviewer was briefly slow or unavailable. The reviewer now gives its evaluation more time and tries again twice before handing the creative to a person. A creative it still cannot evaluate goes to a person for review, as before.

​

5.1323.0 — October 24, 2026 at 10:22 PM UTC

• The pause check in live certification now runs on products that set no minimum spend. Apostra books those products as two packages of USD 5 each, USD 10 in total, so your agent is tested on pausing a buy with a finished package. Products with a minimum of USD 5 or less book each package at that minimum, and products with a higher minimum still book one package and are not judged on the pause.
• Status changes on media buys under your ad-server advertiser accounts reach your storefront within minutes, instead of waiting for the next scheduled check. Nothing to change on your side: the storefront subscribes your advertiser accounts by itself, and it retries any account your sales agent could not serve a change feed for earlier.
• On /mcp/v3, a buyer account can open its Buyer Setup page with open_page and { "page": "buyer_setup" }. It is the same page the buyer API opens with get_buyer_readiness: the go-live checklist, your confirmed operator identity, and what each seller or buying platform still needs. Opening it changes nothing. get_status still returns the same readiness for an agent to read.

​

5.1322.0 — October 24, 2026 at 9:36 PM UTC

• If you sell digital out-of-home screens through Broadsign Guaranteed Campaigns, you can now connect Broadsign to your storefront as an ad-server source. Connect it with your Broadsign production login email, your password, and the currency configured for your Broadsign domain. Apostra forwards the password to the Apostra-managed sales agent and never stores or shows it.
• Each media buy becomes one booked proposal in Broadsign, and buyers see the screens that make up the product. Broadsign doesn’t expose a currency through its API, so the currency you enter is the one every booking uses. Enter your domain’s currency; it must match your storefront’s settlement currency before a booking can go ready.
• Creative trafficking and proof-of-play delivery aren’t included yet. They need an optional Broadsign Control credential, which a follow-up will add. Until then, schedule creative in Broadsign yourself. See Connecting an ad server. If you don’t sell through Broadsign, there’s nothing to do.
• Turn on Allow certification buys on your sales agent’s page so it can earn a pass before its exemption ends. Without a certification exemption, a sales agent takes new buys only for the use cases it has passed, and a pass on one use case does not cover another. A new buy for any other product is refused with PRODUCT_UNAVAILABLE and never reaches your agent. Existing sales agents are exempt until 1 December 2026, earlier than the 1 January 2027 date in our docs until now. Each agent’s page shows its exemption date. A newly created agent has no exemption; ask Apostra support if you need one. Buys already running, Apostra’s own certification buys and sandbox buys are not affected.
• Advertisers with an include property list can now buy products from Apostra-managed sales agents that run on Google Ad Manager. The managed sales agent can’t apply a list reference, so Apostra sends the list as the agent’s property signal instead, as positive targeting on the line item. Any signal targeting already on the buy is kept. Buyers have nothing to change: you won’t see which sellers qualify, only that more of their products now launch with your list instead of being refused. Exclusion lists follow once Apostra keeps running buys’ exclusions current as a seller authorizes more sites; until then a product that only this route could cover for an exclusion list is still refused. Advertisers without property lists are not affected, and managed sales agents on other ad servers are not covered by this change.
• Sellers: a product becomes eligible when it offers the managed sales agent’s property signal and every listed site or app you carry has a value for it. A site’s value is its domain unless you mapped it differently, and an app has a value only through your own mapping. Map sites and apps with replace_property_mappings. The product is refused with the reason key_value_mapping_missing when a listed site or app you carry has no value (or one longer than Google Ad Manager’s 40 characters), the product does not offer the property signal, or one list needs more than 100 values. See the property lists guide.
• When a change to your property lists leaves a live media buy on a storefront that no route can enforce, Apostra now pauses it at the seller as intended, whether the change came from your own save or from Apostra’s scheduled check of live buys. Before this fix, a storefront buy booked under a seller account was refused the pause: you were notified that it could not be paused, and it kept delivering without your lists.

​

5.1321.1 — October 24, 2026 at 9:23 PM UTC

• Storefront products now always declare supports_webhooks: false in reporting_capabilities, including when the seller’s own product declares true. Storefronts don’t yet send reporting webhooks to buyers, so the old declaration promised deliveries that never arrived. Delivery reports stay available through the usual delivery reads, and the product’s report timezone, delay, frequencies and metrics are unchanged. Nothing to change on your side.

​

5.1321.0 — October 24, 2026 at 8:37 PM UTC

• Live certification no longer places extra test buys for a DOOH-only agent, and its seller-reported test buys now carry a test creative when one fits. If your agent holds a buy until it has a creative, the buy can now go live. A DOOH agent that sells image and video_hosted gets two test buys, one per format, not four. Each buy carries the creative that fits its format, size and duration. If no offered creative fits, the buy is still placed without one and the result says why. Nothing to change on your side.
• A product a storefront composes to a buyer’s brief now declares the reporting schedule of the product it was built from: the same reporting_capabilities timezone, report delay, frequencies and metrics that product declares. Before, every composed product claimed daily UTC reports four hours after each day, even when its reports arrived in the seller’s own timezone or sooner. Buyers can now line up reports with the days a composed product actually reports. Where the source product declares no reporting schedule, the composed product keeps the same defaults as before. Nothing to change on your side.
• Recording which account serves a buyer’s inventory source now works through the V3 REST API and the Apostra SDKs, not only through MCP. A save_seller call carrying only sourceDecision was refused with INVALID_REQUEST on REST; it is now accepted, and sending sourceDecision together with any other Seller Account field is still refused. Nothing to change on your side: retry any call that was refused.
• Spotify ads Apostra creates from now on serve once their buy launches. Apostra created every Spotify ad with its delivery switched off, and launching a buy switched on only the campaign and its ad sets, so no ad ever ran. New ads, including ads created when you re-send a creative, are now created with delivery on. A new buy still cannot run before you launch it, because its ads sit in a campaign Apostra keeps paused until launch, and Spotify reviews each ad before it serves. An ad you add to a buy that is already live runs once Spotify approves it.
• Ads created before this fix stay switched off. If you have a Spotify buy that is launched but not delivering, re-send its creative (save_creative with resync: true) to create a new ad with delivery on.

​

5.1320.0 — October 24, 2026 at 7:47 PM UTC

• Your agent can now start connecting an ad server through V3. Call save_inventory_source with only adServer and the ad server’s type (google_ad_manager, freewheel, springserve, adswizz or citrusad), and it opens the Connect ad server form for you to enter the credentials. For Google Ad Manager the result also gives the service account email to add to your GAM network before you connect, so your agent can tell you which email to add. Credentials still go only into the form, never into chat. The Connect ad server form and the ad-server source page work as before. See Connecting an ad server.
• Embedded sellers’ roster advertiser accounts get a working change feed again. Lifecycle changes on their media buys (made by the buyer or seen from the ad server) are announced on that advertiser’s own feed within minutes instead of waiting for the 10-minute poll, once the storefront re-registers them.

​

5.1319.1 — October 24, 2026 at 7:22 PM UTC

• The control that tells Apostra a Sales Agent is ready for certification is now called Allow certification buys. Turn it on and Apostra sends certification buys to the agent. Turn it off and Apostra sends no new ones, whether a run would start automatically or by hand, and a certification buy already running finishes. Only your real traffic can then show your agent working. The agent page, the Test & certify page, the assistant’s replies and the docs all use the new name, and certificationRequested on save_agent keeps its name.
• A Developer account’s certified agents now show as Listed once the account holds Partner standing. Before this, get_status and the Developer home kept every such agent at Certified, even when the account’s Partner standing was in force, so the Listed stage never appeared.
• Google Ad Manager products now declare the same reporting-day timezone used by delivery even while network metadata is being repaired, so product and delivery dates stay aligned.
• Retrying a create_media_buy with the same idempotency key now always returns the context you sent on the original create, as AdCP requires. get_media_buys also returns that context on each buy, so you can match a seller’s media_buy_id to your own records even after a retried create.
• create_media_buy and get_media_buys now return, on each media buy and each package, the context you sent when you created it, so you can match the seller’s media buy id to your own record.
• Every response, task poll and failed media-buy webhook now returns your request’s context exactly as you sent it, including keys whose value is null, and a failed create_media_buy webhook now includes the errors. provide_performance_feedback now returns a valid response that states the feedback was not applied.
• Create and update calls no longer leave an open “workflow” behind, so sellers stop seeing thousands of stuck in-progress items that were never theirs to act on. Existing items are unchanged.

​

5.1319.0 — October 24, 2026 at 6:46 PM UTC

• Buyer readiness now tells you the step after setup: launching your first campaign. The readiness read (GET /api/v2/buyer/readiness) adds firstCampaign, which says whether your account has placed a media buy and, once platform setup is complete, offers Launch your first campaign, which opens Campaigns. It is never a setup check and never blocks anything. Details: /v2/buyer/account/setup#launch-your-first-campaign.

​

5.1318.0 — October 24, 2026 at 6:10 PM UTC

• A certification exemption now counts wherever a certification pass does, including for a publisher in another organization connecting to an exempt sales agent for the first time. An exempt agent can take on new publishers until its exemption ends; the partner connection’s other checks still apply.
• When opening your organization takes you to one of its accounts, a short message now says which account you were switched to and why, for example “Switched to Apostra Distribution, the account you last used in First-party Buyer Distribution.” Inside the organization itself, Settings no longer labels the organization’s own settings as an “Account”: for an organization administrator they sit in the Organization group, which is the whole rail there and is always open. Nothing to change on your side.
• When you save creatives on a campaign before its media buy is booked with the seller, the campaign now shows each creative’s seller review status (storefrontReviewStatus) and its send status (sourceSyncStatus) as soon as the seller has it. Previously both stayed empty until the buy was booked, even while the creative was waiting in the seller’s review queue. Nothing changes for buys that are already booked.
• Your agent can now decide, through V3, which account serves an admitted buyer on each of your inventory sources.
• Reading a buyer account relationship with get or search now returns sources. Each entry gives the source’s state (bound, not_required, missing, ambiguous or stale), the account it is mapped to, the version to send with your next decision, and up to five matching accounts on the source. Record a decision with save_seller and its new sourceDecision field: bound maps the buyer to one of the source’s own accounts, and not_required confirms the source serves the buyer without one. Until you decide, that source’s products are not shown to the buyer and their buys do not route there. The “Use Interchange default” choice, mapping files and billing readiness stay on the Buyers Page. Nothing changes for decisions you have already made.
• Source health for a sales agent now shows whether the agent returns the AdCP context Apostra sends it. AdCP requires every response, and every media buy and package in a get_media_buys reply, to hand that context back unchanged; Apostra uses it to match your agent’s media buys and packages to its own. When your agent leaves it out or changes it, even once, the source’s health shows a context_echo_missing finding that names the tools. The finding clears once your agent returns the context again and a day passes with no miss. Nothing is blocked and certification is unchanged. Today Apostra sends its own context on every create_media_buy and on each of its packages; see “Echo the context we send” in the agent requirements.

​

5.1317.0 — October 24, 2026 at 5:15 PM UTC

• Live certification now checks that your sales agent hands back the context Apostra sends, unchanged, as AdCP requires. During a certification run Apostra sends a context on every call it makes to your agent (sync_accounts, get_products, sync_creatives, create_media_buy and get_media_buys), and each package of a buy carries its own context. Certification fails if any response leaves its context out or changes it, if the create response or get_media_buys leaves out a package’s context, or if get_media_buys reports the buy without the context it was created with. A number your agent returns as 1.0 instead of 1 still counts as unchanged. While your agent has not accepted or reported the buy yet, or cannot be reached, the check waits instead of failing.
• Developers can now paste an agent’s URL and see what Apostra reads from it before anything is saved. In a Developer account, call save_agent with agentUrl and dryRun: true. Apostra calls the agent’s get_adcp_capabilities and returns the kind the agent declares (sales or creative), its declared sales mode, a suggested name and a list of what you still need to choose. A preview saves nothing and needs no idempotencyKey. Saving an agent by its URL arrives in a later release. Until then, register an agent with a kind and a displayName, which now also takes a salesMode. operator is no longer listed in a Developer account’s save_agent tool schema, and a call that still sends one works as before.

​

5.1316.1 — October 24, 2026 at 4:24 PM UTC

• A media buy that Apostra recorded as completed, without its seller ever reporting it completed, is now checked with the seller whenever you read its campaign status, and can be cancelled. If the seller reports it active or paused, the buy shows that status instead of staying stuck as completed. A completion the seller itself reported still stands.

​

5.1316.0 — October 24, 2026 at 4:06 PM UTC

• Buyer accounts under an organization now share the organization’s domain proof. When an organization’s company identity holds a domain, every account under it that uses the same domain is verified when the organization’s domain is approved or verified by DNS, instead of each account proving the domain separately. An account that already proved the domain keeps that proof, and an account on a different domain confirms its own identity as before. See Buyer setup.
• The GET /api/v2/org-api-keys/widget-token endpoint is no longer available. If your application embeds the organization API key widget, stop calling this endpoint and create an organization key with POST /api/v2/org-api-keys instead. That route can now issue only buyer:read keys. Listing and revoking existing organization keys, and the user API key widget, are unchanged.

​

5.1315.0 — October 24, 2026 at 3:48 PM UTC

• A media buy that was recorded as completed only because its create call completed, with a flight that has not ended, is now read from its seller again, so it shows the seller’s real status (such as paused) and can be cancelled. A completion the seller itself reported, or a buy whose flight has ended, still stays completed.

​

5.1314.0 — October 24, 2026 at 3:24 PM UTC

• Opening your organization, when you sign in, from a bookmark or from the Apostra logo, now takes you to one of its accounts instead of the organization itself, because the work happens in accounts. You go to the account you last used there in this browser, or to your only account there. If the organization has several accounts and you have not used one yet, a page asks which one to open. Organization settings are still under Settings → Organization in every account, and a link to an organization setting still opens it. An organization with no accounts you can open still opens as before. Nothing to change on your side.
• A running buy now stays aligned with the lists you set, even when no one changes a list. Apostra checks up to 50 campaigns with active buys every 15 minutes, so a full pass usually takes about 15 minutes for every 50 campaigns, and never more than about 15 minutes for every 25. If a buy can no longer follow a list, it is paused and you receive a notification explaining what needs attention. You do not need to change anything unless you choose to resume that buy after the list can be enforced again.
• For brand teams, this adds a safeguard that keeps a running campaign within the controls your organization set. For agencies and hold-cos, the same safeguard runs across each client campaign in turn. For hands-on buyers, you can resume a paused buy after the seller applies the list or the product identifies every site and app it covers. If you are new to buying through Apostra, the visible change is simple: a buy may pause instead of running without the list you chose, and the notification explains why.
• For sellers, a buy on your storefront can now pause without a list change when the buyer’s list cannot be enforced on your product. Declaring support for buyer lists, or identifying every site and app in a product, keeps eligible buys running. The re-check also clears a campaign list setting that still points at an archived list and sends you the updated list for that campaign’s live buys, so restoring the archived list later does not quietly add it back to the campaign.

​

5.1313.0 — October 24, 2026 at 3:11 PM UTC

• A Seller endpoint that sells through an ad platform no longer passes an Apostra credential on to that platform. If an agent sends one there by mistake, such as an OAuth token issued for another endpoint, Apostra checks it and refuses it with 401 instead of forwarding it. Ad-platform credentials and Apostra API keys work as before. A key starting with sk_ is first checked with Apostra’s identity provider, and if that check can’t complete the request is refused with 503 rather than passed on.
• A media buy whose flight has ended now keeps the status its seller last reported, and is shown as needing attention if the seller still reports it active or has not confirmed it ended, instead of being marked completed by us. It becomes completed when the seller reports it completed. A buy that ended without ever starting still triggers the “ended without delivering” notice.

​

5.1312.0 — October 24, 2026 at 2:33 PM UTC

• In Settings, the account’s own settings now come first, and the Organization group below them is named after your organization (for example “Organization · Acme”). The Organization group starts collapsed; select its heading to open Accounts, Members, Plan & billing and API keys. It stays open while you are working in one of its pages. Nothing moved or changed access, and there is nothing to change on your side.

​

5.1311.0 — October 24, 2026 at 2:05 PM UTC

• An agent inventory source that belongs to your own organization, or a third-party one that was already live when it was connected, no longer has to go through Partner onboarding to stay live or come back online. It now goes live while its sales agent is certified or exempt and the source’s own health isn’t failing. A new third-party connection still goes through Partner onboarding.
• Product searches and proposal requests now ask a media partner for products only when the advertiser has an active account with it, wholesale browses included. A media partner’s catalog and prices can differ for each advertiser, so Apostra no longer shows a public catalog from a media partner your advertiser isn’t connected to yet. When you name such a media partner, its result is skipped with account_pending (the account is still being set up) or account_needs_attention (someone has to act). Otherwise it is counted in the result’s guidance. In request_proposals, per-seller results no longer carry accountNotice, and a marketplace round with no connected media partner fails with NO_ELIGIBLE_SELLERS and those counts. To see a media partner’s products, get the advertiser an account with it on the Media Partners page.

​

5.1310.1 — October 24, 2026 at 1:38 PM UTC

• A sales agent’s live certification pass now stops counting only when its behaviour baseline shows a current Blocker on a check that can stop buys: responsiveness, async completion, call success rate, honours what we send, account references resolve to one account, or lifecycle agreement. A Blocker on payment terms, idempotent account sync, declarations match behaviour or machine-readable errors still shows on the Agent page, but it no longer takes the pass away. An agent whose pass was withheld only for one of those counts again with no action needed.
• A media buy is no longer marked completed by an hourly sweep just because its flight dates have passed. A buy the seller still reports as active or paused now keeps that status, and its campaign stays open, until the seller reports the buy completed.

​

5.1309.0 — October 24, 2026 at 1:07 PM UTC

• A media buy’s status now comes only from the seller. When a seller’s create or update response states no status for the buy, we show it as pending and read the real status from the seller, instead of treating the finished API call as a finished or live buy. This fixes a paused buy being shown as completed right after it was created.
• Changing a property list can now pause live media buys, so check for paused buys after you change one. A change checks every live buy it reaches: the buy keeps running only if its seller applies each list that applies to it, or the sites and apps its products declare prove the list is satisfied. If neither holds, the buy is paused (reason: "list_not_enforceable") and nothing is sent to it. A seller that doesn’t declare support for a list isn’t a failed update; another route has to enforce the list.
• When you create, archive or delete a list, or apply or clear a campaign’s list, buys whose seller applies the list get the updated list and must confirm it. After a few retries of short transient failures, a buy whose seller rejects the change, doesn’t confirm it, or can’t be reached is paused (reason: "list_update_not_applied"). If a seller queues the change for its own approval, the buy isn’t paused: it keeps running on its previous list and is reported as pending. Replacing a list’s contents sends nothing, because sellers read the list directly, but buys are re-checked against the new contents. If the check can’t run, nothing is sent or paused and the change returns a retryable failure.
• You get a media_buy.list_action_required notification for each paused buy. The response lists buys that were paused, could not be paused (pause_failed), or are pending: in cascadeSummary when you save a property list, and in cascade when you apply or clear a campaign’s list. A pause_failed buy may still be delivering without its lists enforced, so pause it yourself. A paused buy stays paused until you resume it, and resuming doesn’t re-send the list: once its seller can apply the list, save the list again.
• Sellers: a buy on your storefront is paused when your inventory source rejects a buyer’s list change, or when nothing can enforce the buyer’s list on your product. Declaring property-list support, or listing each site and app in publisher_properties, keeps those buys running.

​

5.1308.0 — October 24, 2026 at 12:45 PM UTC

• An MCP endpoint URL written in a different letter case, such as /MCP/V3, now serves the same tools as its lowercase form. It used to fall back to the v2 buyer tools.
• Campaign delivery now loads for buys booked under a seller account.
• When a campaign’s media buy was booked with a hosted seller under one of your advertiser’s accounts there, reading that campaign’s delivery returned “media buy not found” instead of its figures. Delivery now reads the buy under the account it was booked with. Buys booked without an account read exactly as before, and nothing changes on your side.

​

5.1307.0 — October 24, 2026 at 12:16 PM UTC

• On an OpenAI Ads (ChatGPT) media buy, update_media_buy now either applies each field you send or refuses it with a clear error, instead of accepting it and doing nothing. You can now change the flight: end_time at any time, and start_time until delivery begins (after that the update is refused with FLIGHT_START_LOCKED), and get_media_buys reports the flight’s start_time and end_time back. Pacing, frequency caps, new_packages, optimization goals, daily caps and package flight dates are not supported on OpenAI Ads, so a request that carries one is refused with UNSUPPORTED_FEATURE and none of its other changes are applied. Creating an OpenAI Ads media buy now requires a bid_price on the package, because OpenAI Ads has no rate card; a missing bid is refused with BID_PRICE_REQUIRED instead of bidding 1 in your currency. Send the bid you want on every new OpenAI Ads media buy. Existing media buys are unchanged.
• A campaign with more than one OpenAI Ads product now launches one media buy per product, each funded from that product’s budget, instead of failing because OpenAI Ads takes exactly one package per media buy.
• OpenAI Ads delivery now includes a per-day breakdown and states its conversion-attribution settings.
• get_media_buy_delivery for an OpenAI Ads buy returns daily_breakdown for the media buy (and for each package when you ask for include_package_daily_breakdown), with each day dated in the ad account’s timezone, so reporting can book OpenAI Ads delivery day by day. Conversions are counted with a 7-day click window and a 1-day view-through window, placed on the day of the ad event, and the response lists these settings in ext.openai_ads.attribution. OpenAI’s own finality markers (coverage and per-row data_status) are passed through in ext.openai_ads exactly as OpenAI reports them.
• A ChatGPT Ads buy now reports the state OpenAI holds for it: waiting for creative or for its start before it can run, its flight start and end, why a creative was rejected, and the reasons OpenAI gives that something is not serving.
• A ChatGPT ads media buy that fails partway through create_media_buy or update_media_buy now says whether it is safe to try again. A change the platform refused reports not_dispatched. A campaign left behind by a failed create is archived and reported rolled_back. A failed update puts back the budget, targeting, ad group and creative it already changed and reports rolled_back once the platform confirms it. When Apostra cannot confirm what the platform holds, the update reports unknown and asks you to check the media buy before sending anything else, instead of telling you to resubmit.
• Certification now applies Apostra’s tracker checks only to formats that declare a place for our trackers. A hosted video or audio format with an impression-tracker or playback-tracker slot is tracked, so a buy that gets no tracker hits fails. A hosted format with no such slot can’t carry our trackers, so it is judged as a seller-reported buy, on going live and on reports arriving on schedule. Before this, products whose only formats were video_hosted or audio_hosted had no certification family at all.
• An inventory source’s poweredByAgent now shows the Agent behind it, not just its id. When a mapping is active, get({ kind: "inventory_source", include: ["poweredByAgent"] }) returns { state: "ACTIVE", agentId, agent }, where agent is the limited view a seller gets of an Agent it uses: name, kind, certification, implementation health, the public validation skill, and the source it was opened from. It works for an Agent another organization owns, which get({ kind: "agent" }) does not read. The operator is named by display name only; its internal id and claim state are never included, even for an Agent you own. null and { state: "REVOKED" } are unchanged. See “Reading an inventory source: adapter, powering Agent and test runs”.

​

5.1306.1 — October 24, 2026 at 11:18 AM UTC

• Creating or updating an advertiser with a brand domain that no source knows and that has no readable website now returns a validation error on brand that tells you to publish a brand.json or register the brand. It previously returned an internal error (HTTP 500) asking you to contact support. Nothing changes for brands that resolve.
• A ChatGPT Ads creative now reports OpenAI’s review of the ads that use it: approved, rejected with OpenAI’s reason, or still in review, per ad group. Before, it always read as approved, or stayed in review without ever settling.

​

5.1306.0 — October 24, 2026 at 11:07 AM UTC

• The account switcher now labels each organization with its ID, indents that organization’s accounts beneath it, and shows every account’s ID, so accounts with similar names are easy to tell apart. Search also finds an account or an organization by ID. There is nothing to change on your side.
• Seller administrators in the Delete from Apostra beta can now select imported files in Library, or open a connected folder from Integrations, to review and schedule permanent deletion. Apostra shows the affected saved proposals before confirmation, archives the files immediately, and keeps an Undo option for 30 days. Source items stay excluded until an administrator selects Include again.
• Copies already sent to buyers cannot be recalled. This beta capability is available only to sellers whose feature profile enables it and does not change pricing or packaging.
• If you change the reporting timezone your product declares while a certification test buy is running, live certification now counts your reports in the new timezone instead of setting them aside and counting those days as missed. A day already marked missed because its report was in the new timezone is counted once that report matches, against the new timezone’s deadline, and days already judged on a report keep their result.
• OpenAI Ads now accepts the standard audience and device targeting fields. audience_include and audience_exclude name OpenAI custom audiences, including the audiences a campaign maps to the seller, and a campaign with audiences can now launch on an OpenAI Ads seller. device_type (desktop, mobile) and device_platform (ios, android) become OpenAI’s platform targeting, and Apostra refuses a device value OpenAI cannot express (tablet, connected TV, other operating systems, exclusion lists) instead of dropping it.
• OpenAI Ads conversion buys now take their conversion event from a standard AdCP optimization_goals event goal.
• Send one event goal with the pixel’s event_source_id and a standard event_type. Apostra finds the matching OpenAI event setting and refuses the buy, before anything is created, if there is none or the goal asks for something the setting cannot express (a cost target, attribution window, value field or custom event). ext.openai_ads.conversion_event_setting_id still works.
• When a buy has several packages on one product, updates, creatives and delivery now land on the right package even if the seller returns those packages in a different order. Before, a storefront paired the seller’s packages with its own by product and then by order, so two packages on the same product could be swapped, and a package the seller listed without its product could stay locked against updates. Each package a storefront sends a seller’s sales agent now carries the storefront’s own context, { "storefront_package_id": "sf_pkg_…" }, and the storefront pairs packages by the value the seller echoes back. Buyers see no change to their own context. If you run a sales agent, echo each package’s context unchanged on your create response and on get_media_buys, as AdCP requires; agents that do not echo it are paired by product and order as before.
• On a desktop screen, the account switcher at the top of the app now shows much longer organization and account names before cutting them off, so you can see which account you are in. The separate Ask Apostra button no longer appears on organization and Developer accounts: the Apostra logo and Home already open the same chat. Nothing to change on your side.

​

5.1305.0 — October 24, 2026 at 10:39 AM UTC

• Each check in a seller’s readiness read now carries actionLabel, the name of the step in the words the status tool uses for it (get with kind: "seller" and include: ["readiness"], beside action). It is null once the check is complete. Nothing else about the readiness read changes. See “Reading your seller’s setup checklist and go-live state”.
• Agent Registration credentials now work only on /mcp/v3 among MCP endpoints. Every other MCP endpoint, including /mcp, refuses them with 401; connect an agent to those with OAuth or an API key. The HTTP API accepts them as before.
• When a use case on your agent’s Test & certify page, or in the V3 get read of the agent, did not pass, its reason now names the check behind the result and what Apostra saw. Until now, a failed use case often showed no reason. A failed use case gives the first check that failed, for example “The click_fires check failed: No click reached our tracker in 1000 impressions.” An inconclusive one gives the first check that has no result yet, for example “Waiting on the report_cadence check: The seller has not yet produced a decided reporting period.” Use cases that pass, and those that show a skip reason or a creative-approval wait, are unchanged. See How certification works.
• Admins of a buyer organization can open Settings → Organization (Accounts, Members, Plan & billing and API keys) again while they are working in the organization itself. Before this fix, the Organization section and Plan & billing did not appear there, although they did appear from the organization’s accounts. Nothing to change on your side, and nobody’s access changes: the same admins see the same settings they see from an account.
• Advertiser and campaign impression trackers that Apostra places inside a creative’s HTML now also reach Google Ad Manager sellers with their AdCP macros, and the seller’s sales agent converts them when it writes the creative to GAM, as it already does for trackers sent in their own field. Apostra still writes the vendor-scoped consent macro itself for these trackers, because the tracker’s IAB vendor ID can’t reach the sales agent inside HTML. The tracker that fires in GAM is unchanged, and so are the rules for what GAM can’t carry. Nothing to change on your side.
• Buyer Account Mapping now refuses to map a sandbox buyer account to an account that bills, so a test buy can never book real spend. On Apostra’s embedded sales agent, a sandbox buyer account can be mapped only to the agent’s own sandbox advertiser; on any other sales agent, only to an account the agent lists as a sandbox account. The refusal applies whether you choose the account on the page or import it in a mapping feed, where the row is rejected with SANDBOX_ACCOUNT_MISMATCH. Your existing mappings are unchanged, and production buyer accounts can be mapped as before.

​

5.1304.0 — October 24, 2026 at 9:46 AM UTC

• When Apostra pauses a buy, your sales agent must skip packages that have finished (canceled, or past their end_time) and pause only the ones that can still serve. Live certification now checks this on every tracked certification buy. If your agent already does this, nothing changes for you.
• Each tracked buy books two packages: the first flies for one hour, and the second starts five minutes after it ends. Three hours in, once our tracker has heard the buy serve, Apostra pauses it. Your agent must accept the pause, report the buy paused on its next get_media_buys read, and stop serving within the channel’s grace (2 hours for display, 6 for video, audio and CTV; the docs list the rest). After the resume, serving must restart. A refused pause or resume fails the check and shows your agent’s own error code and message. The pause, stop and resume checks run on the first certification buy, so an agent whose buys cannot be stopped is not certified.
• The check counts toward certification from the day it ships, with no report-only period, and Apostra’s own embedded sales agents are held to it on the same terms. A product whose smallest budget is above USD 5 books one package and is not judged on the pause. See How certification works.
• Live certification’s quartile check no longer fails a video or audio use case because our tracker counted a few more starts than impressions. A single lost impression request or doubled start used to fail the whole use case; starts may now exceed impressions by up to 1% before the check reads it as a tracker firing twice.

​

5.1301.0 — October 24, 2026 at 6:51 AM UTC

• Breaking (V3 preview): save_creative and the creative read now name social copy and the click destination for the AdCP slots they fill. In social, body is now primary_text, callToAction is cta and displayName is brand_name; headline and components are unchanged. The top-level clickUrl is now landing_page_url. The old names are no longer accepted, so a call that still sends them is refused. get with kind: "creative" returns the same names, so a read can be saved back unchanged. A creative saved before this change keeps working: its click destination reads back as landing_page_url, and an update replaces it in place. The clickUrlAttached flag on the save result and the creative summaries inside campaign and media-buy reads keep their names.

​

5.1300.0 — October 24, 2026 at 6:25 AM UTC

• V3 now names more of the parties in your data by Account id. open_approvals takes buyerAccountId, the same number as buyerCustomerId, which is now marked deprecated and keeps working. A call that sends both must send the same value. Campaign reads also return sellerAccountIds, the Account ids of the sellers in sellerIds, in the same order. The list is present only when every seller on the campaign resolves. Nothing existing changes meaning, so no action is needed, but new integrations should send and read the Account id names.

​

5.1299.0 — October 24, 2026 at 6:06 AM UTC

• Searching inventory sources can now be paged. search({ kind: "inventory_source" }) returns a nextCursor whenever more sources match than fit in limit; pass it as cursor to read the next page and stop when a page has none. Before this, cursor was accepted for this kind but ignored, so a seller with more sources than limit (at most 200) could not list the rest. A cursor that is not a whole number now fails with INVALID_CURSOR. See “Reading an inventory source: adapter, powering Agent and test runs”.
• test_creative_macros now uses AdCP’s names for macro dialects, mappings and values. This changes the tool’s request and report, which is a breaking change for callers of this V3 preview tool.
• Before, sourceDialect took vendor names such as happydemics, gam and vast, mapping entries used our own field names and status values, and values was a list of {macro, value} pairs. Now:
• sourceDialect is adcp, iab_vast or vendor, or left out so Apostra detects it from the URL’s origin. A vendor names its macro reference in sourceDialectNamespace, such as https://support.google.com/admanager/answer/2376981 for Google Ad Manager, and the report returns the revision Apostra applied.
• Each entry in mappings has AdCP’s fields: token, dialect, dialect_namespace, dialect_revision, dialect_semantic, mapping_status (verified_universal or unresolved) and universal_semantic.
• macro_values replaces values. It is a map from an AdCP universal macro name, such as DEVICE_ID, to a raw test value.
• {CAMPAIGN_ID}, {TRACKING_TAG_ID}, {DATA_SET_ID}, {TACTIC_ID}, {SALES_AGENT_ID} and {ATTRIBUTION_TRACKING_ID} stay accepted in click-URL parameters. They are Apostra extension macros that AdCP does not define, and tool descriptions and errors no longer call them AdCP macros. Only {CAMPAIGN_ID} is filled; the others are never filled.

​

5.1298.0 — October 24, 2026 at 5:22 AM UTC

• Seller administrators in the seller beta can request permanent deletion of an imported Library document. Apostra previews affected saved proposals, archives the document immediately and schedules permanent deletion after 30 days. Undo restores the document during that window, but its connected source stays excluded until an administrator explicitly includes it again.
• For buyers, copies already sent to them cannot be recalled; this seller action creates no new buyer-facing management action or change to those existing copies.
• This is an amc-beta capability, not a separately billable product. It does not change packaging or pricing in this release; beta results will inform whether it becomes a differentiated paid-tier capability at beta exit.

​

5.1296.1 — October 24, 2026 at 2:28 AM UTC

• Delivery from Google Ad Manager sellers on Apostra’s embedded sales agent is recorded again. Since 23 October these sellers report each day in their ad server’s timezone, and we were refusing those reports, so recent delivery for their media buys was not recorded, including the last day of buys that ended in that time. We now read those report times correctly. Buys that are still running pick up the missing days on their next delivery check. Nothing to change on your side.
• The Test Runs Page is retired, and Source Diagnostics no longer lists recent Interchange composition attempts, which duplicated the Demand Inbox. Older conversations that reopen the Test Runs Page now show a notice that the Page is no longer available. To read a source’s latest recorded tests, call get with kind: "inventory_source" and include: ["testRuns"]. Practice-brief runs and buyer briefs are in the Demand Inbox, which search lists with kind: "rfp". A failed sandbox test that Murph runs now opens Source Diagnostics for that source instead of the Test Runs Page.

​

5.1296.0 — October 24, 2026 at 2:04 AM UTC

• A seller account can now read its Product marketing counts in one call. Call get with kind: "seller" and include: ["teaching"] for claimCount (selling points teaching the agent), gapClaimCount (selling points your live inventory does not back) and lastVerdictChangeAt (when a result last changed, or null if none has). A seller outside the Product marketing cohort gets ACCESS_DENIED, never a count of zero, and if Apostra cannot read the counts the call fails with SERVICE_UNAVAILABLE. Nothing appears unless you ask for it, so existing calls return what they did before. See “Reading your seller’s Product marketing counts”.

​

5.1295.0 — October 24, 2026 at 1:04 AM UTC

• The source diagnostics view now shows each source’s own latest tests. It used to list the eight most recent tests across the whole account and pick out a source’s from those, so a source that had not been tested lately could read as untested. It now asks for each source’s latest five tests directly. The Apostra adapter, the powering Agent and the web app’s source list still read from the older storefront calls.

​

5.1294.0 — October 24, 2026 at 12:25 AM UTC

• Certification now includes a lifecycle agreement check for your sales agent. For each buy, get_media_buys and get_media_buy_delivery must report the same status, and a buy must not read active while every package that can still serve is paused. A disagreement that lasts more than 15 minutes is a flag. A second one within seven days is a blocker. The check applies from the day it ships, with no report-only period, and Apostra’s own embedded sales agents are held to it on the same terms. If your agent reports status from more than one place, make sure both tools agree.
• Blockers do not hold anything yet: stopping new buys on blockers is not switched on for any developer account. When it is switched on for yours, a blocker holds new buys only, and running buys are never stopped. The Agent page shows the evidence for each disagreement, and How certification works explains how to fix it.
• Live certification now includes a “spend stays within the budget” check on the certification buy, so your sales agent has to keep spend inside the package budget it accepted. To pass, make the ad-server objects behind a package unable to spend more than the package budget together. If you cannot cap a package, refuse or pause it and say so with an AdCP status or error. For a buy booked on a fixed USD CPM (pricing_model: "cpm" with a fixed_price), Apostra prices the impressions its own tracker counts at that CPM. Spend above the package budget plus 20% fails the use case; spend within it passes once the tracker has seen the buy serve. Certification buys are capped at USD 10. Buys on any other pricing or currency are not judged, and the check never stops a buy that is running. It applies from the day it ships, with no report-only period, and Apostra’s own embedded sales agents are held to it on the same terms. See How certification works.
• On a storefront that sells through its own sources as well as a connected sales agent, a new agent inventory source now stays pending until the agent passes Apostra’s account check on your credential. The check confirms the agent accepts the account request Apostra sends when you approve a buyer. Apostra runs it daily until it passes, so the source never goes live unable to take your buyers’ accounts. Sources that are already live keep running.
• When a seller goes live on a buy, or moves it back to pending, the buy’s status now follows within minutes of the seller’s change notice. Before, a buy whose seller had changed it could keep its old status until the next twice-daily check, up to about twelve hours later. The first time a seller reports a live buy with no delivery yet, we now ask the seller for its current status first, instead of relying on the answer from the previous check. Nothing to change on your side. Buys from sellers that do not send change notices are still checked on the same schedule as before.
• A pause or resume that the seller refuses, or applies only in part, now leaves a record and is re-checked sooner. Every such attempt appears in the media buy’s activity log as a failed attempt, with the seller’s code and message. Apostra also asks the seller for the buy’s state straight away, so a pause the seller did apply shows as PAUSED within minutes instead of at the next scheduled check. The error keeps its 503 SERVICE_UNAVAILABLE status and now also carries the seller’s own code in details.code, what the seller said about retrying in details.seller_recovery, and the seller’s wording as the message and suggestion. On /mcp/v3, save_media_buy answers a refusal the seller calls correctable with VALIDATION_ERROR and a final one with CONFLICT.

​

5.1290.3 — October 23, 2026 at 9:30 PM UTC

• A registered Partner standing no longer counts as joining the partner program until it is active, whether it was created by connecting your own agent to your own storefront or by registering as an agent developer. Organizations on the Listing plan that were refused when they created or restored an account because of it can add accounts again.
• When you save a V3 VAST creative, undeclared text slots now return an error before the creative is saved. Send the tag as a typed VAST asset at vast_tag instead.

​

5.1290.2 — October 23, 2026 at 8:57 PM UTC

• Correct buyer-facing campaign pacing and archive response descriptions, including the pacing application note, so they match the product.

​

5.1290.1 — October 23, 2026 at 8:27 PM UTC

• Prevent staged inline media-buy batches from opening seller discovery.
• Fixed syncing legacy VAST tag URLs stored in the video_url text slot.

​

5.1290.0 — October 23, 2026 at 7:51 PM UTC

• Proposal requests to hosted storefronts reached through a pass-through source now present the buyer’s authorised account, so they are no longer refused.
• A pending budget decrease no longer frees campaign headroom until the seller confirms it.

​

5.1287.0 — October 23, 2026 at 6:41 PM UTC

• save_campaign now pushes a targetingOverlay.geo_countries_exclude/geo_regions_exclude change through to already-live media buys, the same way it already does for geo inclusion. This includes removing an exclusion: saving a targetingOverlay that no longer lists it, or clearing the overlay with null, now clears the exclusion on the live media buy too. Previously, changing a geo exclusion on a campaign with live media buys was accepted and stored, but never reached a live buy’s packages, so sellers that support post-launch geo exclusion (OpenAI Ads) never received the update.

​

5.1286.0 — October 23, 2026 at 6:08 PM UTC

• Paired-redirect tags (for example CM360 Internal Redirect) now reach managed sales agents that speak AdCP 3.2, instead of being refused.
• Campaign reads, search results, and review receipts now label flight windows in the advertiser timezone and UTC. Flight dates now include the year. Delivery summaries identify UTC date ranges.
• When a seller refuses to cancel a media buy outright, Apostra no longer sends the same cancellation to that seller again in the background, and you can send the cancellation again straight away. When you cancel a media buy the seller no longer has, the cancellation is not sent again either. Temporary failures are still retried, after the wait the seller asks for. Nothing changes in the response you get when you cancel, and there is nothing to change on your side.
• Saving a campaign with postal-area targeting while it holds an OpenAI Ads media buy is now refused with a clear error, instead of being stored and never applied. OpenAI Ads does not yet support postal-area targeting, so the saved targeting used to look accepted while the live media buy kept its previous geography.
• A creative that is approved, rejected or returned to review now appears in the account change feed (list_account_changes) and rings the account.change_recorded notification, whoever made the change: the AI review, a seller’s decision, or your own sync. Hosts that subscribe to creative.status_changed now receive it for each of those changes.
• When you reject a media buy and Google Ad Manager refuses to release its booking, or can’t be reached, the reject now returns a clear ad-server error that includes GAM’s reason, not a generic server error. Nothing is recorded, so you can fix the cause in GAM or wait, then reject again.
• Google Ad Manager products and delivery reports now use the network’s reporting timezone, so daily totals align with the calendar-day boundaries buyers receive.
• A managed GAM buy that targets one audience signal together with a group of others (an interest plus a set of age bands, say) can now be booked. It used to be refused when the seller’s ad server kept those signals under one targeting key, which is how publishers using a single DMP segment key are set up.
• A sandbox buy that names its account by brand and operator no longer fails as ambiguous when the seller also holds its own account with the same brand and operator; the buy uses the account the buying agent has access to.
• Reopen a completed media buy only after every seller accepts its approved budget increase, reports it active, and the flight is still in progress.

​

5.1285.0 — October 23, 2026 at 3:07 PM UTC

• If your company’s Seller account hasn’t been set up yet, an administrator who signs in with a work email on your company’s domain now gets in straight away. Sign-in finishes the setup, the same way signing up as a new Seller does, and asks you to accept the current Terms of Service if you haven’t. Other members still see that the account isn’t set up yet, and our team is told.
• When a seller refuses a media buy update outright, Apostra no longer sends the same update to that seller again in the background. Temporary failures are still retried, after the wait the seller asks for. Nothing changes in the response you get when you send the update, and there is nothing to change on your side.

​

5.1284.3 — October 23, 2026 at 2:47 PM UTC

• If your company’s Seller account isn’t set up for sign-in yet, signing in now says so instead of showing the Buyer “Request access” form, and flags the account to our team. You don’t need to submit anything.

​

5.1284.2 — October 23, 2026 at 2:28 PM UTC

• Video creatives now match seller products that offer several durations of the same VAST format. The duration read from the creative’s own asset is what chooses between them, so a 15-second and a 30-second ad each resolve to the option that fits. Previously only a duration typed in by hand was considered, so creatives measured on upload were treated as having no duration at all, could not be told apart, and were dropped from the media buy — which then could not be executed.

​

5.1284.0 — October 23, 2026 at 1:46 PM UTC

• Signing up for a Developer account now works when you sign in with Google or single sign-on first and then choose “Build agents (Developer)”. Previously that path was refused with “Buyer account signup is not currently available”, because the Buyer signup check was applied to a Developer signup.
• Campaign creation receipts now show the resolved IANA timezone, and launch previews show the advertiser’s current default with local and UTC flight windows. If that timezone is unavailable, preview continues with a labelled UTC window. This affects buyer-side campaign tooling only; sellers are unchanged.

​

5.1283.0 — October 23, 2026 at 1:27 PM UTC

• save_creative’s typed social fields (headline, body, callToAction, displayName) now reach a pinned creative format that names its slots differently than AdCP’s own defaults, as long as exactly one of the format’s declared slots matches a known spelling for that field (for example OpenAI Ads’ body_text for body). Previously, authoring against such a format with the typed fields always failed, with no way to supply the content through them at all; the social.components workaround still works unchanged. When a format’s slot names cannot be resolved this way, the rejection now names the format’s own declared slot IDs and suggests social.components instead.

​

5.1282.0 — October 23, 2026 at 1:03 PM UTC

• A creative pinned to a seller’s own declared format option — such as an OpenAI Ads chat card’s headline, body text, and landing page URL — now syncs with those fields intact. Previously outbound creative sync resolved the text/url slots from the generic canonical format only, so a format option that names slots the generic kind doesn’t declare had them silently dropped before the creative reached the seller, which could cause the seller to reject the media buy. Launching a campaign whose seller dispatch fails transiently now tells the buyer it will be retried automatically instead of inviting an immediate manual retry, which previously collided with the pending automatic retry and surfaced as a confusing “already in flight” error.

​

5.1281.0 — October 23, 2026 at 12:32 PM UTC

• Organizations still reviewing the updated Terms of Service can keep using Apostra through 31 October 2026. Acceptance of version 4.1 becomes required on 1 November 2026 at 00:00 UTC.

​

5.1280.0 — October 23, 2026 at 12:08 PM UTC

• search/get kind: "creative_format" now shows the character and file-size limit on a slot even when the seller’s declaration doesn’t explicitly author that slot — the same limit save_creative already enforces is now visible before you try a save.
• The Organization IU Rate Card guide no longer says that placing a buy is free. It now says each Apostra media buy is charged in IUs for each billing period in which it is active, and links to the activity schedule for the rate and the rules on when a buy counts.

​

5.1279.0 — October 23, 2026 at 11:33 AM UTC

• V3 buyers can use the advertiser selected in the Campaigns Page workspace when creating a campaign and can send a flight.timezone for naive local flight times. Existing calls that provide an advertiser and offset-bearing flight times behave the same.
• You can now rename a live Pinterest, Google Ads, LinkedIn, Reddit or Spotify media buy by sending name with the buy’s ID to save_media_buy on V3. The new name takes effect only once the platform confirms it. If the platform refuses the rename, or we can’t confirm it, the buy keeps its current name and you get the same errors as a Meta, Snap or TikTok rename. The V2 media-buy update follows the same rules, instead of returning “Renaming isn’t supported for … yet”. Renaming an Amazon or OpenAI Ads media buy is still refused, and nothing changes.

​

5.1278.1 — October 23, 2026 at 10:59 AM UTC

• A creative added to a media buy while the seller is still reviewing it now reaches the seller before the buy does. Before, once the seller approved, the seller’s system could refuse the buy because it had never received that creative, and the buy did not go live. Now the creative is sent to the seller as soon as it is added, and an approved buy waits until the seller has it, usually a minute or two. Nothing to change on your side.

​

5.1277.0 — October 23, 2026 at 10:05 AM UTC

• OpenAI Ads media buys now reject geo targeting that includes a region or Nielsen DMA already covered by an included country (for example, country Australia plus region Tasmania), instead of silently accepting it and serving across the whole country with no narrowing. Remove the broader or narrower location so only the one you mean is included.
• Explain when an uploaded wholesale pricing feed matches no products, and direct sellers to the pre-filled template that corrects its selectors.
• Campaign-scoped creative saves now queue durable seller delivery, so delivery continues after a request completes and is visible through the media-buy operation read.

​

5.1275.0 — October 23, 2026 at 9:04 AM UTC

• Buyers can duplicate a visible canonical campaign creative through save_creative. Retrying the same idempotency key returns the same copy; a different request with that key is refused. Copies do not include seller delivery state or managed-source identities, and sellers receive the copy through the normal delivery flow only once. No customer action is needed.

​

5.1273.0 — October 23, 2026 at 8:37 AM UTC

• Omitting libraryRole leaves a creative’s role unchanged; existing calls behave as before.
• Set libraryRole on save_creative to mark an existing creative as evergreen or reference.
• Evergreen creatives stay deliverable. A reference creative stays in your creative library for reuse, but it can’t be attached to a campaign or media buy, and a creative already attached to delivery can’t be set to reference. The call refuses both with VALIDATION_ERROR.
• save_creative is idempotent when you set libraryRole: idempotencyKey is required with that field and optional otherwise. Repeating the call with the same idempotencyKey returns the same result, and reusing it with a different payload is refused.
• Sellers see nothing new. Reference creatives are never sent to them.
• Allow V3 to stage a separate new media buy on an active campaign.
• OpenAI Ads media buys now apply geo exclusions (geo_countries_exclude, geo_regions_exclude, geo_metros_exclude) instead of silently dropping them — a campaign that excludes a country, region, or metro will no longer serve there. Requesting the same location as both included and excluded is now rejected with a clear error instead of being accepted. Any other targeting dimension OpenAI Ads doesn’t support is also rejected up front instead of being silently ignored.

​

5.1271.0 — October 23, 2026 at 7:31 AM UTC

• Clarify that Apostra does not grant buyer credit lines or block buys based on an Interchange credit limit.
• V3 get_seller_reporting_receipts now declares buyerAccountId as the required buyer field in params and buyerCustomerId as optional, and V3 open_campaign_receipt declares sellerId as optional on each media buy, so read sellerAccountId. Both responses still return the old fields today; the generated OpenAPI document and SDK types match. The chat widgets also now name sellers, buyers and creative engines by their Account ids, with no change to what they show.

​

5.1270.0 — October 23, 2026 at 6:46 AM UTC

• Clarify that campaigns can launch before creatives are ready, while delivery waits for a compatible creative.
• Clarify that creative rejection reasons are Apostra-authored summaries, not seller free-text notes.
• Clarify how Apostra confirms pending update_media_buy changes when a source supports task polling.
• Clarify that media-buy status reads continue polling buys in the ENDING state.
• Creatives attached to campaigns now reach sellers even if a delivery attempt fails right after saving; delivery retries automatically.
• save_campaign now pushes a targetingOverlay.geo_countries/geo_regions change through to already-live media buys, the same way it already did for the legacy constraints.geo_countries/geo_regions field. Previously, updating a campaign’s canonical targeting overlay was accepted and stored on the campaign, but never reached a live media buy’s packages, so sellers that support post-launch geo targeting changes (OpenAI Ads, Meta) never received the update.
• Creating a creative for a seller format that needs more than an image or video — such as an OpenAI Ads chat card’s headline, body text, and landing page URL — now shows those fields in the Creative Library’s inline creator and saves them with the creative. Previously the composer only ever asked for an image or video, so a buyer had no way to complete a creative for a format that also required text, and had to fall back to a format that didn’t match the product.
• Clarify that the media-buy lifecycle has eight documented status values, including ending.
• Webhook-signing readiness now records invalid RFC 9421 callbacks sent to a sales agent’s own callback URL.
• Successful wholesale-pricing uploads now appear in the Changes activity feed. Each record identifies the source, who committed it, row counts, selector-match summary, and effective window. No action is required.
• Refuse V3 media-buy creates for products already owned by a draft buy.
• Warn buyers when V3 media-buy staging proportionally reduces product allocations to fit a campaign’s remaining budget.

​

5.1268.0 — October 23, 2026 at 5:01 AM UTC

• Make repeated V3 media-buy create requests report their original result instead of a misleading empty creation success.

​

5.1267.0 — October 23, 2026 at 4:35 AM UTC

• Show the latest seller creative delivery result in campaign workspaces.
• If your organization has accepted a paid IU plan, it is billed under that plan’s terms with no separate enrollment, and there is nothing to change on your side. A plan’s monthly commitment is charged at the start of each monthly period, usage beyond the plan is billed after the period, and each closed month’s fee invoice appears on Plan & Billing. Organizations paying by card are charged automatically; invoiced organizations receive the invoice instead of a card charge.
• Switching plans in the middle of a billing period is not self-serve when either plan has a monthly commitment: contact Apostra and its staff will make the change.
• A creative that permanently fails local format validation (for example, an image attached to an OpenAI Ads product that only accepts native_in_feed) now blocks launch with a clear, actionable message naming the creative and the reason, instead of being silently treated the same as a creative that simply hasn’t synced yet. This applies to every seller whose platform reviews creatives only after launch (Meta, Snap, Reddit, Spotify, Amazon, OpenAI Ads).
• Update and archive advertiser-level creatives through save_creative without supplying a campaign.
• The Apostra CLI guide now says plainly that the CLI isn’t on npm yet. Until it is, use an API key or an M2M credential for scripts.
• An organization whose certified sales agent belongs to one of its Developer accounts is no longer refused the right to serve other sellers. The check now looks for the agent’s claim, registration and certification on the Developer account that owns the agent, as well as on the organization itself. Agents owned by unrelated accounts still do not count.

​

5.1266.0 — October 23, 2026 at 3:37 AM UTC

• request_proposals no longer refuses a correct expectedSellerAccountId (or the older expectedSellerId) for an ordinary buyer. The fail-closed check previously only recognized a narrow seller-sponsored buyer scope, so it rejected the field for every other buyer even when the named seller was exactly who the request reached. It now checks the field against the buyer’s actual resolved seller cohort for the round, and still refuses the request when that cohort doesn’t resolve to exactly that one seller.
• A buyer can now launch an OpenAI Ads campaign before a creative is ready, the same way Meta works today: the campaign and its ad group are created paused, and the ad is created once a creative is synced and attached with update_media_buy. Before, create_media_buy required exactly one already-synced creative and refused the whole buy without one, even though the launch preview reported no blocker. Activating a package with no creative yet is refused with a clear, correctable error naming the package, instead of a confusing platform-level failure after confirming launch.

​

5.1265.0 — October 23, 2026 at 3:18 AM UTC

• Run apostra login (or npx @apostra/cli login) once on your own machine, approve one account in the browser, and Node.js scripts that use @apostra/sdk call the V3 API as you, with no API key in your code or environment. This applies to the TypeScript SDK in Node.js only. Sign-in needs a server update that ships separately; until it is live, apostra login stops with an error and stores nothing. The sign-in acts only on the account you approve (sign in again to use another), requests read and write access unless you pass --scope, and stays valid for 30 days after its last refresh, so a script you run at least monthly stays signed in. After 30 idle days, run apostra login again. apostra status shows the account and scopes, apostra token prints the access token, and apostra logout revokes the sign-in on the server and deletes the local copy. The SDK uses the sign-in only when no explicit credential and no APOSTRA_API_KEY is set, so it never overrides what you already use; CI and servers should keep using an API key or an M2M application’s access token. No action needed: existing API keys, M2M credentials and scripts work exactly as before. See the CLI guide in the V3 docs.
• When live certification doesn’t count one of your seller reports, the report check now says why: the report couldn’t be read, it left out the buy, its reporting period or finalization date wasn’t valid, or its period isn’t one of the product’s reporting periods in the timezone your reporting_capabilities declare. Before, those reports were dropped without a reason, which made a timezone mismatch look like a missing report.
• Connecting a sales or creative agent from the Developer home now works: the “Operated by” list loads instead of showing “Could not load operators”, so the Create Agent button is no longer stuck disabled. The Task is now titled “Connect an agent” and says it registers an agent you already run. get_status lists the certification page once, as what_is_certification; the separate certification entry in resources is removed, so read the page from what_is_certification.
• Your own preferences now live on one page: choose Your preferences in the menu behind your initials (it was called Account settings). It holds the language the assistant replies in, whether you receive Apostra product updates, your notification preferences and your profile. Settings in the left rail now holds only account and organization settings, and opens at Account members (at the organization’s Members when an organization administrator opens it in the organization itself). An administrator’s default for sharing new conversations with teammates moved to Settings → Account configuration. A language you pick applies to new chats; a conversation you already started keeps its language. Older links to chat preferences or notification settings open the new page. Nothing to change on your side.
• OpenAI Ads products no longer carry a floor_price of 0.001 on every pricing option. That value was a placeholder authored once in USD and applied to every account currency, never a real floor from OpenAI Ads. Products still carry their real pricing_model and currency; a buyer’s agent now sees that these products are auction-priced with no price guidance available, instead of a fixed rate that implied far more delivery than a real bid would buy.
• In beta: when your agent or API client searches or gets your media buys, each buy now says whether what your ad server holds still matches what you agreed with the buyer. If a budget was raised, a flight date moved, targeting changed or a rate edited in your ad server, the buy comes back as out of line, with what was agreed shown next to what your ad server reports. The data behind the Media Buys list also flags those buys for attention and ranks budget, rate and flight differences first, but the Media Buys page does not display any of this yet. Apostra never changes your ad server to match the agreed terms, because the change may be intentional; you decide whether to put it back or agree the change with the buyer. Anything your ad server doesn’t report from its own records shows as “not comparable” rather than in line, and creatives are not checked yet. Nothing to change on your side. Agreed terms check.
• Managed ad-server buys now check targeting before seller approval. Buyers see a safe reason when the selected targeting cannot be represented, and sellers avoid approval items that cannot be delivered.

​

5.1264.0 — October 23, 2026 at 2:23 AM UTC

• Campaign creative delivery status now reflects the latest attempt for each seller route.
• Accepting or switching a plan now sets your account to that plan’s profile in the areas it covers, even if Apostra staff had granted you a different profile by hand in one of them. Before, such a hand-granted profile kept outranking the plan you accepted. Renewals, time-limited betas and grants made after the plan takes effect are unchanged. See Plan & Billing for details.
• Products from a seller’s managed sales agent now show buyers the targeting the seller’s ad server supports, unless the seller has narrowed a product’s targeting themselves. Bookings on these products are held to that targeting, the same as for a product with its own declaration. Until now, buyers saw no targeting on these products and booking targeting wasn’t checked against them. Each product picks up the change the next time the seller’s catalog refreshes. Products the seller has narrowed, and products from other sources, are unchanged.
• a request naming an account you can’t reach is now refused instead of served from your home account
• LinkedIn product listings no longer include the deprecated execution_context in a product’s brief strategy. Read the same assisted-execution inputs from execution_package_ext, or from the execution package template’s package.ext, which is where a LinkedIn create reads them. A LinkedIn create never reads them from context, so copying execution_context into a request had no effect.
• Deprecation: from 6 November 2026, a context.campaign_name no longer names an ad-platform campaign. When you place a media buy directly with an Apostra ad-platform storefront over AdCP, send the buy’s name in AdCP’s name. Until then, a context.campaign_name sent without a name is still used; after that date a buy with no name is named {brand} × {storefront}. Buys placed through an Apostra campaign are named after that campaign. Your context is always echoed back unchanged.

​

5.1263.1 — October 23, 2026 at 1:35 AM UTC

• Apostra emails now show Apostra Inc.’s own postal address — 228 Park Ave S, PMB 24984, New York, New York 10003 — in the footer. It previously showed Scope3, PBC’s address, which did not match the one in our privacy policy.
• A product priced only with your own fixed price in a currency other than your storefront’s settlement currency now says it is priced in the wrong currency, instead of asking you to upload pricing. The product stays hidden from buyers until a fixed price in your storefront’s currency is set.

​

5.1263.0 — October 23, 2026 at 1:16 AM UTC

• Settings for a Developer account now lists only what applies to an account that owns agents. Connections, Single sign-on and the other buyer and seller sections no longer appear, so you stop hitting “Access denied” and “Verify your brand domain first” errors there. Notifications offers only Sales agent alerts, not campaign, creative, audience or optimization ones. Nothing to change on your side; chat preferences, members, API keys, billing and support stay where they were.
• The agent’s Test & certify page now shows the certification exemption date as the day Apostra set, such as December 1, 2026. Before, a viewer in a time zone behind UTC saw the day before, such as November 30.
• Fixed the selectedAccount field on a storefront connection read (REST, MCP V3 get/save_connection) so it always shows the account’s current mapped advertisers and Enhanced Reporting eligibility. Previously selectedAccount could show no mapped advertiser and Enhanced Reporting as ineligible even right after a successful mapping, while the same response’s accounts[] list showed the correct, mapped, eligible state for that same account.
• Reddit buys on an ad account with several Pixels no longer stop to ask you which Pixel to use. Reddit requires a Pixel on every ad group, and Apostra now uses the account’s Pixel with the lowest ID; an account with one Pixel still uses it. Reddit campaigns don’t optimize toward a Pixel yet, so the choice doesn’t change how they are optimized. A context.conversion_pixel_id is no longer read: context is your own correlation data and is echoed back unchanged.

​

5.1262.0 — October 23, 2026 at 12:07 AM UTC

• a bid sent with a fixed-price option is now refused on every path, instead of silently ignored when staging
• Connecting your own agent to your own storefront no longer counts as offering agents to other organizations while its Partner standing is inactive. Organizations on the Listing plan that were refused when they created or restored an account because of it can add accounts again.
• A managed source no longer shows as degraded with “Signal updates have not refreshed buyer discovery recently” when only an old buyer-account cache entry is stale. Source health now follows the shared catalog that buyers actually discover from, so it still flags a source whose shared catalog has genuinely gone stale. Nothing to change on your side.
• Apostra now checks, without a buy, whether a sales agent connected to your storefront accepts the account request it sends when you approve a buyer. This applies to every agent inventory source on a storefront that sells through its own sources as well as the agent, including one still waiting to go live. It runs whether or not the agent’s developer asked for certification: daily until the source passes, then weekly. A failure shows on that source’s health.

​

5.1261.2 — October 22, 2026 at 11:28 PM UTC

• A Developer account’s left rail now switches between Agents and Settings instead of showing a Campaigns segment, since developers own agents and have no campaigns.
• Document the five-minute campaign flight-start clock-skew allowance.

​

5.1261.1 — October 22, 2026 at 10:41 PM UTC

• the approvals docs now say that an approval override never skips a platform safety hold, which always goes to a person

​

5.1261.0 — October 22, 2026 at 10:21 PM UTC

• Sellers that declare paired_redirect receive the third-party ad-request and click URLs as an AdCP display_tag pair.

​

5.1259.1 — October 22, 2026 at 9:13 PM UTC

• Show every reconciliation reason when a media buy needs buyer reconciliation, including marked creates and targeting updates.
• Operator views now describe managed-source unsupported-targeting failures without changing the V2 API contract.
• Completed media buys return to active when an approved extension is accepted and the seller confirms active delivery. Budget-only corrections and terminal buys remain closed.

​

5.1259.0 — October 22, 2026 at 8:28 PM UTC

• Replacing selections on a running campaign is refused, as documented, and budget conflicts return 409.
• Prevents reporting time-zone preferences from changing after an advertiser has a campaign or linked seller account, including when no preference was set previously.
• Approved private modular source tests now retain the exact reviewed product identity, including products composed from the confirmed inventory, through no-spend campaign verification while the Storefront remains paused. Ordinary buyers and public listings remain blocked, and no seller action is required.
• refine_proposals guidance now says plainly that it records your decision and doesn’t contact the seller.

​

5.1258.0 — October 22, 2026 at 6:39 PM UTC

• For live GAM buys, get_media_buys now reports a package’s signal_targeting_groups as GAM holds them and declares the field read in ext.scope3.live_fields, so a signal a seller removed or changed in GAM shows up; when GAM’s targeting does not translate exactly to the seller’s signals, the field stays as booked.
• A pause or resume made directly on a Google Ad Manager line item now shows in ESA within about 15 minutes. Each package reports whether its line item is paused, the storefront is told of the change through the account change feed, and get_media_buys and get_media_buy_delivery report the same buy status. When an update is only partly applied or refused, ESA now records the line items the ad server did pause and what it holds for the rest.
• Media buys on Google Ad Manager now report each package’s budget, pacing and flight counting every line item that can spend for it, including line items added in Google Ad Manager. A package that Google Ad Manager does not cap at its accepted budget is reported as such, cannot be approved or resumed, and is paused automatically.
• Archiving a creative with sync_creatives delete_missing now also stops it serving on Google Ad Manager. If the ad server could not confirm the removal, or the seller’s ad server cannot remove creatives, the creative’s result says so (error code removal_not_confirmed or removal_not_supported) instead of reporting the archive as complete.
• For a creative running on more than one media buy, the sales agent now checks each buy’s line items for the ad-server creative that buy carries. A creative that failed to reach one buy’s line item is pushed again instead of being skipped. Media buy reads show that creative under its own id instead of the raw ad-server id. A buy serving its own copy is no longer flagged as serving a creative the sales agent did not assign.
• Live certification buys now carry a small amount of real traffic on a seller’s Google Ad Manager network. A no-cost sandbox test buy is trafficked as a zero-rate STANDARD line item at the lowest STANDARD priority (10) with a hard goal of 300 impressions, instead of a HOUSE line item that only serves when nothing else matches. It serves ahead of price-priority and house lines until it has delivered 300 impressions, then GAM completes it, so a publisher’s paid lines give up at most 300 impressions per test buy. Test buys placed before this release keep their old line item; place a new one. After this release the GAM write canary reads stale on each network until it is re-run.
• Pausing or resuming a Google Ad Manager buy that has a finished line item now succeeds for the line items that can still serve, and a buy whose remaining line items are all paused now shows as paused.

​

5.1257.0 — October 22, 2026 at 6:02 PM UTC

• Your left rail now works the way a seller’s does. A two-segment switch at the top moves between Campaigns — every destination the rail already carried — and Settings, which was a row at the bottom of the rail. Your chats sit in their own panel below, so the list stays the same size and in the same place whichever segment you are on, with New chat and the control that collapses the rail beside them.
• Default storefront creative sync assignments now send each creative only to packages whose booked product accepts its format and size. When a booked package has no canonical or seller format declaration, implicit assignment is refused rather than sent for seller adjudication. Buyers receive a clear validation failure when no package fits, and sellers no longer receive incompatible creative-package bindings.
• The Library now reads as one surface. A document shows where it is in a single lifecycle — Processing, Draft, Live or Archived — and a document the Library could read only in part stays Live and says Needs attention beside it, with Try reading again in the row’s own menu and a Needs attention filter that lists every one of them. Documents are one flat list you narrow with filters rather than category sections, with sortable Name, Type and Updated columns, a select-all in the table header, and bulk actions that name their count (Apply to 3 documents, Archive 3 documents). Opening a document takes over the surface with its preview beside its details, and adding a file confirms itself with a message that clears on its own.
• If your storefront passes buyer requests through to your own sales agent and you haven’t confirmed your markets, your Listing now shows the markets Apostra assumes for you, the same ones buyers see, and asks you to confirm them. Choose Edit under What you do to review them: the form starts from your assumed markets, with Everywhere selected if no country is assumed. Saving confirms them as your own. The storefront read also returns marketsConfirmed, which is false while your markets are assumed.
• Completed media buys now return to active when a seller accepts an end-date extension that puts the flight back in progress and reports it active. Historical corrections remain completed. Nothing to change on your side.
• Your left rail now stays the way you leave it. Open or close a section and that choice is remembered on this browser, instead of snapping back to our defaults every time the page reloads. Once your storefront is live, every section also starts open — before you are live they still tuck away so the setup steps stay the focus. A section holding whatever you are currently looking at is always shown, whatever you last chose for it. The rail reads more cleanly too: the arrow that opens a section holds one place instead of shifting when the search and add buttons appear, the line under an inventory source is quieter, and a storefront still being set up shows that in colour rather than grey.
• AdCP buyers who call update_media_buy on a Spotify storefront can now rename the media buy: the Spotify campaign is renamed, and the update succeeds only once Spotify shows the new name. If Spotify refuses the rename, the update returns an error and the campaign keeps (or gets back) its old name. If the rename can’t be confirmed, the update returns an error; check the campaign’s name before retrying. A blank name, or one longer than 255 characters, is refused before anything is sent to Spotify. Renaming Spotify media buys through Apostra’s API will follow once it is enabled for Spotify.
• Creative reads now show each creative’s status and approval in AdCP’s terms (such as pending review, approved, or archived), alongside the existing fields. Archived creatives can now be opened by ID and found with an archived filter. Nothing changes for existing fields.
• When you search one campaign, statuses: ["approved"] returns its currently active approved creatives. statuses: ["archived"] returns its archived creatives, including ones whose campaign link is no longer active. Combining them, for example statuses: ["archived", "approved"], returns both sets for that campaign.
• The top-level status combines approval decisions from each platform. A partly approved creative is shown as pending review, so that top-level value does not say that some platforms have already approved it. A request for changes is shown as rejected, so it does not say whether the platform rejected it outright or requested changes. The existing per-platform raw approval value remains available for that detail.
• Later follow-up work will add duplicate date and revision aliases, the save action in AdCP terms, and the stored-data migration; they are not part of this release.

​

5.1256.1 — October 22, 2026 at 4:03 PM UTC

• Connect buttons in the Apostra web app no longer fail with “The host blocked the account authorization link” when your browser blocks the new tab. A notice now appears with an Open link button, and selecting it opens the authorization page. After you finish authorizing in the other tab, the Media Partners widget reloads its connections when you return to the original tab, so a new connection shows up and an old error clears without a manual refresh. Nothing to change on your side.

​

5.1256.0 — October 22, 2026 at 3:09 PM UTC

• When a marketplace proposal round leaves out a media partner that is on for your advertiser but cannot be booked right now, the request_proposals response now names it in skippedSellers with the reason not_transactable and a skipCode saying why (for example go_live_blocked). Before, that media partner was left out of the round without being listed. Media partners that are off for your advertiser are still only counted, not listed. Nothing to change on your side; check skippedSellers to see every media partner a round did not ask.
• The TypeScript and Python SDK example journeys now start by finding your campaigns instead of listing inventory sources. Inventory sources belong to seller accounts, so the first step failed with WRONG_ACCOUNT for the buyer account the journeys read delivery for.
• When Spotify rate-limits a change to a live Spotify media buy, such as a budget, date, or pause change, Apostra now waits and tries again, honouring the wait Spotify asks for, instead of failing on the first rate-limit answer. Apostra spends at most about the first minute of the update waiting; if Spotify is still refusing after that, or asks for a longer wait, the update fails with a rate-limit error and Apostra tries to undo any partial change, as it does today. Creating a Spotify media buy is unchanged. Nothing to change on your side.

​

5.1255.0 — October 22, 2026 at 1:49 PM UTC

• The agent’s Test & certify page now shows “Exempt from certification until” and the date when Apostra has exempted the agent from certification. The page shows nothing extra when the agent has no exemption or the exemption has ended.
• Launching a media buy with property lists, the advertiser’s or the campaign’s own, now refuses any product that nothing enforces those lists on, instead of buying it unchecked. For each product and each list that applies, the seller must apply the list (it declares support and receives the list reference with the buy), or the sites and apps the product declares in publisher_properties must be enough to confirm the list is satisfied. A product that names only a publisher (“all properties”) counts as confirmed only when every site and app that publisher has authorised can be checked against the list; otherwise it is refused unless the seller applies the list. The refusal happens before anything reaches the seller. The error names each product, the list, and the reason: coverage_unknown, property_excluded, or property_outside_include_list. To proceed, remove the product or choose a seller that applies lists. If the lists, or the seller behind a storefront product, can’t be read at that moment, the launch fails with a retryable error instead of going ahead without the check. Buys with no property lists are not affected, and buyers, whether an agency or a single advertiser, change nothing: a product is refused only when the list cannot be held to it.
• Sellers: a product stays buyable for advertisers with property lists when you declare property-list support, or list each site and app it runs on in publisher_properties. Sellers on the Apostra-managed sales agent can’t apply lists yet, so for them only the second route is open. Until a product has one of the two, advertisers with lists will not be able to buy it.
• Uploading a creative asset now works in the web app. Asking Murph to upload one opens the upload window inside the chat. Before, Murph said the window was open when it was not, and only a fallback link appeared. Murph now says it asked the app to open the window and shares the link if it does not appear. The Creative Library’s “Upload a file” dialog also now fits its frame, so the file picker is no longer cut off. Nothing to change on your side.
• The Dashboard in the Apostra app now opens the same Seller Dashboard you get in Claude and ChatGPT: your run analytics, your RFP metrics, the decision record behind each run, and, if your sales agent is connected from outside Apostra, the connected-agent view with your next steps. Dashboards already in your chat history keep working as they were.
• Nothing changes for packages that stay within the targeting their product declares. If a package sets targeting its product doesn’t offer, the buy is now refused instead of passed on to the seller: remove that targeting or choose a product that offers it. You find out when you book, rather than after a seller turns the buy down or delivers it without the targeting you asked for.
• Each product declares which targeting you may set on a package (overlay_support in AdCP), such as countries, regions, Nielsen DMA metros or a frequency cap, with per-package limits. The check runs when you save a draft media buy, create one, or update its targeting, and it includes targeting the package inherits from its campaign. A package is refused if it sets a dimension the product doesn’t declare, a metro or postal system the product doesn’t list, or more values than a per-package limit allows. Nothing is saved or sent to the seller, and the error names the package, the product and the targeting.
• Buyers: read a product’s overlay_support in get_products, or overlaySupport in V3 search(kind: "wholesale_product"), before you set targeting. save_media_buy, save_campaign and create_media_buys return a validation error on targeting_overlay. A storefront’s AdCP endpoint returns UNSUPPORTED_FEATURE with reason undeclared_product_targeting. Buys that are already running are not re-checked, but a later targeting change to one is.
• Sellers: the targeting a product declares is what buyers see in get_products and search, and what they can set on that product, so keep each declaration accurate. A buy that asks for more is refused before it reaches your approval queue or your sales agent. Products with no declaration of their own are not checked this way; your seller-wide targeting and your sales agent still refuse targeting that can’t be applied.

​

5.1254.0 — October 22, 2026 at 1:15 PM UTC

• When an ad platform rate-limits a media buy update, the update no longer reports that nothing was applied. The rate limit is returned as a temporary error with the outcome left open, because a rate-limited update is sent again later and can still take effect. If another change in the same update had already been applied when the rate limit hit, the update reports that its outcome could not be confirmed, as it does for a timeout. This covers Meta, TikTok, Snap, Pinterest, LinkedIn, and Reddit media buys. Every other refusal is reported as before. Nothing to change on your side.
• After a platform update, a seller whose inventory source or sales agent connection had just changed is available for proposal requests and new buys within seconds. Before, it could stay unavailable for about two minutes while a background refresh waited to start. Nothing to change on your side.
• When your storefront sells through its own sources as well as a sales agent you connected, and that agent refused the account request Apostra sends when you approve a buyer, the agent’s inventory source now shows a blocking finding in its health. The finding includes the agent’s reason and what the agent’s operator must change. The agent’s developer sees the same failure on the Agent page. Nothing stops yet. Buyers billed through Apostra get no account on that agent until its operator accepts the request.

​

5.1252.0 — October 22, 2026 at 12:10 PM UTC

• Reading an agent with get now returns certificationExemption: the date until which Apostra has exempted the agent from certification, or null when it has no exemption or the exemption has ended. Only Apostra staff can set, extend or clear an exemption; the field is read-only for you, and save_agent does not accept it.
• A Developer account now opens on one Developer home, with the chat box under it: what to do next, and every agent you own with its kind and the finding that most needs your attention. To work on one agent, choose it from the picker at the top of the left rail, which works like the advertiser picker (a kind label on each agent, your most recent agents first, search, and All agents to come back). Under the picker you see only that agent’s Overview, Test & certify, Inventory sources and Webhooks, and API calls stays under Account. The separate Agents and Your agents rows and the Certification link are gone from the rail. In get_status, each agent in a Developer account now carries findingsHeadline and findingCount, and the Developer home no longer draws a stage stepper. Nothing to set up on your side.

​

5.1251.0 — October 22, 2026 at 11:56 AM UTC

• V3 reads now return a creative engine’s Account id as engineAccountId, beside the engine’s own id. It appears on each engine from search and get with kind: "creative_engine", on the target and engine of a creative engine connection, on a Creative Session’s engine, and on the result of open_creative_engines_page. Send it as target: {kind: "creative_engine", engineAccountId} to save_connection, as engineAccountId to open_creative_engines_page, which now takes it in place of engineId, and in a save_creative_session draft’s engine, so the engine object from a session read can be sent back unchanged. It is a different number from the engine’s id, so never copy one into the other. Nothing you send today changes: an engine’s target.id on save_connection, engineId on open_creative_engines_page and engine.engineId on save_creative_session keep working and mean what they meant, and are now marked deprecated in favour of engineAccountId. A call that sends both must name the same engine, otherwise it fails with a validation error that names both fields. An Account id that owns no live creative engine fails with a validation error that names the field and the id. If the engine Account ids cannot be read for a result, a read fails with a retryable error rather than returning an engine without its Account id; a write keeps its success.
• Certification now checks whether your sales agent accepts the account request a publisher’s storefront sends when the agent runs behind it, for example a publisher’s own ad server. Each run asks for the account twice with billing: agent. To pass, your agent must return the same active sandbox account both times. Every agent gets the result on its Agent page, whether or not a publisher uses it this way today. It does not affect your certification or stop any buy.
• A goal that a measurement vendor counts now reads as “Integral Ad Science · Brand safety rate” instead of integralads.com:brand_safety_rate. The names appear on the goal bar, the campaign seller scorecard, a seller’s scores and the seller’s Media Buys page, and in the text your agent reads, with the identifiers kept beside them. The vendor’s name and kind come from its brand.json and its metric unit and description from its AdCP measurement catalog, both read through the AAO registry. AdCP’s catalog has no display name, so the metric’s name is its metric_id written as words. When a name is missing or not yet fetched, the read shows the identifier and never waits long for it. get_delivery goal progress, the V2 reporting and scorecard reads, and the V3 sellerScorecard and scores includes add optional vendorLabel and metricLabel objects beside vendor and metricId; nothing you send changes.
• When an inventory source is connected to a sales agent, disconnected from one, or turned on or off for requests, the seller’s availability now updates as part of that change. Before, the seller could be left out of proposal requests and refused for new buys until a background refresh ran: a few seconds normally, and up to about two minutes after a platform update. Nothing to change on your side.
• A sales agent that no storefront uses yet now says what to do: attach it to a storefront as an inventory source (a private one if it is not for the marketplace), and certification starts. In a Developer account the brief and transaction tests read as unavailable, with the reason, and the endpoint brief is listed first as the quick check.

​

5.1250.0 — October 22, 2026 at 10:54 AM UTC

• Certification now waits up to five days for you to approve its creative, and tells you it is waiting.
• When your agent holds the certification creative for review, Apostra no longer ends the use case as inconclusive after the first check. It checks again every four hours, creates the test buy as soon as you approve, and shows the finding “Certification is waiting for you to approve the certification creative” on your agent and the Test & certify page. If you do not approve within five days, the use case ends inconclusive as before. A rejected creative still ends it at once with your agent’s reason. Automatic approval for certification creatives avoids the wait. See “Certification-ready sandbox” on the certification page.
• The developer guides now walk through testing and certifying a sales agent: register the agent in your Developer account, create a private storefront in the same organization, add the agent to it as a source, and say it is ready so Apostra’s certification buyer buys through it. The guide also covers testing as a buyer with a buyer account in the same organization.
• AdCP buyers who send update_media_buy directly to a Google Ads storefront can now rename a media buy: the Google Ads campaign is renamed, and the update succeeds only once Google Ads shows the new name. If Google Ads refuses the rename, for example because another campaign in the account already uses that name, the update returns an error and the campaign keeps its old name. If the rename can’t be confirmed, the update returns an error that says so. Renaming Google Ads media buys through Apostra’s API will follow once it is enabled for Google Ads.
• AdCP buyers calling update_media_buy on a LinkedIn storefront can now rename a media buy: the LinkedIn campaign gets the new name, and the update succeeds only once LinkedIn shows it. The campaign group keeps its name. If LinkedIn refuses the rename, the update returns an error and the campaign keeps its old name. If the rename can’t be confirmed, the update returns an error, and LinkedIn may show either name until you check and retry. A blank name, or one longer than 255 characters, is never sent to LinkedIn. Renames through Apostra’s API will follow once they are turned on for LinkedIn.
• AdCP buyers calling update_media_buy on a Pinterest storefront can now rename a media buy: the Pinterest campaign is renamed and the new name is confirmed by reading the campaign back from Pinterest. If Pinterest refuses the rename, or it can’t be confirmed, the update returns an error and the campaign keeps (or gets back) its old name. A blank name, or one longer than 255 characters, is never sent to Pinterest. Rename and cancel a buy in separate requests. Renaming Pinterest media buys through Apostra’s API will follow once it is enabled for Pinterest.
• AdCP buyers who call update_media_buy with a new name on a Reddit storefront now get the Reddit campaign renamed, and the new name is confirmed by reading the campaign back from Reddit. The campaign keeps its [AdCP …] marker after the new name. If Reddit refuses the rename, or it can’t be confirmed, the update returns an error; a refused rename leaves the old name. A blank name, a name longer than 255 characters, or a name ending in an [AdCP …] marker is never sent to Reddit. Any update to a canceled (archived) Reddit campaign is now refused before anything is sent. Renaming Reddit media buys through the Apostra API will follow once it is enabled for Reddit.

​

5.1249.0 — October 22, 2026 at 10:23 AM UTC

• Every buyer account is now its own operating unit, so setup no longer asks whether an account is “the whole company or one team”. When you confirm your company domain, the account gets a short unit code automatically: it is generated from the account name, gets a numeric suffix if another account under the same domain already holds it, and never changes when you rename the account. You can still choose your own code, such as rce. The codes default, global and primary are not accepted, because no account can be called the default, global or primary one.
• In v3, save_buyer_operator takes operatorDomain and an optional operator_unit ({ "id": "rce" }) and no longer accepts operatorScope, and get_status no longer returns operatorIdentity.operatorScope or scopeStatus. In the v2 buyer API, the request to confirm the operator (PATCH /api/v2/buyer/readiness/operator) now refuses operatorScope: "whole_operator" with a 400, where it used to save a whole-operator identity. Whole operator is retired, and nothing is converted for you. If you send that value, send operatorScope: "specific_unit" with operatorUnitId instead, or leave operatorScope out and the unit is generated from the account name. "specific_unit" and no scope work as before. The response and buyer readiness keep operatorScope, scopeConfirmedAt and scopeStatus as deprecated, read-only fields that report the stored scope (an older whole_operator identity still reads that way until it is converted to its own unit), and readiness adds suggestedOperatorUnitId. Buyer readiness no longer asks for a “confirm account scope” step; the deprecated scope_not_confirmed issue now only means the account has neither a unit nor a confirmed older scope.
• Accounts that predate this change keep working until a reviewed one-time update gives each one its unit; until then their account key has no unit and new AdCP 3.2 provisioning waits for it.

​

5.1248.0 — October 22, 2026 at 10:13 AM UTC

• Seller to-do items for an ad-server order now close when the ad server settles the order. An “ad server requires manual order approval” item closes as approved when the order goes live, and is withdrawn when the order is rejected or canceled instead of staying in your queue. A guaranteed-availability review item is withdrawn when its order ends. A buy that is still waiting for approval changes nothing.
• When a seller’s sales agent approves or rejects a creative you sent for a media buy, the creative’s status now updates as soon as the seller reports the decision, instead of at the next scheduled check. If the seller rejects the creative and says why, the v2 creative’s platform_links[].rejection_reason is the seller’s reason, word for word (plain text, up to 500 characters), and its AdCP errors are on the sync row; with no reason the message is unchanged. This applies to sellers whose sales agent publishes an account change feed; for other sellers the scheduled check still applies. V3 creative reads do not show the seller’s reason yet. Nothing to change on your side.

​

5.1247.0 — October 22, 2026 at 9:10 AM UTC

• In a Developer account, the web app’s left rail now lists each agent you own, and choosing one shows four pages under its name: Overview, Test & certify, Inventory sources and Webhooks.
• Overview shows what needs your attention, the checklist, and the agent’s endpoint and protocol details. Test & certify shows live certification results, test runs and AdCP 4.0 readiness. Inventory sources lists the sources connected to the agent. Webhooks shows recent inbound webhook outcomes, with the reason for each refusal.
• Claude, ChatGPT and other MCP hosts open these same pages for the same agent, so the web app and your assistant show you the same thing. The pages are read-only: to change an agent, ask your assistant or call save_agent. They replace the single Agent page with tabs, which no longer opens in a Developer account. API calls is still beside Agents. There is nothing to set up on your side. Seller accounts, and how other hosts show your agent, are unchanged.

​

5.1246.0 — October 22, 2026 at 8:51 AM UTC

• When you place a media buy directly with an Apostra ad-platform storefront over AdCP, the ad-platform campaign is now named from the buy’s AdCP name. A context.campaign_name sent without a name is still used for now, so nothing breaks, but set name instead: context is your own correlation data, which a seller echoes back and does not read. With neither, the campaign is named {brand} × {storefront}, as before. Buys placed through an Apostra campaign keep their names unchanged.
• An agent’s Inventory sources page now shows each source’s own reporting state beside its health: no report due yet, on time, late and recovering, needs action, or complete. The page shows each state as Apostra reads it and does not add them up.

​

5.1245.0 — October 22, 2026 at 8:25 AM UTC

• An agent’s findings now cover four things the old Agent Overview showed as cards. An organization admin sees a blocking “Claimed by your organization” finding for an agent Scope3 mapped to the organization and that is not claimed yet, with an action that opens the claim review. Products with no AdCP channels appear as an advisory finding, inventory sources that need reporting action as an attention finding, and an agent that has passed certification gets one advisory pointer to the Partner page. Each links to a V3 docs section.
• Canonical creatives chosen for a specific format now reach AdCP 3.1 sellers that list each product format both as a format option and as a format ID, even when the product has several formats of the same kind. Before, Apostra refused to send them because it could not tell which format ID matched.

​

5.1244.0 — October 22, 2026 at 8:01 AM UTC

• Teach your storefront agent how you like to sell with Lessons, now on for every seller storefront. In Sessions, leave a private note on an answer, select Teach this to propose a lesson, and preview the change. Once a seller account administrator approves it, your agent follows the lesson on matching briefs. Notes and lessons stay private to your seller account. Your prices and floors still take priority; lessons about pricing or when to decline can’t be approved yet.

​

5.1243.0 — October 22, 2026 at 7:34 AM UTC

• V3 now names a seller, a creative engine and a media-buys filter by their accurate names. open_media_partners_page (and its earlier name open_connections_page) takes the seller’s Account id as sellerAccountId, and save_connection takes a creative engine’s Account id as target: {kind: "creative_engine", engineAccountId}. On the Seller Media Buys Page, the filter that holds the id of a seller account mapping is now sellerAccountMappingId, on open_media_buys_page and its Page data read. An Account id is a different number from the ids that reads return today, so never copy one into the other. Nothing you send today changes: sellerId, an engine’s target.id and the Media Buys Page filter sellerAccountId keep working and mean what they meant, and the two Media Buys names now say they are being retired in favour of sellerAccountMappingId. A call that sends both names for one input must name the same seller, engine or mapping, otherwise it fails with a validation error that names both fields. An Account id that owns no live seller or engine fails with a validation error that names the field and the id. The test-sales-agent skill is now version 1.5.5, which names the seller by sellerAccountId on its writes.

​

5.1242.0 — October 22, 2026 at 7:20 AM UTC

• An agent’s certification findings now match its certification runs, and link to the V3 docs. A use case whose latest run was inconclusive says when it ran, why Apostra could not decide, and what to do next, instead of “not checked yet”. An agent that has certification runs but has never run the test-sales-agent skill now sees that skill named as the step that has not run, instead of “No test has run”. Every finding links to the new Agent requirements page.
• When you read a campaign’s proposals, the platform now tells you which quoted proposal to book, what each seller’s own forecast expects it to deliver, and each seller’s record on the goal the proposal answers. The recommendation names a guarantee that meets your target first, then a best-effort answer that does, then the lowest answered cost, and it is left out when no quoted proposal qualifies. The forecast volume is shown only when the seller’s forecast states it plainly, never worked out from a price. The record, for accounts in the seller record pilot, now covers event goals such as purchases and leads as well as metric goals. In the Campaigns view the recommended proposal is marked and named above the table, and its forecast and record appear beside it. The same fields are on the V3 proposal search and get for agents.
• Recover a direct media-buy update when the seller receives the request but its response is lost.
• Requests that break the AdCP schema, such as a frequency cap with none of its fields or a media buy with no packages, are now refused with a clear validation error when they arrive. Reliable Reporting takes each day’s first reading an hour after the day closes, and until then the reporting status reads “waiting” rather than “delayed”.
• Third-party impression trackers written as <img src> tags inside a GAM creative’s HTML now have AdCP macros such as {CACHEBUSTER} and {DOMAIN} translated to GAM macros, the same as tracker URLs. HTML that already uses GAM macros is unchanged.
• When one creative runs in several media buys on a GAM seller, each buy’s line items now get an ad-server creative carrying that buy’s own tracking and click-through URLs, instead of reusing the creative first built for another buy.
• When you reject a media buy’s approval (or a buy held for inventory availability), the buy now shows as rejected straight away, and its held line items are archived in Google Ad Manager. Before, the buy stayed pending approval until its flight ended and was then reported as canceled.
• When a creative runs in several media buys on a GAM seller, buys created, approved or updated through the sales agent now get an ad-server creative carrying their own tracking and click-through URLs, instead of reusing one built for another buy.
• A GAM order created with creatives attached no longer gets a second copy of each creative added to its line item shortly after booking. Each creative now serves as one GAM creative.
• GAM sellers now declare that the seller fills its own ad-server macros. Product and capability responses report these macros as performed by “seller” instead of “source_ad_server”, which AdCP reserves for the buyer’s own ad server. A buyer that quotes the new value has its macro declarations honoured exactly. GDPR consent declarations work with either value.
• Delivery snapshots for Google Ad Manager media buys now report spend correctly for click-priced packages, which showed no spend before, and for viewable-CPM packages, which counted every impression instead of viewable ones.
• Embedded roster advertisers now receive a clear change-feed refusal instead of records incorrectly labelled as the default account; ESA Account feeds continue normally.
• CM360 snippets with unresolved required placeholders are rejected before reaching Google Ad Manager, with the unfilled placeholders identified.
• Queued seller-approved media-buy updates now report as submitted and can be polled instead of appearing completed before GAM applies them.
• FreeWheel creative uploads now wait briefly for a newly created VAST wrapper URL to become readable instead of rejecting and deleting a creative that FreeWheel subsequently shows as valid.
• Uploading a creative to a FreeWheel ad server no longer slows down as the seller’s FreeWheel creative library grows. On large libraries, sync_creatives used to take several minutes and could time out; it now takes seconds.
• Partner agent detail and list, buyer agent discovery, media buy seller names, campaign seller names, delivery attribution and the admin reporting lists now read a hosted Storefront’s name and route live from the Storefront, instead of from a copy written to the legacy agent row. Two Storefronts whose copied name had gone stale (renamed after the row was last written) now show the Storefront’s current name everywhere; every other Storefront’s name was already correct and is unchanged. Nothing for anyone to do.

​

5.1241.0 — October 22, 2026 at 6:41 AM UTC

• In the Apostra web app, a Developer account now opens on the Developer home. It lists each of your agents with its stage (built, connected, tested, certified or listed), what is blocking it, and the step that moves it forward. To start, connect an agent you already run, or choose “Set up an agent on Apostra”, which is shown as unavailable with the reason until hosted agents are offered to Developer accounts. The page also answers common questions and links to the docs, the AdCP specification and the Apostra GitHub repository. Your agent sees the same view by calling get_status, and opens the page with the new open_developer_home call. Nothing is required of you. See the Developer quickstart.
• If your agent reads nextActions from get_status in a Developer account, existing calls to build_sales_agent, build_creative_agent and build_buyer_agent now fail. Update them to use connect_agent, connect_buyer_agent and set_up_hosted_agent; the old ids have no alias. connect_agent starts sales or creative registration and connect_buyer_agent starts buyer registration. V3 is a preview, so this is a breaking change.
• For a Developer account with a buyer agent that already reached testing, the journey now ends at tested. The old Certified next step and its certification-unavailable blocker disappear because buyer certification is not offered. Certified and Listed are marked unavailable, with no replacement action required. This affects only Developer buyer-agent records already at tested; it does not change what sellers see or do.

​

5.1240.0 — October 22, 2026 at 6:05 AM UTC

• In a Developer account, the owner of an agent can now open an Inventory sources page: how many inventory sources the agent powers, and for each its name, storefront, lane and latest health, with a count of how many more stay private to their own organizations. Ask your assistant to open the agent’s inventory sources, or call open_agent_sources_page with the agent’s id. The page shows the same sources as get, only to the people who can read the agent, and changes nothing.

​

5.1239.0 — October 22, 2026 at 5:15 AM UTC

• You can now tell Interchange which vendor metric carries invalid traffic and brand safety, so the campaign seller scorecard scores them. AdCP’s performance standard names the verification vendor but not which of its metrics holds the value, so these used to read “Not reported”. On an ivt or brand_safety standard, add ext.apostra.metric_id with the metric’s identifier from the vendor’s own list (for example "ext": { "apostra": { "metric_id": "givt_rate" } }, with the vendor named). Interchange judges that metric against your threshold, a ceiling for invalid traffic and a floor for brand safety, and agents on V3 and the Campaigns view show each as its own part of Quality beside the viewable rate. A part appears only when every package of the seller’s buys carries the same standard and the vendor reported a value for it. A seller reading its own scores sees its vendor’s rate for the metric you named, never your threshold or verdict, and Interchange does not send ext.apostra to the seller. This is an extension while a proposal to carry the metric on the AdCP standard is with AdCP. Nothing changes unless you name a metric. Only V3 save_media_buy takes ext; the V2 media buy tools and reads, and the V2 scorecard read, are unchanged and keep quality as not reported.

​

5.1238.0 — October 22, 2026 at 4:56 AM UTC

• A digital out-of-home (DOOH) sales agent can now be certified. Apostra judges a DOOH screen from your own reporting, as it does for out-of-home: the sandbox buy goes live and your reports arrive on the schedule you declare. Hosted image and video_hosted formats qualify, and the buy needs no creative. Previously a DOOH-only agent matched no use case, so it could never pass. Programmatic DOOH where Apostra’s tracker can fire still goes through the display checks.
• In a Developer account, the owner of an agent can now open a Test & certify page: the latest live certification result for each use case with the reason for any that did not pass, the test plan and recent test runs, AdCP 4.0 readiness and the agent’s capability declarations. Ask your assistant to open the agent’s tests and certification, or call open_agent_certification_page with the agent’s id. The page is a curated view of the same read get makes, without internal fields, shown only to the people who can read the agent, and it changes nothing; to say an agent is ready for certification, ask your assistant or call save_agent with certificationRequested: true.

​

5.1237.0 — October 22, 2026 at 4:39 AM UTC

• A developer tool can now sign a person in to the V3 HTTP API with OAuth instead of an API key. The HTTP API (/api/v3) is now its own OAuth resource: the person approves the sign-in in the browser and chooses the one account the token is for, and the token works on /api/v3 only, with the interchange:read, interchange:write or interchange:admin scope the tool asked for. Apostra’s own command-line client can use a loopback redirect on any port. An MCP token is still refused on the HTTP API, and an HTTP API token is refused on MCP and on every other route. The Apostra CLI and SDK sign-in commands ship separately.

​

5.1236.0 — October 22, 2026 at 4:23 AM UTC

• V3 reads now return the seller’s Account id as sellerAccountId, beside every seller id they already carry: on seller and connection reads, media buys, proposals, creative formats, wholesale products, request_proposals outcomes, get_status ready destinations and the seller’s own seller object and listing (and as sellerAccountIds beside lists such as skippedSellerIds). Send that value to the sellerAccountId and sellerAccountIds inputs. The old seller inputs are now marked deprecated and are being retired: sellerIds and expectedSellerId on request_proposals, sellerId on save_media_buy and save_connection, sellerIds on save_campaign, filter.sellerId on search, filter.ids for sellers, and a seller target.id. They keep working and mean what they meant; a later release will refuse them with an error that names the new input and stop returning the old fields, so switch now. Likewise, every response that carries buyerCustomerId also carries buyerAccountId: send buyerAccountId. The seller’s Account id is a different number from the Storefront id beside it, so never copy one into the other. Two fields keep their old meaning for now: a media buy’s operation destinations still hold the Storefront id in sellerAccountId, and a campaign’s sellerIds are seller platform slugs.

​

5.1235.0 — October 22, 2026 at 3:54 AM UTC

• The Apostra developer plugin for Claude Code and Codex now names its connection apostra, matching the quickstart’s mcp add commands. It was named interchange before. The Build with Apostra skill (version 1.0.9) now links to docs.apostra.com. After you update the plugin, your client may ask you to sign in to Apostra once more.
• If your account is in the seller record pilot, the Proposals section in the Campaigns view now shows each seller’s record on the goal it is answering. Guaranteed and best effort records are shown apart, and every rate comes with the number of buys behind it, for example 9 of 10 judged buys hit the target. A seller with no completed buy on the goal reads “No history on this goal yet”. A co-op member sees the pooled record with rounded counts. Accounts outside the pilot see no change.
• If your display ad format takes a tag as inline markup (inline_markup in supported_delivery_types) but declares no impression-tracker slot, certification now measures it instead of skipping it as seller_format_cannot_carry_tracker. For the certification buy only, Apostra adds its impression pixel to the end of the tag it sends in sync_creatives, with CACHEBUSTER, DOMAIN and APP_BUNDLE for your agent to fill where it serves the tag. Nothing to change if your format already declares an impression slot or takes only a tag URL. A format that takes only a tag URL is still skipped, and tags for real buys are sent exactly as the buyer supplied them.
• Opening an agent from Claude, ChatGPT or any other MCP host now shows an Overview page built around what needs your attention: the headline finding first, with what it stops, how to fix it and a link to the explanation, then the checklist with failing and not-yet-checked items open and passed items collapsed, and the agent’s stage, the AdCP versions it declares and its production revision. The page never reads as passed while a check has not run. Call open_agent_page with the agent’s id; the page shows the same findings as get for the agent, only to the people who can read it, and changes nothing. To say an agent is ready for certification from these hosts, ask your assistant or call save_agent with certificationRequested: true.
• Sessions now include the briefs your storefront turned away during product discovery, marked Passed, with the Brief Acceptance rule that declined each one, or the reason it did not fit your inventory. Briefs your storefront forwards to your connected sales agent, such as on a Listing storefront, also appear, marked “Forwarded, not checked”. For briefs your agent answered, the Session shows what your Brief Acceptance check decided. Only you see these Sessions; buyers never see your rules or the reasons.

​

5.1234.0 — October 22, 2026 at 3:15 AM UTC

• If your storefront passes buyer requests through to your own sales agent and you haven’t confirmed your markets, Apostra now assumes them instead of showing none. Your assumed markets are the channels and countries already saved on your storefront plus the primary channels and countries your sales agents declare. If neither names a channel, you’re treated as selling in every channel; the same goes for countries. Buyers see those assumed markets on your Listing, and requests and media buys outside them no longer reach your agent. Once you save your markets in your Listing or with save_seller, only the values you saved count.
• When an advertiser has no account yet with a hosted media partner, a brief search, a refinement or a proposal request now still asks that media partner for its public catalog, instead of leaving it out. You get back the products it lists for every buyer. Your brief is not applied there and the products carry no account pricing: account pricing still needs the account. The media partner’s result says that only its public catalog was searched, and points you to Media Partners to see where your account stands. In a proposal request, that result carries an accountNotice with the reason code catalog_only_pending (the account is being set up) or catalog_only_needs_attention (someone has to act). Nothing to change on your side; if Apostra cannot read your advertiser’s accounts, the search still fails for that media partner.
• The Campaigns view now has a Proposals section that shows how each seller’s proposal answers your campaign goal. Open a campaign and each proposal says whether it meets your goal, can do a different target, has no target for your goal, or came back without a goal answer. It shows the target the seller answered beside the one you asked for, the commitment (guaranteed, best effort or report only), the price and budget, and whether the proposal is quoted, booked, expired or withdrawn. The view never guesses an answer from the seller’s wording.
• If you can edit the campaign, a quoted proposal has a Book button. It asks you to confirm, then creates a draft media buy from the proposal’s own terms and budget, the same as accepting the proposal through your agent. The buy stays a draft until you take it live. You do not need to do anything for this to appear.
• The section does not rank proposals, recommend one, estimate volume or show the sellers that passed.
• Read-only members can no longer change things through the app or API; their existing read permissions and chat access are unchanged.
• A ChatGPT Ads launch no longer fails and archives a correctly created campaign because OpenAI’s list is slow to show the new ad group or ad. A launch now fails only when OpenAI refuses a write or returns something that differs from what was asked for.
• A ChatGPT Ads buy no longer reads as completed right after launch. It now reports the status OpenAI Ads holds for the campaign: paused until you resume it, or active when it was created active. A paused buy can be resumed through the media buy tools.
• A Spotify ad that Apostra created is no longer rejected because Spotify reported an out-of-date account id on it. Apostra reads the ad through your ad account, which already proves whose ad it is. It now relies on that, as it already does for Spotify campaigns, instead of an account field Spotify sometimes fills with an old value.
• Sales agents that only support AdCP 2 are no longer retried on AdCP 2 when they refuse an AdCP 3 request; AdCP 2 reached end of life on 1 August 2026, so these agents now receive the refusal and must upgrade to AdCP 3.

​

5.1233.0 — October 22, 2026 at 2:26 AM UTC

• Coding agents can now find the tested Claude Code, Codex, npm, and PyPI installation commands directly in the public documentation index.
• Uploading creative files from a ChatGPT widget now works. ChatGPT serves our widgets from a different address than the one our storage allowed, so uploads started in ChatGPT failed before the file reached us. Nothing to change on your side.
• Meta catalog features now use the Business Portfolio that owns your connected Meta ad account. Syncing a catalog creates it under that Business, and catalog-sales buys check their catalog against it, instead of failing because no Business was known. A Merchant Center, Business or Amazon region named in a request’s context is now ignored: catalog pushes go only to the Merchant Center or Business recorded on your connected account, and Amazon calls go to the region your account was connected in. Nothing to change on your side.
• The Terms of Service acceptance prompt now correctly names Apostra as the provider.

​

5.1232.0 — October 22, 2026 at 1:52 AM UTC

• A media buy’s pendingReason (e.g. creatives_not_delivered) now comes with a plain-English pendingReasonMessage explaining why the buy is waiting, instead of just the machine code.
• Proposal reads now show each product’s pricing (fixed price, or the floor and bid guidance for auction products) in the text, not only in structured data.
• If your storefront passes buyer requests through to your own sales agent and you haven’t confirmed your markets, your readiness checklist now asks you to set your channels and countries, as it asks every seller, and takes you to your Listing to do it. It no longer counts your sales agent’s declared coverage as your markets, and no longer tells you to update your sales agent instead. The Listing check stays advisory unless your storefront is in the Listing go-live cohort.
• Spotify ads that Apostra creates are no longer all reported as failed. Apostra checked that a new ad read back with a “paused” status, but Spotify ads have no such status: an ad is paused by switching its delivery off. Apostra now confirms the ad is in the right ad set with delivery off, and logs the reason when it can’t confirm one.

​

5.1231.0 — October 22, 2026 at 1:05 AM UTC

• An audience mapping on a seller account is confirmed only when the platform can deliver ads to that audience. Before, a mapping could read confirmed while every buy using the audience was refused as not eligible for delivery. An audience the platform is still building, or that is too small, now keeps the mapping pending with SELLER_OBJECT_SYNC_PENDING; it is checked again about every hour and confirms on its own once the platform can deliver to it.
• The Connect sales agent task now tells you where to register a sales agent of your own. If your organization has a developer account, it names the account to switch to; if it has none, a Create a developer account link opens your account settings, where you can create one. In V3, the seller’s search for kind: "agent" returns the same information as developerAccounts and developerAccountsUrl.
• A creative’s synced status no longer stays false because of an old failed send to a seller where every media buy carrying the creative has since ended. Sellers with a live or draft buy still count, as does a send made after those buys ended or to a seller with no media buy, and every seller link is still listed with its own status.
• save_creative now checks formatParams and formatOptionRef against AdCP definitions, accepting every AdCP-defined parameter and refusing values of the wrong type or invalid publisher domains with a clear error.
• Buyers can now update a campaign creative collection’s role and new-member sync policy, and attach an existing collection through save_creative_collection.
• Reliably recover in-flight Storefront source media-buy writes when a seller callback is missed.
• Product discovery on LinkedIn, Pinterest, Reddit and Snap now treats them as direct-billed, so buyers who have not yet chosen payment terms are no longer limited to public discovery there.
• V3 inputs that name a seller now also take the seller’s Account id, as sellerAccountId for one seller or sellerAccountIds for a list: request_proposals (with expectedSellerAccountId for its fail-closed check), save_media_buy, save_campaign, save_connection (also as target: {kind: "seller", sellerAccountId}), and the seller, proposal and creative format filters on search (filter.sellerAccountIds and filter.sellerAccountId). An Account id is a different number from the seller ids that reads return today, so never copy one into the other. Nothing you send today changes: sellerId, sellerIds, expectedSellerId, a seller target.id, filter.sellerId and a seller search’s filter.ids keep working and mean what they meant. A call that sends both names for one input must name the same seller or sellers, otherwise it fails with a validation error that names both fields. An Account id that is not a live seller fails with a validation error that names the field and the id.
• Creative reads now include AdCP-shaped assets keyed by slot, while preserving the existing flat asset list. You can use the returned durable asset and format selectors to re-save a creative without returning a private upload reference.
• Live certification no longer fails the ad-server delivery check on traffic Apostra drives itself just because your ad server counted fewer of those plays than our tracker did. On that traffic, your pre-filter impression count now passes anywhere from half of our count up to 20% above it, because an ad server drops some driven plays before counting them. A count below half, including zero, still fails. Real-traffic runs still need the counts to agree within 20%.

​

5.1230.0 — October 21, 2026 at 11:47 PM UTC

• When you put a creative on a draft media buy with Meta, TikTok, Snap or OpenAI Ads, it is now sent to that platform straight away, before you submit the buy. Until now these sends always failed and the creative reached the platform only at submit. Each platform now receives the creative early (for example, Meta uploads the image or video and creates the ad creative), and when you submit the buy, the platform uses that creative. Draft buys with Spotify, Reddit, Google, LinkedIn, Amazon and Pinterest are unchanged: those platforms only accept a creative as part of a media buy, so it goes at submit. Nothing to change on your side.
• A creative that declares no format, or declares two, can never be delivered, so its review no longer waits in the seller’s queue. After a day it is closed as expired. The buyer sees it rejected with the reason “Expired: this creative declares no single format, so it can’t be delivered. Resubmit it with a format.” Sellers have nothing to do. Buyers can resubmit the creative with exactly one format, and it is reviewed again. A creative on a media buy that has not reached a final state with the seller stays in review until it does.
• The + on your Inventory sources now opens a focused Add an inventory source task with the three ways to add a source: a managed integration, a sales agent, or a modular source. It no longer repeats your existing sources above the choices; the Inventory sources list keeps them, with its Connect menu.
• A storefront’s channels and countries are now always its own. If your storefront passes buyer requests through to your own sales agent and you haven’t confirmed your markets, your Listing and your Discovery Card now say your markets are not set, instead of showing your sales agent’s declared channels and countries. Buyers see no channels or countries on that card until you confirm them. Requests that reach your storefront still go to your agent, as before. To set your markets, open What you do in your Listing, choose Edit (it starts from what your agent declares) and save, or save them with save_seller.

​

5.1229.0 — October 21, 2026 at 10:59 PM UTC

• Link composed proposal products to matching buyer-visible wholesale catalogue routes.
• Macro mappings on trackers and in test_creative_macros now name each token the way its own dialect does: CACHEBUSTING for VAST [CACHEBUSTING], CACHEBUSTER for Google Ad Manager %%CACHEBUSTER%%, timestamp for Campaign Manager 360 [timestamp], and the macro name, such as CACHEBUSTER, for an AdCP macro. These are the identifiers AdCP expects in dialect_semantic. Before, the semantic field carried descriptive names of our own, such as cache_busting_value. Trackers saved before this change keep the names they were saved with (registryVersion 1.0.0) until the tracker’s URL or dialect changes. How macros are mapped and filled does not change.
• A seller account can now read whether buyers can use it and what its plan includes in one call. Call get with kind: "seller" and include: ["operating"] for status (live, paused, blocked or archived, the same value get_status reports as state), isPaused, archivedAt and routingMode. Add include: ["entitlements"] for merchandising, listingDistribution and operatingMode (LISTING_ONLY or AGENTIC_MEDIA_COMPANY, taken from the plan, not from the stored choice save_account writes). Neither field appears unless you ask for it, so existing calls return what they did before. If Apostra cannot work a value out, the call fails with SERVICE_UNAVAILABLE and returns neither field. See “Reading your seller’s operating state and plan”.
• Spotify creatives are less likely to fail while Spotify is still processing the uploaded audio or image. Apostra now waits up to three minutes for each file, instead of one, before treating it as failed.

​

5.1228.1 — October 21, 2026 at 10:26 PM UTC

• Customers can continue SSO setup when their approved account domain was missing from an existing WorkOS organisation. Setup now adds that approved domain before opening the configuration portal.

​

5.1228.0 — October 21, 2026 at 10:04 PM UTC

• Return AdCP media fact aliases, digest, and file size fields when reading or finalizing buyer creative assets.
• The buyer an Apostra seller reads about is now named by buyerAccountId, the buyer’s Account id. It takes the same number buyerCustomerId did, wherever a V3 tool accepted buyerCustomerId: the search and get_delivery filters, get for a seller media buy, get_seller_reporting_receipts and request_seller_reporting_update. Every V3 response that carried buyerCustomerId now carries buyerAccountId with the same value. Nothing you send today stops working: buyerCustomerId is being retired and will be refused, with an error naming buyerAccountId, in a later release, so switch when convenient. A call that sends both names must send the same value, otherwise it fails with a validation error that names both.
• Creative-format search and get now preserve seller-declared AdCP option fields, including presentation, tracker, macro, technical, locale, channel, and experimental metadata. Creative Library attach-fit results now add the canonical option and its reference at fit.adcp_target, while retaining the existing flat fit.target fields.
• A Seller Account can no longer create a sales agent source from an endpoint alone. Add a sales agent as one of your organization’s agents (register it in your organization’s developer account, then connect it from the Connect sales agent task or with save_inventory_source and its agentId), or connect a certified partner’s agent. save_inventory_source now refuses a sales agent create from endpointUrl with VALIDATION_ERROR on that field, naming both ways forward. Sources you already have keep working, and signal, creative and outcome agents are unchanged.
• When a seller refuses a media buy at launch, the launch error and the media buy now show the seller’s reason in a safe, bounded format.

​

5.1227.1 — October 21, 2026 at 9:28 PM UTC

• Allow V3 buyers to update a saved creative’s click-through URL without recreating the creative.
• Staging a product that is already on one of the campaign’s media buys now says which buy has it, instead of returning an internal error or an unexplained zero-created result.
• Review & go live now opens for a draft campaign that has failed or pending media buys, including when its budget is returned as a numeric value in text form. No action is needed from you.
• Ask updates from an ineligible session now fail before Apostra shows an approval control that cannot complete.

​

5.1227.0 — October 21, 2026 at 8:53 PM UTC

• Product discovery documentation now correctly describes the 35-second continuation window without implying a fixed number of dispatches.
• Live-certification test buys can now pick one of your declared formats for their creative when your agent speaks AdCP 3.1. Before, the certification creative step stopped with “did not provide one unambiguous legacy format reference” even though your products declared their formats correctly. Nothing to change on your side. If a certification creative’s duration matches none of your declared durations, the failure now says the creative must change, instead of asking you to declare format references you already have.
• Recover a direct media-buy cancellation after its seller response is lost, without duplicating or changing the original seller request.
• SDK guidance now links directly to the V3 SDK guide. Existing SDK setup and API calls do not change.
• A Spotify ad that Apostra created is no longer reported as failed. After creating an ad, Apostra reads it back to confirm Spotify holds it paused. That read used an address Spotify doesn’t allow our app to call, so the confirmation failed and the creative showed as not delivered even though the ad existed. The read now goes through your ad account, the way every other Spotify read does.

​

5.1226.1 — October 21, 2026 at 8:08 PM UTC

• Pausing a draft or completed campaign is now refused instead of changing its status.

​

5.1226.0 — October 21, 2026 at 7:41 PM UTC

• When a seller declines your proposal request with a correctable error, you now see the seller’s error code and explanation. Eligibility and account setup skips are unchanged.

​

5.1225.0 — October 21, 2026 at 7:22 PM UTC

• The SDK quickstart now includes the previewed revision when you confirm a campaign launch.

​

5.1224.0 — October 21, 2026 at 7:09 PM UTC

• V3 breaking change: save_creative now takes a third-party display tag as AdCP’s display_tag asset in assets, and no longer takes a tag sent as an HTML asset with formatKind: "display_tag". A display_tag asset has one of three delivery forms, set by delivery_type: tag_url (one url), inline_markup (markup, kept byte for byte, with its markup_type of iframe_javascript, javascript or standard) or paired_redirect (ad_request_url and clickthrough_url, sent together). Each can carry AdCP’s macro_declarations, which are stored as sent, and the creative’s format is display_tag without a formatKind. If you save tags today as HTML with formatKind: "display_tag", send them as display_tag assets instead: that save is now refused, and the error names the display_tag asset. An HTML asset without formatKind: "display_tag" is still inline HTML, and creatives you already saved are unchanged. Reading a saved tag back in the same shape is not part of this change.

​

5.1223.0 — October 21, 2026 at 6:48 PM UTC

• Creating a campaign with an advertiser that is missing, archived, or unavailable to your account now returns a clear not-found response.
• Read-only members who ask Murph to change something now get a clear answer straight away, instead of a form or a confirmation step.
• An inventory source now says whether it is an Apostra-hosted adapter, which Agent powers it and how its latest tests went, all from get and search. Every source in search({ kind: "inventory_source" }) and get({ kind: "inventory_source" }) carries isAdapterSource, a boolean. Add include: ["poweredByAgent"] to a source get for null when no Agent is mapped, { state: "ACTIVE", agentId } or { state: "REVOKED" }. Add include: ["testRuns"] for the five most recent recorded source tests, each with id, toolName, status, productCount and steps. Neither include appears unless you ask for it, so existing calls return what they did before, plus isAdapterSource. Both includes are refused on any other kind. If Apostra cannot work a value out, the call fails with SERVICE_UNAVAILABLE and returns neither field. See “Reading an inventory source: adapter, powering Agent and test runs”.

​

5.1222.0 — October 21, 2026 at 6:16 PM UTC

• Product discovery can now use an active legacy storefront account set up by another member of your buyer company. An account linked to your own login that still needs attention continues to block discovery, and storefronts using organisation-owned accounts are unchanged. Nothing to change on your side.
• Sellers can open and save Library Drafts from the Draft review queue after uploading a file.
• The agent directory now lists every hosted Storefront, including ones that never had a registry record, under its storefront-<platform id> agent id, with its name, route and availability read from the Storefront itself. Another customer’s hosted Storefront is listed only while it is publicly listed, so archived, paused, opted-out, hidden and pending-review Storefronts appear to their owner and no one else. The supportsRegistration filter judges a hosted Storefront by the same operator-authentication value its list entry reports. If Storefronts keep changing while that filter is read, the request fails with a retryable error rather than returning a list that may be incomplete.
• Pause responses now identify seller updates whose outcome could not be confirmed, so you can check and reconcile the media buy before sending another request.
• A seller account can now read its whole setup picture in one call. Call get with kind: "seller" and include: ["readiness"] for the setup phase, the checks still to finish (each with a typed action in the same shape as the status tool’s nextActions), the goLive state and progress, demandCoverage with up to four sample briefs, the wholesaleProductCount, and the source-health diagnoses. Nothing appears unless you ask for it, so existing calls return what they did before. If Apostra cannot work out any part of it, the call fails with SERVICE_UNAVAILABLE and returns none of it. See “Reading your seller’s setup checklist and go-live state”.
• request_proposals now reports a stale expectedCampaignRevision, a campaign with no advertiser, or a campaign with invalid targeting or no market as that error, even while another proposal round for the same account is still running. Before, the one-active-round limit was checked first, so those requests came back as RATE_LIMITED and pointed at the other round instead of the problem with the request.

​

5.1221.0 — October 21, 2026 at 5:01 PM UTC

• The v3 setup pages no longer say v3 is MCP-only. They now point to the v3 HTTP API and say which operations it serves: the public v3 operation catalogue. App-only helpers used by in-chat Pages are not available over HTTP. Buyer and admin operations outside the catalogue stay on stable v2; in production the v2 storefront (seller) API refuses external callers, so sellers use v3 only.
• The v2 storefront API reference now says the API is retired for external callers. In production, calls to /api/v2/storefront/** and the v2-storefront MCP tools from API keys, organization and machine credentials, OAuth agents and other external callers are refused with 410 Gone (code GONE) and a pointer to v3. Use the v3 API instead: read the Seller Account with get {"kind":"seller"}, check readiness with get_status, and start from the v3 Quickstart (https://docs.apostra.com/v3/quickstart).
• You can now rename a TikTok media buy by sending name with the buy’s ID to save_media_buy on V3. The new name takes effect only once TikTok confirms it. If TikTok refuses the rename, or we can’t confirm it, the buy keeps its current name and the error says which of the two happened. Renaming a TikTok buy through the V2 media-buy update follows the same rules, instead of returning “Renaming isn’t supported for TikTok yet”.

​

5.1220.0 — October 21, 2026 at 4:45 PM UTC

• Trackers sent to a seller in the AdCP 3.0 url form now keep their event and method as extra fields, so the seller can still tell an impression tracker from a click or viewability tracker. A native in-feed creative sent to an AdCP 3.0 seller now has its click and viewability trackers converted to that form too, not only its impression tracker.
• Read an agent’s findings with get (kind: "agent"): one ordered list of what needs your attention, each with a severity (blocking, attention or advisory), what it stops, and the fix, with the headline marked. search with kind: "agent" returns each agent’s headline finding and how many findings have not passed. This is a V3 preview change; the agent’s nextAction now follows the headline finding.
• Inventory Components now starts a new draft product with the channel from your Seller listing. The suggestion was meant to appear already, but the widget’s read of the listing was refused, so drafts always guessed the channel from the creative formats instead.
• Document that cancelled campaigns cannot be executed.
• Document event-source binding recheck intervals for campaign launches and approved buys.
• The webhook_signing readiness check now also looks at how your signed callbacks fare. If your agent declares RFC 9421 webhook signing but, in the last 7 days, Apostra refused at least 3 of its callbacks because the signature did not verify, the check fails instead of passing on the declaration alone. It clears when fewer than 3 such refusals remain in the 7-day window. The check becomes required on 1 February 2027, as before. “Getting ready for AdCP 4.0” gives the rule, and your agent’s webhook results show each refusal and its reason.
• Live-certification test buys can sync their creative to your agent again. For about a day, certification runs stopped at the creative step with a media-buy-not-found error and the creative never reached your agent. Nothing to change on your side; the next certification run should get through the creative step.
• The API keys list in Settings no longer shows “Error fetching data” when your organization role has changed in the last few minutes. If your admin role is still being applied, the list shows your own API keys until the change takes effect, and then shows every member’s keys.
• Approved private modular source tests can now discover their exact authorised product during the protected no-spend campaign flow while the Storefront remains paused. Ordinary buyers and public listings remain blocked, and expired product or runtime permissions fail before execution.
• Reactivating a campaign that is not paused now returns a validation error instead of an internal error.
• A paused Creative Engine is now held from buyers. While an engine’s operator has paused it, the engine no longer appears in Creative Engine search, get or the Creative Engines Page, you cannot start a new connection to it, and saving or generating creative against it returns a retryable “unavailable” error. Generation already sent to the provider finishes, and your existing connections are kept, so the engine works again as soon as it resumes.
• In Apostra chat, you can add PDF, PowerPoint, Word, Excel, and CSV documents up to 100 MB to Library. Each document uploads directly to private storage and appears as a Draft; if a document exceeds 100 MB, choose a smaller file and try again.
• If your storefront passes buyer requests through to your own sales agent, you can now edit and confirm your channels and countries in your Listing. Open What you do, choose Edit, and the channels and countries start from what your agent declares. Saving your listing confirms them as your markets: buyers see them, and requests outside them no longer reach your agent. Until you save, your Listing says they come from your connected sales agent and nothing changes. You can also save your listing’s subtitle now; before, the Listing dropped it for these storefronts.
• MCP endpoints, including /mcp, /mcp/v3 and Seller endpoints, no longer accept a sign-in session from the Apostra web app; they refuse it with 401. Connect MCP clients with OAuth or an API key. Connected MCP clients and API-key integrations are not affected, and the Apostra web app works as before. The authentication guide now lists which credential each MCP endpoint accepts.
• The retired Buyer access posture no longer comes from a stored value, so three deprecated fields change. account on the Buyer activation read (GET /api/v2/buyer/activation) is now always null, and so is customer.buyerAccessPosture in the user context that account creation and switching return. A Buyer’s customer.accountProducts.core.buyerAccessPosture stays, but is now derived when the response is built from its capability verdicts: LIVE_ELIGIBLE when the Buyer can spend live, otherwise SANDBOX_ONLY, including when the verdicts cannot be read in time. None of these was ever an authorization source: read Buyer Setup capabilities to see what an account can do. The admin customer responses return buyerAccessPosture: null for the same reason, and the admin create request still accepts that field and ignores it.
• The owner of an agent can now open a Webhooks page that lists the agent’s recent webhook callbacks to Apostra, newest first, with the reason for each refusal and a link to what each reason means. Ask your assistant to open the agent’s webhook results, or call open_agent_webhooks_page with the agent’s id. The page shows the same results as get with include: ["webhookDeliveries"], only to the people who can read the agent, and changes nothing.
• A ChatGPT Ads launch now waits up to about 20 seconds for OpenAI to list the new ad group and ad under their parent before it treats them as missing, since OpenAI lists a new resource a few seconds after it can be read. The campaign, ad group and ad in OpenAI’s Ads Manager are now named from your campaign name, the seller and the media buy id, instead of a generic name.
• The campaign seller scorecard now scores quality for agents on V3 and in the Campaigns view. Where a seller reported viewability on its delivery, its Quality score shows the viewable rate over the impressions that were measured, how much of its delivery that covers, and whether it met the viewability standard you set on its packages. Sellers are ranked on quality only when their rates were counted the same way, by the same counter under the same viewability standard; otherwise each rate shows with no rank. A seller that reported no viewability still reads “Not reported”. The seller scores on a seller read now total quality across your campaigns, and the Campaigns view shows the quality-against-price tab once any seller has a quality score. Invalid traffic and brand safety are not scored yet. The V2 scorecard read keeps quality as not reported. Nothing to change on your side.
• Members with view-only access can again check their account status and open pages in the Apostra assistant. Since 19 October the assistant had been refusing these read-only requests as if they were changes. Changes stay blocked for view-only members.
• Refreshing an external sales agent’s health now re-runs its catalog check too, so a catalog problem you have fixed stops counting against the source on your next refresh. refresh_inventory_source_health runs the no-spend get_products check and, when your agent publishes a wholesale catalog, a catalog refresh. It reports each check’s result in checks, and lists in openFindings any recorded finding it cannot re-run that still counts against the source, such as a failed creative sync. The hourly health recheck runs the same two checks. See Refresh a source’s health.
• save_seller can now hold and resume new business on your Seller Account. Send isPaused: true to hold it, or isPaused: false to resume, and include expectedIsPaused with the hold you last read so a change made in the meantime is not overwritten. Send the hold fields on their own, without any other save_seller field. A stale expectedIsPaused returns CONFLICT with the reason pause_state_changed_concurrently, an archived Seller Account is refused, and setting the hold the Seller Account already has succeeds and changes nothing. The hold stops buyer discovery, new media buys and buyer edits; campaigns already delivering are not paused. It needs the write role and is separate from apostraParticipation. See Hold or resume new business.
• Seller Setup now offers one Sales agent choice in place of the separate partner and bring-your-own cards. It opens the Connect sales agent task, which lists your organization’s own sales agents, such as those registered in your developer account, and the certified partner agents you can connect through. Choosing your own agent opens the connection form bound to it. The task no longer offers a form for an endpoint that is not one of these agents: when your organization has no agent yet, it tells you to register one in your organization’s developer account first.
• You can now rename a Snap media buy by sending name with the buy’s ID to save_media_buy on V3. On a running buy, the new name takes effect only once Snap confirms it. If Snap refuses the rename, or we can’t confirm it, the buy keeps its current name and you get the same errors as a Meta rename. The V2 media-buy update follows the same rules. A rename on a platform that doesn’t support it yet still returns an error saying so, and nothing changes. If you don’t rename Snap media buys, there is nothing to change.
• Spotify ads no longer fail to create because of our click tracking. Spotify refused any click-through link that still contained a placeholder for the ad server to fill, such as the {CACHEBUSTER} on Apostra’s click tracker. Spotify fills no placeholders, so the link Spotify receives now leaves those parameters out. Clicks still go through the tracker to your landing page.
• Breaking change when this ships: a call to a storefront’s get_products with buying_mode brief or refine, or to request_proposals, that sends no account is now refused with ACCOUNT_SETUP_REQUIRED. To keep working, call sync_accounts on the storefront for your brand and operator, then send the returned account_id on each request. You can send the brand and operator instead of the account_id only when they name an account you already synced. get_products with buying_mode wholesale still needs no account. It returns the same public catalog to every caller, with no prices that belong to one account, and ignores any account it names.
• Discounts now follow the brand and operator of your account, not the request body, and a request whose brand does not match its account is refused with INVALID_REQUEST. An account you do not hold returns ACCOUNT_NOT_FOUND, and an account the seller has not approved returns AUTH_REQUIRED. The storefront checks the account before it reads any catalog or asks any inventory source, so a refused request returns no products. Storefronts that enforce this declare account.required_for_products: true in get_adcp_capabilities. Sellers can review new accounts first; discovery then waits until the seller approves the account. A seller calling its own storefront with its own credential needs no buyer account. Buying through Apostra’s own tools needs no change, because your advertiser’s account is already sent.
• For enterprise and agency buyers, the business effect is isolation: each buyer now sees only its own account’s catalogue and prices, and nobody can read another buyer’s account by naming its brand. For sellers, the account-specific products, prices and discounts you set up now reach only the buyer account they were set up for, and discounts follow that account’s brand and operator. Sellers have nothing to configure. No billable area, packaging, plan or price changes; this only changes which already-configured account prices and discounts a caller is shown.
• See Discovering products on a storefront needs an account.
• A storefront can only be set up in a seller account. Setting one up in a buyer account or in an organization is refused with a message to create a seller account first.
• Buyer account relationships read through V3 now say where each one stands. search and get on account_relationship return relationshipState: whether the buyer needs your review, is waiting on someone else, is buying, was rejected or is new, who owes the next step, and the first item that needs you. Agents and integrations read the same answer the Buyers page shows.
• The V3 quickstart now starts with the one-command connection for Codex and Claude Code: add https://api.apostra.com/mcp/v3, sign in, and your agent can read your account. The Build with Apostra package is now an optional extra for people building software. Older V3 setup instructions use the same apostra server name.
• In ChatGPT, the “Couldn’t load this view” screen no longer shows a Reload button that did nothing. It now tells you to ask again in the chat, which opens a fresh page. The Campaigns page also loads when ChatGPT is slow to deliver it, instead of staying on that screen.

​

5.1219.0 — October 21, 2026 at 2:02 PM UTC

• A ChatGPT Ads launch no longer fails because the ad group and the ad do not name their campaign and ad group in OpenAI’s response. The launch now confirms each by listing it under its parent, and changing the bid of a live buy no longer fails on a bid strategy OpenAI adds itself.

​

5.1218.0 — October 21, 2026 at 1:28 PM UTC

• You can now rename a Meta media buy by sending name with the buy’s ID to save_media_buy on V3. On a running buy, the new name takes effect only once Meta confirms it. If Meta refuses, the buy keeps its current name and you get an error. If we can’t confirm the change, the name stays as it was and you’re asked to try again later. On a storefront where the seller reviews changes, the rename also waits for the seller’s approval. A draft is renamed immediately.
• Only Meta buys can be renamed today. A buy on any other platform or seller returns an error saying renaming isn’t supported for that platform yet (for example, “Renaming isn’t supported for Google yet”), and nothing changes. The V2 media-buy update and renaming a media buy from a campaign now follow the same rules. Previously they changed the name only in Apostra, so on non-Meta buys they now return that error instead of appearing to succeed. If you don’t rename media buys, there is nothing to change.

​

5.1217.0 — October 21, 2026 at 1:02 PM UTC

• Approved custom modular sources can now run source-scoped no-spend campaign tests without unpausing their Storefront. Access is limited to the approved source connection, expires automatically, and can be withdrawn. Sellers without approval remain blocked before confirmation and can request access from Apostra Support.
• The Campaigns page now loads in ChatGPT when you ask for all your campaigns. Before, asking without naming an advertiser or campaign opened the page and then showed “Couldn’t load this view”. Nothing to change on your side.
• Source-scoped no-spend campaign plans now check the exact runtime permission before telling sellers that execution can start. If the source is not approved, the plan stops and explains that approval is missing instead of accepting confirmation and failing during execution. Already-authorised sources are unchanged.
• When you put a creative on a draft media buy with Spotify, Reddit, Google, LinkedIn, Amazon or Pinterest, we no longer try to send it before the buy exists. Those attempts always failed, because these platforms only accept a creative as part of a media buy. The creative now goes to the platform when you submit the buy. Draft buys with Meta, TikTok, Snap and OpenAI Ads are unchanged. Nothing to change on your side.
• Draft media-buy video creatives are sent for review again when their selected products are stored under the buyer’s account.
• When a creative’s tracker or VAST tag carries a consent value for a named vendor, the macro declaration sent to the seller now says the seller fills Google Ad Manager’s consent macro, as AdCP defines it for a seller’s own ad server. It previously said the creative’s originating ad server fills it. Sellers whose format options still describe Google Ad Manager’s own macros the earlier way keep their emissions tracking parameter. Nothing to change on your side.
• Advertiser and campaign impression trackers now reach Google Ad Manager sellers with their AdCP macros, and the seller’s sales agent converts them into GAM’s own macros when it writes the tracker to GAM. Previously Apostra converted them before sending. Each tracker declares its macros with AdCP macro_declarations, so a tracker with an IAB vendor ID still gets GAM’s vendor-scoped consent macro. The tracker that fires in GAM is unchanged, and so are the rules for what GAM can’t carry: Apostra still removes a {PAGE_URL} parameter, removes the consent parameter when the tracker has no vendor ID, and doesn’t send a tracker GAM has no macro for. Trackers Apostra places inside a creative’s HTML are still converted by Apostra, because the sales agent doesn’t convert macros inside HTML. Nothing to change on your side.
• A buyer’s AdCP context now stays between the buyer and the storefront. Before, when a storefront passed a buyer’s request on to a seller’s sales agent, the buyer’s context (and any per-package context) went with it. Sellers now receive the storefront’s own context on create_media_buy instead, and no context on updates, creative syncs or reads. Buyers still get their own context echoed back exactly as before. If you run a sales agent, echo the context you receive on reads of the buy, as AdCP requires; nothing else changes on your side.
• The buyer and developer skills now tell agents to open the Media Partners Page with open_media_partners_page and to pass a connection’s account as connectionAccountId, matching the tools Apostra publishes. The Build with Apostra skill is republished as version 1.0.8 with that change; earlier versions are unchanged, and open_connections_page still works.
• A connected Meta ad account now lists every audience your connection can see, including lookalike and website audiences you made in Meta, so you can map them to your audiences and the mapping is confirmed. Before, only audiences created through Apostra were listed, and mapping one you made in Meta stayed unconfirmed with SELLER_AUDIENCE_MISSING. Partner segments shared by a data provider are still not listed. To confirm a mapping that is stuck, save it again with save_audience.
• The List organization advertisers page now says save_advertiser_access is a page-only tool that an agent does not call, and the get_status next step for building a buyer agent now names the published save_buyer_agent call.
• A tracked buy, one found in your connected ad account rather than placed through Apostra, no longer reads as needing attention with the blocker not_delivering_after_flight_start on the media buy status read. Apostra did not set the buy up, so it cannot tell whether the buy is meant to be delivering. Buys you place through Apostra, including those placed through a connected account, are still flagged when they have not started delivering more than 24 hours after their flight start. Nothing to change on your side.
• The Get an Account Ready to Buy skill (version 1.1.0) now teaches agents the current billing flow: request payment authority, confirm it with the returned token, then read the result with get({ kind: 'billing' }). It also sends agents to the Media Partners page with open_media_partners_page. Earlier versions stay available unchanged.
• If Apostra refused a webhook callback from your agent, you can now read why. An administrator of the organization that owns an agent can call get with kind: "agent" and include: ["webhookDeliveries"] to see the agent’s callbacks to its inventory sources from the last 30 days, newest first, up to 50. Each entry shows the time, source and operation, and whether the callback was accepted or refused. A refusal adds a reason code and a plain-language reason. Repeated refusals within a minute are grouped with a repeat count. The sender still receives a generic 401, and existing calls behave as before. Callbacks sent to a sales agent’s own callback URL and accepted sync_accounts callbacks are not included. “Reading your agent’s webhook results” lists every reason and the fix.
• Failed creative uploads now remain unapproved, and exact retries return the original failure instead of an idempotency conflict.
• When the Google Ad Manager user you connected can’t see any of your advertisers, the connection status now says that user needs to be added to a team with your advertisers (or “All entities”). Before, it showed a temporary sync error that retrying never fixed.
• A seller whose ad-server credentials have stopped working now sees the connection reported as down, with a short reason, instead of a connection that looks healthy.
• Apostra now maps a buyer again when the shared account it chose for them stops working for them. If you sell Google Ad Manager inventory through Apostra’s embedded sales agent and change your default advertiser, buyers Apostra mapped to the old default move to the new one at the next advertiser refresh. Until now they stopped buying that inventory until you mapped each one again. The same applies when a sales agent you connected stops listing a shared account, or narrows it to other agencies or brands: Apostra moves those buyers to the next account that fits, or leaves the mapping for you to change if none does. Mappings you chose yourself, or set through an imported mapping feed, are never changed.
• Removed the browser origins setting’s REST endpoints and MCP tools, ahead of the 18 November 2026 date in their deprecation notice. Sign-in and CORS stopped using the setting earlier, so /api/v2/browser-origins and the list_browser_origins, create_browser_origin and delete_browser_origin tools did nothing. A call to them now returns not found or unknown tool, so delete any such call. Agents and browser-based MCP apps need nothing else: the MCP, OAuth and discovery paths already accept any origin.
• If you ask Murph to validate your Sales Agent from an MCP client connected with OAuth, the validation now runs instead of failing at the start. Validations started from the Apostra web app or with an API key work as before. Nothing to change on your side.
• A Seller Account’s search and get for kind: "agent" now list the sales agents your organization owns, such as those registered in your developer account, beside the certified partner agents you can connect through. Each row carries relationship, own or partner. save_inventory_source with an own agent’s agentId opens the connection task bound to that agent, and a Seller Account can now connect an agent another account in its organization owns. Before, search listed only partner agents and a Seller Account could connect only an agent it owned itself.
• Creative sync now reaches sellers that declare AdCP 3.2 on AdCP 3.2, including the embedded sales agent. Sellers that declare only AdCP 3.1 or earlier are called on 3.1 as before.
• When Scope3 connected another company’s sales agent to one of your inventory sources, the source now shows that agent once Scope3 has approved the connection. It had said the source wasn’t linked to an agent yet. Anything that needs your own authorization still asks for it.
• Buyer and Seller agents can now count their asks by type or by state without listing them. Add groupBy: "askType" or groupBy: "askState" to a V3 search for kind: "ask" and you get each value, such as open and closed, with the number of asks that carry it, plus the total. The counts follow filter.askType, filter.askState and query exactly as the list does, so they always add up to the list’s total. Asks come from several places that can each be unavailable; if one could not be read, or returned more asks than one read covers, the count is refused (SERVICE_UNAVAILABLE or UNSUPPORTED_FEATURE) instead of returning a number that could be short. search for kind: "conversation" does not support groupBy, because its filters are a text query and a start time.

​

5.1216.0 — October 21, 2026 at 9:51 AM UTC

• The media buy docs now say that a Meta Sales buy doesn’t need an explicit pixelId when its optimization goal names an event source you’ve mapped on the seller account: the mapped pixel is sent for you. Pass pixelId only when the goal doesn’t name a mapped event source. A pixelId that differs from the mapped pixel is refused.
• If your storefront passes buyer requests through to your own sales agent, you can now set your storefront’s own channels and countries with save_seller. Save your channels together with your countries (or acceptsAllCountries: true) in one call: that confirms them as your markets. Your Listing then shows them instead of your sales agent’s declared coverage, and buyer requests outside them no longer reach your agent. Until you save, nothing changes: your Listing shows your agent’s declared coverage, and every request that reaches your storefront still goes to your agent.
• A media buy that is only waiting for the seller to approve its order no longer re-sends its creatives to the seller every hour. A creative the seller already accepted for that buy, at its current version and for every package it is assigned to, is left alone. A creative whose delivery failed, that was never sent, that was edited since, or that was assigned to another package is still sent. Nothing to change on your side.

​

5.1215.3 — October 21, 2026 at 8:46 AM UTC

• Creatives for draft media buys are sent for review instead of being refused before delivery, including 15-second and 30-second video ads.

​

5.1215.2 — October 21, 2026 at 6:13 AM UTC

• Creatives for a draft media buy are sent to the seller again, including 15-second and 30-second video ads, instead of being refused before they reach the seller.

​

5.1215.1 — October 21, 2026 at 5:44 AM UTC

• Campaign lists now show the configured daily budget and today’s reported spend consistently in V3.

​

5.1215.0 — October 21, 2026 at 5:30 AM UTC

• Demand Inbox is retired; Sessions replaces it. In the app nothing changes for you — Demand Inbox links and saved Demand Inbox cards already open Sessions. If your integration calls GET /api/v2/storefront/demand-inbox or PUT /api/v2/storefront/demand-inbox/{runId}/ledger, those endpoints are removed: read buyer requests and outcomes with get_rfp_performance, and record a result with save_rfp. Agents that call an old Demand Inbox tool get a RETIRED_TOOL response naming the Sessions replacement.

​

5.1214.1 — October 21, 2026 at 5:00 AM UTC

• Campaign tracking updates now follow the same account hold and sponsorship checks as other campaign updates.

​

5.1214.0 — October 21, 2026 at 4:49 AM UTC

• You can now run video ads on Meta. Video creatives for Facebook and Instagram Feed, Stories and Reels are open to every buyer, along with two awareness campaigns built for video: one optimised for ThruPlay views and one for 2-second plays. Until now these were in Testing and not available to buyers.
• One default changes. For Meta products that take video, a new buy where you don’t choose placements now runs across Feed, Stories and Reels on both Facebook and Instagram, instead of Feed only. To keep a buy on Feed only, set its placements to Feed when you create it. Buys you already created keep their placements.
• Details for anyone setting these up directly:
• The video formats are meta_video_feed, meta_stories and meta_reels, and the products are meta_awareness_video_views and meta_awareness_video_plays. get_products lists the video formats on every Meta product that accepts them.
• A thumbnail is optional; without one, Meta picks a frame from the video as the cover image.
• Videos can be as long as Meta allows for the placement: up to 241 minutes for Video Feed, 60 minutes for Stories, and no limit for Reels.
• When you assign a video to a package that names placements, it must also fit each of them. For example, Facebook Stories allows 3 minutes and Instagram Reels allows 15. A video that’s too long, or that doesn’t declare its duration_ms, is refused, with the placement and its limit named.
• Promoting an existing Facebook Page post (meta_existing_post) stays in Testing and isn’t available yet.
• Apart from the placement default, there is nothing to change on your side.

​

5.1213.2 — October 21, 2026 at 2:45 AM UTC

• Fixed a TikTok image creative silently never reaching TikTok when it was authored with the generic headline/body/display name fields instead of TikTok’s own field names. The creative now reports a clear reason it was skipped, naming the exact fix — attach the brand name and ad text using social.components with TikTok’s own slot names — instead of appearing to save successfully while never being delivered.
• When a catalog refresh returns no products, the catalog currently serving buyers stays available while we check again. It clears after three consecutive empty refreshes, and a non-empty refresh resets the count.

​

5.1213.0 — October 21, 2026 at 1:43 AM UTC

• Reading delivery for a directed campaign at a hosted adapter Storefront now finds your advertiser’s seller account from the advertiser’s link to that Storefront’s account, instead of from the older agent record. Before, a hosted Storefront without that record answered “No account is mapped to this advertiser” even though the advertiser was linked. Storefronts that have the record resolve to the same account as before.

​

5.1212.0 — October 21, 2026 at 12:07 AM UTC

• Prevent Enhanced Reporting updates from failing with a server error when they overlap with a seller account mapping change on the same connection.
• You can preview Apostra as a lower role from your profile menu (‘View as’). A banner shows while you’re previewing, and one click switches back.

​

5.1210.0 — October 20, 2026 at 11:01 PM UTC

• Before 1 February 2027, make sure your sales agent supports Reliable Reporting, the compact lifecycle, canonical creative formats and webhook signing. From that date, an agent that lacks any one of them loses its certification that day, including an agent certified earlier. Nothing is enforced before then. Declaring a capability is not always enough: a compact lifecycle that is declared but not certified counts as missing, and compact-lifecycle certification is not available yet. The Overview tab on your Agent page now names anything missing, with the date, and Getting ready for AdCP 4.0 says what to change. Canonical creative formats means every product carries canonical format_options; a product with only format_ids fails. Request signing, operator identity and release versions stay recommended, with no date.
• Breaking change in the V3 preview, for code that reads adcpReadiness from get with kind: "agent": the verdict value UPGRADE_NOW is no longer returned. A sales agent missing a capability with a date now gets LACKS_DATED_CAPABILITY, and datedGaps lists each one with its mustFrom date. NOT_READY_FOR_4 and READY_FOR_4 are unchanged. Each check now carries requirement (SHOULD or MUST) and mustFrom (YYYY-MM-DD or null), and canonical_creatives is a new check id; existing check ids are unchanged. Update any code that switches on verdict or on check ids.
• Demand Inbox now opens Sessions, which shows the same buyer requests, outcomes and scoreboard. Sessions is included for every seller, so the Merchandising plan no longer lists Demand Inbox as a separate feature. Prices and terms are unchanged, and you don’t need to do anything.

​

5.1208.0 — October 20, 2026 at 9:37 PM UTC

• Impression, viewability and click trackers on a creative sent under one of a seller’s legacy format IDs now reach a seller that supports AdCP 3.0 as url assets with url_type: tracker_pixel, the form AdCP 3.0 defines. Before, they were sent as pixel_tracker assets, a type AdCP 3.0 does not have, and sellers that check against 3.0 rejected the creative.
• If your agent declares AdCP 3.2 and lists list_products, control_media_buy and buy_products or accept_proposal in media_buy.lifecycle_tools, your agent’s live certification now shows a Compact lifecycle use case. Apostra does not run that test yet, so it shows as inconclusive and says so. It never counts toward your certification: a pass does not certify your agent and a failure does not fail it, and it has no effect on Storefront readiness, partner connections or any buy. The compact lifecycle becomes required for certification on 1 February 2027, and the AdCP 4.0 readiness check for it now says so. Nothing to change on your side today.
• Reading billing now returns what the Plan & Billing Page shows. get with kind: "billing" adds standing (prepay or credit, and any holds), balance (with showsAvailable, which says whether to show an available figure), usage (IUs used and rated activity), payout (whether payout setup is owed, with no destination detail), permissions, and in the plan section showsChoices, setupGrant and passThroughAvailable. Each offered plan also carries its list and net prices and discount, and the offer carries its discount and activity schedule. The server decides each of these, so a caller reads them instead of working them out. In the Python SDK, the eight auto-generated GetResultKindBilling… response type names for this read now include the new fields, so they have new names. The earlier names remain as aliases of the new types, so existing imports keep working, and the types they name gain the new fields.
• Your agent can now manage your organization’s IU plan through the V3 save_billing tool. Three new operations accept or switch a plan, record that you declined an offer or want to decide later, and cancel at term end or reinstate automatic renewal. You name a plan by the plan code the billing read lists. Each one is tied to the exact offer or renewal version you were shown, so a change made after you looked is refused with the current version instead of applied. Each takes an idempotency key, so a retry never applies a change twice, and each needs the same direct organization authority as accepting the Terms. When Apostra’s chat assistant proposes a plan, you see the exact plan, price, payment option and start, and nothing changes until you confirm. Asking Apostra for plan help, a commercial request through save_ask, now carries your plan context automatically.
• Live media buys whose seller package ids were recorded wrongly are repaired automatically from the seller’s own status report, so changes to them reach the seller instead of being refused. A package the seller’s report cannot identify with certainty is left alone, and updates to it are reported as not sent.
• When you add a creative to a media buy that is still waiting for the seller to approve it, the creative is now added to that pending request for every seller. Before, a seller whose products were booked directly on its Storefront, with no older seller-agent record behind it, didn’t have its pending request updated: the seller reviewed the buy without the new creative, and adding it could report an error. You don’t need to do anything.
• When you sign up to buy media on a domain whose only account is a Seller account created less than 90 days ago, that account is no longer retired for you. It is treated as a live account that owns its domain, so signup creates no Buyer account and nothing is retired. Seller accounts that are at least 90 days old with no Storefront, administrator, or commercial activity are retired as before. Nothing to change on your side; if a new Seller account on your domain blocks you from buying, contact support.
• You can now preview Apostra at a lower role than your own; it only ever reduces what you can do.
• Keep a campaign’s budget total unchanged when a requested package reduction cannot be applied.
• REST campaign creation now saves storefront filters and channel groups supplied by buyers.
• Inventory sources in a Seller account show the sales agent your organization’s Developer account connected to them again, with its certification, read-only. They had said the source wasn’t linked to an agent yet, although it was connected and receiving requests. You still manage the agent in your Developer account.
• Prevent pending or suspended sponsored buyer accounts from changing advertisers or campaigns until their sponsorship is active.
• request_proposals now reports an unknown campaign even when another proposal round is running for the same buyer.
• Products from sales agents Apostra runs for publishers no longer drop out of product discovery when their forecast breaks availability down by country. Before, any such product was missing from buyers’ results without an error, and a seller whose every product had a per-country forecast returned no products at all. These forecasts now keep the AdCP field names the seller sent, including the per-country viewability ranges, so buyer agents can read them.
• When a seller approves creatives before its media buy exists, the campaign now records them as approved and clears the creative-review blocker. Nothing changes for media buys that already exist: their package assignments must still be confirmed by the seller.
• A ChatGPT Ads launch no longer fails when OpenAI returns a time, status, text or link in a different form from the one we sent. The check still fails a value that really differs, and now logs which campaign, ad group or ad field differed.
• When save_account or an Organization read is refused because the call came from a delegated, agent or support session, or from a session switched into another account, the error now says so and tells the caller to switch back to their home account and retry. Before, it only said an Organization administrator or Scope3 platform operator was required.
• Media buy packages now retain creative assignments when a seller response does not include them. A seller can still clear assignments by explicitly sending an empty list.
• A creative a seller has rejected is no longer sent to that seller again when a buy is rebuilt or re-sent. The buy shows the seller’s rejection until the creative is edited, and the edited creative is sent fresh.
• Media buys that need seller reconciliation now stay open after their flight end until seller evidence settles them.
• Older conversations that reopen a retired seller Page now show a notice that the Page is no longer available. This covers the original Demand inbox, Proposal pass, Product marketing, Selling terms, Acceptance policy, Merchandising rules and IU plan selection Pages. Their current replacements, the Sessions and saved-RFP views, Library, Playbook, AI Business Rules and the IU plan Task, are unchanged.
• The V3 Page result’s resource URI list no longer includes the retired Page URIs, so generated SDK types for page results (for example OpenCampaignsPageResult) lose those values.
• The Seller Dashboard in Claude and ChatGPT now shows your run analytics above your RFP metrics: activity and outcomes, win rate, the posture that converts best, what your agent learned, strategy signals, recommended actions, your top buyers and products, and your recent runs. Open a run to read the decision record behind it.
• If every source on your storefront is your own sales agent, the Seller Dashboard in Claude and ChatGPT now shows that agent and what to do next, instead of an empty analytics page. You can upgrade to Public Distribution, view your plan, connect an ad server, or review a source that isn’t ready, all from the Dashboard.
• V3 search no longer returns a matched field for kind: "connection", "creative_engine", "seller", "event_source", "material" and "library_request". On these kinds matched always equalled total, which is already the number of results that match your query and filters, so read total instead. A search for kind: "seller" on a Seller Account now reports total: 0 when your query does not match the account’s own record, where before it reported total: 1 beside matched: 0. The Library page’s line under the materials list now reads “Loaded N of M matching materials visible to your current seller account”. returned, truncated, cursors and rows are unchanged.

​

5.1207.0 — October 20, 2026 at 6:27 PM UTC

• Certified Agent Developer now includes one Listing storefront, so an agent developer can test its agents against a storefront of its own without changing plans. The storefront runs as a Listing (Listing only). Any further Seller or Buyer Account still needs a plan that covers it.
• Product discovery, proposal requests and campaign product selection now return products only from media partners where your advertiser has an account. A relationship granted to your organization is used by every member, service token and staff member acting for it. A relationship granted to one credential is used only by that credential; for any other caller that media partner is left out of account-required discovery, and you are pointed to Media Partners to confirm an account for your organization. Where a media partner identifies accounts by AdCP’s brand and operator key, advertisers of your organization with the same brand and operator share that account, and where it takes company seller accounts each advertiser has its own; an advertiser with a different brand, or another organization’s account, is never used. A media partner where the advertiser has no active account yet is not searched. An empty result tells you how many media partners are still setting up the account and how many need your attention, and points you to Media Partners to see where each stands. If you named a media partner, its result is skipped. V3 gives the reason account_pending or account_needs_attention. The v2 API keeps its existing shape: the reason is eligibility and the suggestion points to Media Partners. A proposal request already waiting when this shipped cannot present a company account, so each media partner it leaves out comes back skipped with the reason round_predates_account_rule; run the request again. If you search in chat, Murph reports the same counts and points you to Media Partners instead of returning fewer products without saying why. How each media partner is presented to you does not change. A wholesale browse still shows every media partner, using the public catalog where the advertiser has no account. Nothing to change on your side unless Media Partners shows a media partner that needs your attention.
• A partner’s sales agent now appears in a Seller Account’s search and get for kind: "agent", and in the Connect sales agent list, only once the partner may operate agents for other organizations’ clients through the Partner Program. Before, any partner that published a connection setup was listed, even before joining the program. Connections a publisher already made are not changed.
• Saving your operator domain in save_seller now also refreshes your Listing’s brand name, logo and logo background from the brand’s published identity. If the brand has no published identity or the lookup is slow, the domain still saves and the stored brand stays as it was. A resolveBrand lookup alone still changes nothing.
• Proposal search now shows the captured product names. If a proposal has no captured product details, the response directs you to retrieve them with get(kind:"proposal", include:["products"]).
• V3 search for kind: "advertiser", "work_item", "rfp" and "rfp_turn" now reports total as the number of results that match your query and filters, not the number the Seller holds. Before, total was the unfiltered count and a second field, matched, carried the filtered one. matched is removed from these four kinds, because total now means what matched did. If your agent read matched, read total instead. For work_item, total covers the queues the search read, so it is a floor when coverage.partial is true. returned, truncated, the cursors and the result rows are unchanged.

​

5.1206.0 — October 20, 2026 at 5:32 PM UTC

• M2M access tokens now work only on the HTTP API (/api/*), as the authentication guide describes. Every MCP endpoint, including /mcp, /mcp/v3 and a Seller’s /seller/{platformId}/mcp, now refuses an M2M token with 401; connect an MCP client with OAuth or an API key instead. If you use an M2M application against /api/v3, nothing changes.
• From 1 January 2027, Apostra sends new buys to a sales agent only for the use cases it has passed. Buys already running are not affected.
• The certification page states the date, says it applies to sales agents only (creative and buyer agents cannot be certified), and lists what to do now: connect the agent to a Source, check it has a sandbox account that serves, and choose Ready for certification on the agent’s page. A certification buy serves for about three days, so start early.

​

5.1205.0 — October 20, 2026 at 4:45 PM UTC

• When your sales agent approves or rejects a creative, we now record that verdict even if we had already closed the sync without hearing from you, for example because our request to your agent timed out or its answer listed package assignment errors. Before, we refused that callback and asked you to retry until the retries ran out, so an approved creative could stay unapproved on our side.
• A callback that repeats the verdict we already hold is acknowledged. A callback whose approval or rejection contradicts the one we already recorded for that creative on the operation is refused with 409 and not applied, so do not redeliver it. We keep the first terminal verdict. Nothing to change on your side unless your sender retries every 4xx.
• In ChatGPT, the Campaigns page can now call the tools it needs once it is open, such as searching advertisers, reading a campaign’s goals and seller scorecard, and saving a campaign. Before, ChatGPT refused those calls from inside the page. Nothing to change on your side.
• In ChatGPT, the Campaigns page can now load your campaigns once it opens. Before, it showed “Couldn’t load this view” because ChatGPT tried to open a second copy of the page for each of its own data requests. Nothing to change on your side.
• Buyer plans that price media buys now charge 1 IU for each media buy that is active in a billing period, social buys included, alongside the seller’s charge for the same buy. A buy counts once the seller has accepted it, whether or not it has delivered yet. It does not count while it is a draft or waiting for approval, if the seller rejects it, or if it is canceled before its flight starts. A buy running across a billing-period boundary counts in each period, except that a buy already running is not charged for a new period it only spills into for under 24 hours. An organization buying its own inventory is charged once (a non-social buy only once it has delivered, since that is the seller’s charge; a social buy as the buyer’s charge), and a media buy that carries a percentage-of-media fee above 0% (for example, 8% under earlier terms) finishes under that fee without an IU charge. Plans that waive media buys, including existing Connect & Buy plans, are not charged.
• New media buys on Meta, TikTok, Snap, Pinterest, Spotify, Google Ads, LinkedIn, and Reddit now appear in the ad platform’s own console under names that identify the buy. The campaign is named {campaign name} - {seller} - {media buy id}, for example “Spring Shoes Sales 2026 - Meta - mb_782y4”, and each ad set, ad group, or ad squad is named after the media buy id and its position, for example “mb_782y4 - Ad Set 3”. When a campaign name is too long for the platform, only the campaign name is shortened; the seller and media buy id are always kept whole. Buys created before this change keep their current names, Amazon Ads naming is unchanged, and there is nothing to change on your side.
• The branded ChatGPT app is now part of Distribution. Seller plans that include Distribution grant it along with the branded AdCP endpoint and public listing distribution. Accounts that already have Distribution keep everything they have; no action is needed.
• Turning on Enhanced Reporting now works on every current plan. Before, some accepted plans refused it with a message saying no active rate card was found, even though the plan was in force. Enhanced Reporting is billed per connected account per billing period at your plan’s rate, and a plan that waives it shows as included at no charge.
• @apostra/mcp-app-host: HostedMcpAppFrame now delivers the launch result’s _meta to the widget. Pass it as directive.meta. Before this, V3 widgets that need the page capability in that _meta, such as Creative Library, showed a launch failure in hosts that used the React frame.
• Pausing and resuming a media buy now works for every buy. Buys that carry a recorded seller account refused to pause, answering that the account required current buyer authority on the storefront, and kept delivering. Pausing a campaign hit the same wall, because a campaign pause works by pausing each of its media buys: the campaign reported that none of its buys confirmed the pause and left them running. Pause and resume now identify the caller to the seller the same way creating, updating and cancelling a buy already did, so the account resolves and the change reaches the seller. This affected the API, the MCP tools and the Apostra UI alike. If a buy or campaign would not pause, retry it — nothing to change on your side.
• If a sales agent you connected keeps accounts per agency, per brand, or one account for everything you send, Apostra now maps buyers to those shared accounts automatically when you approve them, using the most specific account the agent lists: the buyer’s own agency-and-brand account first, then the agency’s, then the brand’s, then your default. Several buyers can share one such account, and choosing a shared account yourself in Buyer Account Mapping no longer reserves it for a single buyer. Shared accounts serve only buyers billed through Apostra; a buyer you bill directly still gets an account of its own requested. Nothing to change on your side.
• If you sell Google Ad Manager inventory through Apostra’s embedded sales agent and have set a default advertiser for that connection, buyers billed through Apostra that you haven’t mapped to an advertiser are now mapped to your default automatically, both when you approve them and each time your advertiser list refreshes. Until now an unmapped buyer couldn’t buy that inventory until you mapped them. It’s the same as choosing Use Interchange default for each buyer: they share your default advertiser in Google Ad Manager. Buyers you bill directly are never put on the default. To keep a buyer separate, map them to a specific advertiser in Buyer Account Mapping; your choice always replaces Apostra’s.
• When an update_media_buy on a Meta media buy changes a package’s budget, targeting, optimization goal, or flight dates, and Meta times out, returns a server error, or reads back without the requested change, the error now reports details.mutation_outcome: "unknown" (reason: adapter_update_outcome_unknown) instead of rolled_back. This applies even when Apostra’s undo of the change succeeded, because Meta can still apply the original change after the undo. Read the media buy’s current state before sending another change. An update that Meta rejects outright is still reported as rolled_back once the undo is confirmed.
• When a tool or endpoint is refused because of the account’s type, such as a Seller account calling a Buyer tool, the refusal now says why in a form your code can read. MCP tool calls return the error code ACCESS_DENIED with details.reason, details.accountType and details.surface. REST calls keep CUSTOMER_ROLE_DENIED and add the same details. The message text is unchanged.
• When you change which pixel or dataset an event source is mapped to on a seller account, a media buy created before the new one is confirmed now waits for it and is sent with the new pixel. Before, such a buy could be sent with the previously confirmed pixel and keep it. Media buys already running on the account keep using the pixel they were sent with.
• In the Connect sales agent task, opened from Seller Setup or Source diagnostics, you can now pick a partner’s shared sales agent from a list and connect in the partner’s own secure form with the credentials the partner gave you. If you don’t have credentials yet, a “Sign up for [partner]” link takes you to the partner’s sign-up page where the partner offers one. The partner’s single certification covers your connection, and buyers never see which partner you use.
• get with kind: "agent" now returns a listed partner sales agent to an organization administrator working in a seller account other than their home account. Before, it refused them with an owned-agent permission error, even though search listed the same agent.
• Choosing Offer a sales agent at signup now creates your organization together with a Developer account, and your sales agent offering lives on that account. Signing up this way always creates a new organization. It no longer takes over an account that already exists for your email domain, so if your company already has an account, ask its administrators to invite you.
• Within one account, two active advertisers can no longer share a brand in the same country. If you create an advertiser, change its brand or countries, or restore an archived one, and another active advertiser already holds that brand in an overlapping country, the save is refused and the message names that advertiser and suggests countries outside the overlap. An advertiser with no countries covers every country, so it can’t sit beside another advertiser of the same brand, and a different currency doesn’t make them separate. Sandbox and live advertisers are checked separately, and other accounts never conflict. Advertisers that already overlap keep working: an unrelated edit still saves, and so does an edit that keeps the overlap the same or narrows it, so you can resolve it by giving each advertiser its own countries.
• A media buy waiting for the seller’s ad server to approve its order no longer shows as “waiting for creatives” once its creatives have been sent after the buy was created. It shows as scheduled, so buyers and sellers see the real reason it isn’t live yet.
• A storefront can attach a creative this sales agent already holds to a new package by sending only assignments, with no creatives, as AdCP 3.2 allows. Before, the sales agent refused that request.
• FreeWheel sync_creatives requests now accept advertiser IDs returned by list_accounts, and approved creatives can be created before a media buy exists.
• Google Ad Manager delivery reports no longer fail for a buy whose video completions exceed its impressions. The buy’s impressions and completions are reported, and the completion rate is left out when it would exceed 100%.
• If you save HTML5 files or HTML ad tags, each one must now carry a size, or the save is refused with a validation error and nothing is saved. Sellers that list one format per banner size turn an unsized creative away after the buy is staged. Now you find out when you save.
• A creative has a size if its HTML declares one: <meta name="ad.size" content="width=300,height=250">, a Campaign Manager ins tag, a Campaign Manager ad tag’s single iframe width and height or its one ;sz=300x250, or a fixed pixel width and height on <body>. It also has a size if you pass format_params with a fixed width and height, or with min_width, max_width, min_height or max_height to declare it responsive. A size in the HTML takes precedence over format_params. A responsive creative has no fixed size to send a seller, so a product that needs one fixed size still refuses it at launch. In the V3 API, pass formatParams to save_creative on a create that carries assets. In buyer chat, an HTML file with no size is left out and the upload notice says how to size it. The other files in the upload are still saved.
• Creatives you saved earlier without a size stay readable and keep working. Saving one again without a size is refused, even for an unrelated change such as renaming it. To fix one in the V2 buyer API, replace its HTML with a version that declares ad.size, or create it again with format_params. In V3, create it again. The launch check for a fixed width and height now also counts a fixed size saved in format_params.
• V3 manage_organization is gone. Its eleven actions now live on the tools you already use. The Organization account’s get_status reports its child account counts, workspace capacity and Developer account. get with kind: "account" and include: ["lifecycle", "capacity"] adds one child’s archive state, blockers and capacity. save_account creates a child (send no id), renames one, or archives and restores it with isArchived, each after an organization administrator approves it on the website, and repeating the call with the same idempotencyKey reports the outcome. Send dryRun: true to preview any of them. Send organizationId to act for an Organization you directly administer from one of its child accounts; a Scope3 platform operator can name any customer Organization, and only an operator can create a Demo Storefront (accountType: "seller" with demoStorefront: true). Delegated, machine and switched-in sessions are refused. A save_account call that sends only id, name and settings.company still renames at once for now.
• Every buyer request your selling agent answers is now recorded as a Session, on every storefront, with nothing to set up.
• V3 save_creative_session no longer asks for an operation or a scope. Send campaignId or advertiserId for the session owner, then a draft to save a brief, selectedVariantId or approvedVariantId with the expectedRevision you last read to choose and approve an output, or a finalization to finalise the approved output. Each call makes one change. It never generates variants; generate_variants does. Saving an approved output to the advertiser Library moved to save_creative: send advertiserId, campaignId, an idempotencyKey and fromCreativeSessionOutput. Over MCP, calls that still send operation and scope keep working for now, and the HTTP API and SDKs take only the new shape.
• V3 save_rfp no longer asks for an action, and a new save_rfp_turn tool changes one existing turn. save_rfp creates an RFP when you send no rfpId, revises it with a new request when you send rfpId and parentTurnId, endorses or removes the endorsement of its response with endorsed (and endorsementCommentary), and attaches an uploaded response with responseMaterialId. save_rfp_turn takes the rfpId and turnId that get returns and exactly one of released: true, representation, cancelRepresentationId, feedback (with the typed grade, ledBy and commentary) or outcome. Feedback and outcome are appended to the turn, and a representation starts rendering a proposal file. Over MCP, calls that still send action keep working for now, and the HTTP API and SDKs take only the new shape.
• Your chats now sit in their own panel at the bottom of the left rail, so they stay the same size and in the same place wherever you are in your storefront — including Settings and Sessions, where the list used to disappear entirely. New chat and the control that collapses the rail move down with them, and an empty list says “Chats appear here” instead of showing blank space. Sections of the rail also open independently now: opening one no longer closes the one you were already in, so you can keep everything you are working across in view at once.
• Sessions now includes a year-to-date RFP performance glance. It shows the same bounded seller figures used by the RFP workspace, while response materials remain available to attach from the related RFP Session.
• Renaming a Snap media buy now renames the campaign in Snap, and the new name is confirmed by reading the campaign back from Snap. If Snap refuses the rename, or we can’t confirm it, the Snap campaign keeps (or gets back) its old name. Today the update still reports success in that case, so if the exact name matters, check the campaign in Snap. Snap’s errors will be returned on the update once renaming is available in the V3 API. A blank name, or one longer than 255 characters, is never sent to Snap.
• A sales agent’s declared channels and countries (primary_channels and primary_countries) no longer limit which requests it receives. If your storefront passes requests through to your own sales agent, every get_products request and media buy that reaches your storefront now goes to your agent, whatever channel or country it asks for, and your agent decides what to answer. Other storefronts keep using their own channels and accepted countries to decide which requests their sources receive. Which storefronts a buyer reaches doesn’t change. Sellers don’t need to change anything.
• If your storefront combines several sources and one of them is a sales agent you connected that lists its accounts, Apostra no longer asks that agent to create a buyer’s account the first time the buyer searches or buys. The buyer’s account is set up when you approve them instead: Apostra maps them to the account the agent lists for them, or asks the agent for one when it lists none. Buyers who already buy through such an agent keep the account they use today. Nothing to change on your side.
• Linking a seller account to an advertiser now works for a hosted Storefront whose account the platform has not mirrored under the older agent record. Before, linking an account at that Storefront answered “not found or sandbox mismatch”; now the account links to the Storefront directly, with the same currency and ownership checks as before. Mapping an account at such a Storefront also sets up your relationship with it. Accounts at Storefronts that are already mirrored link exactly as before.
• Renaming a TikTok media buy now renames the campaign in TikTok, and the new name is confirmed by reading the campaign back from TikTok. If TikTok refuses the rename, the campaign keeps its old name. If the rename can’t be confirmed, TikTok may show either name. Today the media buy update does not report either failure to you, so if the exact name matters, check the campaign in TikTok. Rename errors from TikTok will be reported directly once renaming is available in V3. Rename and cancel a buy in separate requests.
• V3 search for kind: "coverage", "signal" and "wholesale_product" now reports total as the number of results that match your query and filters, not the number the Seller holds. Before, total was the unfiltered count, and a second field, matched, carried the filtered one for coverage, signal and wholesale products. matched is removed from these three kinds, because total now means what matched did, and the text names the one count instead of “N of M match”. If your agent read matched, read total instead. For signal, total covers the signals the search read, so it is a floor when coverage.perOrigin reports a scan that stopped early; the catalog’s own size is still coverage.catalogTotal. For wholesale_product, truncated is now true whenever matching products were cut by limit, including when one source returned more than limit, and active still counts every active product before any filter. returned and the result rows are unchanged.

​

5.1204.0 — October 20, 2026 at 11:23 AM UTC

• V3 search for kind: "skill", "playbook_version", "house_discount" and "business_rules_version" now reports total as the number of results that match your query, not the number the account holds. Before, total was the unfiltered count and a second field, matched, carried the filtered one, and the text read “N of M match”. matched is removed from these four kinds, because total now means what matched did, and the text names the one count. If your agent read matched, read total instead. When the seller’s list came back incomplete, total is a floor and sourceListTruncated still says so. returned, truncated and the result rows are unchanged.

​

5.1203.0 — October 20, 2026 at 11:09 AM UTC

• If your storefront combines several sources and one of them is a sales agent you connected, approving a buyer now sets up that buyer’s account on the agent for you. When the agent lists exactly one account for the buyer’s agency and brand, Apostra maps the buyer to it, so it shows as Mapped in Buyer Account Mapping without you choosing it. When the agent lists several, you still choose. When it lists none, Apostra asks the agent for one and maps the buyer once the agent’s listing shows it. An account you map yourself, or one a mapping feed sets, always replaces Apostra’s choice and is never changed back. Nothing to change on your side.

​

5.1202.0 — October 20, 2026 at 10:42 AM UTC

• The Campaigns page now loads in ChatGPT. Before, ChatGPT opened it and then showed “Couldn’t load this view”. Nothing to change on your side.
• The Sessions page is now open to every seller, not only sellers on Merchandising plans. Recorded RFP exchanges now appear in its default list alongside the buyer requests your agent answered, and every seller can try the practice simulator. Nothing to set up.
• Market readiness now counts sellers whose inventory comes through a sales agent or a managed sales agent, not just platform adapters. Before this fix, POST /api/v2/market-readiness left out every seller except the platform adapters (such as Meta, Snap and Spotify), so a country and channel could show no supply even when listed, live sellers covered it. Pass-through sellers now count for the countries and channels their sales agent declares. Managed sellers count for the countries they accept. Sellers don’t need to change anything.
• Sessions now shows the full outcome of a received brief, including its commercial status and where it came from. You can record a grade, who led the response and your commentary, attach a response, endorse it or remove an endorsement, and retry details that did not load. This brings the RFP work you already do in Demand Inbox into the related Session without changing where you open it.
• V3 search for kind: "agent" and kind: "buyer_agent" now reports total as the number of Agents that match your query, not the number the organization holds. Before, total was the unfiltered count and a second field, matched, carried the filtered one. matched is removed from these two kinds, because total now means what matched did. If your agent read matched, read total instead. returned and truncated are unchanged.

​

5.1201.0 — October 20, 2026 at 10:09 AM UTC

• Saving an uploaded avails sheet right after previewing it no longer fails with “The avails sheet changed after preview” when the only change was a name, description or label filled in automatically while the file finished processing. Changing the sheet’s contents, its inventory source or its buyer scope after a preview still requires a new preview.
• When an app that registered itself asks for access to your account, the approval screen now leads with the address the app returns you to, and shows the app’s name below it labeled as chosen by the app and not verified. Apps such as Claude, ChatGPT and Cursor, and apps that publish a metadata document, look the same as before.
• V3 save_material no longer asks for an action. Its fields say what the call does, and one call declares one change: no materialId creates a Material; with one, source adds a source revision, metadata and labels edit it, isArchived archives (true) or restores (false) it, candidateDecisions records decisions on extracted candidates, unitReusable marks slides, pages, or sheets reusable, reprocess asks for a new rendition of a source revision, and commitPreview applies a previewed rate card or avails sheet. The rate-card and avails-sheet previews are now reads: call get on the Material with the rate_card_preview or avails_sheet_preview include, then send its previewToken in commitPreview. Accepting a destination-owned candidate whose typed save already ran now records its receipt, which reconcile_candidate did. Over MCP, calls that still send action keep working for now, and the HTTP API and SDKs take only the new shape.

​

5.1200.5 — October 20, 2026 at 7:28 AM UTC

• Campaign creative syncs for draft media buys now use the campaign’s advertiser account when resolving the seller account. No request changes are needed.

​

5.1200.2 — October 20, 2026 at 5:59 AM UTC

• When you create a campaign or stage a media buy, a discovery session outside your advertiser access now appears as not found. Nothing to change on your side.
• When a campaign has compatible and incompatible creatives, compatible creatives continue delivery and incompatible creatives are reported separately.
• Fixed Spotify create_media_buy failing with a generic upstream error on every launch. Spotify’s ad-set API now echoes the requested country as both country_code and a new country_codes array in its targeting confirmation; the adapter rejected the array as an unrecognized field and reported SERVICE_UNAVAILABLE, even though the campaign and ad set had already been created successfully on Spotify. The adapter now accepts this echoed field. No action needed on your side.

​

5.1200.1 — October 20, 2026 at 5:24 AM UTC

• Keep a paced media buy line item’s displayed budget in step with the total of its packages after a package budget change.
• V3 now refuses a campaign when its name or brief states a different currency next to an amount than budget.currency.

​

5.1200.0 — October 20, 2026 at 4:44 AM UTC

• The docs now answer two questions developers ask first: what certification is, and what Apostra adds on top of building an agent on AdCP directly.
• Creative syncs immediately after creating a media buy now use the buyer route identity until the seller identity is available, avoiding a spurious seller failure while the route is already ready to receive the creative.

​

5.1199.1 — October 20, 2026 at 3:13 AM UTC

• a discovery session that isn’t yours now reads as not found

​

5.1199.0 — October 20, 2026 at 2:52 AM UTC

• To limit get_products results by how age is known, send accepted_bases (verified, declared or inferred) on targeting_overlay.demographics.age. Discovery refused this field before. It now applies the rule a campaign’s age range uses when its media buy is created. A product with a fixed audience is returned only if every basis it states is accepted. A product that lets you set age is returned only if its supported_bases include one you accept. A product that states no basis is left out, so a request for ages 18-55 with accepted_bases: ["verified"] can return no products. Products a built-in adapter applies through its ad platform are not held to the list. An empty or unrecognised list is rejected, and accepted_verification_methods is still refused. Requests without accepted_bases behave as before, and ext.scope3_age_targeting keeps its exact meaning; a request that sends both must satisfy both. See the age targeting guide.
• Sellers: a product that lets the buyer set age (overlay_support.demographics) needs demographic_targeting.age.supported_bases declared to stay eligible for buyers who send accepted_bases. Without it, that product no longer appears for those requests. Requests that do not send accepted_bases are unaffected.
• New guide: Plan & Billing in an agent host. It explains how to open the Page with open_page, read an organization’s billing with get, accept Terms and set up payment, who has the authority to change what, and what never passes through the model. The v2 Plan & Billing page now points to it.
• In a Developer account, a buyer agent now shows up in your account status beside your sales and creative agents, with the stage it has reached: built, connected (it has a credential and has made an authenticated call to Apostra) or tested. Creating a buyer agent with save_buyer_agent or save_agent now also creates its agent record, and existing buyer agents in an organization with one Developer account get theirs from Apostra. The record only tracks the agent: its credential and its advertiser access are unchanged. Certification for buyer agents isn’t available yet, so a buyer agent stops at the last stage Apostra can prove, and the status says why and points to the certification guide. For a step with no call to make, a status nextAction can now carry a resource to read in place of tool and arguments. Nothing to change on your side.
• When you convert an account into an organization, the organization now keeps the features that come with the account’s plan, and keeps them when the plan renews. Previously only the account’s free, beta and manual features moved to the new organization, and the plan’s features were lost.
• Seller agents can now ask how many inventory sources are in each status without listing them. Add groupBy: "status" to a v3 search for kind: "inventory_source" and you get each status with its count, in one small response. Other kinds will gain counts one at a time. Breaking change to the v3 preview: a plain search for inventory_source now reports total as the number of sources that match your filters, not every source the account holds, and no longer returns matched. Read total wherever you read matched.
• A disabled ad server connection now says it is disabled, instead of showing its last sync problem. Before, the Ad server source page could tell you “A background sync is failing — we’re looking into it” for a connection you had turned off, which no longer syncs and which no one is looking into. The page now shows that the connection is disabled and offers to connect your ad server again. A status request for a disabled connection returns 409 CONFLICT explaining that you can reactivate it or connect the ad server again.
• When you save a creative against a seller’s format, a slot limit the seller declared in AdCP’s own terms is now enforced. A slot’s max_chars (or the format’s matching headline_max_chars-style parameter) refuses text that is too long, max_size_kb refuses a file that is too large, and min and max on a slot that holds a list, such as a carousel cards slot with min: 2 and max: 10, accept a count inside the range and refuse one outside it. Before this, those limits were ignored, so a 200-character headline could be saved against a 25-character slot and a list slot could not be filled at all. Limits that sellers declared in their older form keep working. Nothing to change on your side; a save that was passing only because the limit was ignored now returns a validation error that names the slot.
• Prevent playback tracker assets from being sent to sellers that do not support them.
• When you skip the reporting time zone question while creating an advertiser through the V3 buyer agent, the agent now uses UTC explicitly and tells you that you can change it while the reporting time zone is unlocked. Existing advertisers are unaffected; no action is required.
• Fixed TikTok media buys getting stuck without any ad ever being created. Attaching a creative to a TikTok campaign after the media buy was already created — the normal flow — previously failed outright with no attempt to reach TikTok, and a creative that hit a brief upload hiccup could get stuck indefinitely with no automatic retry. Both are fixed: TikTok media buys can now have a creative attached after creation, and a stuck creative upload recovers automatically instead of requiring manual intervention.
• A VAST tag you upload in the creative upload widget can now be sent to sellers. The draft it creates stores the tag under AdCP’s default vast_tag slot, so it passes the format check against an unpinned video_vast format and builds a seller payload. Before, the tag was stored under a slot named vast, and sending it failed with “assets could not be adapted”. Nothing to change on your side: no VAST draft from the widget had reached this state in production, so there is nothing to re-upload.
• Downloading the PDF from a Listing card no longer fails with an internal error when the PDF renderer’s browser can’t set up its crash reporting.
• If your account is on the free listing plan and your storefront is already listed on Apostra, the Listing page now shows it as Live after you reload it, instead of Off. The Listing card download also shows as ready. Nothing changes on your side, and your listing was never unlisted. Hostname, ChatGPT app and the other Distribution controls still need the Listing + Distribution package.
• Creative Engines now loads in the web app, including when Murph opens it in the chat. Before, the page sat blank for about ten seconds and then showed “Couldn’t load this view”, or “MCP app tool call denied”. Nothing to change on your side.
• App names on the screen where you approve an AI assistant’s access, and on your list of connected apps, no longer keep hidden characters (right-to-left overrides, zero-width spaces and other invisible characters) that can make one app’s name look like another’s. Agents that register a client_name have those characters removed when they register.
• The Media Buys page now shows expected delivery beside delivered, in the unit each buy was booked in. Open a buy and “Is it pacing as expected?” compares, for example, the impressions an even pace expects by now with the impressions delivered for a cost-per-thousand buy, and clicks with clicks for a cost-per-click buy. The expected figure comes from the fixed price the buy was booked at: the budget divided by that price is what the buy should deliver over the flight. A buy with no fixed price on record, lines priced differently from one another, or a price on something delivery does not count (cost per action, viewable CPM, rating points or a flat fee) shows what was delivered and says why there is nothing to compare it with. Nothing to set up and no action needed.
• The Media Buys page’s own data read carries the same figures on each buy’s pace as expectedDelivery (unit, booked, expected, actual) and expectedDeliveryWithheld.
• Buyers who create a media buy for an advertiser can now book products a seller returned for their account when that account has no synced account mapping. Previously these buys could still read only the public catalogue, so the seller’s products were refused or withheld.
• The Campaigns page now opens in ChatGPT when you ask for all your campaigns. It used to show an empty frame and a message that the page has no supported browser URL.
• An organization administrator working in a seller account other than their home account can now list and read the partner sales agents that account can connect through. Before, search and get with kind: "agent" refused them, although they could already open a partner’s connection form.
• The partner connection form now stops waiting after a set time and lets the publisher retry the step that failed instead of starting over.
• If your storefront passes buyer requests through to your own sales agent, you can now change your account’s domain. Before this fix, the domain change failed and was rolled back, because the storefront rejected the channels it already had. Your storefront’s channels and countries still come from your sales agent and can’t be edited on the storefront. Nothing to change on your side: retry the domain change if it failed before.
• On a pass-through storefront, a get_products request that filters by channel or country now reaches a sales agent based only on the channels and countries that agent declares (primary_channels and primary_countries). The storefront’s own channel and country settings no longer apply. If an agent declares channels but no countries, it gets requests for those channels in any country. If it declares neither, it gets every filtered request. If its declared coverage is malformed, it still gets none. Requests with no channel or country filter still go to every source on the storefront. Managed and mixed storefronts are unchanged. Sellers don’t need to change anything: to adjust which requests reach an agent, update the coverage that agent declares.
• Archived advertisers’ catalogs can be read again.
• Market readiness now counts a pass-through storefront’s sales agent in the countries and channels the agent declares. Before this fix, Apostra skipped every current agent’s declared coverage (primary_channels and primary_countries), so a pass-through storefront never qualified for a market through its agent. Agents that declare no coverage are counted the same way as before. Sellers don’t need to change anything.
• The deprecated v2 storefront endpoints that listed, opened, approved and rejected pending approval requests on an ad server Interchange manages for you (/api/v2/storefront/inventory-sources/{sourceId}/workflows and the routes under it) have been removed and now return not found. Review and approve media buys and creatives in Interchange’s approval queue, which in V3 opens with open_approvals. Those endpoints never queued anything you needed to act on: Interchange keeps a managed ad server’s own approval automatic, so every review happens in Interchange’s queue. Nothing to change on your side.
• Organizations created by converting an account before this release now have the features that come with the account’s plan, and keep them when the plan renews.
• save_creative drafts now accept campaignId and no longer need uploaded files. A draft is owned by its advertiser: send advertiserId, or send campaignId to have the owning advertiser resolved and the campaign recorded as the one the Creative is meant for (if you send both they must name the same advertiser). The draft is not on that campaign, its media buys, or any seller until a mode: "complete" save succeeds on the same creativeId, which then joins it to the campaign. You can also save a draft with only a creativeFormatId before any slot is filled, and bind files with sourceAssets on a later save; a formatKind draft still binds its files in the save that creates it. Completing still requires every required slot. Previously a draft with a campaignId, or with no sourceAssets, was refused.
• Every product you find through a storefront, whether the storefront hosts the seller or an external seller sits behind it, and whether you search with get_products, request_proposals or search, is now saved to your own account. The prices and details you see in product details and when you buy always come from your own search. Products you selected before this release need a fresh search before you can buy them, for external sellers as well as hosted ones. Media buys you already created keep their packages on the products they were created on, and seller updates to them keep applying.
• If your product feed names its own creative formats with ids that look like standard AdCP ones (for example a video_1080x1920 or display_728x90 published under your own format agent), buyers now get your whole product list. Previously one such format, declared as a canonical format that differs from what the standard-looking id implies, caused the entire list to be rejected. Nothing to change on your side; your format declarations are now trusted over name-based guesses, and ids under the standard AdCP format agent are checked as before.
• A publisher can now see which partner sales agents it can connect through. In a Seller account, search with kind: "agent" lists them, each with the partner’s name, whether it takes one shared URL or a URL per publisher, and the partner’s sign-up link when it published one. get with kind: "agent" and an agent’s ID reads one of them with the same fields. Buyers never see this list. This replaces what kind: "agent" returned in a Seller account, which was the organization’s own agents; those are still read with get and listed from a Developer account.
• Images sent to sellers now follow AdCP. An image whose width and height are unknown is refused before send with a reason you can act on (re-upload the image so its dimensions are recorded), instead of going out and getting a whole creative batch rejected by a strict seller. Every image also carries its size in bytes as file_size_bytes, which sellers that set a maximum file size need, and format is now the file format such as png rather than a MIME type such as image/png. The earlier file_size field is still sent alongside.
• Spotify buys that start “as soon as possible” now start about 20 minutes after launch, because Spotify refuses ad sets that would start sooner than 15 minutes out. Launches also wait longer for Spotify to confirm the new campaign is paused before adding ad sets. When Spotify refuses a request, its own reason now appears in the error.
• Archiving a draft media buy now stops a queued seller create for it, so the seller is not asked to create a buy you archived. Previously a create still waiting to be sent kept calling the seller after the archive and, if the seller accepted it, could turn the archived buy active. Nothing to change on your side.

​

5.1198.2 — October 19, 2026 at 11:43 PM UTC

• Seller diagnostics now distinguish failed source operations from failed connection checks, naming the affected operation when available instead of reporting that a working connection is down.
• Requests rejected by Apostra’s local validation now return a correctable request error without marking the seller’s inventory source unhealthy.

​

5.1198.0 — October 19, 2026 at 10:28 PM UTC

• In a Developer account, an MCP client calling save_agent or open_agent_page was refused with “you are in a buyer account”, and now the account is recognised as a Developer account so a person who administers it can register an agent and open it.
• The finalize refine action’s description no longer says it holds inventory; proposals don’t reserve inventory.
• Settings → Generative creative is rebuilt on the same frame as the rest of Settings. Your connected generation-provider keys are now a real table — provider, advertisers, default and status in aligned columns, with the same row menu as before — instead of a hand-built grid, and the pane carries one title over both the key list and the connect form.
• The confirmations for editing advertisers, rotating a key and disconnecting one are unchanged in what they ask and what they do.
• You can now read an archived advertiser and see its status as ARCHIVED. Its campaigns, catalogs, linked accounts, reporting, delivery, and creatives stay readable; catalog and linked-account writes, and all other changes, remain blocked until you restore the advertiser.
• When Murph opens Media Partners in the web app chat, the page now loads your media partners. Before, it sat blank for about ten seconds and then showed “Couldn’t load this view”. Nothing to change on your side.
• @apostra/mcp-app-host is now on npm (npm install @apostra/mcp-app-host). It is the host layer Apostra’s own web app uses to render V3 widgets: the bridge, the sandboxed frame, its CSP and the link guard, plus a helper that frames a widget’s published page so uploads work. The host contract page now links it.
• Product composition now comes from a Merchandising plan. An account with the custom modular sources add-on also has it. Before, an older separate access grant could turn composition on for an account with neither. That grant no longer has any effect, so an account with neither a Merchandising plan nor the add-on keeps its Listing and loses product composition. If you expect composition and no longer see it, check your plan under Plan & Billing or contact support.
• Settings → Messaging apps is rebuilt on the same frame as the rest of Settings, and every provider now reads the same way. Slack, Discord, Microsoft Teams and WhatsApp each get one card in a single list, instead of Slack sitting apart under its own “shared app” heading. Which app is ours and which one you register with the provider is no longer something the page asks you to understand before picking a provider.
• Inside a provider, a registered app’s status sits beside its name rather than across the card from it, the headings step down so a registered app no longer looks like a peer of the provider it belongs to, and Register location moved under the fields it submits — it previously sat in the row header, where it could be pressed while those fields were collapsed out of sight.
• Open the Media Buys Page on one seller account. open_media_buys_page now takes sellerAccountId, for a buyer company that transacts through a company-owned account, in place of accountRelationshipId; pass one or the other, not both.
• A seller can now connect to a partner’s shared sales agent through one form. Call save_inventory_source with only the agent’s agentId to open it. The form shows how the partner lets publishers connect, asks for the partner’s fields and credentials, creates the source and starts validation. The connection goes live once validation passes and the agent is certified. Credentials are entered in the form and never travel through chat. agentId is refused if sent with any other source field, and adding or changing a source you operate yourself works as before.
• A partner that runs a shared sales agent can now publish a sign-up link with its connection setup. Publishers who don’t have credentials yet follow it to get them. Add signupUrl, a public HTTPS page, to the connection setup you publish; leave it out if you hand out credentials another way.
• Updating an advertiser with sandbox in the request is now refused instead of silently ignored. PUT /api/v2/buyer/advertisers/{id}, the v2 buyer update_advertiser operation and Murph return IMMUTABLE_FIELD (HTTP 400, field: "sandbox"), matching V3 save_advertiser. Sandbox is set only when the advertiser is created and never changes; to move from sandbox to live, create a new advertiser without it. The Sandbox mode page and V3 account access guide now also say what sandbox work needs (accepted Terms, a plan and a verified organization, no payment route) compared with live spend.
• Six organization-advertiser REST operations are removed: PATCH /api/v2/organization/advertisers/{advertiserId}/operating-mode, POST /api/v2/organization/advertisers/lifecycles/{lifecycleId}/revoke, POST /api/v2/organization/advertisers/{advertiserId}/admissions/{admissionId}/decision, PUT /api/v2/organization/advertisers/{advertiserId}/admissions/{admissionId}/capabilities, POST /api/v2/organization/advertisers/{advertiserId}/self-service-invitations, and PUT /api/v2/organization/advertisers/{relationshipRef}/reconciliation. Requests to them are no longer served. To invite a client, approve, suspend, reactivate or revoke them, or change their role, use Client access in Advertiser settings or the save_advertiser_access tool. The roster read (GET /api/v2/organization/advertisers) and managed advertiser creation are unchanged.
• V3 save_agent no longer asks for an operation. A Seller account sends the Agent, a product mode and a reason to confirm the mode. A Developer account registers a Sales or Creative Agent by sending no agentId, or updates an owned Agent by sending its agentId with a new name, a certification request, or both. Create a buyer agent with save_buyer_agent; save_agent no longer lists a buyer kind. Over MCP, calls that still send operation keep working for now, and the HTTP API and SDKs take only the new shape.
• The Sessions Page’s page-only V3 tools are now registered for every seller account instead of as staff-only tools, and its two remaining hand-offs, brief artifacts and media-buy timelines, gain V3 homes. The whole Page now runs on V3. These tools are not visible to models, the public API or the SDKs, and the Sessions Page looks and behaves as it did. Access is unchanged: RFP, brief and media-buy-timeline reads still need the Demand entitlement, and retained conversations and private notes still need a signed-in, non-impersonated seller user.
• Settings → Support, API keys and Single sign-on now use the same frame as the rest of Settings. Each pane carries one title in its own card instead of a page heading sitting above a second frame, so the settings column reads as one surface rather than a page dropped inside it.
• Nothing moves and nothing is renamed: the same notification settings, the same key lists, and the same single sign-on setup, in the same places.
• A Spotify podcast promotion (Engagement Streams Promotion or Cross-promotion) that doesn’t say which show to promote is now refused before anything is created on Spotify, with a message saying how to name the show. Before, Spotify created the campaign, then refused its ad set, and left an empty paused campaign in your Spotify account. AdCP callers name the show in ext.promotion_target_id, as the show’s Spotify id, its spotify:show: URI or its https://open.spotify.com/show/ link.
• The Team pane — the account’s member list, in Settings and on the seller Team page — now uses the same frame as the rest of Settings. One title, with Invite members and the membership gear beside it, over the member table. Previously a page heading sat above a separately framed table, which read as two stacked surfaces.
• The members, their roles, and everything you can do to them are unchanged.
• If your organization still needs to accept the updated Terms of Service, every signed-in page of the web app now shows a banner with the acceptance deadline in your own time zone. Organization admins can open the terms from the banner and accept them; other members can notify their admins with one click. The banner stays after you choose “Review later” and disappears as soon as an admin accepts. After the deadline, access is restricted until an organization admin accepts. The banner appears only in the web app, not in Murph in other chat apps or in API responses.

​

5.1197.0 — October 19, 2026 at 8:39 PM UTC

• Every row on the Media Buys page now shows a one-line status, so you can see which buys have a problem without opening them: Behind pace, Needs you, Missing the buyer’s goal, or On track. Each row shows the buyer, its status, the one problem that matters most, and the flight dates. Select a row and it opens in place, showing the buy’s operator, budget, creatives, sources, billing and ID, whether it is pacing as expected, and whether it is hitting the buyer’s goal. When a goal is missed, the row says what was measured and in what units, such as “Cost per click is $3.60, against the buyer's $3.00 target”. The per-buy timeline is now an Open full timeline button inside the opened row. It is live for all sellers, with nothing to set up.
• The pacing answer compares spend delivered with the spend an even pace expects by now, and shows the share of the flight elapsed, daily spend against the daily rate that finishes on budget, and impressions delivered. When there is no verdict (no booked budget, no flight dates, flight not started, too little reported, or nothing reported), the row says why instead of drawing a bar. The goal answer shows the buyer’s goal, target, actual, who counted it, how recent the count is, and what you committed to. Vendor-counted goals name the vendor by its domain. If the vendor’s numbers aren’t shared with you, you see the score the buyer reported. A buy with no goal says so, and a buy with too little delivery reads “Too early to call”, not red. Buys managed by your ad server open to the same pacing and goal answers but have no timeline. Expected impressions are not shown yet, only expected spend.
• You can now test a buyer brief against your Brief Acceptance rules before a buyer sends one like it. On the AI Business Rules page, paste a buyer’s AdCP get_products request into Test a brief and run it against your active rules, or against edits you have not saved yet. Two answers appear side by side. Production shows what product discovery does with that brief today, and says when its limits applied: it reads the first 4,000 characters of a brief and can decline only on rules up to 4,000 characters or 80 rules. Beta shows what Cloudflare Clef, an evaluator we are trying as a possible replacement for today’s check, would decide: Pass, Needs review, Does not pass, or Inconclusive, with no written reason. A test never approves, declines, or saves anything. Any member of your seller account can run one, on the page only, not in chat. Nothing to change on your side.
• If you run a Listing storefront, Production shows “Not checked”: product discovery does not check Brief Acceptance on a Listing storefront, on a storefront that answers through a sales adapter, or on wholesale and refine requests. A Listing storefront’s rules apply when a submitted media buy is evaluated under manual approval. The AI Business Rules docs previously said Listing storefronts check briefs at discovery. We corrected them, and your storefront’s behavior did not change.

​

5.1196.1 — October 19, 2026 at 8:11 PM UTC

• Re-staging a campaign no longer fails or splits its draft media buy in two when the draft was booked through a Storefront. Before, adding products to such a campaign, or just changing its flight dates, could stop with “At least one product is required”, or put the new products in a second draft and leave the first draft’s dates stale. Now new products are added to the existing draft and its dates are refreshed. Adding a product from a Storefront that has no separate agent record also now works instead of being rejected.

​

5.1196.0 — October 19, 2026 at 7:45 PM UTC

• In the V3 API, save_billing now takes only terms (accept the current Terms) and paymentTerms (choose the payment terms sellers are asked for), alone or together, with no operation field. Requesting a card for your organization is now two tools: request_payment_authority returns a confirmation token, and confirm_payment_authority takes that token and returns the hosted link for your cardholder. Read the status of the handoff with get and kind: "billing", under paymentAuthority.status. The HTTP API and the SDKs accept only the new save_billing shape, so callers that sent operation or paymentAuthority must move to it. The MCP endpoint keeps accepting the earlier shape for now, so deployed agents keep working, and a later release removes it.

​

5.1195.0 — October 19, 2026 at 7:11 PM UTC

• LinkedIn products in the wholesale catalogue now show whether your connected LinkedIn ad account is ready to buy them, including whether its Company Page could be read and which inputs, such as the creative or the landing page URL, you still need to supply.

​

5.1194.0 — October 19, 2026 at 6:44 PM UTC

• Amazon Sponsored Products Manual now shows its execution readiness in the wholesale catalogue, so before you buy you can see that the product needs the ASINs you want to advertise.
• Executing a media buy whose lines name a Storefront but no separate sales-agent record no longer fails. Before, you could create and save such a buy as a draft, but executing it was refused. Those drafts now execute like any other buy, including drafts you saved earlier, so there is nothing to redo on your side. A Storefront that is paused, archived, or has no supported settlement currency is still refused, with a message that says why.
• Google Search products in the wholesale catalogue now show whether your connected Google Ads account can buy them: Search Conversions lists the conversion actions you can optimize for, or says you need to create one first.
• Creatives sent to an AdCP 3.0 or 3.1 seller under one of the seller’s legacy format IDs now name their assets the way that format does, for example banner_image and click_url for display_300x250_image. Before, they kept their canonical names, such as image and landing_page_url, and sellers that validate against the format rejected them.
• Media buys now show, price and validate each line against the product it was booked on. When one buy carries the same product on more than one line, each line reads its own product details (formats, pricing options, name) instead of whichever matching product was found first.
• When you browse the full Reddit product catalogue for a selected Reddit ad account, each product now shows whether that account is ready to buy it: whether it has a business profile to post ads as, and exactly one Reddit Pixel to attach to every ad group. If the account has no Pixel or no business profile it shows that setup is needed, and if it has several Pixels it shows that you need to choose one with context.conversion_pixel_id. If Reddit cannot be reached, readiness shows as unavailable and every product is still listed. Which products are listed, and their prices, do not change, and nothing changes in how you buy.
• Your reporting dashboard now includes every buy booked on your Storefront, including buys that were saved against the Storefront itself rather than a separate seller agent record. Before, those buys were missing from the dashboard’s delivery and spend totals, and a Storefront with no agent record showed nothing at all. Buys that were already counted look exactly the same. You don’t need to do anything.
• A creative you publish after a media buy exists now reaches every seller on that buy. Before, a seller whose products were booked directly on its Storefront, with no older seller-agent record behind it, was skipped: the creative was never sent to it and nothing told you. Those sellers now receive the creative and can review or reject it like any other. You don’t need to do anything.

​

5.1193.0 — October 19, 2026 at 5:52 PM UTC

• There is now one page to start from when you build an agent for Apostra: the Developer quickstart. It explains what a Developer account is, the three kinds of agent (sales, creative and buyer), and the path from build to connect, test, certify and the agent marketplace. It links the commands for connecting Codex, Claude Code, ChatGPT and other MCP hosts, the apostra-developer plugin and skills, the public GitHub repository and the SDKs, the AdCP spec, and the guides for building, signing in and certifying an agent. It also tells an agent to make get_status its first call in a Developer account, and explains what that call returns: each agent’s stage, what is stuck, and the next call to make.
• Every agent owner now sees their agent’s behaviour baseline on the Agent page, under Agent-wide behaviour. It shows which checks pass, which are flagged and which would block new buys, with what we saw and how to fix it. Stopping new buys on a blocker is still not switched on, so nothing about your buys changes today.
• The Agents page is now only in a Developer account, never in a storefront account. Open the account switcher, choose your Developer account, and it opens on the Agents page, where you register, test, and connect your agents. If your organization has no Developer account yet, choose Create on the Developer account row of your organization’s account list. Your agents, their connections, and your sources are unchanged, and the Powered by card in Source diagnostics stays where it is.
• Sessions can alert your team when your agent passes on a buyer request and send a daily summary after days with buyer-request activity. If your storefront has Sessions enabled, each team member can opt in to either alert in-app or by email. Buyers see no change.
• The Merchandising Simulator now calls its starter example a sample buyer brief, so sellers know it represents the request their agent answers. Its accessible label now uses the simulator name instead of an internal resource address. Simulations and their results do not change.
• A buyer agent that lists accounts at a seller now sees the reporting delivery configurations it set up on any account its company holds, not only on accounts first linked through its own credential.
• When Apostra stops a creative before sending it because no format the seller offers for the booked product can carry it, the send result now says so, with the error code creative_format_unresolved, instead of only “The creative could not be sent to the seller.” Creatives refused in a sync_creatives call for this reason now carry the code ADCP_CREATIVE_FORMAT_PROJECTION_FAILED instead of source_forward_failed, so they can be told apart from a seller that could not be reached.
• When a seller’s Session rollout is enabled, your proposal response can include a secure link to its immutable HTML proposal document. Use your existing buyer credentials to exchange the link for a short-lived download URL.
• When your seller Session rollout is enabled, buyers can securely retrieve the same immutable proposal document that your Session shows. The document and the proposal response use the same saved commercial terms.
• In a Developer account, reading an agent now tells you where it stands. get and search for an agent return its stage (built, connected, tested, certified or listed), the nextStage, and what is stuck (stuckOn: the reason and the exact V3 call that unblocks it), the same values get_status reports. The Agents list and the Agent page show the stage and what’s stuck, with a button for the next step. The text version of each read carries the same stage and reason.
• When you open Review & go live, the campaign receipt now shows the campaign budget, staged media buys and readiness state returned for that campaign. Nothing changes in campaign editing or creative management.
• Sessions search now returns results when you enter text. If a search request is invalid, Sessions explains that instead of reporting a service outage.
• Get media buy status now flags a booked media buy that is still not delivering more than 24 hours after its flight started. The buy reports operational_status: "attention_required" with the blocker not_delivering_after_flight_start, whether it is still waiting for the seller’s approval, for the seller’s ad server, or for creatives. A flight with start_time: "asap" counts as starting when the buy was booked. The buy’s internal_status does not change, and its pending_reason says what it is waiting on and who needs to act. The blocker clears as soon as the seller reports the buy delivering, or when it is paused, canceled or its flight ends.
• A VAST creative whose tag was saved without a version no longer stays pending on its first send to a storefront seller that approves it. Reading the tag’s version while the send was in flight counted as a change to the creative, so the seller’s approval of what was sent was discarded as out of date, the creative kept reading pending, and a media buy update was refused with “the seller has not accepted the current revision”. The version is now recorded without making a new revision, and a seller’s approval settles the creative as synced and approved. Changing the tag, or declaring a version yourself, still makes a new revision. Nothing to change on your side; a creative that is stuck pending settles the next time it is synced.
• When you read a Meta media buy, each package now names the product it was bought from (product_id) next to its package ID, so you can match each Meta ad set to the product you selected. A package whose product was not recorded when the buy was created is still shown, without a product. Nothing to change on your side.
• Updating multiple Google Ad Manager package budgets now either applies every change or restores earlier changes if a later one fails. If GAM cannot restore a package, the error names the packages that may still be changed.
• GAM image creatives missing a click-through URL now tell buyers to add one instead of retrying an error that cannot succeed.
• A product’s audience evidence snapshot id now stays reserved for the content it was first published with, even after the evidence is cleared or replaced or the product is deleted. Publishing different evidence under a retired snapshot id is refused with audience_evidence_snapshot_reused, so buyers that cached or recorded the snapshot never see the same id describe different evidence. Sending the same evidence again is still accepted.
• Delivery reports for Google Ad Manager buys booked under an account’s own advertiser, including no-spend sandbox buys, now show the impressions, clicks and video quartiles the buy actually delivered. Before, they read zero.
• When a buyer’s storefront attaches a creative this sales agent already holds to a new package, without sending the creative again, the sync response now reports that creative and the packages it reached.
• When a seller is still setting up or reviewing your account, creatives you save onto a draft media buy, and creatives resent after a click-through parameter change, now wait for the seller instead of failing. They go out on their own once the seller reports the account active, so you do not need to sync them again. If the seller refuses or closes the account, they stop waiting; contact the seller. Other creative syncs stopped by an account that is not ready still need to be synced again once the seller accepts it.
• Sellers can ask their assistant to practise a buyer brief, open a simulation, or review their storefront’s Sessions instead of being sent to campaign testing or told that a restricted direct read means no history exists.
• Agents no longer change an advertiser’s client access. Inviting a client, approving, suspending or revoking them, and changing their role are now done only in Client access on the advertiser’s Advertiser settings page, and the save_advertiser_access tool is no longer listed to agents, the public V3 HTTP API or the SDKs. An agent can still read who has access and what the page offers with get and kind: "advertiser_access", then send you to the page.
• save_buyer_agent now states the end state you want instead of naming an operation. With no id it creates an external buyer agent. With an id it makes exactly one change: displayName renames the agent, access replaces its advertiser grants, lifecycleState (active, suspended or retired) with expectedLifecycleState changes its state, and credentialHandoff: true prepares credential setup. Asking for the state an agent is already in succeeds and changes nothing, so a retry after a lost reply is safe. Calls that still send operation and lifecycle.action keep working for now, but they are no longer in the published definition, so move new callers to the shape above.
• New V3 seller guides cover creating and managing wholesale products, declaring the Scope3 Prebid module on a product, saving buyer instructions, and opening the Buyer Account Mapping, source diagnostics and modular source Pages. They are in “Sell with Apostra” under “Sell media”.
• The Sessions guide now points sellers to Session alerts, instead of saying Sessions sends no alerts.
• Spotify products are now named by campaign objective and delivery goal, the way Spotify Ads Manager organizes them: for example spotify_brand_awareness_reach (“Spotify – Brand awareness – Reach”) instead of spotify_audio_awareness. All seven products are renamed; what each one buys is unchanged. A product id returned before this change is refused when you create a media buy with it; call get_products again to get the current id.
• Spotify products now list the one delivery goal they actually optimize for. Before, six of the seven listed a goal Spotify doesn’t optimize them for, extra goals, or values Spotify doesn’t accept: Audio Awareness showed Impressions but optimizes for Reach; Podcast Audio showed AUDIO_LISTENS, and both podcast promotion products showed PODCAST_STREAMS instead of Streams. Display Awareness and Video Takeover dropped goals they never used. What each product buys is unchanged.
• Testing your own sales agent with the test-sales-agent skill now sets up the sandbox advertiser with markets and channels, so a seller account is provisioned and the sandbox buy can launch instead of stopping at “complete advertiser setup”. The skill (now 1.5.4, the default version), and validation runs that Apostra runs for you, stop before staging a buy when the advertiser still owes a setup step or its seller account setup failed, and report what is missing. If you pinned an earlier version, switch to the default to get this; nothing else changes on your side.

​

5.1192.0 — October 19, 2026 at 1:38 PM UTC

• The account switcher in the top bar now groups your accounts under their organization’s name, with the organization you’re working in listed first, and uses the full height of the screen. If you can open eight or more accounts, type in the search field at the top to find one by its own name or its organization’s, then press Enter to open it.
• The Agent page now shows its Overview, Test Agent and Inventory sources tabs for Developer accounts in the web app, so you can reach your agent’s tests, capability declarations and AdCP 4.0 readiness from the page.
• Buyers no longer see an old delivery error after that same seller task later succeeds.
• Changes to a live media buy at some sellers now reach the seller. We used to send the seller our own package id, which it did not recognise, so the change silently did not apply. An update we cannot match to the seller’s package is now reported to you as not sent, instead of failing without a word.
• When your sales agent’s behaviour baseline marks a check as a blocker, fixing it is now the next step on its Agent page. The page says what Apostra saw, how to fix it, and links the check’s section of the Sales Agent requirements. A missing capability declaration still comes first.
• When your seller Session rollout is enabled, store each inbound AdCP proposal as an immutable RFP document and queue its default HTML representation in Session. Sellers can review the document there; no action is required.
• A sales agent’s live certification pass no longer counts while its behaviour baseline shows a current blocker on any active Source that uses it, such as creating a second account for a repeat sync_accounts. Until the blocker clears, the Successful transaction go-live step stays open and publishers in other organizations cannot go live on the agent; their connection reports AGENT_BEHAVIOUR_BLOCKED. Connections already live stay live.
• Calls with the status NOT_SENT in your source’s Diagnostics Calls list are now described accurately: Apostra didn’t send the call because a step before sending it failed, such as discovering your agent’s endpoint. The reason can be on either side, including your endpoint timing out, refusing the connection or rate-limiting the request. These calls are now also listed under their AdCP task name (for example get_products), so filtering by task finds them. They still don’t count against your agent’s health or behaviour checks.
• The browser origins setting no longer does anything, so its REST endpoints (/api/v2/browser-origins) and the list_browser_origins, create_browser_origin, and delete_browser_origin MCP operations are deprecated and will be removed on 18 November 2026. Nothing to do: agents and browser apps sign in and call the MCP endpoints without registering an origin.
• The docs now list the AI providers Apostra works with (Anthropic, Amazon Web Services, Google Cloud, Cloudflare and OpenAI) on a new AI providers page, linked from Support.
• The campaign readiness page now documents catalog_sync_unavailable and what to do about it.
• A new guide explains how to render Apostra’s V3 widgets, including Creative Library and file uploads, in an MCP Apps host you build yourself. It also documents how a host or agent uploads images, video and audio from its own code, with no widget, using prepare_creative_asset_upload and finalize_creative_asset_upload.
• A campaign launch on an Apostra seller whose inventory runs on Apostra’s managed sales agent now says what the advertiser still needs when the seller has no account for it yet. Before, the buy failed as “execution failed” with no reason. Now it fails with ACCOUNT_SETUP_REQUIRED and names the step: set the advertiser’s markets and channels, enable the advertiser for the seller, or wait while the account is set up or approved. Retry once the seller shows the advertiser’s activation as active.
• Sessions now shows your team the recorded commercial facts behind an agent response: its selling approach; offered price against the target, floor and, when applicable, ceiling; available capacity; applied buyer terms; relevant seller history; and the recorded rule behind a pitch, counter-pitch or pass. It appears only in Sessions enabled for your storefront. Buyers cannot see it. The view uses facts recorded with the response, not the agent’s free-text reasoning. Nothing to change on your side.
• Advertiser creative library listing now returns a validation error for malformed or out-of-range advertiser IDs instead of a server error.
• If your storefront uses an ad server that Interchange manages for you, you can list, open, approve and reject its pending approval requests through the inventory source workflow endpoints again. Those calls had been failing with a not-found error. A rejection reason now reaches the ad server as the rejection note. Nothing to change on your side.
• Microsoft 365 Library setup now skips locked, archived, deleted, or otherwise inaccessible SharePoint sites while keeping accessible libraries available. Loading more sources returns a bounded batch of libraries instead of one at a time, and each library name now identifies its SharePoint site. Folder search continues to use Microsoft Graph across both site names and folders inside site libraries.
• Reading billing now includes the plan. get with kind: "billing" returns the organization’s current and upcoming plan, the offer it can accept at its exact version, its renewal with the changes allowed on it, whether a plan help request can be filed, and its ten most recent invoices. The next action now names plan steps, such as choosing a plan, and carries a severity. The read still leaves out card data, secrets, setup tokens and payment or invoice links. In the Python SDK, the eight auto-generated GetResultKindBilling… response type names for this read now include the new fields, so they have new names. The old names remain as aliases of the new types, so existing imports keep working, and the types they name gain the new fields.
• A creative a seller has already approved is no longer sent back for review when the buyer rebuilds a buy, adds products or changes only per-buy tracking values. Any edit to the creative itself is still reviewed.
• The fix that sends a creative under its stored legacy format ID now also covers sellers that don’t declare which creative format they accept. Those sellers get the legacy format either way, so a creative stored with one of the seller’s own format IDs is now sent under that ID instead of being refused.
• If your Media Company is on a current Merchandising plan (Storefront agent, Storefront agent + Distribution, or Enterprise - Storefront agent), you can now create advertisers and launch live campaigns on your own inventory. There is no enrollment step, so there is nothing to set up. Each live launch still passes creative approval, funding, publisher authorization, and seller approval. Listing and Listing + Distribution plans include sandbox campaigns only, which spend nothing and are available to every Media Company. Accounts created before plans existed keep their current live access until they are placed on a plan. Accounts still on a legacy Merchandising arrangement that includes Custom sources keep their current access and get live managed campaigns when they move to a current plan.
• A creative the publisher has approved no longer fails while a seller whose own team traffics creatives is still working on it. It waits in the seller’s trafficking queue for up to 7 days and reads approved once the seller confirms it is trafficked; after 7 days without an answer from the seller, the delivery fails. If the seller declines it, the delivery fails with the seller’s refusal.
• Read-only members can no longer make changes through Murph; they can still ask questions and view everything their role allows.
• Launching on OpenAI Ads no longer fails with Expected a value <= 100, but got 500. The adapter asked OpenAI Ads for 500 rows at a time when it looked up a location, and OpenAI Ads allows at most 100 for that lookup. Every OpenAI Ads list request now asks for at most 100 rows and follows the cursor for the rest.
• A publisher’s connection to a sales agent that another organization owns can now go live once that agent passes live certification. Before, these connections waited on a retired check that could no longer be met, so none could activate. Until the agent passes, the connection now says so plainly, and its owner can mark it ready for certification on the agent’s page. Sources served by your own organization’s agent do not need certification to go live.
• Partner Program readiness now looks at live-traffic certification. An organization is ready to operate agents for other organizations’ clients once it owns a claimed sales agent that has passed live certification on the same terms the Successful transaction readiness check uses. Before, readiness required the retired production certificate that no sales agent can earn, so nobody could be ready. When an agent is not ready, the next step now says to choose Ready for certification on the agent’s page and links to How certification works. The readiness reason value production_certification_incomplete is unchanged for existing integrations.
• The v2 storefront API is retired for API callers. Calls to /mcp/v2/storefront and /api/v2/storefront made with an API key or an OAuth client now get a “moved to V3” refusal that names https://api.apostra.com/mcp/v3 (MCP), https://api.apostra.com/api/v3 (HTTP) and the V3 quickstart. Apostra’s own app and the partner-agent OAuth callback keep working.
• Accounts turned into organizations before this release get back the features they lost in the change: their free and manually granted features now apply to the organization again.
• The “Sell media” docs now start with V3. The seller RFP lifecycle and RFP performance guides moved to /v3/, and the old /v2/setup/v3/ links redirect. The v2 storefront API pages are marked deprecated, with a link to the V3 replacement where one exists.
• Impression trackers set on an advertiser or campaign are now sent to the seller with a VAST or DAAST URL tag, as tracker assets beside the tag, the same way Apostra’s own trackers are. Before, they were dropped. A tag the seller receives as the hosted wrapper, or under a legacy format reference, still carries no advertiser tracker, and Apostra logs each one it did not send.
• Campaign proposal requests now send the Campaign ID as the AdCP opportunity ID when the buyer’s rollout is enabled, so sellers can keep related requests in one Session.
• Spotify audio creatives are now sent to Spotify as stereo audio. Apostra decodes an MP3 and uploads it as 16-bit stereo WAV, copying a mono recording to both channels, and copies a mono 16-bit WAV to both channels. Stereo WAV and stereo OGG files are sent unchanged. A mono OGG file, or a mono WAV in another format, is refused with a message asking for MP3 or 16-bit WAV, because Spotify’s ad specs call for stereo. When Spotify refuses an upload, its own reason is now kept, so we can tell you why.
• Sessions now keep a buyer’s related compose requests together when they carry the same verified AdCP opportunity. Each request records a plain buying stage, from exploring through booked, so your team can follow the opportunity without reading or relying on the buyer’s brief text. Requests without a verified opportunity remain separate Sessions.
• V3 adds open_media_partners_page, the new name for the tool that opens the Media Partners page, where you connect to sellers. It takes the same inputs and opens the same page as open_connections_page. “Connections” also names the cloud-drive and data connections under Settings, so the new name says which page you get. open_connections_page keeps working for now. It will be removed once ChatGPT has approved the new name, so move V3 integrations to open_media_partners_page. v2 buyer is unchanged.
• If you upload your own wholesale pricing, the notice you get in the last 7 days before it expires now gives the expiry date and says your products are still on the market, with an Upload wholesale pricing action. Before, that notice said your products had already come off the market. Upload a current feed before the date to keep them listed. If the date passes without an upload, the existing “wholesale pricing out of date” notice applies, as before. Nothing changes if your pricing comes from your ad server.

​

5.1189.0 — October 19, 2026 at 6:20 AM UTC

• A media buy’s creative refusal details now list creatives in the order the buy lists them.

​

5.1188.4 — October 19, 2026 at 5:22 AM UTC

• Show when a seller still needs to finish setting up your account before a media buy can launch, in discovery results and after saving a draft.

​

5.1188.3 — October 19, 2026 at 4:58 AM UTC

• When a buyer saves a draft that cannot launch because their account is not mapped to an inventory source, you now receive one work item naming the buyer account and source. It closes automatically after you add the mapping.

​

5.1188.2 — October 19, 2026 at 4:44 AM UTC

• When a seller cannot accept a creative sync, buyers now see that send as failed instead of successful.
• Reliable Reporting’s controlled-staging grace period for an overdue official report now follows the seller’s declared reporting cadence, not acquisition polling or retry timing. No action is required.

​

5.1188.1 — October 19, 2026 at 4:12 AM UTC

• Post-approval creative syncs and media-buy updates now keep using the seller catalogue partition recorded for the booked buy, so account-scoped booked products remain available.
• Creative sync now identifies a Storefront format-projection refusal as a local retryable issue instead of a seller rejection.
• Creative sync now reports when Apostra cannot read a booked product required by a legacy seller, instead of incorrectly treating it as a seller format problem. The response names the unread product IDs and records that Apostra must restore the catalog record before the creative can sync.
• Repeated campaign launches no longer return an internal error while an earlier media-buy submission is waiting to retry. The API now returns 409 CONFLICT and does not start another seller request or spend attempt.

​

5.1188.0 — October 19, 2026 at 3:51 AM UTC

• Campaign launches that are waiting for an event source to finish binding keep waiting without exhausting their delivery retries. No action is needed.
• Campaign creative sync now uses the seller format declaration recorded for the buyer’s booked product, so creatives to some existing storefront media buys are planned with the correct format.
• Direct sales-agent media buys now keep their submitted-task handles separate from Storefront approval handles, so status polling continues against the sales agent instead of treating the buy as awaiting Storefront approval.
• Keep a proposal available for retry when staging its draft media buy fails. A proposal is shown as bound only after its draft media buy is created and linked.
• Fix partial v2 campaign budget updates so omitting currency retains the campaign’s existing currency.
• Approved media buy edits now preserve buyer pause ownership, so reactivating a campaign does not resume a media buy you paused individually.
• When create_media_buys stages a buy, its receipt now reports inherited creatives omitted for missing legacy formats or incompatible canonical formats.

​

5.1187.1 — October 19, 2026 at 2:39 AM UTC

• Seller Setup now shows, for each Google Ad Manager source, that its Google Ad Manager user must be able to approve orders, which built-in roles cannot, and how to fix it. The item shows as blocked while Google Ad Manager reports an approval problem.

​

5.1186.0 — October 19, 2026 at 1:25 AM UTC

• When a seller reports a different budget, rate or flight end for one of your media buys than the one you booked, the media-buy status now shows it: the buy and its campaign report attention_required with the blocker contract_out_of_line. This holds while the buy is live and for 7 days after its flight ends, including after it completes. The buy’s own status and delivery signal do not change, and there is nothing to change on your side: Apostra takes the difference up with the seller, and the blocker clears when the seller’s report matches your booking again, or when you update the buy to match.
• When you accept a multi-account IU plan in the IU Plan task, the confirmation now shows that the plan is active for your new organization.
• Turning an account into an organization no longer drops the features it had. The new organization keeps the account’s free, beta and manually granted features, at the same versions and with the same end dates.
• In a Developer account, get_status now shows where each agent stands: its stage (built, connected, tested, certified or listed), what is blocking the next stage, and the exact V3 call that unblocks it. It also returns build calls for sales, creative and buyer agents and links to the developer docs, the AdCP specification, the Apostra GitHub repository and the apostra-developer plugin.
• V3 is in preview, so two next actions changed: build_agent is now one build action per agent kind, and list_agents is gone because the agents are in the status itself.
• The Listing page no longer asks you to add Distribution when your account already includes it. If your Seller Account’s package includes Listing + Distribution, at any version, step 4 now goes straight to pointing your domain at Interchange.
• Updates, pauses and cancels on a media buy placed through a connected ad platform now act only in the platform account the buy was created in. Before, if your connection had several ad accounts, a change that named a different account, or reached the buy through an advertiser whose account link had since moved, could be applied to an order in the wrong account when the platform reuses order ids across accounts. Now that change is refused before anything is sent to the platform, with a message naming the mismatch. Nothing to change on your side unless you see that refusal: retry without an account, or restore the original account link under Settings → Connections. Buys created before the account was recorded keep their existing behavior.
• Guaranteed Google Ad Manager orders that Apostra approves go live without waiting on an extra activation step. If your GAM user can’t approve an order, Apostra now tells you for guaranteed orders as well, and approving that notice in Apostra no longer tries to approve the order on your behalf: approve it in Google Ad Manager (or give our user permission), and the buy moves on automatically. A new setting, managed from the storefront, decides whether guaranteed buys that exceed your ad server’s forecast are booked anyway (the default) or held for your review.
• A GAM connection using a known built-in role that cannot approve orders is now flagged before buyers can list the storefront, with instructions to grant approval or add an approver.
• A GAM buy now confirms only when GAM holds the key-value and audience-segment targeting the sales agent sent; a line item GAM stored without it, or with different values, reads back as a mismatch on custom_targeting instead of confirming.
• GAM delivery reports for wholesale video products now include zero-valued completed views and quartile data when GAM measured no video events.
• A sandbox advertiser’s buy of a product from a linked partner storefront no longer reaches the partner’s provider. Until now your storefront passed the buy to the partner as an ordinary curator buy, and the partner could not tell it was a sandbox buy, so a partner source connected to a provider’s campaign system could create a real campaign there. Your storefront now works out that the buy is a sandbox buy and tells the partner, which records it as a sandbox campaign waiting to start and sends nothing to the provider. If the partner is connected to an ad platform through an adapter, the buy is refused with sandbox_buy_refused_for_adapter and nothing is created at the platform. A sandbox order that already exists at an adapter platform can still be paused or cancelled, but not resumed or changed. If your storefront cannot confirm the buy’s sandbox status, it sends nothing to the partner and the buyer retries. A buy waiting for the partner’s approval is recorded as a sandbox buy when it is queued, so approving it later still sends nothing. Live advertisers’ buys of linked partner products are unchanged.

​

5.1185.0 — October 18, 2026 at 11:50 PM UTC

• A Google Ad Manager user that can’t approve orders leaves every buyer order in draft, so Apostra now stops you from listing a managed Google Ad Manager storefront on Apostra, or making it public, while Google Ad Manager shows that problem (a refused approval, or a built-in role such as Trafficker). To clear it, give that user the Administrator role or a custom role with order approval, or add it as an order approver. Storefronts already listed stay listed, you can unlist at any time, and if your user can already approve orders, nothing changes.
• Live certification results now say what happened and what to change. A skipped use case shows the explanation and fix from the certification guide, followed by the detail the run recorded and your agent’s own message, instead of a raw code such as seller_sandbox_account_failed. The Agent page’s next step also says where certification stands: ready to request, running, or certified.
• You can now say which kind of agent to build when you create one in a Developer account: sales, creative or buyer. save_agent with operation: "developer_create" takes kind as sales, creative or buyer, replacing the earlier SALES and CREATIVE values, so send the lower-case words from now on. A sales or creative agent is registered as an Agent record, as before. A buyer agent is registered as a buyer agent, the same record save_buyer_agent creates, and it takes no operator and no idempotencyKey, so search before you retry because a repeated request creates another buyer agent. sales and creative still require idempotencyKey. Any other kind is refused with a validation error.
• The Developer account’s Create Agent launcher, developer_open_create_agent, also accepts an optional kind, and the Create Agent Task opens with that kind chosen when you pass one. For buyer the Task explains that a buyer agent is registered through your assistant rather than from the Sales and Creative form. Leave kind out and the Task opens unset, as before.
• Creative formats now show a seller’s current requirements after Interchange next refreshes that seller’s product catalog. Before, a change such as a seller starting to accept extra video tracking pixels stayed hidden from search and get for creative_format until someone ran product discovery against that seller, which on a quiet seller could take days. This applies to products that have already been discovered; a product nobody has discovered yet still appears after its first discovery. Nothing to change on your side. If you saved a creative format id before the seller’s change, search again for the current one.
• Signing up to buy media as an Advertiser works again. The signup put new Advertisers on a free plan that the current Rate Card no longer offers, so it stopped with “The direct Advertiser package is temporarily unavailable.” New Advertisers now start on Connect & Buy, the free Buyer plan with no monthly commitment, and pay only for what they use.
• Creatives to some storefront sellers that were refused after a media buy was created now sync using the booked product format for the buyer’s account.
• Publishers no longer wait for a partner to approve their connection. When a publisher completes a partner’s invitation with the partner’s credentials, the connection is accepted and checked straight away, and it goes live on its own once the check passes and the partner’s sales agent is certified. Partners who run a shared sales agent no longer review or accept each publisher: a publisher who holds the partner’s credentials, or signs up with the partner, connects directly.
• When a seller supports only AdCP 3.0, creative syncs now send the supported creatives and report HTML5 bundles or URLs with macros as failed instead of blocking the whole batch. Use a seller on AdCP 3.1 or later for those creative types.
• A media buy that ends at its flight end is now only finished once the seller agrees. Apostra keeps checking with the seller for up to 14 days after the end. If the seller still reports the buy active more than 24 hours after the end, Get media buy status shows the buy as attention_required with the blocker seller_still_active, because the seller may still be delivering. If the seller never confirms the end within 14 days, it shows seller_end_unconfirmed. The buy stays COMPLETED either way: a seller’s answer never reopens it. Buys that ended before this release are not checked again.

​

5.1184.0 — October 18, 2026 at 10:25 PM UTC

• The counts on your Advertisers page now cover your whole roster, not just the first 500 advertisers. The House, Partner-managed, Self-serve, System and Needs you chips are counted by the server, and picking a chip or Show sandbox loads the matching advertisers instead of filtering what the page already holds. A count with a trailing + means a source of advertisers was cut off, so the real number is at least that high. See Storefront overview.
• When a media buy is refused because a seller’s inventory source is withheld, the error now says why instead of the generic “temporarily withheld” text. It names whether the source was not eligible for the request, held back by the seller’s latest readiness check, blocked by the seller’s agent behaviour baseline, could not have its product formats verified for your account, or has no ready execution currency. When the cause is not yours to fix, re-run get_products and try again later, as before.

​

5.1183.0 — October 18, 2026 at 9:46 PM UTC

• A creative chosen for a specific format now reaches AdCP 3.1 sellers that list each product format both ways, as a format option and as a format ID. Before, Apostra refused to send it, because the seller listed more than one format of the same kind. Account syncs to a seller on AdCP 3.1 or earlier now carry only the account fields that seller can read: the brand domain, brand ID, operator and sandbox. Advertisers that differ only in operator unit, currency, timezone or brand countries share one account at that seller. Sellers on AdCP 3.2 still receive the complete account key.
• Advertisers created earlier now load their campaigns and settings in Managed campaigns, and a campaigns list that can’t open an advertiser now says so instead of showing a generic error.
• Needs you now means one thing everywhere: an advertiser whose setup is waiting on your decision. An advertiser waiting on the buyer for information, or held for billing, no longer adds to the needs-setup number on each group chip of the organization Advertisers list, so that number can read lower than before. The Advertisers page and the navigation already counted this way. The Advertisers read also returns whole-roster counts for each group, ready for the page to show. See Storefront overview.
• A media partner that discovery leaves out of a search now reports its real cause. get_products skipped results (ext.interchange.storefront_results[].outcome) carry an optional skip_code such as advertiser_not_accessible, account_requests_blocked, go_live_blocked or coverage_mismatch, so a skip is no longer labelled eligibility by default. reason_code keeps its three values.

​

5.1182.1 — October 18, 2026 at 8:59 PM UTC

• Sandbox advertiser documentation now distinguishes Apostra’s protected no-spend workflows from provider calls that require the provider’s own sandbox or test account. Do not rely on sandbox: true alone to prevent a provider account from reserving, delivering, or spending.

​

5.1182.0 — October 18, 2026 at 8:39 PM UTC

• A verified person who chooses Buy media on a company domain held only by an inactive, archived Seller account now finishes signup even where open self-serve Buyer signup is closed. After retiring the inactive Seller, signup re-checked whether the domain still had one, found none, and refused the person with “Buyer account signup is not currently available”, leaving their new Buyer account unusable.
• New sales agent connections need a credential. Connecting an agent with no authentication is now accepted only from a Developer account, for testing, because anyone who can reach the agent’s endpoint could act on that connection. Connect with an API key, a username and password, OAuth, or OAuth client credentials from the agent’s operator instead. Connections that already use no authentication keep working, and adding another source on an agent you already connected keeps that agent’s authentication.
• Your recent chats now appear in the left rail as soon as you open Apostra, and the setup checklist shows its loading and retry states. Before, recent chats stayed hidden until you opened a conversation, and when the setup checklist failed to load the rail showed nothing, with no way to retry. You don’t need to do anything.

​

5.1181.1 — October 18, 2026 at 8:05 PM UTC

• Plan & Billing loads for Seller accounts again. Opening it in Murph showed “Couldn’t load your account. Try again shortly.”; it now shows your account, and you can accept current terms, manage payout details and choose an IU plan.
• Murph no longer points people to a Settings → Advertisers page that no longer exists.
• A sandbox advertiser’s buy on a storefront connected to an ad platform through an adapter (Google Ad Manager, Meta, LinkedIn, Amazon and the others) is now refused instead of sent. Until now it created a real order, campaign or budget in your ad platform, even though sandbox campaigns are meant to be no-spend. The buy is refused with sandbox_buy_refused_for_adapter before anything reaches the platform, whether it runs straight away or after your approval. A buy that waits for your approval is recognised as a sandbox buy from the fact recorded when it was queued, so it is refused on approval even if it can no longer be matched to its advertiser; buys already waiting before this release are judged by their advertiser, and one that cannot be matched to an advertiser is refused when you approve it, so the buyer submits it again. Creative uploads and changes for that buy are refused too. A sandbox order that already exists at the platform can still be paused or cancelled, but not resumed or changed. To test an adapter storefront, buy with a live advertiser. Sandbox campaigns on modular sources are unchanged by this release.
• When a seller rejects a creative sent automatically to a draft media buy, the creative is now reported as failed with the seller’s reason straight away. Before this fix, the rejected creative was sent to the seller again on every retry until the retries ran out, and the buyer only saw a generic failure at the end. Temporary seller failures are still retried.
• An HTML5 or display-tag creative no longer gets its size from a number in its filename, such as banner_300x250.html. A misnamed file used to reach sellers at the wrong size. The size now comes only from what was measured in the creative itself or declared with the creative, and a creative that has neither is sent with no size instead of a guessed one. If you upload loose HTML, add <meta name="ad.size" content="width=300,height=250"> to the file or declare the size when you save the creative. Creatives that already have a stored size keep it.

​

5.1180.1 — October 18, 2026 at 6:50 PM UTC

• A verified person who chooses Buy media on a company domain that only an inactive, archived Seller account still held now gets their Buyer account. Signup had been stopping with “No matching active customer was found” after retiring the inactive Seller, leaving the new Buyer account unusable.

​

5.1179.2 — October 18, 2026 at 5:39 PM UTC

• The separate Advertisers page and the Advertisers section in Account settings are gone. In a Media Company account, open an advertiser’s settings from the pencil beside it in the left rail to see its status and manage who at the client has access. Older links to the Advertisers page open the Advertisers workspace, and older links that name one advertiser still open that advertiser’s chat. Nothing to change on your side.

​

5.1179.1 — October 18, 2026 at 5:24 PM UTC

• Your Managed campaigns workspace now follows your plan. If your plan includes Merchandising, Managed campaigns and the own-advertiser and campaign tools are available. If it doesn’t, they aren’t, whatever the storefront setting says. Merchandising comes with the Merchandising plan. Settings → Selling mode shows which one you have and takes you to Plan & Billing to change it.
• For API integrations: operatingMode on /api/v2/storefront is unchanged. You still write it and read back the value you stored. It no longer decides what the storefront can do; your plan does. It still decides which plans you are offered.

​

5.1177.0 — October 18, 2026 at 4:07 PM UTC

• Your Agent page now shows whether your sales agent is ready for AdCP 4.0. The Test Agent tab lists six checks (release versions, Reliable Reporting, request signing and webhook signing under RFC 9421, brand.json operator identity, and the compact lifecycle) with what we found and what to change for each one that fails. The Overview tab shows a short notice if your agent declares no AdCP release at or above 3.2, which will fail certification soon, or isn’t ready for 4.0. Nothing to do today: the verdict is advisory, doesn’t change your certification or block any buy, and only your organization and Apostra staff see it. No agent can show as ready yet, because the compact lifecycle check waits on a certification we haven’t released. See Getting ready for AdCP 4.0.

​

5.1176.1 — October 18, 2026 at 3:33 PM UTC

• Sellers whose storefront has a source connected to a provider, such as Epsilon Retail Media or FreeWheel automatic execution, can now clear the “Successful transaction” check with a sandbox campaign like every other modular seller. The checklist and get_status no longer tell them to avoid it. For a product from one of those sources, Apostra records a sandbox advertiser’s campaign instead of sending it to the provider, so it cannot create a real campaign or a charge there. The campaign does not test the provider connection, so use the provider’s own sandbox or test account for that. The “Pass the go-live test” guide covers both cases.
• The House, Partner-managed and Self-serve groups now sort advertisers the same way on every Advertisers view. On the Advertisers page, a self-serve advertiser you own now appears under Self-serve instead of House, and a connected partner’s advertiser appears under Partner-managed whatever its operating mode. The setup counts on the group chips follow the same grouping.

​

5.1175.0 — October 18, 2026 at 2:30 PM UTC

• If you are adding Python SDK support, install apostra with Python 3.11 or later. It ships alongside @apostra/sdk for TypeScript and covers the V3 operation surface. V3 response variants are typed by kind, and generated type names are stable and contextual rather than numbered. Existing TypeScript integrations need no change.
• In ChatGPT, asking Apostra to open a connection’s account in Media Partners works again. ChatGPT still uses the version of open_connections_page it approved, where accountId names the connection account, and on /mcp/v3 that call was being read as a request to switch to that account. On /mcp/v3, a call with connectionId and accountId but no connectionAccountId once again opens that connection account. Use connectionAccountId for new integrations.
• Several /mcp/v3 tools now describe their effects accurately to MCP clients. save_seller, save_material and save_advertiser_access are marked as reaching outside Apostra (they fetch brand and document sources, or email invitations), and save_agent is marked as able to overwrite existing settings. open_page stays read-only, and its description now says that creating or attaching an Agent happens inside the source diagnostics Page, not when the Page opens. Tool behaviour is unchanged.

​

5.1174.0 — October 18, 2026 at 1:52 PM UTC

• Buyers can list reporting-only Meta campaign identifiers on a connected account and read their AdCP delivery without creating a campaign mirror. The new routes do not make those campaigns editable or expose their targeting, packages, budgets, or optimisation details.
• Monetization: none. This release adds no billable feature, packaging, pricing, entitlement, or seller-visible setup. It is available after the parent and child normal deployments to existing customer-wide connected Meta buyers; buyer agents and advertiser-limited principals remain denied. Existing users need no migration, reconnection, or action unless they choose to call the new routes, and no selected or mapped account is required.
• Native impression trackers now reach AdCP 3.0-only sellers in the URL tracker shape that release accepts.
• When OpenAI Ads refuses a campaign request as invalid (HTTP 400), the launch now fails as an invalid request you can correct, instead of an “Upstream request failed” outage that was retried. The refusal’s code, message and field are logged for support. A buy set to start asap no longer sends OpenAI Ads a start time that has already passed by the time the request arrives; OpenAI Ads starts such a campaign at once.

​

5.1173.3 — October 18, 2026 at 1:29 PM UTC

• Resyncing a creative now replays each package’s own desired assignment instead of applying a buy-wide assignment to every compatible package.
• Products on Google Ad Manager sellers that offer signal targeting options now also declare signal targeting support, so buyers that check a product’s declared targeting can target those signals.

​

5.1173.2 — October 18, 2026 at 1:04 PM UTC

• The seller-history co-op page, the sellerHistoryCoop field text on save_buyer_operator and PATCH /api/v2/buyer/readiness/operator, the join and leave previews and the Settings copy now use the wording of Section 6.3 of the Terms of Service. The page says the seller-history co-op is how an account takes part in the data co-op, and lists what the Terms promise next to what exists today: contributing performance data and enhanced matching (other members’ pooled seller history, and automatic selection that ranks with it) are available, while optimization recommendations and pricing signals are not available yet. Pricing signals will mean wholesale product avails. Seller history never pools what a seller charged a buyer. The pages also state that opting out does not affect access to standard Platform features, and that the market-wide signals in Section 6.2 sit outside the co-op. Nothing about how the co-op works changes. Nothing to do on your side. What a member shares and gets: docs.interchange.io/v2/concepts/seller-history-co-op
• Fixed a gap where editing a creative could skip re-sending it to the sellers it was already sent to. The skip happened when one of those sellers was a Storefront with no seller agent record. The edit now reaches every Storefront the creative was sent to.

​

5.1173.1 — October 18, 2026 at 12:45 PM UTC

• Repeated blocked GAM approvals now keep one operator task per order instead of creating duplicates.
• Reading accounts from a managed sales agent works again for accounts subscribed to the account change feed. Since 15 October, account lists and account syncs for those accounts returned a schema validation error.

​

5.1173.0 — October 18, 2026 at 12:31 PM UTC

• Organization admins can now archive an account that the archive screen wrongly said was already archived. An account counts as archived only once it has actually been switched off, so an account left half-archived by an earlier attempt can be archived again to finish the job.

​

5.1172.0 — October 18, 2026 at 11:54 AM UTC

• Leaving the seller-history co-op now takes effect from the day you leave, as Section 6.3 of the Terms of Service says, instead of withdrawing everything at once. When a member leaves, it stops reading pooled seller history right away and its buys that complete afterwards are not shared. The buys it shared while a member stay in the pool and keep counting in published figures under the same rules as every other buy, so a leave no longer removes or changes a published figure. Previously a leave withdrew every published figure its buys stood behind, and the docs, the save_buyer_operator field text and the Settings confirmation said so; they now describe the new behavior. Rejoining counts all of the account’s completed buys again. If you joined expecting a leave to take your results back out of the pool, they stay. Nothing else changes: joining, the minimum of 3 operators and 5 judged buys, rounding and what a member reads are as before. What a member shares and gets: docs.interchange.io/v2/concepts/seller-history-co-op
• Sellers can now see the retained opening words their agent sent in a Session response summary. The summary makes clear that only the summary is private; it does not change the buyer’s response.

​

5.1171.0 — October 18, 2026 at 11:24 AM UTC

• Microsoft 365 Library setup now discovers followed and accessible SharePoint sites with Microsoft Graph Search and loads SharePoint document libraries progressively as you load more sources, so the initial OneDrive page does not wait on every site.

​

5.1170.0 — October 18, 2026 at 11:13 AM UTC

• Apostra storefronts now speak AdCP 3.2 alongside 3.1 and 3.0. Pin adcp_version: "3.2" to send targeting_overlay.demographics and read back targeting_resolution.demographics. A request that pins 3.0 or 3.1, or pins nothing, is served as before. Account sync on a storefront that has not enabled 3.2 account identity still refuses 3.2-only account fields such as brand.countries, and tells you which field to drop.
• Archived accounts no longer count toward your plan’s account limit, so an organization that was held at its limit by archived accounts can add accounts again, up to the limit. Restoring an archived account now needs a free account slot: if your plan has a limit and every slot is in use, the restore is refused with a “Workspace limit reached” message until you free a slot or change plans. Organizations with no plan, or a plan with no account limit, are not affected, and nothing needs to change on your side.
• Certify an agent that sells through briefs when it declares the brief buying mode, whether or not it sets supports_proposals. When buyers cannot see a Source because its Storefront is not set up or the Source is not mapped to an agent, certification now says so instead of reporting that the Seller has no wholesale inventory to mirror.
• Sellers can now see the advertiser, short request title, outcome and product count for new proposal-request Sessions. When the advertiser is unavailable, Sessions now say “Buyer request” instead of an internal title.
• Opening the Creative Library composer for a campaign now works. Before, it failed with “Supply a supported hosted image, audio or video format”, so the composer never opened from chat or from an agent. Saving a creative draft with the wrong inputs now says exactly what to change: for example, that a draft belongs to the advertiser rather than a campaign, or that an image must be uploaded before it can be used in a draft.
• Editing a media buy that is not live yet, such as attaching creatives to a buy that is waiting for them, no longer reports a failure when an Apostra-managed seller has applied the change. The edit is saved and the buy keeps its pending status until the seller activates it.
• A media buy no longer reads live while its seller’s ad server has not approved it. When the seller’s own status read says a buy is still pending and nothing has delivered, the buy now reads pending, with the reason shown when the seller’s ad-server user cannot approve the order.
• Microsoft 365 Library setup now keeps OneDrive available when SharePoint cannot load, explains whether no company sites were found or a tenant administrator must approve access, and lets you search while adding folders to an existing connection.
• Murph starts working on every message about three-quarters of a second sooner. It no longer waits for a background safety check that only records its result and never changes the answer.
• When you ask Murph to open the Creative Library, it now appears in the chat. Before, Murph replied as if it had opened the Library or its composer, but nothing showed up. Opening the composer from chat resumes the draft Murph started rather than creating a second one. Opening the Library from the left rail was not affected.
• An OpenAI Ads campaign can now launch with the creative you attached. The launch sent the creative the way AdCP 3 names it, creative_assignments, but OpenAI Ads only looked for the older creative_ids, so it refused the buy with “Exactly one synced creative_id is required” even though the creative had synced. A buy set to start asap is also accepted now; it starts at launch.
• A developer can now say a Sales Agent is ready for certification from the agent’s page. In a Developer account, an administrator sees Ready for certification on the agent’s Overview and under Test & certify, and choosing it saves certificationRequested: true through save_agent, the same setting the API already offered. The page shows the control only when Apostra says you can set it, and shows Apostra’s own message if a save is refused. Once the agent is marked ready, the page says so. This replaces Request live test buy, which is gone from the Agent page, and Murph no longer files a live test buy request for a person to arrange: ask_murph now refuses salesAgentLiveTestBuyRequest with a message naming save_agent, and files nothing. Once you say an agent is ready, Apostra starts certification on its own.
• Media buys for products targeted with a seller’s age band, such as adults 25 to 34, now go through on Google Ad Manager sellers. Before, the sales agent refused them because the age band is described by its age range.
• A media buy waiting for the seller’s ad server to approve its order, waiting for creatives, rejected or canceled no longer reports itself as active in delivery reports once its flight dates start. It reports its real status, the same one shown everywhere else, so buyers aren’t told a buy is live when nothing is delivering.
• Previously stranded GAM orders that already have active creatives can be approved automatically instead of remaining in DRAFT.

​

5.1169.0 — October 18, 2026 at 6:20 AM UTC

• Compose Sessions now show the buyer and request clearly. Private notes are marked separately from seller-only summaries.

​

5.1168.0 — October 18, 2026 at 5:07 AM UTC

• Resyncing a creative now sends only that creative to the media buys where it is assigned. Creatives that are incompatible with every package are skipped without preventing compatible creatives from being delivered.
• Creative syncs that reach a seller before a synchronous ad-server push times out now remain in progress, so a later seller callback can record the final approval instead of leaving the creative failed.
• V3 preview: when a developer sets certificationRequested on a Sales agent, Apostra now starts certification on its own, with no one at Apostra acting. It runs on each active Source that uses the agent. It starts again a few days before the latest passed or failed result leaves the seven-day evidence window, once the previous run has finished. Each Source has one run at a time, and a Source whose sandbox account is not ready gets no test buy: Apostra checks it again after a day. A run that ends with nothing to judge is retried no sooner than a day later. Apostra does not yet start a run when an agent’s products or capabilities change. How certification works has the details.

​

5.1167.1 — October 18, 2026 at 4:45 AM UTC

• Sending a campaign’s creatives now works for media buys whose product lines don’t name a seller agent. These buys used to return SELLER_AGENT_ROUTE_UNAVAILABLE and send nothing; their creatives now go to the seller through the storefront the buy is on.
• Lesson cards in Sessions now show their actual proposed, active, or retired state and describe lesson previews in plain seller-facing language. This applies to the seller lessons pilot.
• A chat-card creative now syncs to OpenAI Ads when it was built from a product’s format. OpenAI Ads refused it with “format_option_ref must select a supported publisher format”, so no launch with a chat card could get past creative sync. When OpenAI Ads refuses a creative, the refusal is now logged with its reason, and a creative that fails our own checks (for example a headline under 3 characters) shows that reason and is marked as one the buyer must fix.
• New seller guides explain Sessions and lessons in plain language: how to read your storefront agent’s conversations, leave private notes, and teach the agent with lessons that an administrator approves. They also cover who can see what and the pilot limits.

​

5.1167.0 — October 18, 2026 at 4:10 AM UTC

• get_status on /mcp/v3 now returns operatorIdentity.sellerHistoryCoop only to buyer accounts inside the pooled-reading pilot. For every other buyer account the field is absent (not false), because those accounts cannot read pooled seller history and are not asked to join the seller-history co-op. Inside the pilot nothing changes. GET /api/v2/buyer/readiness still reports identity.sellerHistoryCoop for every buyer account, and joining or leaving through save_buyer_operator or PATCH /api/v2/buyer/readiness/operator still works for every buyer account. Nothing to change on your side unless an /mcp/v3 integration reads the field from get_status: treat a missing value as “not shown”, not as “not a member”.
• Launching an OpenAI Ads campaign with a creative in the plain image format now fails with the real reason: OpenAI Ads takes only chat-card creatives, and no product option declares the image format. Before, the launch said the seller library had not verified the creative, which pointed nowhere. Attach a chat-card creative (an image, headline, body text and landing page) to launch.
• When Apostra’s certification skips a test buy because your sales agent’s account answer was not usable, the Agent page now says why, not only the reason code. It shows a short message and, when your agent returned one, its first error code and message, so you can see whether the fix is a billing model, an account that is not active, or a missing account_id.
• Compose Sessions now retain clearer seller-only request and response summaries, including a bounded opening line, outcome, product and bundle details, and the lesson labels that shaped a response. Passes with no matching products are retained for seller review and teaching. This applies only where the Sessions pilot is enabled.
• When your Google Ad Manager user can’t approve orders, Apostra now shows it where you already look, not only inside the source’s diagnostics. It appears as an “Ad-server order approval” warning on your setup checklist and storefront health, and as one source health task per source, until the permission is in place. Orders still go live once you approve them in GAM, so it does not block your storefront from selling. Apostra rechecks about every 15 minutes and clears the warning and the task on its own. The ad-server source dashboard also points to the order-approval guide instead of the general GAM access guide.

​

5.1166.0 — October 18, 2026 at 3:34 AM UTC

• Open settings for your own advertisers, and manage who at the client can use them, in one place. In a Media Company account, use the pencil beside an advertiser in the left rail, or Settings on its row on the Advertisers page. Advertiser settings now opens for your House and Self-serve advertisers, which sellers couldn’t open before. Its header shows the advertiser’s status and a Sandbox label where it applies, the brand and currency fields carry their own status, and you can change the advertiser’s name and, until it has a campaign or linked seller account, its reporting time zone. Client access lets you invite someone from the client with their work email, their company website, and a role (Can view, Can edit, or Admin). You can then approve, suspend, reactivate, or revoke them, or change their role. Only an organization administrator signed in directly can make those changes, and where client access isn’t turned on for your account, the section says so. If a change is refused, it says why. Scope3-operated advertisers stay read-only and have no settings action. The advertiser section in the account Settings menu is gone: its brand, currency, and status checks now sit in Advertiser settings.
• Only your own seller account administrator can switch a seller lesson on or off. Scope3 staff and support sessions cannot approve or retire your lessons.
• V3 preview: a developer can now say a Sales Agent is ready for certification with one setting, certificationRequested, saved with save_agent (operation: "developer_update") from the Developer account that owns the agent. true asks Apostra to start certification and false stops new certification runs while running buys continue; saving the value an agent already has changes nothing. search and get for agents now return certificationRequested, false until it is set. In this release the value is recorded and returned. The automatic certification runner that acts on it is rolling out separately, so saving true does not yet start a buy on its own. save_agent’s developer_update no longer requires displayName; send displayName, certificationRequested or both.

​

5.1165.0 — October 18, 2026 at 3:09 AM UTC

• Syncing a campaign’s creatives again returns errorCode: source_account_not_bound when the storefront’s inventory source has no active account for you, as documented. Recent syncs returned the generic INVALID_REQUEST for that case. A media buy that names no seller agent for its storefront now returns errorCode: SELLER_AGENT_ROUTE_UNAVAILABLE, and nothing is sent for it.
• Buyers can now launch a media buy using products discovered for their account when the buy is forwarded through a storefront seller. Previously, some launches read only the public catalogue and refused products that the seller had already returned for that buyer.
• A sandbox advertiser’s media buy that waits for your approval is now kept from your provider after you approve it, even if Apostra can no longer match the buy to its advertiser by then. Apostra records whether the buy is a sandbox buy when it arrives. On a source connected to a provider’s campaign system, approving it saves the buy in Apostra without sending it. On a storefront connected through an ad platform adapter, approving it is refused. Buys from live advertisers and external buyers are sent as before. Buys already waiting for approval keep their earlier behavior. Nothing to change.

​

5.1164.0 — October 18, 2026 at 2:35 AM UTC

• Your Sales Agent’s behaviour findings now check that it accepts the billing models it declares. If your Agent lists a billing model in supported_billing, such as agent, and then refuses a sync_accounts request for it with BILLING_NOT_PERMITTED_FOR_AGENT or BILLING_NOT_SUPPORTED, the “Declarations match behaviour” finding shows a flag, and a blocker when it happens on three or more days in a week. Buyers pick a billing model from your declaration, so a model you declare and then refuse leaves their account unopened. Accept every model you declare, or remove the ones you refuse. Like the other behaviour findings, this is reported on your Agent and does not stop any buy today.
• Canceling a media buy that a managed seller’s sales agent has already canceled now succeeds and marks the buy canceled. Before, the cancel came back as “No source accepted update_media_buy” and the buy kept showing as booked.
• There is now one page that explains how certification works for sales agent developers: what makes an agent ready, what each check judges, how long it takes, and what every result and skip reason means. The Agent, onboarding, inventory source and Partner Program pages no longer describe the retired test setup, endpoint confirmation and fixture steps, and now point to it. Saying an agent is ready for certification from the Agent page or save_agent is rolling out; until it reaches your account, ask Apostra support.
• A media buy placed through a storefront no longer stays canceled for good when the seller’s system later says otherwise. A leg that ended because we stopped waiting for the seller, or because the seller’s system could not be reached, is now marked as our own decision rather than the seller’s, and the leg is read from the seller’s system again once a day until a flight length after the buy ends. If the seller reports the buy live, the leg follows it. A buy the seller refused stays refused unless the seller says it is live.
• On sellers still using the original account setup, a teammate now sees the account their colleague set up when they list accounts, and the same account comes back when they set it up again, instead of a second account request, whichever advertiser they are working in. The account stays inside your organisation.
• The approve-or-deny step of agent sign-in now accepts requests only from Apostra’s own pages, and only with the person’s browser sign-in. A website elsewhere can no longer submit an approval, and an access token sent in the request body is no longer accepted in place of that sign-in. Agents signing in through the normal consent page see no change.
• Apostra and Interchange app pages, including the page where you approve an AI assistant’s access to your account, can no longer be loaded inside another website’s frame. This stops a site from hiding the approval page under a decoy and tricking you into clicking Approve. Opening the app directly, and widgets shown in Claude, ChatGPT and Murph, work as before.
• V3 save_event_source and save_audience now name the seller’s object in each sellerAccounts[] entry as platformId instead of sellerId, and the event_source and audience reads return it as platformId too. Elsewhere in V3, sellerId means the seller itself, so the old name was easy to misread. If you map event sources or audiences to seller accounts through the V3 API, rename the field in your calls; requests that still send sellerId are refused with VALIDATION_ERROR.
• The read now shows the pixel or audience you mapped from the moment you save it, with status saying whether the seller account has confirmed it. If you change a mapping, the read shows the new id with its own status, or the reason the seller refused it, instead of the previously confirmed one.
• A creative’s first send to an ad-platform seller (Meta, TikTok, OpenAI Ads, Spotify) now matches its later sends, with the same click wrapping, measurement trackers, and video poster frame, so the platform reviews one version of the creative.

​

5.1163.0 — October 18, 2026 at 1:32 AM UTC

• Measurement freshness now loads faster for advertisers with a large amount of uploaded measurement data. Each check used to take several seconds for the largest advertisers, and now reads only a summary of what has been uploaded. The gaps, coverage and last upload date it reports are unchanged. Nothing to change on your side.
• A creative the seller already approved no longer shows as failed when a resend of the same content fails before reaching the seller. It stays approved, so launch readiness is no longer blocked on content the seller has already accepted.
• When you approve a buyer on a storefront that combines several inventory sources, we no longer ask a sales agent of yours that lists its accounts to create a new account for that buyer at approval. You map the buyer to one of the accounts the agent already lists, in Buyer Account Mapping. An agent that cannot list its accounts is still asked for the buyer’s account at approval. For now, a buyer’s first purchase or product search may still ask an agent that lists its accounts for an account when none is mapped.
• On a storefront that combines several inventory sources, a buyer’s purchase, creative upload or product search no longer asks one of your own sales agents that cannot list its accounts (for example an ad server’s AdCP agent) to create an account for that buyer. That agent is asked once, when you approve the buyer, and afterwards we only use the account it gave. Until it has one, its products are left out of the buyer’s search instead of being retried on every search. Agents that list their accounts are unchanged for now.
• Mapping an event source to a seller-managed object, such as Meta’s Instant Forms leads source, is now refused when you save it, with a validation error on that entry’s sellerId. Before, the save went through and the mapping failed about a minute and a half later. Seller-managed objects measure the seller’s own surface and can’t receive your events, so map a pixel or dataset you manage instead.
• Meta video creatives now carry the poster frame Apostra selected on every send. Until now the poster frame was not reaching Meta at all, so Meta showed its own auto-generated frame instead of the thumbnail you see in the Creative Library. Creatives sent when you buy, re-sent after a change, or sent directly from a campaign now all reach Meta with that thumbnail. If no poster is ready yet, the video is sent without one, as before.
• If a campaign launch fails and you then archive the draft media buy, the queued launch retry now stops instead of running again. Previously each retry re-sent the archived buy’s creatives to the seller and could overwrite the seller’s earlier review result for them. Nothing to change on your side.
• An HTML tag from Campaign Manager is now sized from the size it declares even when it is not an <ins class="dcmads"> tag: the width and height of its single iframe, or the ;sz=300x250 in its ad-server URL. Display tags that had no recorded size are measured the same way, so sellers receive the size the tag declares. Where the tag declares more than one size, or the sizes disagree, nothing is recorded and the creative saves as before.

​

5.1162.2 — October 18, 2026 at 12:23 AM UTC

• Media buys for products that use a seller’s audience segment or fixed key-value signal now go through when the seller’s managed sales agent doesn’t state whether the signal includes or excludes. The signal is included, as the sales agent’s ad server connection does. Before, those buys were refused with “Signal targeting metadata could not be resolved”.
• On FreeWheel sellers, buying tools now accept the account ids that list_accounts returns. Buyers can discover products and signals, create and update media buys, and read buys and delivery under those accounts. Each account sees only its own buys, and books against the advertiser the seller mapped to it, or the seller’s default when it has none.
• A creative a buyer removes from a package is now reliably turned off in Google Ad Manager. Previously, if Ad Manager rejected the first deactivation, nothing retried it and the removed creative kept serving. The removal is now kept until Ad Manager confirms it, and is retried automatically.
• When you approve an order by hand in Google Ad Manager (or book it in FreeWheel) before its flight starts, the media buy now stops waiting for approval within the hour. Its approval item closes and it shows as scheduled. Before, it kept showing as waiting for approval until the flight began.
• A cancel or pause that the ad server accepted but ESA failed to save no longer leaves the media buy showing as live. For GAM, FreeWheel, AdsWizz and SpringServe, ESA now reads the pause or cancellation back from the ad server on its next hourly status check. For Broadstreet, ESA alerts the team when it cannot tell whether the change reached the ad server. A paused Broadstreet buy is also no longer switched back to active by the hourly status check.
• Lowering a Google Ad Manager package’s budget below what it has already delivered is now refused. The error states the delivered amount and the smallest budget that covers it, instead of the change going through to the ad server.
• Creative-sync responses now clearly report when an ad-server upload failed instead of showing the creative as synced.
• An approved creative whose upload to Google Ad Manager failed, or whose line-item association is no longer active, is now pushed again automatically within about 15 minutes instead of waiting for the buyer to touch it. If Google Ad Manager still refuses it, ESA raises one alert for it.
• When Google Ad Manager isn’t ready to approve a new order yet (its inventory forecast is still running), Apostra now keeps trying in the background instead of giving up after two minutes, so the media buy goes live without anyone stepping in. If approval still hasn’t gone through after a few attempts, our team is alerted.
• GAM creative uploads now place creatives on every booked package line item and retries reuse the original GAM creative instead of creating duplicates.
• Removed the Browser origins section from Settings, API keys and from Discovery & distribution. The setting no longer does anything, because sign-in and CORS accept any origin for MCP apps, so there is nothing to configure and nothing to do.

​

5.1161.0 — October 17, 2026 at 10:43 PM UTC

• A new page, “Sign in a self-built agent”, explains how an agent you build signs in to Apostra: how it registers, which redirect addresses it can use, how tokens last and end, how to call from a browser, and what each sign-in error means. Nothing changes in how sign-in works, and you have nothing to do.
• Murph’s recent conversations list now loads for an advertiser-scoped chat even when a different advertiser, or none, is selected elsewhere in the app. Previously the list came back empty with “Conversation scope is no longer active.”
• When you approve a buyer on a storefront that combines several inventory sources, we now ask each of your own sales agents (for example an ad server’s AdCP agent you connected) for that buyer’s account straight away, instead of waiting until the buyer’s first purchase or search. The request uses the credential you gave the source, names the buyer’s brand and agency, and asks the agent to bill your storefront, never the buyer. If your agent refuses, we record the refusal and stop asking rather than retrying.
• A sales agent’s date-times in delivery reports and product reporting fields must now carry seconds, as AdCP requires (RFC 3339). A live delivery report with a time like 2026-12-31T23:59Z is refused, and the failing field is logged so the seller can be told. Buyers can still send times without seconds; we add :00 before storing or sending them.

​

5.1160.0 — October 17, 2026 at 10:05 PM UTC

• MCP clients that sign in through discovery are now offered only Apostra’s own sign-in server. Before, the discovery document for the platform MCP endpoints also listed a second sign-in server, and a client that chose it completed sign-in but then got a 401 “Invalid M2M token” on every call, because Apostra does not accept tokens from that server. Nothing changes for clients already connected, API keys, M2M applications, or agents that register through the activation contract.

​

5.1158.2 — October 17, 2026 at 8:32 PM UTC

• Draft media-buy reads now show the seller recorded on their booked product route before the buy has been forwarded to that seller.

​

5.1158.0 — October 17, 2026 at 7:28 PM UTC

• MCP clients can now identify themselves with a Client ID Metadata Document, a JSON file hosted at an https URL the client controls, instead of registering first. Send that URL as the client_id. Apostra fetches the document, checks its redirect URIs, and shows the client’s name and the domain that published it on the consent screen. The OAuth metadata now advertises client_id_metadata_document_supported, and dynamic client registration keeps working.

​

5.1157.0 — October 17, 2026 at 7:07 PM UTC

• Desktop and mobile agents can now register a private-use URL scheme redirect (for example cursor://anysphere.cursor-mcp/oauth/callback) when they self-register an OAuth client. Script, file and web-transport schemes are still refused, and a custom-scheme redirect must match the registered URL exactly.
• Public API schemas now explicitly identify discriminated input unions, improving generated TypeScript and Python SDK type selection.

​

5.1156.1 — October 17, 2026 at 6:19 PM UTC

• A creative sent to a media buy before it goes live now goes out the same way as the send that follows when the buy activates, so it carries Apostra’s measurement trackers from the start. Before, the first send had none, the later send added them, and the seller had to review the creative again. Buys with direct ad-platform storefronts such as Meta are unchanged.

​

5.1156.0 — October 17, 2026 at 6:01 PM UTC

• A media buy whose start or end time was sent with minute precision, such as 2026-12-31T23:59Z, can now be executed and updated with its seller. Minute-precision times are still accepted everywhere a date-time is, and are now stored and returned with seconds added (2026-12-31T23:59:00Z): the same instant, in the full RFC 3339 form sellers require. Before this, such a buy failed when it was sent to the seller, because the request carried a time without seconds.
• A creative the seller could not attach to its line item is now shown as failed and is retried, instead of reading as delivered.
• REST, MCP, and S2S buyer builders and seller automation owners must add kind to existing save_ask calls. Calls without it return a typed 4xx as soon as this release deploys, with no grace period. Send kind: "create" to file an ask and kind: "update" to update one. Platform-direct buyer and seller workflows need no setup. Follow the V3 write-request migration guide for the contract. This does not change pricing, packages, entitlements, or billable behaviour.

​

5.1155.1 — October 17, 2026 at 5:30 PM UTC

• Agents you build yourself can now sign in to Apostra without an account admin first approving the agent’s website. The person signing in approves the agent on the consent screen, which shows its name and the domain it returns to, and browser code on any origin can call the MCP and OAuth endpoints with a bearer token. The browser origins setting is no longer needed for this.

​

5.1155.0 — October 17, 2026 at 5:13 PM UTC

• Buyers can launch a storefront buy when the seller creates product ids during discovery instead of adding them to the catalog cache.
• Sellers can now see how they are doing for each of their buyers. On V3, get on your own seller with include: ["scores"] returns one entry for each buyer campaign you have buys in, most recent delivery first and at most 25, with entriesOmitted counting the rest. Each entry names the buyer and your own media buys for that campaign, and gives four separate scores: delivery against the budget you were sent and an even pace, your own net price per unit of the buyer’s goal (or per thousand impressions), performance against the goal you were sent, and the viewability you reported. Each score says who counted it. Everything comes from your own delivery reports, the requests you were sent and the scores buyers sent you. You never see a buyer’s fee-inclusive price, a rank or another seller’s figures, and an entry never names the buyer’s campaign, though it does show which of your buys belong to the same one. Every seller account can read it, as it can read its own commitment record.
• Composed products can now use age signals from a managed sales agent. A brief that asks for an age band, such as adults 25 to 34, gets products targeted with the seller’s matching age signal. Before, those signals were ignored, so such briefs returned no products from storefronts whose only age data came from a managed sales agent.

​

5.1154.0 — October 17, 2026 at 4:39 PM UTC

• The Campaigns view now shows a seller scorecard when you open a live campaign: every seller you bought from, scored on delivery, price, performance and quality, with each seller’s rank on each score alone and who counted it. A score with no data reads as not reported, never zero. Quality is not judged yet, so it reads as not reported for now; once sellers have quality scores, a second tab puts quality and price side by side for each seller, so you can see who costs more and who delivers better without blending the two into one number.
• An event source whose id is the id of a pixel or dataset on a seller account now uses that pixel on that account without a manual mapping. If you registered your Meta pixel’s id as your event source, media buys that optimize toward it go out as they did before mappings were introduced, instead of being refused for a missing mapping.
• Creatives on a media buy now reach the seller when the buy’s products name a specific inventory source, instead of failing with “creative sync target identity is immutable”. If your creatives were stuck unsent on such a buy, the next sync attempt delivers them; nothing to change on your side.
• Launch previews now show a draft media buy’s saved budget when its catalog package has no separate budget yet. If an inventory source has no mapped account, launch now explains that the seller must complete Buyer Account Mapping before you create a new media buy, instead of reporting a generic seller rejection.
• A campaign with a creative attached can now launch on an OpenAI Ads seller. Before, the launch check said the creative needed seller approval, and confirming the launch failed because the seller library had not verified it. The creative is now uploaded to OpenAI Ads as part of the launch, and a rejected creative still blocks it.
• Murph opens pages and runs actions faster in the web chat. When Murph named the account it was working in, its first attempt failed and it had to try again, which added several seconds to requests like opening the Creative Library or the Campaigns page. Murph now gets it right the first time.
• The Campaigns and Advertisers pages now load when Murph opens them in chat. Before, the page opened but showed “Could not load campaigns” (or failed to list advertisers), even though the data was there. Opening those pages from the left rail was not affected.
• Sellers can review the recorded agent response in a Session for product requests that do not create a proposal.
• Removing a creative from a campaign now reaches the seller when the seller has already booked the media buy. Before, a buy that showed as pending approval was edited only on our side, so the creative could keep serving. The removal is now queued and retried for up to five attempts. If the seller still has not accepted it, the creative stays on the media buy, the media buy’s operations show the removal as failed, and Apostra operations is alerted.
• When a seller’s sales agent firmly refuses a media buy, audience or event-source update, for example with ACCOUNT_SUSPENDED or BILLING_NOT_PERMITTED_FOR_AGENT, Apostra now stops on the first answer even if the agent marks it transient. Before, it tried up to five times and could report the refusal as failing “after repeated attempts”. The buy shows as failed with a buyer-safe reason, and the operation is recorded as the seller’s refusal. Refusals marked correctable, credential errors such as AUTH_INVALID, and temporary faults are handled as before.

​

5.1153.0 — October 17, 2026 at 3:13 PM UTC

• If your API, SDK, MCP, or agent integration calls these V3 tools, update it before this release. Every affected request must include kind to identify the form it sends. Requests without kind are rejected immediately. There is no grace period. UI-only customers do not need to act.
• Buyer writes: for save_creative, identify a source asset as asset_ref or asset_id; for save_media_buy, identify age targeting as minimum, maximum, or range.
• Seller writes: for save_rfp, identify a budget as zero_decimal, two_decimal, or three_decimal, and identify a Quick preset as typed or legacy.
• Buyer reads: get(kind: "rfp_turn") now returns outcome: "rfp_turn" instead of "object". Generated-client consumers must handle "rfp_turn". Existing saved data remains readable.
• Seller impact: buyer-only values are removed before requests reach sellers. Sellers will not see the new fields or any other change to their visible data.
• Show sellers the private request and response summaries from their compose Sessions.

​

5.1152.3 — October 17, 2026 at 2:47 PM UTC

• Fixed buyer admission provenance for eligible requests handled by persisted CHEF storefront agents. Seller Session history now records the admitted buyer only when the dispatched storefront exactly matches the server-resolved relationship and grant.

​

5.1152.2 — October 17, 2026 at 2:22 PM UTC

• If your TypeScript SDK integration sends an idempotency key in a V3 write request body, keep using the documented request branch. The SDK now preserves each request-union branch while making that body key optional, so invalid cross-branch payloads no longer type-check.

​

5.1152.1 — October 17, 2026 at 2:11 PM UTC

• Keep approved managed-source creative evidence exact when the matching execute acknowledgement supplies its previously unknown format option.
• GAM-backed sellers can accept display creatives with valid HTTPS click-through URLs again, so buyers can create those media buys.

​

5.1152.0 — October 17, 2026 at 1:41 PM UTC

• Buyers can create media buys with seller products discovered by a storefront even when the storefront catalog cache no longer has those product IDs.
• Sellers who can switch to a lessons-pilot or compose-Session-pilot storefront can discover its teaching tools before changing accounts. Each write still checks the selected storefront.
• Creative sync now leaves out VAST and DAAST playback tracker assets that a seller’s negotiated AdCP version or declared format does not support. Impression tracker pixels sent as URL assets continue to be delivered.

​

5.1151.0 — October 17, 2026 at 12:40 PM UTC

• Agents on V3 can now ask how one seller has done for you across your campaigns with get on the seller and include: ["scores"]. You get one entry per campaign you ran with that seller, most recent delivery first and at most 25, each with the seller’s delivery, price, performance and quality scores and its rank among that campaign’s sellers, the same figures the campaign’s own seller scorecard shows. campaignsOmitted counts any campaigns past the 25. totals counts every campaign by whether the seller delivered on pace, behind or ahead; quality reads as not judged yet, and price and performance are never totalled, because each campaign prices and judges them in its own goal’s unit. A campaign that cannot be scored, because a media buy in it reported spend in more than one currency, is listed in unavailableCampaigns with the media buys at fault, and totals.campaignsExcluded says how many campaigns the totals leave out. The text answer names the seller and each campaign and gives every score’s value and rank or the reason it has no rank. The include is open to buyer accounts on the standard buyer profile, which new buyer accounts get by default, and to buyers in the V3 beta; an account without it gets a FEATURE_NOT_ENABLED error instead of empty scores. Seller accounts cannot request it, and searching sellers does not offer it.
• Generated Apostra SDKs now reject unreviewed public type renames and shape changes, keeping existing imports and model classes stable.
• When an OpenAI Ads media buy can’t be created because of the request itself, the refusal now says what to change and stops retrying. Before, a launch with no synced creative, or with more than one package (OpenAI Ads takes exactly one package per media buy; use one media buy per product), failed as a generic “Upstream request failed” and the launch kept retrying. A connection that is missing its credential identity now tells you to reconnect OpenAI Ads instead of the generic message.
• Sandbox (mock) seller products now list place targeting (cities, counties, states and other named places in the geonames, Google Ads and Microsoft Ads systems) in their targeting declaration, so buyers can book place-targeted packages against sandbox sellers instead of being refused. Real ad-server sellers are unchanged.
• Meta campaign reporting now reads a supported campaign bid strategy when a campaign-budget ad set omits its inherited strategy.

​

5.1150.0 — October 17, 2026 at 11:58 AM UTC

• After you record an IU plan decision, the plan task no longer shows the “Need help choosing a plan?” card under the result.
• The Python SDK now gives generated models stable, descriptive names based on their API context. Adding an unrelated API field no longer renumbers other model classes, and generation stops before publishing a counter-based name. TypeScript receives the same generated-name check; its previous numbered exports remain available as deprecated aliases while you move to the descriptive names. HTTP behavior, authentication, and client method signatures do not change. These Python name changes replace unpublished numbered classes; the Python SDK has not yet been released to PyPI.
• A sales agent that passes live-traffic certification for at least one use case now completes the Successful transaction step in Required to go live. The pass covers every Source that uses the same agent, including a Source that hasn’t gone live yet, and it stands until a later certification buy for the same use case fails. If the step is still open, it now says the agent isn’t certified yet and links to what certification needs, instead of asking you to run the retired certification suite.
• Record the admitted buyer authority on seller compose runs started from v3 product requests, so eligible shared Sessions retain buyer-facing history and seller-private summaries.
• Audience, event-source and catalog sharing now works with a seller whose Storefront has no separate agent record, as long as you have an active connection to that Storefront. Such a sharing record identifies the seller by its Storefront key (storefront-<platformId>) in adcpAgentId.

​

5.1149.0 — October 17, 2026 at 11:26 AM UTC

• Certification test creatives and buys no longer wait in your Storefront’s creative review or media-buy approval queue, so your sales agent can be certified even when you approve buyers’ creatives and buys by hand. They go straight to your agent, which still applies its own review, and platform safety review still holds a buy that needs it.
• A sales agent that sells only through briefs can now be certified. If your agent declares media_buy.supports_proposals: true and lists no products for a wholesale get_products, certification sends it a standard brief for display and for video, buys the product your proposal offers within the USD 10 per-buy cap, and checks that buy like any other certification buy. A use case whose brief returns nothing that fits is skipped as buy_no_matching_proposal, and the message names the brief that came back empty. Agents that list wholesale products are certified as before.
• Murph no longer says a page didn’t open when it did. Opening a page in chat, such as the Creative Library, used to add a “that view didn’t open” note under Murph’s reply even though the page was on screen. The note now appears only when nothing opened.
• When a Creative can’t be sent to a seller because the format option it is matched to gives no older-style format ID, the refusal now says the seller has to act: “…so the seller must declare v1_format_ref on its format options…”. Before, this refusal didn’t say who needed to fix it, while the similar refusal for an unmatched Creative already did.
• An update_media_buy that fails no longer leaves part of it applied. Before, a request that changed several things and then hit a refusal (a bad date range, a package the ad server rejected, or an adapter that cannot push a change) saved the changes made before the refusal. Now nothing is saved, except changes the ad server already accepted: those are recorded, and the error says which ones.
• For FreeWheel sellers, the advertisers sync on the status page now shows its real health. A failed or never-run advertiser sync is reported instead of always reading as healthy.
• save_creative with resync: true, and attaching a Creative to a campaign that has a live media buy, no longer report success when the seller never received the Creative. Before this fix, if we refused to send the Creative to a seller (for example because the seller’s product declares no format it could be sent in), the media buy update still went through and the campaign came back confirmed. That campaign now comes back as not delivered, naming the Creative and the recorded reason, and you can retry once the cause is fixed.
• Spotify audio creatives now upload. Apostra sends your MP3, OGG or WAV file to Spotify as it is, instead of first converting it to WAV, a step that failed in production and blocked every Spotify audio launch. Audio in any other format is refused with a message naming the formats Spotify accepts. Spotify recommends stereo audio at 44.1 kHz and 192–320 kbps; mono files are sent unchanged.
• Nothing to change on your side. Buyers can now choose to join a seller-history co-op, and in a coming release the buyers who join will be able to read your record against the goal commitments you made on completed buys, pooled across co-op members. Joining is opt-in and off by default, and the operator that owns the buyer account decides. When a member buyer looks at your seller, it will see, for each goal objective and commitment kind (guaranteed, best effort or report only), roughly how many buys were judged and how often you met or beat your commitment, with the share that beat, met or missed it for records with enough buys behind them. Member buyers’ automatic product selection will use the same published figures. Figures are published as monthly snapshots and rounded. A figure appears only when at least 3 distinct buyer operators and 5 judged buys stand behind it, and no single operator supplied more than half of those buys. No buyer, campaign or media buy is named, and price is never pooled. You can see your own record now, across all your buyers, by asking for commitmentRecord on your seller read. It will not match the pooled figures exactly, because it covers every buyer rather than co-op members only, but it shows the same measures buyers will read.
• Buys and creative syncs sent to an Apostra-managed sales agent with only a brand and operator now use your company’s approved account instead of failing with MANAGED_ACCOUNT_LINKAGE_REQUIRED. Before this fix, a request that named the buyer by brand domain and operator, without an account_id, was refused for any teammate who had not run sync_accounts themselves, even when your company already had an active approved account for that brand and operator. Now the request resolves that account the same way a request carrying the account_id does: your own approval first, otherwise your company’s active approval. The buy or sync runs on the sales agent account mapped to the seller’s advertiser, and the buy’s route records that account so later updates and creative syncs reuse it. If your company has no active approval for the brand and operator, or the approved account cannot serve that source, the request behaves as before.
• On v3, open_connections_page now takes the connection account to open as connectionAccountId (from the connection’s accounts[].id), and its accountId names the Apostra account the call runs in, as on every other tool. A v3 call that still sends the connection account as accountId is read as an Apostra account and refused with ACCOUNT_NOT_REACHABLE; reconnect to refresh the tool list, then send connectionAccountId. On v2 buyer, accountId stays the connection account. The Media Partners page’s account mapping takes the provider account as providerAccountId, and existing pages keep working.

​

5.1148.0 — October 17, 2026 at 10:10 AM UTC

• The media-buy timeline now loads quickly for every buy. Before, it could take up to 30 seconds, or fail with “could not load its stored forwarding state”, because finding a buy’s delivery reports meant reading every report on record.
• Murph no longer leaves you thinking a page or library opened when it didn’t. If a reply says it opened a view, such as the Creative Library or a composer, and nothing actually opened, Murph adds a note saying the view didn’t open and that you can ask it to try again.

​

5.1147.5 — October 17, 2026 at 4:38 AM UTC

• Property lists now keep every identifier you submit. An app, CTV or other non-domain identifier that the AAO registry has not confirmed is saved on the list and returned in unresolvedIdentifiers on later GET and list responses, not only in the create or update response. It is not applied until AAO confirms it. Domains are always applied, whether or not AAO knows them. registeredIdentifiers is now always empty and registeredCount is always 0.

​

5.1147.1 — October 17, 2026 at 12:31 AM UTC

• You now hear about it when a storefront rejects your Creative, or approves it but can’t deliver it. Before this fix, those updates never reached Apostra: the Creative stayed “waiting for seller review”, and save_creative with resync: true did nothing for up to seven days. A Creative that was approved but not delivered now shows the reason “Seller approved this creative but could not deliver it (delivery_failed).” Resync then sends it again. Resync also skips media buys that have ended (failed, canceled, rejected, or completed), so a campaign that still holds a failed media buy no longer reports CONFLICT for a Creative that reached the live buy.

​

5.1147.0 — October 17, 2026 at 12:10 AM UTC

• Launching a campaign with a creative already attached now works with sellers whose own team traffics creatives into their ad server. Before, the launch failed with “the seller library has not verified creative(s) yet”, and retrying could never succeed because these sellers traffic creatives only after a media buy is booked. Now the media buy is booked, the creative goes to the seller’s trafficking queue, and the buy shows pending_creatives until the seller confirms it is trafficked.
• Connecting an MCP client such as Claude, ChatGPT, or mcp-remote now asks you to approve or deny it before it gets access. The screen shows the client’s name, the address it returns you to, the MCP resource it asks for, and the account you are signed in as. Approve continues in the same tab. Deny returns the client the standard OAuth access_denied error. You are asked every time a client authorizes, including when you are already signed in. See Approving an MCP client.
• Settings → Accounts and Members are rebuilt on the same frame as the rest of Settings. Each pane now carries one title and one set of actions instead of a generic “Organization” heading stacked above the pane’s own.
• Accounts lists every account at once, active and archived together, and the Status column sorts them — the Active/Archived dropdown is gone, so an archived account is no longer hidden behind a filter you had to find first.
• On Members, search and the account filter sit above the roster rather than competing with the title, and the columns are sized so the table no longer scrolls sideways: a long name truncates instead. A pending invitation now shows the first letter of the invited address instead of a ”?”, and Resend invitation and Cancel invitation moved into the same row menu every other member has. Domain auto-join opens in place, above the roster it governs, instead of over it.
• A member of a child account now sees the same Plan & billing row in the settings rail that everyone else does, rather than one renamed “Managed by your organization”. Opening it is what says the organization above owns the billing.
• Tables across the product now draw their own border, so a list reads as one framed block rather than rows bleeding into the surface around them, and a table’s pager sits closer to the rows it counts.
• A VAST tag URL saved without a version is no longer refused when it is sent to a managed Google Ad Manager or FreeWheel connection. Apostra reads the tag’s version at send time, sends the creative, and keeps the version for later sends. If the tag cannot be read at that moment, the creative is held back and sent on a later sync (destination_vast_version_unavailable, with Apostra as the party who must act) instead of being reported as a creative you need to replace. Reclassifying an asset to VAST now records its version the same way a new tag does.
• When a seller’s sales agent firmly refuses an approved media buy, for example with BILLING_NOT_PERMITTED_FOR_AGENT or ACCOUNT_SUSPENDED, Apostra now stops sending it straight away, even if the agent marks the refusal transient. Before, it re-sent the same buy for up to 6 hours. The buy is marked failed with the seller’s code, and the seller’s pending operations show it as a refusal that retrying cannot fix. Refusals marked correctable and credential errors such as AUTH_INVALID are handled as before. Cancellations are still retried, so a live order is never marked ended by mistake.

​

5.1146.5 — October 16, 2026 at 11:32 PM UTC

• When a seller’s sales agent firmly refuses to open a buyer’s account, for example with ACCOUNT_SUSPENDED or AGENT_BLOCKED, Apostra now stops asking and shows the buyer that the seller rejected the account. Before, it repeated the request, eventually once a day, and the buyer saw “waiting on seller” indefinitely. Billing refusals already worked this way. Credential errors such as AUTH_INVALID are still retried, because reconnecting fixes them. A seller who changes its answer can ask Apostra support to send the request again.
• Impression trackers set on an advertiser or campaign are not sent with a VAST or DAAST URL tag, because the tag has no place to carry them. Apostra’s own trackers are sent beside the tag as before. The creative sync log now names each tracker it did not send and why, and no longer reads as if Apostra’s own trackers were missing.

​

5.1146.4 — October 16, 2026 at 11:05 PM UTC

• The /mcp/v3 tool list no longer includes the custom modular source tools (create_feed_modular_inventory_source, prepare_modular_source, get_modular_inventory_source_readiness) for accounts whose plan does not include Custom modular sources. Their setup screens were already unavailable to those accounts, so a client that scanned every tool’s screen, such as OpenAI’s plugin review, could not finish the scan. Accounts whose plan includes Custom modular sources see no change.

​

5.1146.3 — October 16, 2026 at 10:26 PM UTC

• An expired Demo Storefront whose cleanup keeps failing now stops retrying after five failed attempts. Its status stays CLEANUP_FAILED, and its cleanup error says that automatic retries have stopped. Delete now tries the cleanup again straight away. Reset or Extend 7 days returns the Demo Storefront to ACTIVE. Any of the three gives cleanup five new attempts. A Demo Storefront that cleans up normally is unaffected, and nothing changes for buyers.
• GAM click and impression trackers no longer receive the raw page URL. GAM inserted it unencoded, which broke tracker query strings. Trackers that ask for the page URL on GAM now receive it unfilled, as for other macros GAM cannot fill.

​

5.1146.2 — October 16, 2026 at 9:48 PM UTC

• Impression trackers that use {PAGE_URL} no longer pick up stray parameters on Google Ad Manager sellers. Google Ad Manager inserts the page address without encoding it, so a query in the page address became extra parameters of your tracker and the page address itself was cut short. Google Ad Manager has no macro that fills an encoded page address, so Apostra now removes the parameter that carries {PAGE_URL} and sends the rest of the tracker unchanged. Other sellers still receive {PAGE_URL}. The same applies to a tracker written in Google Ad Manager’s own syntax with %%PATTERN:url%%, and saving one through save_advertiser or save_campaign now returns an error that names the macro. Nothing to change on your side.

​

5.1146.1 — October 16, 2026 at 9:12 PM UTC

• Deleting a product or taking a source off sale in chat now uses the shared approval card, and the approval stays open for 24 hours.

​

5.1146.0 — October 16, 2026 at 8:58 PM UTC

• Creatives can now be assigned to a media buy whose product was booked before we started saving the seller’s accepted formats on the buy. Previously those buys refused every creative with “The products on this media buy have no declared formats”, even when the seller’s product declares formats. They now use the formats the seller currently declares for that product. Buys that saved their formats when they were booked keep using those. Nothing to change on your side; resend the creative if one was refused.

​

5.1145.5 — October 16, 2026 at 7:53 PM UTC

• Execute no longer refuses approved creatives for sellers reached through a storefront agent.

​

5.1145.4 — October 16, 2026 at 7:36 PM UTC

• Buyers now see a seller’s correctable update refusal, including the action the seller says will fix it, instead of a generic synchronization failure.
• Saving or attaching a creative you just uploaded in chat is now quicker: Murph goes straight to the save instead of looking things up first.

​

5.1145.1 — October 16, 2026 at 5:17 PM UTC

• Creatives now reach sellers that review creatives by hand and have moved to company seller accounts. Before this fix, sending a campaign’s creatives to such a seller, including the automatic send to a draft media buy’s seller, failed with “This account is not active for this buyer principal on this storefront”, even though the seller account was active. The send now checks that account against the campaign’s advertiser and the person or service token that made the change.
• Creatives now reach sales agents on AdCP 3.0 or 3.1 whose products list legacy format IDs without linking them to their format options. When a creative was stored with one of that seller’s own legacy format IDs and the booked product lists it, the creative is sent under that ID instead of being refused. When the seller’s format options leave out that link and no stored ID applies, the error now says the seller must add the link (v1_format_ref) rather than telling you the creative fits no format.
• Buyer reporting retains seller-stated reporting period, next expected report, notification type, and sequence number from processed valid delivery reports. When a later report omits one of those values, the existing stored value stays available rather than being inferred or cleared. This retains the existing sparse-value persistence behavior and adds no ordering guarantee.
• Media buys no longer launch when their campaign has no advertiser. The launch stops before it sends a request to a seller.

​

5.1145.0 — October 16, 2026 at 4:24 PM UTC

• Saving your own creative to your advertiser’s Library in chat no longer asks for approval.

​

5.1144.0 — October 16, 2026 at 4:08 PM UTC

• When a campaign launch cannot post its committed-spend ledger entry after dispatch, the error now explains which campaign state persisted and that already-sent media buys are not dispatched again on retry.
• Create Agent and Open now work from a Developer account’s Agents page in the web app. Before this, clicking Create Agent showed “This account does not have Seller API access”, because the page’s launchers ran through the Seller API, which a Developer account has no access to. Developer accounts still have no access to any other Seller or Buyer tool.
• VAST and DAAST URL creatives now reach the seller with our start and quartile measurement trackers. Before this fix, a creative carrying those trackers could be refused before it was sent, and the seller never received it.
• A media buy whose attached creatives were all stopped before they could serve at the seller now says so. Its pending reason is creatives_not_delivered, on the media buy and on the same buy inside its campaign, and on the seller’s Media Buys list. This covers a buy the seller shows as live or scheduled when none of its creatives ever reached the seller, because Apostra did not send them (an unlinked account, an unresolved format, a refused destination, a failed send) or the seller cannot take them without a correction. Before, that buy showed no pending reason at all. A buy with at least one creative synced or pending at the seller does not read this way, a seller’s rejection of every creative still reads source_rejected_creatives, and a buy with nothing attached still reads no_creatives_attached. Read each creative’s failure reason to see who must act: Apostra for a creative we did not send, or you for a creative that must change. Nothing to change on your side for the buy itself.
• Buyers launching a media buy through a storefront-wrapped seller now keep the seller’s creative approval on the booked source. Before, we saved that approval without the source, then could not verify it when launching the buy.
• Campaign creation and flight-only updates now reject an end date that is not after the start date, before saving the campaign.
• Delivery reports now show a media buy as paused when the seller has paused it in their ad server, instead of reporting it as active while nothing serves. Filtering delivery by paused status now returns these buys too.
• Sales agents now say up front whether product discovery needs a buyer account. Interchange can show a seller’s catalogue without first making a failing request.
• When you choose direct billing for a seller and approve it, Apostra now asks that seller to open your account on direct billing, so the seller invoices you itself. Before, the request stopped before reaching the seller, and the account was never opened. The seller receives the advertiser’s media billing entity (legal name, tax ID, address and billing emails) so it knows whom to invoice. An advertiser with no media billing entity stays at Action required until you add one.

​

5.1143.0 — October 16, 2026 at 3:07 PM UTC

• Product discovery lists sellers whose formats say which tracker macros they fill again. Since 16 October those sellers’ products were refused as “creative requirements are not ready yet”, and buyers saw no products from them.
• Product discovery for an advertiser now names up to 50 of the sellers it left out because they are not on for that advertiser, instead of 10, in get_products ext.interchange.storefronts_not_searched and its text summary. Sellers you can turn on are listed first, then sellers that cannot transact with you, each group by name, so a seller you could switch on is no longer hidden behind ones you cannot change. When some are still unlisted, total counts them, and the text summary says when every unlisted seller is one you cannot change. Nothing to change on your side.
• When a seller refuses a media buy on its first delivery attempt, Apostra now reports that it will not retry automatically without claiming repeated attempts. Seller-provided refusal text remains private.

​

5.1142.0 — October 16, 2026 at 2:29 PM UTC

• Buyer writes: send kind for generate_variants (campaign_generate, advertiser_generate, campaign_feedback, or advertiser_feedback), save_dimension (create or update), and save_media_buy (create, proposal, or update).
• Seller writes: send kind for save_connection billing (billing_party or direct_billing).
• Buyer reads: read Creative Session galleries as campaign or advertiser, and Creative Library launches as library or asset.
• Seller-impact reads: read advertiser impact sellers as storefront or legacy_sales_agent.
• This is a breaking V3 contract change with no grace window.
• The Library now shows each document’s status exactly as the Library reports it. A document whose upload never finished was labelled Incomplete in the document list but Processing in its detail view. It now shows Processing in both.
• Broadstreet and Google Ad Manager no longer create ads from incomplete creatives. A Broadstreet static ad with no image used to be created as an empty ad. A GAM image, HTML5 or tag creative with no declared size used to be uploaded as 300x250. Both are now refused before anything is created in the ad server, and the creative comes back failed with a message that names it and says what is missing (the image, or the width and height).
• Image creatives synced without a pixel size on the image itself, but with a size on the creative’s format, now reach Broadstreet with their image. Before this fix, Broadstreet static ads for these creatives were created with no image.
• Buyer agents assigned to a Google Ad Manager advertiser now see that advertiser’s existing GAM orders on get_media_buys, and GAM package delivery snapshots are filled in, refreshed hourly. Both had been empty.
• You can now add a VAST video creative to a media buy that is already booked or waiting for approval on a Google Ad Manager seller. Before, the creative was refused because it had no width or height.
• Saving a wholesale product no longer removes slots you declared on a format option. A video option that lists its VAST tag or hosted video next to your own slots keeps them all, and a tracker slot you declared yourself (for example an impression tracker you made required) stays as you declared it. Re-saving a product you just read back changes none of its slots.
• When your sales agent firmly refuses to set up a buyer’s account, for example with ACCOUNT_SUSPENDED or AGENT_BLOCKED, Apostra now stops asking. Before, it repeated the same request every hour. This already applied to billing refusals such as BILLING_NOT_PERMITTED_FOR_AGENT, and it now covers every refusal your agent marks as final, including your own codes when you return them with recovery: terminal. A later buyer request for that account asks again. Credential errors such as AUTH_INVALID keep being retried, because reconnecting fixes them.
• Buyer agents can now sign in with OAuth on a Seller’s shared-host endpoint, https://api.apostra.com/seller/{platformId}/mcp, as well as using an API key. MCP clients such as mcp-remote find the sign-in from the endpoint itself and complete it in one browser sign-in. Each sign-in works only for that one Seller, so connect each Seller you buy from separately; a sign-in for /mcp/v3 does not work on a Seller endpoint. API keys keep working as before. A Seller that sells through an ad platform such as Meta still takes that platform’s credentials, and a Seller’s own domain (/adcp/mcp) still needs an API key.

​

5.1141.0 — October 16, 2026 at 1:48 PM UTC

• Browsing wholesale products across sellers (search with kind: "wholesale_product") no longer loses products when a page has more text than a response can carry. Before, the list was cut off partway through, so your agent could see a seller’s full product count but only some of its products and pricing option ids. Now each page carries only whole products, says how many were held back, and the next page (nextCursor) starts with them. A page can therefore hold fewer products than your limit. Keep following nextCursor until no cursor comes back before treating the list as complete.
• An admin of the organization that owns your seller account, such as an agency or holding company above it, can now approve or reject your storefront’s media-buy and creative approvals when the approval is routed to a role they hold, including the default of organization admins. Before, only the account’s own members could decide, so a parent-organization admin was told the approval was assigned to another audience. Parent-organization admins are not routed to or notified, and approvals routed only to named people still go to those people.
• Sellers selected for the Sessions pilot can now review a bounded record of the buyer brief and the agent response, including the products and lessons that shaped it. Briefs show up to 1,200 characters, and lists show up to 12 products, bundles and lessons. Buyers see nothing new: their view of the exchange is unchanged.
• Opening a connection’s account with open_connections_page (connectionId plus accountId) works again. Since 15 October 2026 accountId on that tool had been read as the Apostra account to run the call in rather than the connection’s own account, so the call was refused (ACCOUNT_NOT_REACHABLE or ACCOUNT_MISMATCH) or opened the page without that account. Mapping a provider account from the Media Partners page is fixed the same way.

​

5.1140.0 — October 16, 2026 at 1:15 PM UTC

• The AdCP 4.0 readiness guidance now says to keep sending adcp.major_versions alongside adcp.supported_versions. AdCP 3.x still requires it, and an agent that drops it fails the AdCP 3 requirement today.

​

5.1139.0 — October 16, 2026 at 12:02 PM UTC

• The v3 creative read now returns what a seller said about refusing a creative. Each platformLinks entry on get with kind: "creative" can carry sellerErrors: the same list v2 returns as seller_errors, with the seller’s standard AdCP error code, its recovery (transient, correctable or terminal), and the field path and issues[].pointer it names, at most 10. The field name is camelCase and its contents keep AdCP’s snake_case names. It is present only for a failure the seller authored in its reply, and never carries the seller’s free text (message, suggestion, details, buyer_reason), so a refused creative can still show no sellerErrors. failureReason is unchanged and remains the reason to act on. Nothing to change on your side. What is kept, and what is left out, is in the Creative sync outcomes guide.
• Media buys now show failed creative deliveries and their reason, clear updates that failed after approval, and describe future-start buys as pending start instead of pending approval.

​

5.1137.0 — October 16, 2026 at 11:03 AM UTC

• Nothing changes for your account unless an administrator turns on the seller-history co-op, with one exception below. Joining is a setting on your buyer operator identity and starts off. Set sellerHistoryCoop with save_buyer_operator on /mcp/v3 (preview, then confirm) or PATCH /api/v2/buyer/readiness/operator. get_status and GET /api/v2/buyer/readiness report whether the account is a member.
• A member shares the judged results of its completed buys, only as aggregates that name no buyer, campaign or buy. Price is never shared. In return, a member reads other members’ pooled history of a seller once pooled reading opens for the account; until then joining only means your buys will count. Pooled figures are published monthly and rounded, and appear only with at least 3 operators and 5 judged buys behind them. A seller with less history than that shows no figure. Buys from an account with no confirmed operator identity are not counted, so confirm it before joining. Leaving withdraws your results at once.
• What changes for every account: the commitmentRecord include on a seller, and automatic product selection, no longer use the record pooled across every buyer. Members with pooled reading open read the co-op’s pooled history. Everyone else, including a member while the pilot is closed to it, reads only their own buys with that seller, with exact counts. A pooled record built from 40 or more judged buys has buys and judged rounded to the nearest 5, and beat, met and missed become beatShare, metShare and missedShare; a smaller one shows only a size band and a hit rate rounded to quarters. A seller’s own view of its record is unchanged. Buyers read the record in a pilot, and an account outside it that asks receives FEATURE_NOT_ENABLED. See the seller-history co-op.
• When Create Agent, Open or Review and claim cannot start from the Agents page, the page now keeps your list of agents and shows what went wrong beside it, with the reason when the server gave one. Before this, a failed launch replaced the whole list with “Couldn’t load Agents”.
• Ask Apostra in a Developer account can now start building an agent. Ask for a sales or creative agent and it opens the Create Agent task instead of sending you to the API. The Developer account’s Ask Apostra page no longer shows the advertiser picker, Media Partners or Creative Engines, and its starter prompts are about building, testing and certifying agents.
• Changing an advertiser’s brand is no longer blocked by a buy that has already ended (completed, canceled, rejected or failed) when that buy’s seller account can’t be worked out. Such a buy is skipped and listed in the advertiser’s audit history, because it will not be updated or canceled again. A live buy whose seller account can’t be worked out still blocks the change, and the error names it.
• A creative now reaches the seller as soon as it is on a media buy with that seller, including a draft buy that has not been submitted. Saving or editing a creative, attaching it to a campaign, and creating or changing a draft buy all send it within about two minutes, and failed sends are retried automatically. Buyers no longer call sync_creatives to start creative review, which also makes this work from the V3 API, where there was no such call. Sellers with manual creative review see these creatives in their review queue before the buy is submitted, so approval can be done by launch; other sellers receive them at their ad server or sales agent. A creative that is not on any buy with a seller is not sent to that seller.
• Signing up as an advertiser on your company’s domain no longer waits for a review when the only account already on that domain is a dead Seller account from the earlier Scope3 product. That old account is retired and your new account is created straight away. Its old contracts and invoices stay where they are. Nothing to change on your side.
• Organization administrators can now open Plan & Billing from Murph or an MCP client while they are in their organization account. Before this fix, asking to open Plan & Billing there was refused with a message saying it only opens inside a seller or buyer account, even though plan, usage and billing belong to the organization. Murph and agent tools also now name the account you are actually working in after you switch to it in the web app, instead of the account you signed in from. Nothing to change on your side.
• Explain whether a creative is awaiting a seller review, was superseded, or was rejected when media-buy execution cannot verify its seller-library revision.
• Creatives sent inline when a media buy is created or updated now follow the same rule as creative sync for Apostra’s impression and video playback trackers: axem and tmpx are included only when the seller’s format option declares that it fills them (AdCP macro_resolution_capabilities). A seller whose option declares neither receives neither parameter, and tmpx no longer reaches GAM-backed sellers on these paths. When Apostra can’t tell which of a seller’s options a creative is going to, the tracker keeps axem and drops tmpx. Stored creatives are unchanged; only the copy sent to the seller is affected. Nothing to change on your side.
• When your sales agent rejects Apostra’s credentials (AUTH_INVALID), Apostra no longer waits 24 hours before asking it to set up the account again. Reconnect your agent and the next account request goes out straight away. Other refusals your agent marks as final, such as BILLING_NOT_PERMITTED_FOR_AGENT or ACCOUNT_SUSPENDED, are still held for 24 hours.
• Murph replies now keep their paragraphs, headings, lists and quotes instead of arriving as one run-on paragraph with stray ###, --- and > characters.
• For Google Ad Manager buys, get_media_buys now lists each package’s creatives as GAM holds them (the creatives with an active association on the line item), so a creative that never reached GAM no longer shows as attached and a creative added in GAM appears. ext.scope3.live_fields says whether the list was read from GAM or is ESA’s own record.
• GAM products set to exclude child ad units can be booked again when their ad units have no child ad units. Since 1.68.0, GAM refused every new line item on such a product, and the order was archived.
• Buyers that register a completion webhook on creative syncs to Apostra-managed sales agents now receive it when a creative is auto-approved. Before this fix the sales agent approved the creative but never sent the webhook.
• Large product catalog and signals responses from sellers keep working: we now accept seller responses up to 64 MiB, instead of the 4 MiB limit the latest AdCP SDK would otherwise apply.
• You can now sync a customer list to an OpenAI Ads account with audience sync (save_audience). The first sync creates an OpenAI custom audience; later syncs add or remove SHA-256 hashed emails on it, and a repeated or retried change is applied once. Phone numbers and device IDs are not sent. Put the audience ID from the result in ext.openai_ads on a package: custom_audience_ids to include, excluded_custom_audience_ids to exclude, custom_audience_bid_multipliers (when you update a media buy) to bid up. Including or bidding up needs about 25,000 matched users, and Apostra refuses a smaller audience before writing the change; smaller audiences can still exclude people. Creating an audience without an uploaded file needs the small-audiences feature on your OpenAI Ads account, and the sync names it if it is off. Audiences can’t be renamed or used for campaigns targeting the European Economic Area or Switzerland. New and not yet certified against live OpenAI Ads.

​

5.1136.0 — October 16, 2026 at 9:41 AM UTC

• When our destination check finds that a creative’s format cannot be delivered to a seller’s destination, the creative now says the buyer must act. It reads sync_stage: not_sent and must_act: buyer with sync_reason: destination_profile_rejected on v2 platform_links, and platformLinks[].failureReason: destination_profile_rejected on v3. Before, it named Apostra, so the buyer was told they did not need to change anything. Supply a creative in a format that destination accepts. A creative the check rejected before this change may still name Apostra until it is sent again. The other two destination refusals, a destination we have not certified and a rendition we owe, still name Apostra. The creative sync outcomes guide lists every reason.
• If your V3 integration saves a campaign or material, add the required kind field to each bidding, channel group, age-targeting, metadata, or buyer-scope object before sending the request. Requests without it fail validation immediately; V2 and saved records are unchanged. See https://docs.apostra.com/v3/build-an-agent and https://docs.apostra.com/v3/bring-data-in for the current request guidance.
• Accepting an account invitation now opens the account you were invited to, including when you were working inside another account as Scope3 staff.
• When a seller refuses a creative in its reply, the creative’s seller link now keeps what the seller said about why, in AdCP’s own field names, so you can see what to fix. In v2, each platform_links entry on get_creative and list_creatives can carry seller_errors: the seller’s standard AdCP error code, its recovery (transient, correctable or terminal), and the field path and issues[].pointer it names. A code outside AdCP’s standard set, a path that names a field we do not know, and the seller’s free text (message, suggestion, details, buyer_reason) are never kept or returned, so a creative can show no seller_errors even when the seller gave a reason. A seller that refuses later through its review webhook shows none yet. The v3 read does not return seller_errors today; failureReason is still the reason to act on. Nothing to change on your side. What is kept, and what is left out, is in the Creative sync outcomes guide.
• Your source’s Diagnostics Calls list now includes calls Apostra could not send to your agent, for example when discovering your agent’s endpoint failed on our side. They show with the status NOT_SENT and the reason. Your agent never received them, and they don’t count against your agent’s health or behaviour checks. Before, these calls left no trace, so a failure on our side could look as if your agent had never been asked. Nothing is needed from you.
• A sandbox advertiser’s media buy is now recorded in Apostra instead of being sent to a provider such as Epsilon Retail Media or FreeWheel, so a test buy can’t create a real campaign or charge. This applies to sources connected to a provider’s campaign system, including your own sandbox advertiser buying from your own storefront. Sources where your team books by hand work as before.
• The recorded buy still counts for the Successful transaction go-live check, but it has no delivery or reporting and doesn’t prove your provider connection can create a campaign. To test that, use the provider’s own sandbox or test account. Editing isn’t supported; cancel the buy and create a new one. Nothing to change unless you were testing your provider connection with a sandbox buy.
• Media partners where your advertiser’s account is already active no longer ask you to complete advertiser setup.

​

5.1135.6 — October 16, 2026 at 8:38 AM UTC

• When a creative fits none of a product’s formats, creative sync now says so. It names the product and lists the sizes or durations the product offers for that kind, or says the product offers none of that kind. Previously the buyer was told the creative fits several formats and must state which one, which is wrong when none fits. The “several formats” message is now used only when more than one format really fits.
• Completed media buys now get one final delivery check before polling ends. If the seller’s lifetime impression total is higher than the stored daily reporting, Interchange retries the final breakdown and alerts our operations team when the totals still do not match. Nothing to change on your side.
• Apostra’s impression and video playback trackers now include axem and tmpx only when the seller’s format option declares that it fills them (AdCP macro_resolution_capabilities). A seller whose ad server can’t fill a macro no longer receives a placeholder it would pass through unfilled: GAM has no {TMPX}, so tmpx no longer reaches GAM-backed sellers, and a seller whose option declares no macros receives neither parameter. When Apostra can’t tell which of a seller’s options a creative is going to, the tracker keeps axem and drops tmpx. Stored creatives are unchanged; only the copy sent to the seller is affected. Sellers that want these filled can declare them on their format options. Nothing else to change on your side.

​

5.1135.5 — October 16, 2026 at 8:11 AM UTC

• A media buy now shows as active as soon as the seller’s system reports it active. Before, a buy with a Google Ad Manager–backed leg could stay on “pending” after the seller’s system was already delivering it. Nothing to change on your side; affected buys update on the next status check.
• GAM sellers now state in get_adcp_capabilities which macros they fill, and that list matches what their image and video format options say. Buyers that check both lists before putting a macro in a tracker will now accept GAM’s macros instead of treating them as unsupported.
• GAM storefronts now say which tracker macros they fill (cache buster, domain, GDPR flag, device id, and AXE where the publisher runs it). Buyers can rely on those macros being filled on image, hosted-video and VAST formats.
• Google Ad Manager sellers now honor the macro declarations a buyer attaches to a tracker or tag URL. A macro the buyer marks preserve stays exactly as written. A declared translation the format option supports is applied. A required declaration the seller cannot perform fails that creative with an error that names the declaration, instead of trafficking it silently. URLs without declarations, and the declarations Interchange sends today, are translated exactly as before.
• Interchange now measures impressions and quartiles on VAST creatives booked with GAM sellers through the ESA.
• If the Google Ad Manager user connected to Apostra isn’t allowed to approve orders, your orders used to sit in draft in GAM with no explanation outside the order itself. Apostra now shows a setup task, “Let Apostra approve your GAM orders”, that says what to ask your GAM admin for (permission to approve orders, or adding the user as an approver in your order approval workflow). Each order held for this reason also says why it is waiting. The task clears itself the next time an order is approved.
• Google Ad Manager sellers now describe their macro dialect with the same version Interchange uses, so Interchange’s macro declarations match what those sellers say they fill.
• Managed ESA buyers using AdCP 3.1 can read GAM delivery and product responses again; 3.2-only vendor metric details are omitted only for 3.1 responses.
• When Google Ad Manager refuses a flight-date or pacing change, the media buy now keeps the dates and pacing Ad Manager still holds. Before, the new values were saved and reported even though Ad Manager had not accepted them. The error now says nothing was changed, and the buyer retries the same update.
• Ads trafficked from a synced (library) creative to Broadstreet now keep the click-through exactly as the buyer approved it. Before, they carried Google Ad Manager placeholders such as %%CACHEBUSTER%% that Broadstreet never fills, so click trackers got literal placeholder text. Google Ad Manager creatives are unchanged.

​

5.1135.3 — October 16, 2026 at 7:00 AM UTC

• When your agent lists campaigns, the response now explains that it searches campaigns already saved in Apostra and points to the import option for campaigns created in Spotify Ads Manager or another connected ad platform. The import tool explains that it starts an ongoing, read-only sync, including future-start campaigns, and asks for confirmation first. No action is needed for campaigns already imported.
• If your buyer or seller integration handles 4xx responses from V3 public HTTP writes, continue reading the response code: validation, permission, missing-resource, and conflict errors now remain readable as terminal idempotency receipts instead of becoming uncertain. No request fields or retry logic need to change.

​

5.1135.0 — October 16, 2026 at 5:30 AM UTC

• If your V3 integration validates responses strictly, accept the response variants in V3 response variants before deploying this release. This is a breaking change with no grace window: calls that do not accept the new literals can reject successful responses. If you do not validate response shapes strictly, you do not need to change anything.
• Buyer-side callers of save_campaign and save_creative must accept their documented action values, including the campaign read-back-required receipts. Seller-side callers of bulk save_advertiser and save_connection must accept their documented action values; bulk advertiser lifecycle responses now use bulk_archived and bulk_restored instead of archived and restored.
• get, search, and get_delivery now identify their successful branches with documented outcome or report values. save_billing also has documented payment-authority action values.
• The API integrations team will monitor real-account response-validation rejections for seven days after deployment. The check passes when no new strict-parser rejection is attributed to these result variants. If one occurs, contact the API integrations owner and revert this contract change.
• Uploading a video through the creative-upload widget’s campaign-composition flow now shows the same name/headline/body/call-to-action/display-name/click-URL form images get, and saves it as a campaign creative with that copy attached. Previously the widget silently finished the task without creating any creative for video uploads, even when a campaign composition was requested. Image uploads are unaffected.
• Campaign creative sync keeps completed managed storefront deliveries available to a later media-buy launch when the creative revision and selected inventory source match.

​

5.1134.0 — October 16, 2026 at 4:42 AM UTC

• A creative’s seller links now say where the creative stands, who must act, and why, so a creative Apostra never sent is no longer reported as a seller rejection. In v2, get_creative and list_creatives add sync_stage (not_sent, pending or failed), must_act (seller, buyer or apostra) and sync_reason to each platform_links entry. In v3, platformLinks[].failureReason now carries the same reason for a creative that was not sent or failed, in place of the fixed sentence it carried for a missing click-through URL; a creative that is pending or live has no failureReason. Creatives that were last written before this release show no reason until they are next sent to that seller. Nothing to change on your side. The meaning of every reason is in the new Creative sync outcomes guide.

​

5.1133.2 — October 16, 2026 at 4:24 AM UTC

• A seller issued us an account id. When we attached that id to a creative upload or media-buy create, the seller refused and asked us to let it identify the account from who is calling. We now retry that call once without the id, remember this separately for each call, and nothing changes for any other seller.
• In Settings > Connections, Advertiser mapping shows each platform account once when multiple connections reach it. Existing advertiser mappings appear together, and mapped accounts no longer also appear as unmapped. Your connections and authorizations remain separate. No action is needed.

​

5.1133.1 — October 16, 2026 at 4:05 AM UTC

• Accepting a multi-account plan now converts an invited standalone Buyer account into an organization before applying the plan.
• Approving a creative save in chat now uses the shared approval card, and the approval stays open for 24 hours.

​

5.1133.0 — October 16, 2026 at 3:29 AM UTC

• Fixed the Meta “Awareness — 2-Second Video Plays” product so a media buy launched without an explicit buyer optimization goal now sets the Meta ad set’s performance goal to “Maximise 2-second continuous video plays,” matching the product’s stated outcome. Previously it silently fell back to “Maximise reach of ads.”
• Keep OneDrive available when Microsoft 365 SharePoint consent is missing and show the administrator action in the source picker.
• Fixed save_creative rejecting headline, body, call-to-action, display name, and click-URL copy on a hosted-video creative that uses the canonical video_hosted format kind with no seller- or product-specific format option. Social-seller video ads (Meta, TikTok, and similar) can now carry the same ad copy and destination URL a hosted-video placement needs.
• As part of this fix, the underlying slot ids these fields are stored under now match AdCP’s own video_hosted defaults instead of this platform’s prior internal names (the typed social.body/social.callToAction/social.displayName field names you set are unchanged). Breaking: the typed social.description field is removed — AdCP’s video_hosted format has no equivalent slot, so it’s no longer accepted on save_creative or offered in the creative-upload widget. If you currently send social.description, drop it from your call; every other field keeps working unchanged.
• Sellers: not applicable. The renamed slot ids are this platform’s internal storage representation only — the values your storefront’s ad-server sync receives and renders for Meta, TikTok, Amazon, Spotify, and LinkedIn are unchanged, and the rollout keeps reading both the old and new ids throughout the migration so no existing creative becomes unresolvable.
• Sellers in the Lessons pilot can now choose Teach this from a private Session note in any compatible MCP Apps host. The note remains private, and only a directly signed-in seller can propose a lesson from it. This does not change what buyers see. Nothing to change on your side.

​

5.1132.0 — October 16, 2026 at 2:49 AM UTC

• A launched media buy with no creative attached now reads as waiting for creative: its pending reason is no_creatives_attached, whatever lifecycle the seller reports for it, including active and pending_start. Before, a buy the seller showed as live or scheduled without a creative looked as if delivery had started or was merely scheduled. The reason shows on the media buy and on the same buy inside its campaign, and clears once you attach a creative. A buy whose creatives were attached but none matched the seller’s formats is unchanged. Nothing to change on your side; attach a creative to a buy that shows this reason so it can deliver.

​

5.1131.0 — October 16, 2026 at 2:35 AM UTC

• Filter your media-buy list to one seller account with sellerAccountId on GET /media-buys. Use it when a buyer company transacts through a company-owned account; pass either it or accountRelationshipId, not both.
• Creatives, media buys and discovery on a storefront that passes your requests to a third-party sales agent no longer fail with source_account_not_bound when the agent’s account listing shows more than one account for your brand and operator. Apostra now uses the account the agent returned when your account was set up, or sends your brand and operator when the agent issues no account IDs. A seller’s explicit account mapping still comes first.
• On storefronts that use complete account keys, an account with no mapping to a third-party sales agent’s own account is no longer refused with source_account_not_bound. Apostra now sends the agent the account’s key as far as its AdCP version can read it, including the brand ID, and uses the account the agent returns. Complete account keys are not yet enabled in production.
• In Sessions, after you save a private note on an agent response, choose “Turn this into a lesson” and Murph proposes a lesson in your own words, with a card showing its scope and wording. A seller account admin approves or retires the lesson from that card; nothing changes for buyers until it’s approved, and buyers never see the lesson text. Available only on storefronts where your Scope3 team has enabled the pilot.
• Plan refusals now explain when an account change would make your organization both buy and sell, and name the plans that cover it. Which accounts and plans are allowed does not change.
• OpenAI Ads media buys now report an accurate revision and the actions you can take next. get_media_buys returns a revision that changes whenever the campaign, an ad group or an ad changes, lists the valid actions for the buy’s current status, accepts status_filter, and returns each package’s bid_price and audience bid multipliers. update_media_buy rejects a stale revision with a conflict before changing anything, applies one update to a campaign at a time, and returns the revision, status and valid actions read back after the change. A bid cannot be cleared: send a positive bid_price instead. Nothing to change on your side unless you pass a revision you read earlier, in which case re-read the media buy first.
• Your request list loads again if one of the requests we track for you is a support request. Since the previous release, GET /api/v2/asks, the V3 search tool for asks, and Murph’s answers about your requests returned an error for those accounts instead of the list. They now return every request. A support request we track alongside your product requests is listed with type product. Nothing to change on your side.
• Approved media buys on a seller account your organization holds through automatic activation now forward to the seller, and deleting such a buy now cancels it with the seller instead of failing.
• When a launch is refused because a creative hasn’t reached the seller yet, the error now names both ways forward: sync the creative and launch again, or remove the creative from the media buy to launch it now as pending_creatives and attach the creative once the seller has it. See Media buy lifecycle.
• Mapping an event source to a seller account no longer requires the Conversion events switch. Mapping only records which pixel or dataset on the account your source uses and sends none of your conversion data, so a mapping now confirms with the switch off, and media buys whose goals name that source go ahead. Mappings that were waiting on the switch confirm on their own within about an hour.
• When an account becomes an organization, any current Commercial Offer that has not been accepted moves with it and remains available in Plan & Billing.
• When your Google Ad Manager user can’t approve orders, Apostra now says so. Source health shows a seller-owned gam_user_cannot_approve_orders finding with your network in detail, the ad-server status shows the same issue with a docsUrl, and a buy that GAM holds in draft for this reason shows the pending reason awaiting_ad_server_approval_permission, with the next step on the Media Buys list. See Your GAM user can’t approve orders for the three causes and the permission your GAM admin changes. Approving each order by hand in GAM also works.
• A creative that cannot sync because a seller’s product offers several formats now says who must act. When the creative lacks a size or duration, the buyer is asked to declare it. When the seller’s ids are not defined by its creative agent, the seller must correct them. When the creative states everything and Apostra still cannot choose, Apostra must act and neither the buyer nor the seller is asked to change anything.
• You can now measure ChatGPT ad conversions through Apostra. When you attach an event source to an OpenAI Ads account with sync_event_sources, Apostra creates or reuses the account’s OpenAI pixel and one standard event setting (30-day attribution window) for each event type you declare, then reads them back to confirm. After that, log_event forwards your server-side conversions to OpenAI’s Conversions API, with the IP address, user agent and OpenAI click ID (oppref) when an event carries them. Hashed email and phone are not forwarded to OpenAI Ads. Apostra stores the account’s Conversions API key securely and never returns it. Set up the event source before you send events, because log_event returns an error for an account that has none. Apostra checks each event first (type, a seven-day window, and a source URL for website events), refuses any that fail and sends the rest, so one bad event no longer fails the batch. AdCP event types with no standard OpenAI event, such as refund and search, are refused rather than approximated.
• If your storefront passes requests through to your own sales agent, the channels and countries your agent declares in get_adcp_capabilities (primary_channels and primary_countries) now show on your Listing. Before this fix they stayed empty, so Listing step 2 could not be completed. Requests that filter by channel or country are now sent to your source only when they match what your agent declares. If your agent leaves out either list, your storefront’s own channels and countries are used instead, as before.
• A media buy that doesn’t state a currency is now bought in the currency its selected pricing is quoted in, instead of the Seller’s default currency, so a USD-priced product on a GBP-default Seller books in USD. A buy whose stated currency differs from the selected pricing, whose pricing options are in different currencies, or whose pricing currency the Seller doesn’t settle in is refused before it reaches the Seller, with an error naming the currencies and how to fix it. Previously such buys were locked in the Seller’s default currency and then could not be booked. When a product has several pricing options, the buy is also now booked at the option you selected rather than the product’s first option.
• When Apostra refuses a signed-in session, the sign-in page now says why and offers Sign out, instead of silently returning you to an empty sign-in form.
• Buyer Setup now asks one question before you create your first advertiser: “Have you double-checked your media partners?” Choose “Review media partners” to open them. It is a reminder, not a requirement: it never blocks creating an advertiser or setting up accounts with media partners, and it shows as done once your company has made a choice about its media partners. Agents see it as a recommended step in get_status, and the v2 API returns it as the media_partners readiness check.
• Campaign creative sync no longer says a held creative has no compatible format. A creative held from delivery, such as one imported from a third-party tag sheet, is now listed in the media buy’s heldCreatives with its reason and what clears it, and is not sent to the seller. When every creative on the campaign is held, the buy reports CREATIVES_HELD_FROM_DELIVERY. NO_COMPATIBLE_CREATIVES now means a creative’s format was checked against the buy’s products and fit none of them. When a campaign has both held and deliverable creatives, the deliverable ones still sync.
• If your storefront’s inventory is a modular catalogue, such as an avails feed, you can clear the “Successful transaction” check yourself, with nothing to request from Apostra. The checklist used to ask for a “seller-owned no-spend test campaign” without saying how. It now does: in your own seller account, create a sandbox advertiser, then launch a sandbox campaign with it against a product from your own catalogue. The check turns complete shortly after your inventory source accepts the buy. If your storefront has a source that sends campaigns to a provider, such as a CitrusAd connection, do not run a sandbox campaign against it: Apostra does not currently stop that buy from creating a real campaign at the provider, and the provider may charge you for it. For those storefronts the checklist no longer recommends a sandbox campaign. Use the provider’s own sandbox or test account if it gives you one, or ask Apostra Support to review your storefront. Clear the other items on your checklist first. A storefront with an external sales agent still needs that agent’s own test, storefronts that run only on managed ad servers and demo storefronts never needed this test, and passing the check does not make your storefront live to buyers by itself. The new “Pass the go-live test” guide in the docs walks through each step.
• The seller rail rows now carry the same name as the page they open: Dashboard is now Seller analytics, Business rules is now AI Business Rules, and Branding & distribution is now Listing.
• When a colleague or service token asks a storefront for a seller account your organisation already holds, sync_accounts now returns that account as unchanged instead of opening a second account for the same brand. Dry runs report the same result, so a dry run no longer says created for an account you already have. This applies to storefronts that use the original account mapping; a caller’s own existing grant or request for the account still comes first, and an account is never shared with another organisation.
• Sign-up now explains why you can’t sell with a personal email. If you sign up with a Gmail, Outlook or other personal address, “Sell inventory” appears greyed out with the note “To sell inventory, sign up with your work email.” Previously the option was hidden with no explanation.
• An HTML creative saved as a single file or tag now takes its size from its own markup: a <meta name="ad.size"> tag, the size on a Campaign Manager <ins class="dcmads"> tag, or a fixed pixel size on the page body. Existing HTML creatives that had no recorded size are being measured the same way, so sellers receive the size the creative declares rather than one guessed from its file name. When the markup does not state a size clearly, nothing changes: the creative saves as before.
• Sales agents that declare RFC 9421 webhook signing no longer get an HMAC credential on creative syncs. If your capabilities declare webhook_signing.supported: true and an identity.brand_json_url, the sync_creatives call carries no authentication block, which is how AdCP asks a seller to sign with RFC 9421. Sign the callback with the key in your brand.json, over the callback URL exactly as sent. Every other agent keeps the HMAC credential and needs to change nothing.
• You can now send an optional accountId (the value from get_status) on V3 tools other than switch_account and manage_organization. It runs that one call in that account, so you can work in several accounts at once without switching and without moving another conversation on the same connection. Access is checked the same way switch_account checks it, so naming an account never grants new access. On member reads in get, save_account and save_directed_campaign_subscription, accountId names the call’s account only alongside memberAccountId, id or providerAccountId; without them it keeps its earlier meaning. Calls that leave it out behave as before, running in the account the connection last switched to, and their results now end with a reminder to send accountId; switch_account will be retired later, with no date yet.
• You can now declare a VAST tag’s version when you save a VAST creative through V3. In save_creative, a VAST asset takes an optional vastVersion (2.0, 3.0, 4.0, 4.1, 4.2 or 4.3), for a tag URL and for inline VAST XML sent as a dataUrl. A managed Google Ad Manager seller needs a known version, so an inline VAST creative, or a tag we could not read when you saved it, can now reach that seller instead of failing with missing:vastVersion. The version you declare is kept; if the tag returns a different one, the save response’s warnings tell you. The V3 creative read and the save response return the stored version as assets[].vastVersion. In the V2 API, linked_assets entries take the same field as vast_version. Creatives you saved without a version keep working as before, using the version we read from the tag when we could.

​

5.1130.3 — October 16, 2026 at 12:17 AM UTC

• In Media Partners, selected ad platforms you have connected now keep their connection action visible when advertiser activation status is missing or does not qualify. In an advertiser’s view, a mapped account shows Manage; otherwise the card offers account selection, reconnecting or advertiser mapping when needed. You do not need to reconnect an already working account. Existing exclusions and buying restrictions still apply; this corrects the displayed action without changing account access or buying permissions.
• {MEDIA_BUY_ID} in Apostra’s impression, playback and click trackers is now always your media buy’s own id, the mb_… id the API returns, whichever way the creative reaches the seller. Before, a creative sent after the buy was submitted, or through a campaign creative sync, carried the storefront’s transaction id instead, so the same buy could report under two ids. Click-URL parameters you configure keep the storefront transaction id used for attribution. Creatives already at a seller keep what they were sent until their next sync. Nothing to change on your side.

​

5.1129.0 — October 15, 2026 at 10:29 PM UTC

• Agents on V3 can now read how each seller in a campaign did with get on the campaign and include: ["sellerScorecard"]. You get the same scorecard as the API’s campaign seller scorecard, over the campaign’s whole reported life: delivery, price, performance and quality, each ranked on its own with who counted it. The read carries at most 50 sellers, most spend first, with sellersOmitted counting the rest; every rank is computed over all of the campaign’s sellers before that cut. The text answer names each seller beside its Storefront id, gives every score’s value and rank or the reason it has no rank, and says when reporting is missing days so spend is understated. The include is open to buyer accounts on the standard buyer profile, which new buyer accounts get by default, and to buyers in the V3 beta; an account without it gets a FEATURE_NOT_ENABLED error instead of an empty scorecard. Seller accounts cannot request it, and searching campaigns does not offer it.
• Choosing All channels for an advertiser now completes its setup. Before, Media Partners kept showing “Complete advertiser setup” for an advertiser saved with All channels, and saving again did not clear it. Now an advertiser that chose All channels opens Media Partners, is matched in every channel a media partner offers, and gets seller accounts set up ahead of time with every matching media partner in its markets, the same as an advertiser that named its channels.
• If an advertiser has not chosen its channels yet, Advertiser settings now asks for All channels or specific channels before it can save, and Media Partners asks for the same thing. Until then, no seller account is set up ahead of time for that advertiser. Advertisers saved before this release with a blank channel list are treated as not chosen yet, because a blank list could not tell a deliberate All channels choice from a question nobody answered. Choose once to continue. Creating an advertiser now asks the same question rather than defaulting to All channels.
• Through the API, advertiser reads now include channelsKnown. When it is true, an empty channels list means All channels; when it is false, the advertiser has not chosen yet. Send channels: [] to choose All channels. Creating an advertiser without channels leaves them unchosen, and V3 search results for advertisers carry the same channelsKnown field.
• Products you priced with your own fixed CPM are visible to buyers again. Since a Google Ad Manager pricing sync on 15 October, products whose only price was a fixed price you set were hidden from buyer discovery as having unusable pricing. A fixed price in one of your storefront’s currencies is now enough on its own, whatever the ad server reports.
• Fixed creatives on account-pinned Storefront media buys never reaching the seller when re-sent automatically. Our Storefront refused every automatic re-send with “An account id requires current buyer authority on this storefront”, so a creative that failed its first send stayed undelivered. Automatic re-sends now carry the buy’s recorded account authority and go through.
• Storefront readiness now identifies managed ad-server connections that need a sales-agent principal before linked buyer accounts can sync creatives.
• The Media Partners page and the seller read now say why an account request is waiting in two more cases. If a media partner refuses the billing Apostra asked for, the advertiser shows Action required with Media partner refused the requested billing, so you know to contact the partner instead of waiting. If you chose direct billing and the advertiser has no usable media billing entity, it shows Action required with Add or fix the media billing entity. Before, both showed as a generic setup failure.
• Accepting a seller proposal now retains the products needed to stage its draft media buy and leaves the proposal available when that staging cannot start.
• Notifications in the web app no longer appear inside a second, dark container. A toast now draws one surface, tinted for its severity with a matching icon, so an error reads as an error at a glance instead of a pink message framed by a near-black box. The error a widget raises when it cannot load — “Couldn’t load your media buys.”, for example — was the worst case and is fixed with the rest.
• When your sales agent refuses an account request in a way that sending it again can’t change, Apostra no longer repeats the same request every hour. One example is answering BILLING_NOT_PERMITTED_FOR_AGENT for a billing mode your agent declares. Source diagnostics now show the refusal with your agent’s error code and recovery: "structural", and Apostra waits 24 hours before sending the same account request again. To clear it, fix the cause in your agent, for example by accepting the billing mode you declare or removing it from supported_billing.
• Inventory Components now names the mapping table by the inventory type you select. Choosing GAM Ad Unit shows the column header as “Ad unit” and the group counts as “N ad units”, instead of always reading “Placement”. Other selector types (including FreeWheel sites and sections) follow the same rule.
• If you validate MCP structuredContent against tools/list, expect a schema that identifies the response variant and its required fields. Use the OpenAPI specification or the TypeScript or Python SDK for complete nested response types.
• GET /api/v2/buyer/advertisers/:advertiserId/measurement-freshness no longer requires geos. An advertiser with no geo breakdown was refused with a 400 instead of being told it has no gaps. An empty geos is now read as no geos rather than as one geo with an empty name, which the freshness check used to report as missing in every window.
• Media Partners no longer hides every media partner while an advertiser’s setup is incomplete. When an advertiser has not answered its country scope or channels, the advertiser view now shows one Complete advertiser setup notice above the directory instead of replacing it. Direct ad platforms such as Meta stay visible and can be connected and managed as usual, because they never depend on the advertiser’s markets or channels. Seller-managed media partners that do depend on them read Needs advertiser setup until you answer. Nothing changes for API integrations.
• An advertiser’s all-campaigns property lists now apply in every channel. Saving a new all-campaigns list replaces every previous list of the same purpose (include or exclude), and the response names them in replacedPropertyListIds. filters.channels_any is kept with the list as AdCP’s channel filter and no longer limits which channels a list applies to. Creating or restoring a property list no longer requires the advertiser to have a linked brand, and an advertiser’s lists keep applying when its brand is re-linked.
• Orders on a GAM network where your GAM user may approve orders but not overbook them are now approved instead of staying in draft. If your GAM user can’t approve orders at all, the order stays in draft and the message names the network and says to ask a GAM admin for permission to approve orders, or to add the user as an approver in your order approval workflow.
• Impression and playback trackers (start, quartiles, complete) on a hosted VAST tag are now sent to Google Ad Manager. They were previously dropped, so measurement on VAST creatives is no longer missing. A tracker Google Ad Manager cannot carry is now reported in the logs instead of vanishing.
• Buyers can use seller connections whose legacy managed records did not retain the Sales Agent default principal, instead of being refused as incompletely set up.
• If a creative you attach to a live media buy fails to reach the ad server, syncing it again now retries the upload. Before, a failed upload could not be retried by re-syncing.
• Changing the ad units on a Google Ad Manager product whose display formats were saved without sizes now works. The product’s display formats take the sizes of the new ad units and get a new format ID for the sized version, so buyers pinned to the old ID must pick the new one.
• Creatives you attach to a Google Ad Manager media buy after it is booked now upload to the ad server when the buy’s advertiser comes from your account. If the seller has no advertiser for the buy, the sync now reports an error for that creative instead of reporting success.
• A creative that failed to sync to a seller platform (such as Spotify or Meta) is now sent again the next time you launch or sync. Before, an identical retry replayed the earlier failure for 24 hours, so a creative stayed stuck after the cause was fixed. A sync in which any creative succeeded is still replayed, so a retry never creates a duplicate ad.
• A VAST or DAAST tag from Campaign Manager 360 now reaches a seller with its macros filled in. When Apostra sends your tag URL to a seller as it is, [timestamp], ${GDPR} and ${GDPR_CONSENT_<vendor id>} go out as the AdCP macros {CACHEBUSTER}, {GDPR} and {GDPR_CONSENT}, each declared in the creative’s macro_declarations, so the seller’s sales agent can fill them. Consent keeps the vendor id your token names. Tokens Apostra cannot map are sent as you wrote them, and the tag you saved is never changed.
• Settings → Selling mode is rebuilt on the Apostra design system, and now says what the choice is between: listing your inventory with your own agent, or listing and selling it with Apostra’s hosted agent by creating an AMC account. Previously the pane asked “How would you like to sell?” three times over and explained only the mode already chosen.
• An empty field reads as a prompt rather than a blank, and “Just list” is now “List only”. An archived storefront keeps the control visible but locked, and says why.
• Our impression and playback measurement now reaches sellers for a buyer’s VAST or DAAST tag even when Interchange’s hosted wrapper is not in use. The creative carries our impression tracker as a standard AdCP url asset (url_type: "tracker_pixel") and our start, quartile and complete trackers as vast_tracker assets (daast_tracker for audio), each with its macros declared, for the seller’s sales agent to assemble into the VAST it serves. Previously the tag reached the seller with none of our trackers.
• Seller-refused media-buy updates now clear the pending change while keeping the live buy unchanged.
• V3 tools: member reads in get, save_account, and save_directed_campaign_subscription name their account with new inputs (memberAccountId, id, and providerAccountId) instead of accountId. Calls that still send accountId keep working for now.

​

5.1128.0 — October 15, 2026 at 7:02 PM UTC

• When a media partner’s sales agent cannot take account requests, advertisers that don’t already have an account with that partner no longer see its products in discovery and can’t book with it, and the booking refusal now says why. Advertisers whose accounts the partner already accepted keep discovering and buying as before.
• For sellers: your agent must list both sync_accounts and list_accounts and accept the connected credential. Until it does, certification skips your agent and new buyers can’t start buying from you. Your Agent page shows this as Takes buyer account requests.
• An operation on a source’s health page now reads Degraded while a blocking or needs-attention diagnosis finding is about it, even when every call succeeded. The source diagnostics widget shows such a row as Needs attention with the finding’s summary as the reason, so product discovery no longer shows Healthy next to a finding that products declare creative formats their creative agent does not define. Each operation row lists its findings in findingIds, and the most severe finding’s owner is the row’s owner when no failing call set one.
• Each finding under Agent-wide behaviour on the Agent page now says which threshold it applied and what to do next, and links to a section of “Sales Agent requirements and best practices” that gives the threshold, the usual causes and the next step. For example, the async completion finding now says a handed-off task needs a final status within five minutes of our request, instead of “before its deadline”. Nothing changes in how Agents are assessed, and no action is needed on your side.
• Your request list now includes the product requests we are tracking for your account. For some accounts, GET /api/v2/asks, the V3 search tool for asks, and Murph’s answers about your requests left those product requests out and reported product requests as unavailable, and opening one of them by id returned an error. Support and supply requests were not affected. Nothing to change on your side.
• When a change you make in Inventory Components is refused, the widget now shows the reason it was refused instead of “REST call failed”.
• Fixed some creatives that were never re-sent to the seller after our own Storefront refused them. Before 15 October, such a refusal was recorded as if the seller had rejected the creative, so the automatic retry skipped it. Those creatives are now retried on live buys, up to the usual three attempts.
• An advertiser’s brand domain is now stored in lowercase, however it was typed. Advertisers whose brand domain had a capital letter (for example Prominent.nu) could not be matched to the accounts media partners opened for them, so their accounts didn’t show as active and automatic setup with those partners stalled. Those advertisers are fixed, and reads now return the brand domain in lowercase. Nothing is needed from you.

​

5.1127.0 — October 15, 2026 at 6:12 PM UTC

• Your organization’s account domain now counts as a company domain of the organization. When your organization has a designated owner for new Buyer accounts, people signing up with an email on that domain are no longer offered a separate account; they are asked to request an invitation from your admin. A Buyer signup link claimed with an email on a domain owned by a different organization now goes to Apostra for review. A domain that another organization already holds, or that several organizations claim, is never reassigned.
• On a source’s health page, a finding’s calls now open right under the finding instead of switching to another view. Select Show calls on a finding to see the calls for the operation it is about, within the time window the finding covers, and keep reading the rest of the diagnosis in place. See all calls still opens the full list of calls for that operation. The calls shown are ones you could already read.

​

5.1126.1 — October 15, 2026 at 5:33 PM UTC

• On Google Ad Manager sellers, a buyer can now get the GDPR consent string filled in their trackers. They declare the IAB vendor (for example ${GDPR_CONSENT_755}) for {GDPR_CONSENT} in the tracker’s AdCP macro declarations. Without a declaration, consent stays empty as before.
• Google Ad Manager products that cover a whole site, or ad units with many child ad units, now list the display sizes those ad units commonly take, instead of every one-off size any single ad unit carries. Sponsor strips and labels shorter than 50px are no longer offered as display sizes. Products set to exclude child ad units now book only the ad units the seller chose.

​

5.1126.0 — October 15, 2026 at 5:19 PM UTC

• The Settings button in the seller rail’s mode switch now uses a sliders glyph instead of a gear, so it reads as “adjust your account” rather than repeating the gear used elsewhere in the rail.
• When a v2 call is refused because the account is not enabled for the v2 API, the refusal now names the account it is about and what opens it, instead of “your account does not have MCP access enabled, please contact your administrator”. A caller who has switched between several accounts can tell which one was refused. The MCP refusal also carries a structured ACCESS_DENIED code, as every other refusal on that surface already did.
• A call refused because the check itself could not be completed now says so and asks you to retry, rather than reading identically to a settled refusal where retrying does nothing.
• V3 campaigns now use AdCP’s own names for budget pacing and channel group inventory. save_campaign takes and V3 get and search return budget.pacing as even, asap or front_loaded (it was frontloaded), and a channel group’s inventory as property_types, device_type and format_kinds (it was propertyTypes, deviceTypes and formatKinds). channels is unchanged.
• V3 callers that send frontloaded or the camelCase inventory names now get a validation error, and callers that read those fields must read the new names. Existing campaigns keep their saved pacing and channel groups and read back in the new names. The V2 API is unchanged and still uses FRONTLOADED and the camelCase inventory names.
• Reading your wholesale products with an inventory source’s numeric ID now reports whether buyers can find them correctly. Before, those reads showed every product as hidden from buyers (catalog_unavailable), even when buyers could find it. Reads that use the source ID shown in your source list were already correct.

​

5.1125.0 — October 15, 2026 at 4:47 PM UTC

• Fix advertiser edit so selecting the pencil opens Advertiser Setup.
• Reject invalid campaign seller IDs instead of silently dropping named sellers from a saved campaign.
• Seller calls now consistently retain Scope3’s debug and correlation identifiers when a source configuration contains similarly named headers.
• Prevent duplicate browser fallback links for MCP hosts that render buyer widgets.
• A server-to-server integration that calls switch_customer keeps its access again. Since 14 October, switching customer on such a credential downgraded it to read-only, and every later call that reads an advertiser failed with “Access denied. No user context available for advertiser permission check.” Nothing needs to be changed on your side; existing credentials recover on their next connection.
• Live certification now counts tracker hits on regular media buys when the sales agent reports its own media buy id, not only on certification buys.
• Breaking (V3): save_notification_config now takes trigger.kind instead of trigger.type, and content.kind instead of content.type. A request that still sends type is refused. Every notification_config label is now kind, and the save response and get(kind: "notification_config") return the same subscription shape.
• Callers must rename:
• trigger.type → trigger.kind (schedule or condition), in requests and reads.
• content.type → content.kind, in requests and reads.
• provenance.type → provenance.kind (user, contract, plan or system), in reads.
• Each condition predicate is labelled only by kind (metric or campaign_pacing_behind_continuously); get now returns it, as the save response already did.

​

5.1124.0 — October 15, 2026 at 3:14 PM UTC

• Plan & billing now has one place for each thing it tells you. Media invoices moved onto the Media billing tab, beside the entities that route them, so Payment & invoices covers Apostra fees alone. The Contracts & orders tab is gone: the agreements you accepted, their signed documents, and every plan they put you on now sit in a Plan history panel on Plan & pricing, which already showed the contract those records describe — that tab repeated its status, dates and renewal in full. Billing details reads as a summary of what we hold on file, with an Edit action that swaps the section into a form and a Cancel beside Save. Sections that were named after the tab they sat on are named after what they contain: Fee invoices, Media invoices, Who gets each invoice, Preview a match, Fee rates on media. Payout activity and invoice activity are tables rather than loose rows, payouts read as one line per account, and a payment hold states itself once, as a single warning with the action beside it.

​

5.1123.1 — October 15, 2026 at 2:45 PM UTC

• Buyers with booked storefront products that are no longer present in the live catalog can continue syncing creatives with the seller’s required legacy format.

​

5.1123.0 — October 15, 2026 at 2:33 PM UTC

• Signing up to build agents now gives you an organization with your Developer account inside it, and makes you the organization’s Admin. You still land on the Developer account’s Agents page, with the same free agent-builder features. Because the organization holds your company’s plan, billing and people, you can add Buyer or Seller accounts to it later without converting anything. If the organization cannot be set up, signup now returns a retryable error rather than succeeding without it, and signing up again finishes the setup. Nothing else to change on your side.
• Report canonical creative-format ambiguity for the relevant product when updating a multi-product media buy.
• Seller-authored fixed CPM products keep their configured prices when GAM pricing syncs run; GAM no longer adds auction guidance, a floor, or a minimum spend to those options.
• Media buys now tell the seller which currency the buy is in. Previously the request carried only bare package amounts, so a seller that trades in several currencies could book a buy in its own default currency instead of the one you chose. A buy with a line that has no currency, or whose lines are in different currencies, is now refused before it is sent, rather than guessed. See Cross-currency buying.

​

5.1122.0 — October 15, 2026 at 1:50 PM UTC

• Account administrators can now change an advertiser’s brand without creating a new advertiser, even after its first campaign or seller account. The change applies to future buys only. The advertiser keeps its ID, campaigns, reporting, creatives and settings. Nothing changes for existing advertisers unless an administrator makes the change.
• To do it, call save_advertiser with identityContract: "confirmed-v1", the new brand and preview: true. The preview lists the live buys that stay on the current brand until they end, the buys not yet sent that will go out under the new brand, and the sellers that will see a new account, and says when that seller list may be incomplete. Once the person confirms, repeat the call with the confirmationToken.
• Buys already sent to a seller keep the seller account they were booked under, so updates, cancellation and delivery reporting keep working. The first buy under the new brand at each seller opens a new seller account for that brand, and the seller decides on it separately. Changing back to an earlier brand reuses its seller accounts. A brand an advertiser has used stays reserved to it, so no other advertiser can take it.
• Limits:
• If a buy already sent to a seller can’t be matched to its seller account with certainty, the change is blocked and that buy is named.
• The change is refused for an advertiser a seller reaches through external self-serve access, and for an advertiser a seller lists in its own roster.
• Currency and sandbox still cannot change after first use, and the v2 PUT for an advertiser still refuses a brand change at that point.
• People who sign up to build agents are no longer signed out straight after signing in. Developer accounts now stay signed in instead of being sent to the advertiser waitlist.
• Updating a media buy’s creatives no longer silently ships incomplete content to a seller when a creative’s text (e.g. a headline) fails a pre-dispatch completeness check. Previously that refusal was swallowed by an existing fallback and the update proceeded anyway with a frozen, incomplete payload; the update now fails instead, matching every other local payload refusal (e.g. a private-storage URL).
• Show managed wholesale products as available to composition when they pass the same cached visibility check used by storefront health.
• Proposal request rounds now finish after a seller dispatch fails before it starts five times, so a stuck round no longer prevents a new round.

​

5.1121.2 — October 15, 2026 at 12:55 PM UTC

• A workflow left open in the storefront’s queue for a media buy that has since been approved, canceled, rejected or completed now closes on its own within about 20 minutes, and anything the system cannot reconcile by itself is reported to the operations team instead of staying silent.
• Video buys on Google Ad Manager sellers now report quartile completions (25%, 50%, 75% and 100% of the video played) on the buy and on each package. Completions and quartiles are reported as 0 when none happened, instead of being left out.
• Delivery reports from Google Ad Manager sellers now include each package’s impressions and clicks before invalid-traffic filtering, reported as vendor metrics from google.com beside the billable counts. The gap between the two shows how much of a buy’s traffic Google Ad Manager filtered out.
• Approving a pending ad-server order approval now approves the order already in Google Ad Manager. It no longer creates a duplicate order. If GAM still refuses (for example, the service account can’t approve orders), the approval stays pending in the seller’s queue, the media buy stays pending, and nothing new is created in GAM.
• Approving a held workflow step on a media buy whose order already exists in the ad server no longer creates a second order. Approving an inventory availability review, or retrying a buy approval, approves the order the buy already holds; approving a step with nothing to do on an existing order is refused and the step stays pending. A failed retry of an approved step now stays pending instead of reading as approved.
• A workflow in the storefront’s queue now closes by itself when its media buy is approved in the ad server (shown as approved) or is canceled, rejected or completed (shown as cancelled), instead of staying open until someone clicks it.
• Fixed-price wholesale products no longer receive GAM auction guidance, preventing fixed rates from being represented with auction pricing metadata.
• A media buy booked in GAM, FreeWheel or AdsWizz is no longer marked completed from the flight dates alone, so a pause or cancellation made in the ad server is no longer overwritten. It is marked completed once the ad server reports the order ended, which can take up to an hour after the flight ends. Other buys still complete at the end of their flight.

​

5.1121.0 — October 15, 2026 at 12:15 PM UTC

• A VAST tag URL on a creative can now go to a seller on Google Ad Manager. Apostra sends Google Ad Manager the address of its hosted wrapper around your tag, so the tag’s macros are filled each time the ad is served. VAST XML saved inline is refused up front as destination_profile_rejected with the reason ingress:vast_xml, before anything reaches the seller. Save the tag as a URL tag instead.
• When a seller can’t accept one of the creatives you sync, the creatives it can accept are now attached to your media buy. Before, the refused creative’s assignment was still sent to the seller, which rejected the whole request, so none of the creatives in that sync were attached.
• On a storefront that reviews media buy changes, an approved update_media_buy task now stays submitted while the storefront retries sending the change to the seller, and completes when a retry succeeds. Before, the first failed attempt marked the task failed with “retry in 60 seconds”, even though the storefront kept retrying and the change could still go through. If no attempt succeeds within six hours, the task fails with INVALID_STATE and reason forward_retry_window_lapsed, and the storefront never sends that change afterwards, including when the seller later resumes intake, so submitting it again does not apply it twice. A change no retry can fix still fails its task right away, now with the per-source diagnosis and without retry advice. A cancellation that cannot be sent still shows as blocked in the seller’s approval queue.
• Campaigns with a new creative now launch on Spotify. Launch used to stop with “the seller library has not verified creative(s) … yet”, because Spotify could only accept a creative once its ad set existed, and that ad set is created at launch. Apostra now uploads the creative’s media to your Spotify ad account before launch, then creates the paused ad in the new ad set once the buy exists. Nothing to change on your side. If a launch stopped with this message, launch it again.

​

5.1120.1 — October 15, 2026 at 11:40 AM UTC

• Media Partners no longer offers the partner-managed seller account request action while its activation, billing, and retry handling are corrected. The deprecated requestAccount API field remains accepted as a compatibility no-op so existing activation clients continue to work. Existing sync_accounts callers may still select an advertiser with the deprecated advertiserId field; the API checks write access and targets that advertiser. Existing seller account setup continues unchanged.

​

5.1119.2 — October 15, 2026 at 11:04 AM UTC

• Display tags from a CM360 tag sheet are now delivered. Each display row is saved as a display tag, with the tag’s code and vendor macros (such as [timestamp] and ${GDPR}) left exactly as the sheet wrote them. It attaches to any seller product that accepts display tags at the same size, and goes out with that product’s media buy like any other display creative. Before this, these rows were saved as custom creatives that could not attach to a display tag product and were never sent to sellers. Display tags you already uploaded from a sheet are released without a re-upload. Rows that only carry an Internal Redirect pair are still saved as source only. Rows with VAST pre-fetch URLs keep becoming VAST video creatives, as before.

​

5.1119.1 — October 15, 2026 at 10:42 AM UTC

• Fixed a follow-up gap in the canonical creative format label fix: a media buy read (get(kind: "media_buy", include: ["creatives"])) could still show “format unknown” for a creative that only has a canonical format (no legacy format reference), because the lookup that merges in the canonical format used an untested filter that didn’t return results for every media buy. The lookup now uses the same, already-proven filter the campaign-level read uses, so the real format label shows up consistently.

​

5.1119.0 — October 15, 2026 at 10:21 AM UTC

• When a storefront forwards your creatives to a seller that accepts AdCP’s current creative format, a format option the seller never declared itself is now sent as the format’s kind and parameters instead of an option ID the seller doesn’t recognise. This applies to sellers whose products list only older format references, where the option IDs are generated on your side. Sellers that declare their own format options, and sellers on the older creative format, receive creatives exactly as before.
• get_status now names your live advertisers whose markets or channels are blank, as a recommended next action that points to save_advertiser. Sellers already match these advertisers in every market and channel, but seller accounts are set up ahead of time only once markets and channels are set. Until then, an account is requested when you buy. Nothing changes for advertisers that already have both set, and your account’s readiness status is unaffected.

​

5.1118.0 — October 15, 2026 at 10:07 AM UTC

• Your agent can now send a creative again to the media buys it is already on, including live and paused buys. Call save_creative with the creative’s creativeId, advertiserId, and resync: true. Campaign membership stays as it is. The result shows, for each campaign, which media buys’ sellers confirmed the creative, or the seller’s error and whether a retry can help. Use it when a creative did not reach a seller because of a problem that has since been fixed. Nothing changes unless you send resync.

​

5.1117.6 — October 15, 2026 at 9:13 AM UTC

• A creative saved before you picked a format could have a text asset you explicitly placed — for example a headline — silently disappear when it later synced to a seller, if the matched format did not use that slot. Syncing now fails with a clear error naming the missing text and the format, for example Creative text asset "headline" is not declared by the resolved format "feed_image"..., instead of silently publishing without it.
• get on a creative asset you just uploaded through the V3 upload Task no longer reports “not found” while it is still a Draft pending review. It now returns the Draft’s name, kind, and review status (needs confirmation, still processing, or needs to be discarded), matching what search already lists when you pass filter.assetState: "draft". Confirming or discarding a Draft is still done from the Creative Library.

​

5.1117.5 — October 15, 2026 at 8:52 AM UTC

• You can now request a partner-managed seller account for one advertiser from Media Partners. REST and MCP account-sync requests can also name advertiserId; Apostra checks your access before sending the request, and repeated requests reuse the same seller review.

​

5.1117.3 — October 15, 2026 at 5:34 AM UTC

• Fixed a background retry that could leave assigned creatives undelivered after a temporary delivery error on an active media buy.

​

5.1117.2 — October 15, 2026 at 4:49 AM UTC

• Fixed a display bug where a creative that has no legacy format reference — including a creative successfully synced to a platform like Meta — showed as “format unknown” on a media buy or campaign read, even though its canonical format (e.g. “Image”) was known. The format label now resolves from the creative’s canonical format when no legacy reference is present, so a synced-but-unpinned creative shows its real format instead of reading as unresolved.

​

5.1117.0 — October 15, 2026 at 3:31 AM UTC

• Fixed an unpinned image creative’s click URL being silently dropped before it reached Snap or Pinterest, and rejected outright before it reached Spotify or LinkedIn. The destination URL now reaches the ad on all four platforms whether it was authored under each platform’s own exact field name or an equivalent alias.
• A VAST creative now previews in the Creative Library. Apostra follows the tag on its own servers and plays the video file the ad resolves to, so the preview does not depend on your ad server allowing browser requests, and it does not request any impression or tracking URL in the tag. The get read for a Creative with include: ["preview"] also returns vastTag, the facts Apostra read from the tag when it was saved: the outcome, VAST version, wrapper chain, duration, media files, and whether it uses VPAID, SIMID or OMID. When those facts already show there is nothing to play, such as an empty response or an ad with no progressive MP4 or WebM file, the preview says so instead of loading.
• sync_creatives now surfaces the specific reason a creative was rejected before it ever reached a seller — for example a missing click-through URL or an unsupported asset for the format — instead of the generic “Seller rejected this creative (creative_rejected).” Buyers can now act on the real problem without filing a support ticket.

​

5.1116.1 — October 15, 2026 at 3:12 AM UTC

• Return a retryable error instead of reporting missing brand data when a temporary lookup failure blocks advertiser creation.

​

5.1116.0 — October 15, 2026 at 2:52 AM UTC

• Buyers whose creatives sync to a legacy-format seller through a storefront no longer get a seller-blaming refusal on their first launch.
• The hosted VAST wrapper we send sellers now follows what your tag returns. It uses the newest VAST version in your tag’s chain instead of the version you declared (a Campaign Manager 360 tag that returns VAST 2.0 now goes out as 2.0), and the creative’s vast_version on the seller’s copy matches. A tag that returns an ad pod now plays as a pod; before, the wrapper blocked it. The wrapper also lets the player fall back to another ad when your tag returns no ad, and reports player failures to us with the IAB error code, so a tag that fails in the player no longer fails silently. Wrappers already published keep their document until the creative changes.

​

5.1115.1 — October 15, 2026 at 2:35 AM UTC

• Keep marketplace seller catalogue reads available when registry brand-card lookups are rate limited.

​

5.1115.0 — October 15, 2026 at 1:52 AM UTC

• Connect through https://api.apostra.com/mcp to follow your account’s API rollout without changing the connection URL. Buyers receive V2 or V3 according to their existing Murph feature profile; sellers receive V3. Existing stateful sessions keep their version until a new session starts. Explicit versioned URLs keep their current behavior. When changing an existing connection URL, complete OAuth for the new URL. See MCP client setup.
• A buyer agent with at least one advertiser grant, whose credential belongs to your organization’s parent account, now gets its buyer tools on the Buyer MCP server and the V3 MCP endpoint, where it used to see only billing tools on the Buyer MCP server and the organization account on V3. On V3, get_status reports a buyer account and the tool list is the buyer catalogue. Each call runs in the account below the parent that owns the advertiser it names; an advertiser the parent account itself owns can be worked only through api_call, as before. The agent can list its granted advertisers without naming one. Any other call that names none is refused, with agent_advertiser_required when the tool can name one; for example, creating an advertiser or changing billing details through api_call is refused, and the Plan & Billing tools that change billing still need an administrator. An agent with no active grant keeps the parent account’s organization tools exactly as before, and a call from an agent with no grant that needs an advertiser is now refused with agent_no_advertiser_access rather than agent_advertiser_required. The agent still cannot switch accounts, and REST requests on the parent account are refused as before.
• Fixed an unpinned image creative’s click URL being silently dropped before it reached Meta, which caused the creative to be rejected at sync time with a generic “Seller rejected this creative” error and blocked the media buy from launching. The destination URL now reaches the ad whether it was authored under Meta’s exact field name or an equivalent alias.

​

5.1114.0 — October 15, 2026 at 1:21 AM UTC

• Saving a VAST tag now checks what the tag really returns. Apostra requests the tag the way a player would, follows its wrappers and redirects, and records the version, the wrapper chain, whether it returned an ad, and the features it uses (VPAID, SIMID, OMID, mezzanine, companions). A tag with no declared vast_version now takes the version it returns, however you attach it (url_asset, linked_assets, or a slot), so it no longer fails creative sync with missing:vastVersion. The creative’s warnings now tell you when a tag returns no ad, returns an error, or returns a different VAST version from the one you declared. The save always goes through, and the version you declared is kept.

​

5.1113.0 — October 15, 2026 at 12:52 AM UTC

• Buyer agents with advertiser access are no longer refused solely because their registration uses the current account identity. Existing permissions and organisation boundaries still apply. No setup change is needed; this fix does not enable hosted event automations.
• Keep private notes on your advertisers with save_advertiser.privateNotes, then read them with get(kind: "advertiser") in the owning Buyer Account. Sellers cannot see these notes. They do not change seller prices or terms. This adds no plan requirement or charge. See Private advertiser notes.

​

5.1111.0 — October 14, 2026 at 11:03 PM UTC

• Signals you register through the v2 storefront signals API (/api/v2/storefront/signals) now use AdCP’s signal fields. countries, a list of ISO 3166-1 alpha-2 codes such as US or FR, replaces regions (NORAM, EMEA and so on): leave it out for no restriction, and you can now change it after registration with Update signal. An access record’s price is now AdCP’s signal pricing option, with model set to cpm, percent_of_media, flat_fee, per_unit or custom, instead of the media-buy pricing option with pricing_model. If you register signals through the API, send countries and the new price shape: a request with the old price shape or with regions is refused. Existing signals have no countries, which means no restriction; they had no stored prices to convert.

​

5.1110.0 — October 14, 2026 at 10:48 PM UTC

• A buyer agent with access to more than one advertiser can now work all of them from one V3 MCP connection. Each call names its advertiser with advertiserId, filter.advertiserId on search, or filters.advertiserId on get_delivery, or addresses an existing campaign or media buy by id, in which case it runs for the advertiser that owns it. A campaign or media-buy search, a get, a save_media_buy or a save_creative that does neither is refused with agent_advertiser_required (VALIDATION_ERROR), which lists up to 10 of the agent’s granted advertisers by id and name. Agents with access to one advertiser keep working as before, and the agent’s advertiser grants are still checked on every call.
• Improve long-history transport diagnostics by loading details for the requested page while keeping exact totals and existing access rules intact.
• Source health now names the setup steps still missing when a source shows “Setup incomplete”. Under that badge on the Buyer requests row, each missing step is listed, such as verifying your operator domain or adding a source’s credentials, with a link that opens Seller Setup where you finish it. The same steps are available to API callers as sourceHealth.identity.routing.setupSteps. An agent operator sees only the steps for the source itself, not your seller account’s own setup.
• Open operations in your source diagnostics now has a button that opens what an operation is waiting for. A media buy waiting for the buyer’s creatives opens that media buy. The Source Health API carries the same action as waitingOn.nextAction, the tool and arguments that open it, and leaves it null where waitingOn.target is hidden from the caller.
• On storefronts whose sales agent manages buyer accounts, sync_accounts now returns action: created for an account you don’t yet hold on that storefront, including in a dry run. Before, it could return unchanged when the seller’s agent already had its own account for that brand, even though you had no account on the storefront and list_accounts returned nothing. A dry run still records nothing: send the request without dry_run to set up the account.
• V3 property-list creation now requires an explicit appliesToAllCampaigns choice. Agents must ask whether an allowlist or blocklist should apply to all campaigns or be saved for campaign use. Calls that omit the choice are rejected before saving, instead of silently applying the list advertiser-wide.
• V3 clients must send true for all-campaign scope or false to save without applying. Existing lists and the supported V2 create contract are unchanged.
• Restore an archived property list with save_property_list and isArchived: false. An all-campaigns list replaces the current list in its matching advertiser slots and names displaced lists in propertyList.replacedPropertyListIds. A campaign-only list stays unapplied until you set it on a campaign again. Restore clears this advertiser’s stale campaign assignments; references outside this advertiser cause a refusal with campaign IDs before anything changes. A saved restore remains successful if the active-buy push fails, with results or an explicit error in propertyList.cascadeSummary; seller updates remain best effort. Existing calls need no changes.
• Seller reads scoped to an advertiser now show that advertiser’s activation state and required action. A ready advertiser no longer appears blocked by another advertiser’s incomplete setup. Scoped results contain only the requested advertiser’s activation row. Omit advertiser scope when you need the account-wide summary and all advertiser rows. The seller text also counts explicit preferences separately from activation records. Your advertiser’s own setup and grant requirements still apply; this correction requires no new account setup or grant migration.

​

5.1109.0 — October 14, 2026 at 9:06 PM UTC

• Source diagnostics no longer blame your sales agent for rejecting a request that broke the capabilities it declared. When we send a request that contradicts your get_adcp_capabilities declaration, for example buying_mode: wholesale to an agent that declares only brief and refine, or no account to an agent that requires one, the diagnosis now names Apostra as the owner and states what we sent against what you declared. Calls Apostra makes to refresh its copy of your catalog now carry origin.workflow: "catalog_warm" in recent activity and show as a catalog refresh in the diagnostics view; origin.kind is unchanged.
• When you ask an agent to create a catalog, the tool guidance now tells it to collect a feed URL or product items before saving. Existing API requests keep the same validation rules; no client changes are required.
• Settings → Danger zone is rebuilt on the Apostra design system, matching the rest of the settings surface. Each lifecycle action is a single row that names what it does and who can do it.
• An archived storefront now shows one status row explaining what happened and how to get it back, instead of two disabled buttons for actions that no longer exist — archiving cannot be undone from the product. A buyer who is not an organization administrator sees an “Organization admins only” marker on the archive row, so the row reads as information rather than a control that failed to appear. The seller’s archive row says “Archive this storefront”, matching the button, the description, and the confirmation beside it.
• Campaign reads now show saved targeting in the text response, so connected assistants can verify country, language, and other campaign constraints after an update. Use get with kind: "campaign" and the saved campaign ID before requesting proposals. Campaign search returns summaries. No configuration change is required.
• Changing a media buy that needs the seller’s approval, such as raising its budget or adding creatives, no longer fails with an internal error. The change is queued for the seller to approve, as before.
• A buyer agent connected to a Slack channel no longer goes silent when our service restarts while the agent is working on a message. The service now waits for the agent to finish before it restarts, up to a time limit. If the agent is still working when that limit is reached, the thread gets a reply saying the service restarted before the agent answered. The agent may still have acted on the message, so the reply asks you to check whether it took effect before you send it again.
• Each finding in your source’s health diagnosis now has a View calls link. It opens the source’s calls for the operation the finding is about, over the window you have selected, so you can see the requests and responses behind the finding without searching for them. The link shows only the calls you could already read.
• The source health response gains diagnosis.findings[].evidence: the operation and time window behind each finding, and where the caller opens them. It is null for an agent operator, whose view of request and response bodies still depends on your debug invitation.
• Open operations in your source diagnostics now name what a buy waiting on the buyer is waiting for. A media buy a source accepted that still needs the buyer’s creatives shows “Media buy creatives” with the media buy’s id under “Waiting for”, where it used to show “None”.
• When you edit a product in Inventory Components, Find inventory to add now searches your ad server’s ad units and placements by name or ID, so you can add inventory you haven’t loaded on the Components tab first. A match that’s already on the product says so instead of disappearing from the results.
• When a seller with its own sales agent approves, refuses or suspends your account, creative sync and media buys now follow that decision from the seller’s next account list. Previously they kept using whatever the seller said when the account was first set up.
• Nothing changes for existing reporting calls; this is opt-in. Add outcomeType (for example signup) to the reporting metrics call with view=timeseries, and each row, one per package per day, shows your count of that outcome and its cost per outcome. The call needs a campaign or media buy, plus a start and end date no more than 90 days apart. It does not work with the summary view, CSV download, or demo data. Counts come from the measurement records you upload that name the media buy and package. A record counts on a day only if its window is exactly that day, so a weekly total uploaded beside daily counts is never added twice, and records from different sources or geos on the same package and day are added together. Each row gains outcomeCount, costPerOutcome (spend divided by count), and outcomeSource (measurement_records). A day with no matching record returns outcomeCount as null (not measured), never 0, and costPerOutcome is null when the count is null or 0. Listing measurement records can now also filter by media buy and package. Seller-reported conversions and cpa are unchanged.
• Source health now tells an operation your agent does not support apart from one that has not been seen yet. A row in Health by operation reads Not supported by seller, owned by the seller, when the agent’s own capabilities declare no media buy protocol or no creative library, or when its live tool list leaves the operation out. The source health API adds a supported field to each row (false, true or null); status stays null on an unsupported row.

​

5.1108.0 — October 14, 2026 at 7:39 PM UTC

• A buyer agent with access to more than one advertiser can now work all of them from one Buyer MCP connection. Each call that acts on one advertiser names it: in api_call with the advertiserId path or query parameter, or advertiserId or account.account_id in the body; in get_products with ext.interchange.advertiser_id; and with the new optional advertiserId argument on update_media_buy, and on create_media_buys when it adds to an existing campaign. When such an agent names no advertiser, the call is refused with the new agent_advertiser_required error (VALIDATION_ERROR), which lists up to 10 of the agent’s granted advertisers by id and name. Agents with access to one advertiser keep working as before, and the agent’s advertiser grants are still checked on every call.
• The payment-terms certification check now flags, rather than blocks, an existing account your agent kept on other terms than the ones we requested; only a new account returned on other terms is a blocker. The account checks also read every page of your latest complete list_accounts listing, so a paged roster is no longer judged from its last page alone.
• Source diagnostics now name the AdCP error your sales agent returned. When get_products fails with a typed error such as AUTH_MISSING or ACCOUNT_REQUIRED, the diagnosis says which code it was and what that kind of code asks for, instead of “an error diagnostics could not classify”. Your agent’s own message still appears unchanged in the technical details. Codes outside the AdCP standard set still read as unclassified.
• An HTML5 or display-tag creative built for one target format, such as display_300x250_html, now syncs and launches with that size when its uploaded files carry none, so it can match one of a seller’s per-size formats. When a creative still fits several of a product’s valid formats, the error now names the product and its sizes or durations and asks for the creative’s size or duration, instead of telling the buyer that the seller must correct its declaration. A seller is named only when two of its formats are the same format.
• Storefront media-buy delivery now reports the dates you asked for as its reporting period when the seller’s source has no delivery to report yet. Before, a buy with no or pending delivery reported today’s date as both the start and end of the period, which looked like the seller had ignored your requested dates. When you request no dates, the period is the buy’s booked flight. When the seller reports its own period, that period is returned unchanged.
• describe_operation on the buyer MCP now returns effect: "read" or effect: "write" for each operation, so your agent can tell whether a call changes anything without guessing from the HTTP method. Some reads, such as get_products and preview_creative, are POSTs; they now report read. The create_property_list and update_property_list descriptions now tell agents to send identifiers inline in one call (up to 100,000) instead of pointing them at the file-upload endpoint, which an MCP agent cannot call.
• Sandbox media buys now reach Google Ad Manager sellers that run on Apostra’s managed sales agent, so an own-supply sandbox test can launch. Before, the launch was refused with source_account_not_bound until the seller had mapped that sandbox account to an advertiser. Now the buy books on the seller’s sandbox advertiser, which is where every sandbox account belongs. Live accounts still need the seller’s advertiser mapping. The sandbox account must still bill through the agent.
• VAST creatives now sync to sellers that offer the same video size at several durations. The creative is matched to the seller format for its own measured length, so a 30-second spot goes to the 30-second format instead of being refused.
• A buy that a source has accepted but is holding for creatives no longer shows as waiting on the buyer when the buyer has already attached creatives. In your source’s open operations it now waits on Apostra until the creatives have reached the source, then on the source’s own review (seller). It waits on the buyer only while no creatives are attached. A buy whose flight has ended and whose buyer’s buy is completed, archived or canceled is no longer listed as open.
• Creative syncs and media buys no longer stop with “source_account_not_bound” just because a seller also holds accounts for other advertisers. When your storefront account isn’t yet linked to an account on that seller, it is now set up with the seller the first time you sync creatives or submit a buy, the same as on a seller with a single account. There is nothing to change on your side: retry the creative sync or resubmit the buy. A seller that holds your account for approval still blocks the sync until it approves the account.
• Source health messages now read naturally when your ad server has no product name, such as a Demo Storefront’s synthetic inventory. For example, “No sellable products have been built or imported from your ad server inventory yet” replaces “from your Your ad server inventory”.
• An Agent operator reading your source’s health no longer sees the product ids and formats named in a creative-formats finding unless you have invited them to debug that source. While your debug grant is active they still see them.
• On a storefront that reviews media buys and books them through an ad platform such as Meta or TikTok, an approved buy’s create_media_buy task now stays submitted while the storefront retries sending it, and completes when a retry succeeds. Before, the first failed attempt marked the task failed with “retry in 60 seconds”, even though the storefront kept retrying and the buy could still go through. While it retries, get_media_buys reports the buy as retrying, with the cause when it is one you can fix, such as a missing event-source destination. If no attempt succeeds within six hours, the task fails with INVALID_STATE and reason forward_retry_window_lapsed.
• When you attach a file in Murph and ask it to add what is in it, for example a tag sheet of VAST URLs to a campaign, Murph now stages the exact change straight away and shows an Approve control, instead of asking “want me to go ahead?” in text first. When you click Approve, the staged change itself runs, exactly as shown on the card, rather than Murph rebuilding it from memory. Before, a text question could lose the values from your file by the time you answered, and Murph would ask you to paste them again. Nothing changes if you did not attach a file. Replying in text instead of clicking Approve is unchanged for now. Nothing to do on your side.
• When you approve a change Murph has staged by replying in your own words instead of clicking Approve, in any language, Murph now runs exactly the change that was staged, as shown on the card, instead of rebuilding it from memory. If Murph tries to repeat a staged change while it is still waiting for you, nothing runs; it tells you the change is waiting for your approval. A reply that is not clearly an approval, such as a greeting, never runs it. Nothing to do on your side.
• The Source health view is easier to read. An incomplete setup now points you to Seller Setup for the steps still to finish, and a finding about creative formats your agent declares lists the affected products and formats. Single calls read “1 call”, “Who acts” appears only when someone needs to act, and Open operations puts “Since” next to “Waiting on”.
• Opening Buyers from the rail now shows the Your buyers page on its own, without the “What do you want to work on?” question above it.
• The left navigation in the Apostra app now has three modes, Storefront, Managed campaigns, and Settings, in place of the five workspace tabs (Inventory, Advertisers, Buyers, Agents, Sessions). It is on for every storefront and needs no setup: your sources, buyers, advertisers, sessions, and settings are all still there, regrouped by what you are doing.
• Storefront is where you run your storefront, in four groups with one open at a time:
• Inventory sources lists your sources and has the action to add one.
• Your storefront holds branding and distribution, business rules, buyers, and Demo Storefront.
• Merchandise holds your library or product marketing, inventory components, signals, playbook, and demand.
• Operate holds sessions, approvals, media buys, seller analytics, and activity.
• Setup progress stays at the top of Storefront. Select the count of required steps beside your status chip to open the full setup checklist.
• Managed campaigns is for the advertisers you run campaigns for. If your storefront is on the Listing product, it is hidden and you see only Storefront and Settings.
• Settings is now a mode of its own, so the Settings row at the bottom of the navigation is gone.
• Agents are no longer in the seller navigation. To reach them, switch to your organization’s Developer account, which opens on the Agents page. Only the app’s navigation changes: the API, MCP tools, permissions, and your data stay the same.
• Each inventory source in your left rail now shows what kind of source it is, such as an ad-server connection, a modular source or an external sales agent, so a source named like a news feed or a campaign still reads as an inventory source. Nothing to change on your side.

​

5.1107.0 — October 14, 2026 at 5:22 PM UTC

• A buyer agent connected to a Slack channel now replies in the thread when it cannot reach the agent, instead of staying silent. If the connection to the agent fails, the reply says it lost contact before the agent answered. If the agent takes too long, the reply says it stopped waiting. Because the agent may already have acted on the message in either case, the reply asks you to check whether it took effect before you send it again.
• log_event now rejects a uids value or click_id that looks like a plaintext email or phone number, and a call that repeats an event_type + event_id pair, with a 400 VALIDATION_ERROR that names the event and field; nothing from a rejected call is forwarded. The log_event docs now say that deduplication across calls and keeping test_event_code traffic out of production data are done by the tracking service, and that a malformed hashed_email or hashed_phone fails the whole request rather than being dropped.
• get_measurement_freshness now says whether it checked anything. A new status field returns no_sources when the advertiser has no measurement sources, not_evaluated when no source has a cadence the check supports, and evaluated otherwise, so totalMissing: 0 no longer reads as “up to date” when nothing was checked. sourcesEvaluated and sourcesSkipped show which sources were checked and which were not, and why. Daily sources are now checked one day at a time, so a missed day shows up as a gap. baselineCoverage is null when the advertiser has no sources.

​

5.1106.0 — October 14, 2026 at 4:26 PM UTC

• Storefront connections now keep their sales-agent principal when they reconnect, so linked buyer accounts, creative syncs and buys keep working. If a sales agent completes setup without returning a principal, setup now stops with a message to contact support instead of failing later.
• Buyer agents can add and remove existing assets in campaign creative collections through V3. The deprecated saved-creative member ID aliases continue to work.

​

5.1105.0 — October 14, 2026 at 3:52 PM UTC

• Creative sync and media buys on a seller’s own sales agent now use your account at that seller only once the seller has accepted it. If the seller is still reviewing the account, we ask it again for the current status instead of relying on its earlier answer. The creatives or buy go through as soon as the seller reports the account active.
• The V3 buyer tools and guides now call the commercial counterparty a Seller everywhere.

​

5.1104.0 — October 14, 2026 at 2:41 PM UTC

• Media-buy reads now show when a guaranteed buy’s requested cancellation awaits operator approval, while the buy keeps delivering; the marker clears after the operator approves or rejects it.
• Allow buyers to change an auction bid on open packages of a live media buy through save_media_buy, with the selected pricing option’s bid rules enforced before the seller confirms the change.
• Media-buy writes now warn when their optimization goals diverge from the campaign’s ranked goals. Your write still succeeds today. Read the response’s warnings entry, then align the media buy’s optimizationGoals with the campaign before divergent goals become a rejected request in a later release. See the campaign guide’s Media-buy goal alignment section for the rule.

​

5.1103.0 — October 14, 2026 at 1:57 PM UTC

• Buyer agents can now filter a connected account’s V3 inventory read by audience or event source.

​

5.1102.1 — October 14, 2026 at 1:40 PM UTC

• The payment-terms certification check now only counts accounts Apostra requested with agent billing and payment terms; accounts opened without terms are on the seller’s default and aren’t counted.

​

5.1102.0 — October 14, 2026 at 1:25 PM UTC

• Settings now has a Chat preferences section, renamed from Murph preferences, holding the language Murph replies in, product announcements, and — for administrators — the account’s conversation-sharing default. Each preference is a single row that names the setting and carries its control, instead of a heading above a row that repeated it.
• Notification settings is rebuilt on the same frame. The channel columns line up with the switches beneath them, the duplicated rules between categories are gone, and each notification type reads at full contrast rather than as greyed supporting text.
• Package-level delivery and reporting now appear for older Storefront buys whose routes predate package routing; buy-level totals were already correct.
• Correct the V3 lifecycle limitations for media-buy archive state.
• Renaming a Meta media buy now renames the campaign in Meta. The new name is confirmed by reading the campaign back from Meta. If Meta refuses the rename, or we can’t confirm it, the update fails, rather than reporting success while Meta still shows the old name. A blank name, or one longer than 255 characters, is refused before anything is sent to Meta. Rename and resume a paused buy in separate requests. Nothing else to change on your side.
• Pausing a campaign that is not active, including a draft or completed campaign, is now refused with a clear error instead of silently marking it paused.
• Clearer V3 lifecycle errors: archiving a live media buy now tells you to cancel it with isCanceled: true first, a completed buy says no action is needed, and canceling a draft points you to archive. The V3 guides now describe live-buy pause, cancel, and cancellationPending.

​

5.1101.0 — October 14, 2026 at 12:37 PM UTC

• Campaign cancel’s documentation now says plainly that it cancels every live media buy in the campaign; to stop one buy, cancel or pause that buy instead.
• Background creative reconciliation now delivers account-pinned assignments when the recorded account access is still active.
• Meta campaigns launched with creatives now get one ad per creative in each ad set, carrying the campaign’s tracking parameters. Before, each creative got a second ad, and the first one kept a click URL without the campaign’s tracking values.

​

5.1100.0 — October 14, 2026 at 11:44 AM UTC

• A VAST or DAAST tag sent to a seller through our hosted wrapper now reaches your ad server with its macros filled. Before, the seller’s ad server saw only our wrapper URL, so Campaign Manager 360’s ord=[timestamp] cache-buster and its ${GDPR} and ${GDPR_CONSENT_<id>} consent tokens arrived literal. The wrapper now gets a fresh cache-buster on every request and passes on the consent values the seller supplies; with no consent flag it sends the flag and consent empty rather than as literal tokens. The creative preview shows the same filled URL.
• Apostra now passes a tag or link you paste into chat exactly as you wrote it. A VAST URL with macros such as ${GDPR}, or a display tag, is no longer retyped, repaired or refused as “cut off” before it reaches the creative tools.
• Google Ad Manager products no longer advertise tiny sizes like 2x2, 3x3 or 300x2 as display creative sizes. GAM uses those sizes to mark out-of-page and pixel slots, and no buyer creative is built to them. Run-of-site products now list only sizes buyers can build to.
• A Google Ad Manager product whose ad units are set not to include their child ad units now books exactly those ad units. Before, it also delivered on every ad unit below them. A product that sets this differently on different ad units is refused with a clear error, because a GAM line item targets all its ad units the same way.
• Google Ad Manager creatives no longer carry a consent macro that Google could never fill. The consent parameter of a translated tracker URL is now empty when no consent vendor is known.
• Macros in a third-party VAST tag URL sent to Google Ad Manager, such as {CACHEBUSTER} and {GDPR}, are now translated into Ad Manager’s syntax, so Ad Manager fills them when it requests the tag instead of passing them on as literal text.

​

5.1099.0 — October 14, 2026 at 11:05 AM UTC

• Links to the Apostra app now show the Apostra name, description and icon in previews instead of Scope3 branding. Nothing changes inside the app.
• On a storefront that reviews media buys, an approved buy’s create_media_buy task now stays submitted while the storefront retries sending it to the seller, and completes when a retry succeeds. Before, the first failed attempt marked the task failed with “retry in 60 seconds”, even though the storefront kept retrying and the buy could still go through. If no attempt succeeds within six hours, the task fails with INVALID_STATE and reason forward_retry_window_lapsed, and the storefront no longer re-sends that buy when the seller later resumes intake. A failure no retry can fix still fails the task right away, now with the per-source diagnosis and without retry advice.
• Storefronts backed by a managed sales agent now advertise the targeting their ad server actually applies. get_adcp_capabilities publishes the geo targeting the sales agent itself reports (countries, regions, metros and postal areas), and a media buy that asks for a targeting type the agent does not support is refused up front instead of failing later.
• Meta video creatives without an explicit thumbnail now sync successfully. Meta’s API accepts video ads without a thumbnail and auto-generates a poster frame, so the adapter no longer rejects them before upload.
• Creatives sent to a seller whose campaigns are trafficked by the seller’s own team now reach that seller’s trafficking queue. Before, sending a creative to one of these sellers could fail with a source sync error, because the request carried the buyer’s notification settings, which the seller’s queue refuses to store. Those settings are now left out of the seller’s task.
• Murph no longer tells you a change was made when nothing made it. If a draft reply says it created or updated something and no action in that turn did, Murph now gets one more chance to do it or to say it has not. If the reply still claims a change that did not happen, a short note under it says so.
• Apostra no longer cuts long messages short. A pasted ad tag, a multi-row tag list or a long brief used to lose everything after the first 4,000 characters, and Apostra answered as though it had read the whole message. Messages up to 60,000 characters now reach Apostra in full, in chat, in Slack and through the API. A message over that limit is refused with its length and the limit, and nothing from it is sent or acted on, so you can split it and try again. Nothing to change on your side.
• When we can’t refresh the OAuth token for your connected sales agent, we no longer keep sending the expired token. Your source now reports why the refresh failed, or that it must be reconnected when the token has expired and can’t be renewed, instead of showing the agent’s rejection of a dead credential. A token that is still valid keeps working while a refresh is retried.
• Third-party tracker URLs from Campaign Manager 360 (ad.doubleclick.net/ddm/...) are no longer rejected for their [timestamp], ${GDPR}, ${GDPR_CONSENT_<id>}, ${GPP_STRING_<id>} and ${GPP_SID} placeholders. They map to the matching AdCP macros, and any placeholder Google does not document is still reported as unresolved.
• Video rows in a CM360 tag sheet now become VAST video creatives. A row in the VAST 2.0, 3.0 or 4.0 Pre-fetch Tag columns is saved as one creative named after its placement, with the VAST URL stored exactly as the sheet wrote it (macros such as [timestamp] and ${GDPR} untouched) and the version the column declares. If a row carries several VAST versions, the newest is used and every version is kept in the creative’s tag-sheet details. Nothing to change on your side: upload the sheet as before. Rows with only an Internal Redirect tag are still saved as source only.

​

5.1098.0 — October 14, 2026 at 10:09 AM UTC

• Buyer delivery reports now include days that have media-buy totals but no package breakdown. Package detail remains available on the days where sellers provide it, with nothing to change on your side.
• Buyer agents can see what targeting each product allows before they build a package. A buyer’s wholesale_product search now returns supportedTargeting, the targeting dimensions each product allows, and overlaySupport, the full declaration with its systems and limits, and reading a seller with get returns targeting, the targeting that seller declares for products with no declaration of their own, with its supportedTargeting too. Both use AdCP’s own shape, and the text of each read lists every declared dimension with its systems, such as Nielsen DMA, and its limits. A product or seller declaration too large to return inline is withheld rather than cut short; its supportedTargeting is still returned. Products from a seller’s own inventory feed now keep the overlay_support declaration the feed provides when the catalog refreshes.

​

5.1096.4 — October 14, 2026 at 5:29 AM UTC

• Fixed a bug where Meta ads had a literal {CACHEBUSTER} string in the click URL instead of a unique random value per impression. Meta’s ad server only expands its own {{random}} macro syntax, so cache-busting was non-functional for all Meta ads. This could cause click undercounting and stale cached page loads on click.

​

5.1096.2 — October 14, 2026 at 4:45 AM UTC

• Run-of-site Google Ad Manager products, which target a site’s root ad unit and everything under it, can be booked again. Their display formats now list the sizes of the ad units they serve on, so buyers know which creative sizes to send.

​

5.1096.1 — October 14, 2026 at 4:31 AM UTC

• Reading a media buy’s live status now explains that previousAdcpStatus/previousInternalStatus reflect that single read’s own status check rather than a record of what changed over time, so a status recheck right after an update is no longer misread as evidence that something else happened to the buy in between.
• If your sales agent’s creative review callback lists the same creative more than once with the same decision, that decision now takes effect instead of the callback being refused on every delivery. A callback that lists one creative with different decisions, or with two different ad-server creative IDs, is still refused and changes nothing until your agent sends one consistent result. Nothing to change on your side, but send one result per creative where you can, as the protocol expects.

​

5.1096.0 — October 14, 2026 at 4:06 AM UTC

• The payment-terms certification check now reports the number of distinct accounts affected rather than repeated observations.
• A campaign launch that fails because the seller rejected a creative now says so and tells you to replace it, instead of telling you to retry or wait for a sync that was never going to succeed.
• When you accept an account invitation in Interchange, you now open the invited account even if you belong to other accounts. Staff members enter as account members when they accept a direct invitation. Nothing to change on your side.
• Show company SharePoint sites alongside OneDrive when selecting a Microsoft 365 Library source, and explain when administrator consent is needed.
• Buyer administrators can now review and accept an active private plan offer in Plan & billing or the IU plan picker. No action is needed unless you have an offer to review.
• Inventory Components and your storefront agent now offer exactly the creative formats your ad-server source says it supports, and a format the source can’t serve is refused by the source with an error on that format. The storefront no longer applies its own list of unsupported formats on top.

​

5.1095.0 — October 14, 2026 at 3:05 AM UTC

• Every member of a buyer company, not only Premium and Admin members, can now browse products under the company’s seller account, as can the company’s service tokens, its registered buyer agents with access to the advertiser, and Scope3 support switched in. Buying still needs a Premium or Admin member or a token that is not read-only.
• If your seller integration validates responses from save_work_item or save_media_kit strictly, accept the new required outcome field before deploying this release. save_work_item reports created or unchanged, and save_media_kit reports updated. Integrations that do not update will reject otherwise successful save responses; lenient parsers continue to receive the same structured receipts. content[0] for both tools is now the canonical JSON serialization of the structured result. Read structuredContent or later text blocks for the previous human-readable receipt message. Sellers are affected; buyers do not use these tools and need not act.
• Our seller integrations team will monitor real-account save responses for seven days after deployment. The check passes when no strict-response validation failures are attributed to outcome. If one occurs, contact the seller integration owner and revert this contract change.
• Voice spots generated with ElevenLabs are now 192 kbps MP3 instead of 128 kbps, so they meet Spotify’s audio requirement (192–320 kbps) and can run on Spotify. Nothing to change on your side; regenerate a voice spot made before this change if you want to use it on Spotify.
• VAST tags from ad servers that redirect, or that carry macros such as [timestamp] and ${GDPR}, are now checked the way a player would read them. We fill the macros with safe test values and follow up to five redirects, so these tags are measured and no longer held back as unverified. The URL you saved is never changed.
• Pricing for wholesale and pass-through products now uses only your own account’s prices and the seller’s public prices. If a selection can no longer be priced, run discovery again.
• If your sales agent builds products for each brief, an old catalog check no longer marks it as “stopped responding”. We don’t refresh a catalog from those agents, so an earlier catalog failure now clears automatically within about 15 minutes, and your inventory source’s health reflects the checks that still apply. Nothing to change on your side.
• If your agent publishes a wholesale catalog and answers our request for the public catalog (sent with no buyer account) with cache_scope: "account", the diagnosis now says exactly that, instead of telling you the agent stopped responding. AdCP requires cache_scope: "public" when a get_products request carries no account. The troubleshooting guide explains the fix, and the diagnosis clears on the next successful catalog refresh.

​

5.1094.0 — October 14, 2026 at 2:15 AM UTC

• Your sales agent now carries an AdCP 4.0 readiness verdict. Read your Agent with get (kind: "agent") and adcpReadiness tells you whether you need to upgrade to AdCP 3.2 now, which 4.0 requirements you are missing (Reliable Reporting, RFC 9421 request and webhook signing, brand.json identity, the compact lifecycle), and what to change for each. It is a warning only: it does not affect certification or buys. See Getting ready for AdCP 4.0.
• If your seller integration validates responses from save_seller, save_inventory_source, save_coverage, save_material, save_wholesale_product, save_playbook, save_business_rules, save_advertiser_instructions, save_signal, or save_rfp strictly, accept the new required outcome field before deploying this release. It identifies the returned receipt branch. Integrations that do not update will reject otherwise successful save responses; lenient parsers continue to receive the same structured receipts. The MCP text channel for these tools also changes: content[0] is now the canonical JSON serialization of the structured result, with seller- and buyer-authored strings fenced as untrusted output, and the previous human-readable receipt text moves to the content blocks after it. If your integration reads the receipt sentence from content[0], read structuredContent or the later text blocks instead. Sellers are affected; buyers do not use these response families and need not act.
• Our seller integrations team will monitor real-account save responses for seven days after deployment. The check passes when no strict-response validation failures are attributed to outcome. If one occurs, contact the seller integration owner and revert this contract change.
• Changing the flight dates on a Meta media buy after it has launched now actually updates when it runs. Previously the change could fail or report success without moving anything on Meta. Extending or shortening the end date still works at any point; moving the start date earlier or later is only possible before that package has started delivering — after that, you’ll get a clear message instead of a failed or silently ignored update.
• Ad-server tags such as Campaign Manager 360 VAST URLs now get a readable asset name taken from the tag’s path, instead of a name made of leftover macro parameters. A tag sent both as url_asset and in linked_assets is now stored as one asset rather than two, keeping the linked asset’s label and declared duration and the vast_version you declared.
• Approval requests in chat now stay open for 24 hours instead of 30 minutes.
• Library Draft review notes now stay with the chat file they describe when Murph saves several files together.
• The Plan & pricing tab in Plan & Billing now opens with the plan your organization is on and what it includes: product access, included IUs, how many of your accounts the plan’s account limit covers, and the activities it charges for. Below it, every other plan available to your organization is listed with the same details. Organization administrators choose Switch plan to move to another plan, and nothing changes until they accept it; other members see the plans and are told to ask an administrator. A custom agreement stays visible and is still changed through Scope3. An organization that has not chosen a plan sees the plan we suggest, labelled Suggested, and the plans to choose from. Nothing to change on your side.
• Creating a property list with filters.feature_requirements (for example “ASPI at least 20”) is now refused with NOT_IMPLEMENTED instead of being saved. Until now the requirement was stored and never applied, so a list that looked like it set a quality floor did nothing. This applies to both save_property_list and the v2 POST /advertisers/{advertiserId}/property-lists create. If you send feature_requirements, remove it and save the list again; lists already saved with one keep working as before, with the requirement still ignored.
• Google Ad Manager products whose display formats had no size now take the size of the ad units they sell, so a buy books the right placeholder and the buyer’s creative is accepted. Before, these products booked a 300x250 placeholder that most slots can’t serve. Buyers now see each display format’s size on get_products. A seller saving an active product whose ad units have no synced display size gets a clear error asking for a size.
• Delivery reported for a Google Ad Manager media buy now only ever includes that buy’s own order. A buy can no longer be credited with impressions or spend from another order under the same advertiser.
• Saving a wholesale product with a format buyers can’t be served now fails with a clear error on that format option, instead of saving a product that then disappears from your catalog. The creative-format list no longer offers “custom”.
• Publishers can approve a GAM order that is waiting for their approval through the tenant-management API, and those approvals now show as pending. Before, approving one was refused as “already decided” and it was missing from the pending list, so the buy could not go live.
• The signup page no longer shows a Demo Environment Notice link under the Terms of Service checkbox. The link suggested you could sign up for a demo account instead, but signup has always required accepting the Terms. Nothing changes for existing accounts, and the notice is still published for agents using the demo environment.
• V3 callers sending the deprecated country-fused postal form must send each geo_postal_areas or geo_postal_areas_exclude entry as { country, system, values }. For example, replace { "system": "us_zip", "values": ["94105"] } with { "country": "US", "system": "zip", "values": ["94105"] }. Requests that keep the old form fail validation immediately.
• This is a buyer-only change. Sellers have no changed response or read behaviour, and existing media buys remain readable. For seven days after deployment, the API team will monitor real buyer-account validation errors. The check passes when no valid native postal request is rejected. If a buyer reports a valid request being blocked, contact API support; the API team will revert the validation change and investigate.
• Creatives synced to a storefront seller now reach the seller in AdCP’s canonical format, naming the exact format option they match on the booked product. Previously some image, HTML5 and video creatives were refused before they reached the seller, with a message wrongly asking the seller to correct its format declaration.
• When a buyer’s third-party VAST tag is forwarded to your sales agent, it now carries the tag’s duration_ms: the duration the buyer declared, otherwise the one Apostra measured from the tag. A tag with neither is sent without it. Nothing changes on your side, and the tag URL and vast_version are unchanged.

​

5.1093.0 — October 14, 2026 at 12:33 AM UTC

• Fixed creatives on some Storefront media buys never being sent to the seller. Retries stopped with “Cannot reconcile creative … before its storefront package is available” even though the package existed. Creatives on those buys now reach the seller on the next automatic retry.
• Wholesale product search and get responses now say whether buyers can discover each product, and why not when they cannot: a paused storefront or a source that is not set up or eligible, a catalogue that has not loaded, a product beyond the first 200 buyers read from one source, or a pricing or currency problem. An active status remains the product’s lifecycle state and no longer implies buyer visibility. Nothing needs changing unless the response identifies a hidden product.

​

5.1091.0 — October 13, 2026 at 7:47 PM UTC

• Managed sales agents now report what the publisher’s ad server actually holds, and tell you when it changes.
• For Google Ad Manager and FreeWheel buys, get_media_buys returns the status, flight dates, budget and paused state the ad server holds, with the time it was last read. For Google Ad Manager it also returns the countries, regions and metro areas being targeted, where those can be stated exactly. Each buy says which fields came from the ad server and which are as booked.
• A media buy’s revision now advances whenever anyone changes it, including the publisher in their ad server. Request include_history to see who changed what. An update sent with an older revision is refused with a conflict, so it can’t undo a change you haven’t seen.
• Agents now advertise the AdCP account change feed. Subscribe to account.change_recorded and you’re notified when a media buy or creative changes; read list_account_changes to catch up.

​

5.1090.1 — October 13, 2026 at 6:36 PM UTC

• When you choose Developer at sign-up, the button now says “Create Developer account” instead of “Create Buyer account”. It always created a Developer account; only the label was wrong.

​

5.1089.0 — October 13, 2026 at 4:14 PM UTC

• When Apostra doesn’t send a creative sync or a media buy to your sales agent because a creative fits none of the formats your product declares, the blocked attempt is now recorded as creative_format_unresolved, with recovery structural. Before, it was recorded as client_setup_failed, which read as a connection problem on Apostra’s side. In your source’s health, this code appears on the finished operation’s attempts, which Apostra support can read: it means the product’s format declaration in your agent needs correcting, and sending the same request again cannot succeed. Nothing changes in which writes are sent.

​

5.1088.1 — October 13, 2026 at 3:32 PM UTC

• When a seller rejects a save_connection request — authorizing, selecting, refreshing accounts, mapping advertisers, or removing a connection — the error response now includes the seller’s actual classified error (code, message, field, suggestion, recovery, and details) instead of a generic STOREFRONT_ERROR with a bare message.

​

5.1088.0 — October 13, 2026 at 2:39 PM UTC

• Adding a new creative to a live media buy on Meta, Snap, Reddit, Spotify or Amazon no longer fails with “the seller has not accepted the current revision”. These platforms review creatives only after they run, so the update now proceeds once the platform confirms it created the creative; a creative the platform rejected still stops the update.
• Every Developer account now opens its Agent Page. Before this, agents moved into Developer accounts on 11 October showed an Open link that did nothing.
• A launch that fails because a sandbox advertiser is mapped to a live ad account (or a live advertiser to a sandbox one) now says so, and points to Settings → Connections to map a matching account, instead of showing only “execution failed”.
• Setting up an account with a seller no longer fails when the seller’s reply is large. Activation now accepts the same reply size as the rest of seller discovery, so a seller with a long account list is no longer stuck. A reply we cannot read is retried automatically and is no longer reported as a decision by the seller.
• Agent pages count and list the inventory sources your own organization connects to the agent again. They had shown zero after agents moved into Developer accounts.
• New advertisers now get set up with every media partner your company already chose, without any extra step. Before this, an advertiser added after your company’s media partners were selected could sit without accounts at those partners until you reselected them. Nothing to change on your side.
• Every table on Plan & billing now sits in a bordered frame, so its rows read as one object rather than as lines floating on the panel, and column headers are no longer dimmer than the values under them. On Accounts, the organization’s terms no longer print a summary line that repeated the first row of the agreements table beneath it — and disagreed with it about when the terms were accepted. An account’s type reads as plain text instead of a coloured chip (its status keeps one), period fees are formatted as money rather than a raw number, and archiving an account has moved into a per-row actions menu instead of sitting in the table as something that looked like a label.
• Accounts that were set up with a media partner before we recorded your company’s account locally are now requested again. Previously a few of these accounts showed as active but could not be used, and nothing retried them. They are re-requested automatically, and the media partner’s existing account is reused, so no duplicate account is opened.
• You can now see viewability alongside your other reporting metrics. Buyer and seller reporting add a viewability object at every level (advertiser, campaign, media buy, package, and totals), with viewable_impressions, measurable_impressions, and viewable_rate (viewable divided by measurable impressions). The CSV export adds the same three values as new columns at the end, so existing columns don’t move. The object is filled in only when a seller reports both viewable and measurable impression counts, measured under the MRC standard or with no standard declared. A seller that reports only a rate, or measures under a different standard such as GroupM, isn’t counted, so coverage varies by seller and you’ll see gaps for now. For packages, a multi-day report with a daily breakdown is split into daily rows, so its whole-period viewability isn’t repeated on those rows; a multi-day report without a daily breakdown contributes once, on its start date. When nothing in the selected range was measured, viewability is null rather than zero, so an unmeasured buy never reads as having no viewable impressions. Nothing to change on your side: the object appears in your next reporting request, with no setup required. If you sell through us, this is the viewability you already report, now visible to the buyers you work with. Where you report only a rate, or don’t report viewability at all, buyers see null rather than zero, and we never estimate the counts from a rate — so a gap reads as “not measured”, not as poor performance.

​

5.1087.0 — October 13, 2026 at 12:59 PM UTC

• A campaign launch that fails because a creative hasn’t finished syncing to the seller’s library now tells you that directly, instead of a generic “execution failed” with no explanation.
• When a creative can’t enter seller review because of a source account problem, the error now says which source and why.
• A media buy approved on a storefront that reviews buys keeps its pending status while the storefront retries sending it to the seller. A fixable delivery failure, such as an account not yet linked on the seller’s side, no longer turns the buy canceled and revokes the approval within minutes. The buy is reported canceled or rejected only if the retry fails permanently or the six-hour retry window ends.
• You can sign up with a personal email address to build agents, or use one to advertise once advertiser sign-up is open to you (it is currently invite-only; until then you can join the advertiser waitlist with a personal email).
• Sellers, media companies, and anyone offering a sales agent to other organizations: sign up with your company email address, so we can tie your inventory or agent to your business.
• If your storefront is in the lessons pilot, review the proposed lessons that saving Playbook text now creates: each one changes nothing until a seller account admin approves it, and your active Playbook stays as it was. Until 31 December 2026, older Playbook writes keep working this way; after that, pilot storefronts must use lessons. Storefronts outside the pilot are unaffected.
• When you edit a creative’s content while a seller is still reviewing the previous version, the new version now goes to that seller straight away instead of waiting for the earlier review to finish. A seller’s answer about the previous version is recorded but no longer applied, so a creative is never shown as approved for content the seller has not reviewed. Nothing to change on your side.

​

5.1086.1 — October 13, 2026 at 12:10 PM UTC

• A reference-only creative sync now names the affected reference creatives and explains how to promote them, instead of a generic library-verification failure.

​

5.1085.0 — October 13, 2026 at 11:30 AM UTC

• Certification now expects a sales agent to treat sync_accounts as idempotent on the account key (brand domain, operator and sandbox flag): a repeat call for an account it already holds returns that same account with action unchanged or updated and the same account_id, and never creates a second one. It starts in report-only mode: a duplicate creation, or a list_accounts roster that lists one key twice, shows as a flag on the agent’s behaviour baseline, and as a blocker when seen on three or more days. Neither stops new buys yet.
• Avoid duplicate Library Drafts when a seller saves the same file more than once.

​

5.1083.3 — October 13, 2026 at 10:55 AM UTC

• Inventory Components no longer offers the Custom creative format on ad-server products, and the storefront now refuses a custom format when you validate, create, or save a product, whether in Inventory Components or through your storefront agent. Saving a custom format could leave a product hidden from your product list. If a product can’t be loaded for editing, the editor now says so and offers Try again instead of opening an empty form.
• When a media partner’s agent answers your account request with an error, your advertiser now shows Waiting on media partner instead of Failed. We retry the request automatically, first within minutes and then once a day, until the media partner’s agent accepts it. Nothing is needed from you. Requests that failed this way earlier are retried too.

​

5.1083.2 — October 13, 2026 at 10:32 AM UTC

• Looking up a product’s details from a discovery session now reads only the account of the advertiser that session belongs to, plus the public catalog.

​

5.1083.1 — October 13, 2026 at 10:05 AM UTC

• Account syncs to every seller now carry your organization’s chosen payment terms. Sellers that still use the older account mapping previously received agent-billed accounts without terms, even though other sellers received them.

​

5.1083.0 — October 13, 2026 at 9:55 AM UTC

• Certification now expects sales agents to return billing and payment_terms on agent-billed accounts in sync_accounts and list_accounts responses, and to accept the requested terms or reject the account rather than returning it active on different terms. It starts in report-only mode: a missing field shows as a flag and a remapped account as a blocker on the agent’s behaviour baseline, and neither stops new buys yet.
• After Murph saves a file to your Library, you can open the Draft straight from the chat.

​

5.1082.0 — October 13, 2026 at 9:38 AM UTC

• Sellers in the lessons pilot can compare a frozen scenario with selected lessons included or excluded, without changing live buyer responses.
• Launching a campaign with a new creative on a platform seller such as Meta no longer fails with “execution failed”. The platform reviews a creative only once its ads exist, after launch, so the launch no longer waits for an approval that could not arrive first. A creative the platform has rejected still stops the launch.
• Meta campaigns launched with creatives are now created with their ads and start delivering, instead of being left paused with no ads.

​

5.1081.0 — October 13, 2026 at 8:58 AM UTC

• Staff can enable seller lessons for a selected Storefront, so sellers can save guidance for future product and pitch responses.
• Fixed HTML5 and other sized creatives that failed to sync to sellers who list one legacy format per size (for example display_300x250_html and display_728x90_html on the same product). The creative now goes out under the seller format that matches the size measured from the creative itself. A creative with no measured size, or a size the seller doesn’t offer for that creative type, is still refused before anything is sent.

​

5.1080.0 — October 13, 2026 at 8:28 AM UTC

• V3 save_library_request responses now require outcome (opened or closed), and legacy V3 open_page refusals now require errorKind. These additive fields let clients select response branches; strict response validators must allow them. The frozen V2 library_save_request alias is unchanged.
• V3 save_ask and save_notification_config now fence text-only response projections as untrusted data. Structured response objects are unchanged.

​

5.1079.0 — October 13, 2026 at 7:33 AM UTC

• V3 save_notification_config responses now require a top-level outcome: readback, readback_unavailable, or event_subscription_saved. Each condition trigger’s predicate.kind is now required (metric or campaign_pacing_behind_continuously). These additive fields let callers use typed response branches, but strict response validators must allow them.

​

5.1078.0 — October 13, 2026 at 6:40 AM UTC

• Sellers can save versioned selling settings for qualification thresholds and buyer-decline disclosure. Storefronts without settings continue their existing behaviour and default to no decline disclosure, so no seller action is required. A seller who wants buyers to receive a factual availability gap must choose gap or gap_and_invitation; the latter also adds a fixed invitation to submit a revised brief. Buyer messages never expose seller-private thresholds or inventory rules.

​

5.1077.2 — October 13, 2026 at 5:56 AM UTC

• Creatives a Storefront seller reports as still processing now stay pending instead of failing, and settle when the seller answers.

​

5.1077.1 — October 13, 2026 at 5:18 AM UTC

• Reliable Reporting uses source-local dates and reports unreadable revisions as unavailable instead of zero.

​

5.1077.0 — October 13, 2026 at 5:07 AM UTC

• In Sessions, you can now add a private note to an individual agent response in an exchange between a buyer agent and your storefront agent; the note appears only in your own timeline and the buyer never sees it. RFP responses stay read-only in Sessions, so give feedback on those in Proposal Pass, which Sessions links to; nothing to change on your side.
• Campaign execution now persists its seller-dispatch intent before contacting a seller, then drains that intent in the same request. Buyers keep synchronous validation and seller-correction responses; the outbox worker only recovers interrupted or transient delivery without sending the media buy twice.
• Corrected campaigns can also retry after an older terminal delivery record has had its request payload retained away. Each retry receives a new fenced delivery attempt, while a refused execute leaves the campaign unchanged.

​

5.1076.0 — October 13, 2026 at 4:51 AM UTC

• V3 save_ask responses now include the required top-level outcome field. Use it to distinguish filed, suppressed, updated, and filing_refused results; strict response validators must allow this new field. V2 responses are unchanged.
• Let selected sellers read published buyer compose exchanges and add private notes to their retained turns.

​

5.1075.2 — October 13, 2026 at 4:09 AM UTC

• An MP3 creative uploaded with the standard audio/mpeg file type now passes a seller’s MP3 requirement, so it is included when you launch a media buy. Before, it was left out and the launch failed with “no carriable canonical or legacy product format match”. WAV files labelled audio/x-wav, audio/wave or audio/vnd.wave are accepted the same way.
• Audio is now also checked against a seller’s minimum bitrate. Spotify requires MP3s of at least 192 kbps, so a lower-bitrate MP3 is no longer sent to Spotify; upload the original WAV, or an MP3 of 192 kbps or more, and relaunch.
• Creatives a Storefront seller is still reviewing now stay pending instead of failing, and settle when the seller answers.
• Media Partners now says why an account cannot be requested from a media partner instead of showing the advertiser as Provisioning. When the partner’s sales agent does not take account requests, the advertiser shows Action required with “Media partner does not take account requests yet”. When the partner has not finished its own storefront setup, it shows “Media partner setup is incomplete on their side”. Trusted Media Brands, which was wrongly held back because of a deactivated embedded sales agent beside its one external agent, now gets account requests like every other partner.
• Media Partners that open your advertiser’s account on Interchange itself no longer get stuck on “Waiting on media partner” when nothing is waiting on them. New accounts are now created and shown as active within seconds, and an attempt that does not finish is retried instead of being held for the Media Partner. Nothing to change on your side.
• Chef now understands negotiation stance from buyer briefs in supported languages, while preserving seller controls and pricing context.
• When a seller agent rejects a request_proposals call, the response and the seller’s error entry now include the seller’s buyer-safe reason and a recovery classification (transient, correctable, or terminal) whenever the seller’s agent supplied them, instead of just a bare error code. This makes it clearer whether retrying is worth it and what to fix.

​

5.1075.1 — October 13, 2026 at 3:13 AM UTC

• When a launch fails because a creative does not meet the seller’s file requirements, the error now says which one, for example “slot “audio” audio bitrate too low. Minimum: 192kbps, Got: 128kbps”. Before, it only said “no carriable canonical or legacy product format match”, which did not tell you what to fix.

​

5.1075.0 — October 13, 2026 at 2:55 AM UTC

• Creative sessions accept a language so audio is generated in the language you ask for.
• Murph no longer replaces correct answers with “I can’t confirm that action completed.” or “I can’t share that.” Saving creatives, reading back a media buy, and similar answers now arrive as Murph wrote them. When Murph says it sent a report to the Scope3 team but nothing was filed in that turn, it now adds a short note saying so, and you can ask it to file one.
• When a seller’s own sales agent opens a new account on payment terms other than the ones your organization requested, Apostra now treats it as a refusal: the account is not activated and waits for you to review the seller’s terms. An existing account the agent keeps on other terms stays active and usable, and now shows a warning naming both the requested and the kept terms until they match again.
• When a seller adjusts a buyer’s demand exchange, the revised proposal now includes only products from inventory sources the buyer’s account can book. Before, a revision could include a product from a source the buyer’s account was not set up for, and the buyer would then be refused when booking it. Revisions for demand that came in under an account also no longer include inventory resold from other storefronts, matching what the buyer was offered. If the buyer’s account has been suspended or removed, the exchange now reads as not adjustable with the reason account_not_active, and composing, amending, submitting or approving a revision is refused with that reason; reactivate the account, or wait for the buyer’s next request. Exchanges that were not made under an account are unchanged. Nothing to change on your side.

​

5.1074.0 — October 13, 2026 at 1:59 AM UTC

• Buyer accounts that Scope3 staff admit or create, and accounts added under an organization, now start with the standard buyer experience, including Campaigns V3. Before this fix those accounts had no buyer profile assigned, so Campaigns V3 and the other buyer features stayed off until we assigned a profile by hand. Nothing to change on your side. Accounts created earlier are unchanged by this release.
• Reading a media buy through V3 get now shows how many changes to that buy are still waiting, blocked, or failed on the way to each seller, plus recent completions, so you can see where a change is stuck. Add include: ["operations"] to get up to 20 recent changes, each with its state, since-timestamp, attempts, destination, and the next step or the reason it’s blocked. Existing calls are unchanged, the summary appears only when seller work exists, and it shows progress only, not seller identity or performance.

​

5.1073.0 — October 13, 2026 at 1:29 AM UTC

• Sellers and their agents can now invite a client to one of their advertisers, approve, suspend, reactivate, or revoke that client, and change their role, with the new save_advertiser_access tool. Read who has access, and exactly what you can do next, with get and kind: "advertiser_access". Only an organization administrator signed in directly can make the changes.
• A wholesale product request (buying_mode: "wholesale") that names an account by its account_id, where none of the seller’s wholesale inventory sources can be bought under that account and the seller does not relay wholesale requests to its sales agents, now returns an empty product list with a message saying no products are available to that account. Previously it returned a retryable SERVICE_UNAVAILABLE error saying the seller had no active wholesale sources and should connect one, even though the seller had sources.
• Creatives a seller accepts for asynchronous review are tracked again instead of failing to sync.
• SDK update and cancel calls to save_media_buy send the idempotency key again.
• The impression tracker Apostra adds to a creative now asks the seller’s ad server for the site or app each ad ran on, whether or not the creative format names those macros. Where the creative has a tracker slot and the seller’s ad server fills the macro, each impression is recorded with its site or app; otherwise the impression is still counted, with no site or app. Creatives that already exist pick up the change when their tracker is regenerated, for example when they are edited, copied or moved to another campaign.
• Before you deploy a v3 preview integration that calls generate_variants, send both scope and variantAction. Set scope to "campaign" or "advertiser". Set variantAction to "generate" to start a generation or "feedback" to refine a named parent variant with feedback. Each request shape accepts only fields allowed for it. Requests without either selector, or with fields from another request shape, return a validation error. Existing v2 callers are unchanged.
• On sellers still using the original account setup, anyone in a buyer account can now sync creatives to, and launch buys on, an account a teammate already set up, instead of being told to request a new account. Sellers on the newer per-advertiser accounts are not affected, and an account is never shared outside your organisation.
• V3 Connections Page seller selection now refers to the commercial counterparty as a Seller.

​

5.1072.0 — October 12, 2026 at 11:27 PM UTC

• Creatives a seller accepts for asynchronous review are no longer reported as rejected; they stay pending until the seller confirms the outcome.
• V3 SDK types for save_billing, save_creative_session, and save_buyer_agent now use stable, descriptive branch names. If your code imports a positional generated branch type, update that import. HTTP and MCP request contracts are unchanged, so request bodies need no changes.
• You can now change targeting on a draft media buy with save_media_buy in the V3 API and MCP. Set countries as ISO 3166-1 alpha-2 codes (US), regions as ISO 3166-2 codes (US-CA; region names are rejected), audiences, and other targeting overlays. Targeting must stay within the campaign’s. Each package is checked against its seller’s supported targeting before anything is saved, so an unsupported value comes back as an error you can correct. Clearing a value reverts that buy to the campaign’s targeting. Media buys that are no longer drafts are refused with a correctable error.

​

5.1071.1 — October 12, 2026 at 11:08 PM UTC

• Show each Sales Agent’s latest live-certification result by use case instead of retired fixed certification requirements.
• API callers keep the previous certification field for now. It is deprecated in favour of liveCertification and will be removed after a deprecation window.

​

5.1071.0 — October 12, 2026 at 9:38 PM UTC

• You can now enter OAuth client credentials for a sales-agent inventory source in a secure form in chat. Choose OAuth client credentials, then enter the token endpoint, client ID and client secret from the operator of your sales agent. You can also add a scope and audience, and choose how Apostra sends the client ID and secret to the token endpoint: in an HTTP Basic header (the default) or in the request body. Apostra requests and renews access tokens for you. The client secret is stored encrypted and is never shown in chat or returned.
• Murph opens the form after it registers a source, and you can open it for an existing source, including from the setup step in Source Diagnostics. Murph’s source registration now accepts OAuth client credentials as an authentication type.
• If you use the v2 API, you no longer have to send credentials when you create a source with authenticationType set to OAUTH_CLIENT_CREDENTIALS. The source stays PENDING until you add them.
• Saving the form replaces all stored client-credential settings. The resource value (RFC 8707) can only be set through the API, so saving from the form clears a resource you set that way. If you use resource, update the credentials through the API instead.
• Nothing changes for existing sources or other authentication types, and you don’t need to do anything. See the “OAuth client credentials” section of the Create inventory source page for the full setup.

​

5.1070.0 — October 12, 2026 at 9:25 PM UTC

• Agents on the Buyer MCP server can now look up an operation’s exact parameters before calling it. The new describe_operation tool returns an operation’s method, path, path parameters, query parameters (with their types, whether each is required, and allowed values such as view=timeseries on reporting) and body schema, plus an example call. When api_call rejects a request with a 400, the response now lists the operation’s accepted path parameters, query parameters and body fields, so the agent can correct the call in one retry. ask_about_capability answers a question that names an operation with that operation’s parameters first.

​

5.1069.1 — October 12, 2026 at 8:47 PM UTC

• Listing an advertiser’s audiences works again once the advertiser has at least one audience. Before this fix, list_audiences over REST and MCP returned “Failed to list audiences” as soon as the first audience existed. Each audience now comes back with ISO-8601 createdAt and updatedAt strings, as documented. Nothing to change on your side.

​

5.1069.0 — October 12, 2026 at 8:35 PM UTC

• Reading the measurement config for an advertiser with no saved config now says so. The response carries isDefault: true, which means you are seeing the defaults and no config has been saved. Reading never saves one. When isDefault is true, createdAt and updatedAt are the time of your read, not of a saved record. Saved configs return isDefault: false with their stored timestamps, and nothing else in the response changes. This applies to GET /api/v2/buyer/advertisers/{advertiserId}/measurement-config, its PUT response, and the get_measurement_config tool. Nothing to change on your side.

​

5.1068.0 — October 12, 2026 at 8:11 PM UTC

• Advertiser settings now close when you’re done. Saving your changes opens your advertisers and closes the settings, and Cancel closes them without saving. After you create an advertiser, the confirmation stays until you choose Done. Forms Murph opens in a chat, including advertiser settings, no longer reappear when you return to that chat after finishing or cancelling them.
• Confirm your payment terms in one click. If you have never chosen payment terms, Buyer Setup now asks you to accept the default (Net 60) or pick different terms, and records nothing until you do. When a media partner is waiting on that choice, the Media Partners page shows a “Confirm your payment terms” prompt that records Net 60 with one click and resumes the held setup. Only an organization administrator can confirm.
• Previewing a saved creative no longer fails with an internal server error. Creatives synced to a seller that supports previews now return the seller’s preview again. A creative with no successful seller sync, or whose seller connection is no longer active, returns 409 CONFLICT with reason creative_not_synced. A creative synced to more than one seller that can preview returns 409 CONFLICT with reason preview_route_ambiguous, and a creative synced to a seller whose platform has no preview returns 422 CAPABILITY_NOT_SUPPORTED. Your agent can say why no preview is available instead of retrying.
• The unread-notification count an agent sees in ask_about_capability and at MCP session start now matches what list_notifications returns. Before, these counted every notification type, so an agent could report unread notifications, such as a media-buy forward failure, that the user had not opted into and could not list.
• For operations that take query parameters, the buyer MCP api_call tool now rejects one the operation does not support, instead of ignoring it and returning unfiltered results that look filtered. For example, list_activity_changes with startTime returns a 400 VALIDATION_ERROR that names startTime, lists the accepted parameters, and suggests startDate. A top-level queryParams argument is rejected the same way, with a pointer to params. Calls that use only supported parameters behave as before, and the REST API is unchanged.
• Packages on a finished media buy now read completed instead of active. Before, when a buy completed at the end of its flight, its packages still showed active (or paused) in get_campaign (mediaBuys[].packages[].status) and in get_media_buy_packages, as if they were still buying. The same applies when a buy failed, was rejected or was archived. A package that was canceled still reads canceled, including every package on a buy you canceled. Packages on live buys are unchanged, and package budgets are not affected. If your integration checks package status against a fixed list of values, add completed to it.

​

5.1067.1 — October 12, 2026 at 7:21 PM UTC

• A media buy whose status is COMPLETED, CANCELED, FAILED, REJECTED or ARCHIVED now shows an empty validActions in get_campaign. Before, a buy that completed at the end of its flight could still list cancel or update_budget, copied from the seller’s last report while the buy was live. Live buys are unchanged.

​

5.1067.0 — October 12, 2026 at 7:12 PM UTC

• Creative sync works again for media buys booked before seller product ids were recorded on the route.
• VAST video creatives now sync to sellers that validate the standard vast_tag asset.
• Buyers the seller bills directly, and buyers identified by a complete AdCP account key, no longer see products from embedded sales agent sources they cannot buy on. These are sources whose agent books under an account billed through Apostra: a Google Ad Manager embedded agent the buyer is mapped to, or an embedded agent such as AdsWizz or SpringServe where the seller marked the buyer’s account as not required. Previously product discovery offered these products and the media buy was then refused. Buyers billed through Apostra on a relationship account see and buy them as before.
• Buys and creative syncs from a linked storefront account now reach sellers that run their own sales agent, even when the account was only approved on the storefront. Before this fix, once a buyer ran sync_accounts on a storefront that builds its own products (for example Opt Out), the account existed only on the storefront. Every buy was then refused with “The Seller is not linked to every inventory source required by this media buy.” before anything reached the seller. Now, when a linked account has no mapping on a seller’s sales agent that issues its own account IDs, the buy or creative sync asks that seller for the account with sync_accounts and continues with the account it returns, once the seller reports it active. A seller that declines or holds the account answers MANAGED_ACCOUNT_LINKAGE_REQUIRED. This covers agent-billed accounts. When a mapping is still missing, the error now says your account is not mapped to every inventory source, and that the seller maps it in Buyer Account Mapping.
• An account on a seller whose own sales agent decides accounts now shows the payment terms that agent reports, including accounts opened before Apostra recorded them. Apostra reads the terms from the agent’s account list each time it re-reads that list, so they stay current if the agent changes them.

​

5.1066.1 — October 12, 2026 at 6:31 PM UTC

• Murph no longer stops with “Required grounding source is unavailable” or a “could not load the current customer-request status” error on questions that don’t need that source; it answers with the sources it has.
• Plan & billing now reads as one page rather than a run of unlabelled sections. Each topic — your plan, the terms behind it, media charges — sits in its own panel with its status beside the title and its action at the trailing edge. Plan & pricing no longer repeats the same fact in two places: the term’s start and end are one row, a rate card’s name and kind sit together, and the plan’s figures are labelled the same way as the plans you could switch to. Dates read as dates, labels no longer wrap away from their values, and a tab only tells you about a next action when something is actually owed.
• Opening a seller account now needs an operating unit on your buyer account. A buyer account whose operator identity is whole-operator, or has no confirmed scope, is refused with ACCOUNT_SETUP_REQUIRED and details.reason: "operator_unit_required" and nothing is created. Set a unit with save_buyer_operator and operatorScope: "specific_unit", or request support through save_ask if an advertiser has locked the identity. Existing seller accounts are unchanged.
• A buyer agent connected to a Slack channel now answers each Slack message once. Before, if Slack delivered the same message twice, the agent could run the request twice and repeat any change it made, such as creating a campaign. If the agent cannot safely record that it received a message, it now replies in the thread asking you to send the message again, rather than running it.
• New Slack support channels now use the ext-apostra-... naming pattern. Support can also rename existing customer channels without recreating them.

​

5.1066.0 — October 12, 2026 at 5:56 PM UTC

• When your buyer agent answers in a Slack channel with a collapsible section, Slack now shows the section’s title in bold followed by its text. Before, the raw <details> and <summary> tags appeared in the reply. Nothing to change on your side.
• The “Terms of Service acceptance required” error now shows the payload accept_tos accepts, { "psaVersion": "<version>" }. It used to show tosVersion, which accept_tos rejects. The structured error keeps details.tosVersion and adds details.psaVersion.
• Hosted buyer agents now get recovery steps they can follow. An api_call that passes customerId or customer_id tells the agent to retry without that key, and no longer points it at customer_switch, which buyer agents can’t call. When a buyer agent’s session is on a parent account, the tool refusal and the ask_about_capability banner say that an account admin has to change the agent’s advertiser grant. They no longer ask the agent to pick a child account and switch to it. When an agent hits the Terms of Service gate, the error also says that only a direct organization admin can accept, and that the agent should ask one to accept in the app if its own attempt is refused. Responses for people signed in to their own accounts are unchanged, apart from the psaVersion fix.
• If your V3 Seller or Developer integration calls save_agent, add operation before your next deployment. Use seller_save in a Seller Account to confirm or correct a Sales Agent product mode; use developer_create in a Developer Account to register a Sales or Creative Agent; use developer_update to rename an owned Agent. Requests without operation, or with fields for another operation, return a validation error. V2 callers and V3 Buyer callers are unchanged.

​

5.1065.0 — October 12, 2026 at 5:05 PM UTC

• Buyer account resolution now avoids timing out while counting active inventory-source account observations, so creative sync and media buys can continue for high-volume storefronts.
• Fix connecting a Meta login that has access to more than 25 ad accounts. The connection finished with “0 accounts discovered” and a provider connection error, and reconnecting did not help. Apostra now discovers every ad account the login can reach. The Facebook Pages a login can advertise as, and the Events and Instant Forms on them, also load for logins that manage more than 25 Pages.
• A seller’s declared age on a product from an ad-server source now reaches buyers. Before, the included age signal and audience evidence a seller declared were dropped before buyers saw the product, so a buyer’s hard age request, such as ages 25-54, never found a product whose seller had declared that age. Buyers now see the declared age as an included signal on the product, and a hard age request finds it when its range fits and the buyer accepts how the age was determined. Audience evidence is sent to buyers on AdCP 3.2 exactly as the seller declared it, and never to buyers on earlier versions. It still informs planning only and never counts toward a hard age request. Products with no declared age or evidence are unchanged. A change to a product shows to buyers on the next catalog refresh. See Declare who a product reaches.
• Creatives that the Apostra-managed sales agent approves after review now reach you as a sync_creatives completion webhook again, so you no longer have to re-check their status. Your webhook registration is passed on to the managed sales agent the same way it is for other sales agents. Nothing to change on your side.

​

5.1064.0 — October 12, 2026 at 4:34 PM UTC

• Retrying a creative sync for a media buy no longer fails with “creative sync target identity is immutable” when the earlier attempt failed.
• Buyer agents can register Bearer or HMAC-SHA256 webhook authentication on sales-agent requests again, so creative approvals and other task callbacks reach them without polling. Buyers that already verify RFC 9421 signatures see no change.
• Before you deploy a REST, MCP, or SDK integration that calls save_buyer_agent in the V3 preview, add operation. Choose one of create, update_display_name, update_access, lifecycle, or credential_handoff. Each operation accepts only its own fields. Requests that omit operation or combine fields from different operations return a validation error. Existing V2 callers are unchanged.

​

5.1062.0 — October 12, 2026 at 3:36 PM UTC

• Sign-in links now open on the Apostra app domain instead of routing through the retired Interchange address. You do not need to change anything.

​

5.1060.0 — October 12, 2026 at 2:48 PM UTC

• Apostra no longer returns AI token counts. The usage object (token counts, latency, and model) is removed from chat replies on POST /api/v2/murph/chat, the done event of /chat/stream, confirmation decisions, and the ask_murph and ask_apostra tool results. Conversation and message reads no longer include totalInputTokens, totalOutputTokens, inputTokens, or outputTokens, and the GET /api/v2/murph/usage endpoint is removed. The temporary-pause message shown when an account hits the safety limit no longer quotes token numbers. If your integration read any of these fields, stop reading them; nothing else about the replies changes.
• The plan chooser now lists every plan your organization can move to, whether it is on a paid plan, a plan that has ended, or no plan yet, and shows each plan’s monthly commitment, included IUs, price per IU, account limit and what it includes. Switching to another public plan asks an organization Admin to confirm and takes effect immediately (a private offer starts at the end of the current term); the confirmation states the current plan, the new plan and what changes. On the pay-as-you-go plan, the chooser lists what you are charged for from the published Rate Card: for buyers, media buys that book delivery and Enhanced Reporting; for sellers, every brief they run and each media buy delivered, when the plan charges for them. An organization whose plan has ended is now prompted to choose a plan.
• The POST /chat endpoint no longer returns AI token counts (usage.inputTokens and usage.outputTokens). A failed request now returns the standard error body, { "data": null, "error": { "code": "INTERNAL_ERROR", "message": "..." } }, with a generic message instead of the underlying provider error text. If you read usage, remove that read. If you read the top-level error or message on a failure, read error.code and error.message instead.

​

5.1059.0 — October 12, 2026 at 1:41 PM UTC

• Fixed creative review results being dropped when a seller took more than seven days to review a creative. A late approval or rejection now updates the creative’s status instead of leaving it under review.
• When Apostra sends a creative to a seller for a media buy, {CAMPAIGN_ID} in its tracker and click-through URLs is now filled with the campaign that media buy belongs to. Before, a creative sent for a media buy whose campaign shares a strategy with other campaigns could carry another campaign’s id, and a creative synced without an advertiser on the sync carried the placeholder unfilled. When the media buy has no campaign, {CAMPAIGN_ID} is now sent empty instead of as the literal placeholder. Click-URL parameters you configure on an advertiser, campaign or creative are unchanged. Nothing to change on your side.
• Launching a Meta campaign on an ad account with more than one Facebook Page no longer fails when the creatives are sent to Meta. The Page (and Instagram account) you chose for the media buy is now used for its creatives too; before, Meta refused them for not naming a Page, and the launch stopped with “execution failed”. Nothing to change on your side.
• The ad-server read-back on GAM media buys (ext.scope3.ad_server_readback.order_status in get_media_buys) now shows the GAM order’s current status, such as APPROVED, instead of staying at the DRAFT status recorded when the order was created.
• The Partner AI usage statement (GET /api/v2/provider/ai-usage-statement) no longer returns AI token totals. The totalTokens field is gone from the statement summary and from each detail line. The statement still returns event counts, the rating disposition for each event, iuAmountMilli, and the capability, client, source and incident details. If your reconciliation read totalTokens, use the event counts instead.
• Intelligence-run records no longer include AI token counts. The input_tokens and output_tokens fields are gone from negotiationSummary.qualification, and the model-usage counters (input, output and cache token counts) are gone from negotiationSummary.chef_llm. This applies to GET /api/v2/storefront/intelligence-runs (both views), GET /api/v2/storefront/intelligence-runs/{id}, the label endpoint’s response, and the same calls made through MCP, including records created before this change. If your code reads these fields, remove it. The verdict, model name, latency and every other field are unchanged.
• Sellers can now declare who a product reaches, so buyers who require a specific age range can find and buy it. On a product from an ad-server source, save_wholesale_product takes an included age signal: one age range every impression reaches, such as ages 25-54 verified at sign-in. A buyer’s hard age request accepts the product when its range fits and the buyer accepts how the age was determined. The same tool takes audience evidence, such as a panel’s age mix. Buyers use it to plan and rank, and it never satisfies a hard age request. If your age data comes from a survey, a panel or a model, declare it as audience evidence. A modelled age in an included age signal is refused on save. Both fields are optional, and existing products keep working unchanged. You set them through the tool or the REST product routes, not the Inventory Components editor yet. Declare who a product reaches.
• Media-buy and creative-generation responses no longer include AI model token counts or provider cost. The undocumented ext.scope3.llm_token_usage field has been removed from create_media_buy and build_creative responses, and the token and cost fields (*_tokens, cost_micro_usd) have been removed from ext.scope3.media_generation.provider_usage. This applies to the standalone creative agent and to the webhook and task results it sends for async builds. Unit counts such as calls, images and seconds, and everything else in ext.scope3, are unchanged. If you read these fields, stop; they are not part of the response contract.

​

5.1058.0 — October 12, 2026 at 1:07 PM UTC

• Creative sync now honours the managed source selected on a draft media buy and returns actionable account errors without checking unrelated storefront sources. Per-buy failures keep the existing HTTP 200 response and human-readable message, and now populate the existing optional error-code field with MANAGED_ACCOUNT_LINKAGE_REQUIRED or source_account_not_bound when applicable.
• A new advertiser’s currency and reporting time zone now come from its countries. Choose United Kingdom and the advertiser setup form fills in GBP and Europe/London, with a note under each field saying where the value came from. Countries that share a currency or clock fill in the same way (France and Germany give EUR). When the countries disagree, or a country such as the United States spans several time zones that don’t include yours, the field starts empty and you choose before creating the advertiser. Anything you pick yourself stays when you change countries. With All countries the form keeps its previous defaults: USD and your own time zone.
• The API applies the same rule. save_advertiser fills in an omitted primaryCurrency or preferredTimezone from brandCountries, and returns needs_input for that field when the countries don’t share one; with no countries it still uses USD and UTC. POST /api/v2/buyer/advertisers fills in an omitted preferredTimezone from brandCountries, or uses UTC when there are no countries or they don’t share one. primaryCurrency stays required there. See Create an advertiser.
• If your connection can be switched to another account, you now need to send expectedAccountId on every V3 write. Call get_status when the conversation starts and pass its accountId as expectedAccountId. A write without the field is refused with ACCOUNT_CONFIRMATION_REQUIRED, and nothing is written; if the conversation has no account yet, the agent should confirm it with the person rather than adopt whatever account the connection is in now. V3 is a preview, and this is a breaking change for these callers.
• This applies to people signed in through a connector (Claude, ChatGPT and others) and to personal (legacy) Scope3 API keys. On these connections, a switch made in one conversation moves every conversation on the same connection. Without the field, a write could land in an account that another conversation switched to. For these callers, tools/list now marks expectedAccountId as required on every write.
• If a write names an account the connection is no longer in, it is refused with ACCOUNT_MISMATCH. Your agent should ask the person before calling switch_account, because a switch moves every conversation on the connection.
• Nothing changes for credentials fixed to one account (WorkOS user and organization API keys, and machine credentials) or for the V3 HTTP API. The field is not listed for them. switch_account, manage_organization and the reads (get_status, search, get) never take the field.

​

5.1057.0 — October 12, 2026 at 12:23 PM UTC

• Advertiser Portfolio and Media Company now complete signup with email and password, Google, and single sign-on. Before, choosing either with email and password stopped with “Signup is temporarily unavailable”, and choosing it with Google or single sign-on quietly created an ordinary Buyer or Seller account instead. Advertiser Portfolio now creates a Buyer account with no advertiser, and Media Company creates a Seller account with its Storefront already set up. These choices appear only in the four-choice signup chooser, which is rolling out gradually; nothing changes for anyone who does not see it.
• Accounts opened through a seller’s own sales agent now record the payment terms requested and the terms the seller confirmed, so the account reports them like any other.
• Products from a managed sales agent can now carry AdCP audience evidence (for example a panel’s age composition) and a fixed age cohort for age-gated or age-verified inventory, which AdCP 3.2 buyers see as an included signal with its age range. AdCP 3.1 buyers no longer receive product fields that only AdCP 3.2 defines.
• Media buys and creatives now reach embedded sales agents whose seller has marked the buyer’s account as not required, such as agents on AdsWizz or SpringServe. For buyers billed through Apostra, the storefront sends the buyer’s brand and operator as the account, and the sales agent books it on the seller’s advertiser routing rules or default advertiser. Previously these requests were stopped before reaching the agent because no account was sent. Media buys and creative syncs from buyers the seller bills directly are refused on these sources, because the sales agent would otherwise book them as billed through Apostra.
• Reporting webhooks use Apostra’s RFC 9421 signature. Verify requests with the buyer agent public key published through its AdCP identity instead of supplying a Bearer or HMAC credential.
• Spotify audio creatives whose call to action is written as its label, such as “Listen Now” or “Learn more”, now reach Spotify as the matching Spotify button (LISTEN_NOW, LEARN_MORE). Before, Spotify refused the creative unless the call to action was typed exactly as the code. Text that is not one of Spotify’s buttons is still refused. Nothing to change on your side.

​

5.1056.0 — October 12, 2026 at 11:32 AM UTC

• Measure VAST duration, without treating a rendition size or buyer declaration as seller-format evidence, so buyer creative sync can select a seller’s matching legacy video format.
• Running your own advertisers and campaigns is now part of the Agentic Media Company product only. If your storefront sells as an Agentic Media Company, nothing changes: you keep the Advertisers workspace and can create advertisers and campaigns in the Apostra web app, in Murph, and through Claude or other connected assistants. If your storefront is Listing-only, or hasn’t chosen how it sells yet, those advertiser and campaign tools are no longer offered on any of these surfaces, and requests to use them are refused. To run your own advertisers, choose Agentic Media Company in Settings → How would you like to sell? Your inventory sources, media buys, approvals and buyer relationships are unaffected.
• Asking Murph, or any connected agent, to add an advertiser now opens the Add advertiser form directly instead of collecting the details in chat.

​

5.1055.0 — October 12, 2026 at 11:00 AM UTC

• Buyer agents in the V3 beta can manage their own verified-endpoint event subscriptions through notification settings.
• Murph no longer refuses some customer requests, such as asking it to file a support request or save a change, with “I can’t follow instructions that try to override my operating rules.” Requests that carry structural prompt-injection markers are still refused.
• Murph no longer fails a turn with “Murph could not load the current customer-request status” when one of your request sources is temporarily unavailable. It answers from the requests it could read and says which sources were missing. It also stops repeating the same request lookup when the ledger can’t be read, and fails promptly instead.
• A hard age request, such as ages 25-54 in targeting_overlay.demographics.age or read from the brief, now matches a product’s fixed age audience only when the product delivers that age to every impression. Storefronts read that from AdCP included_signals: an entry with a demographic_predicate.age and restricted_attributes including age, with how the ages are known in ext.apostra.age_determination_bases (verified, declared or inferred) until AdCP adds a field for it. Storefronts still read the earlier ext.scope3_product_targeting.demographics.age declaration, but only an age a built-in adapter applies, or one whose every person’s age is verified or self-provided (user_verified or user_provided), now counts. A survey-based, modeled or undeclared audience claim describes who the inventory tends to reach, so it no longer matches a hard age request, and AdCP audience_evidence never does. Products using an age signal, their ad platform’s own age targeting, or letting the buyer set age are unchanged. Composed products now describe a delivered age as an included signal. At campaign launch, a fixed audience that does not count is not narrowed to or refused for. Buyers will now see the demographics_not_applied warning at launch for a product whose age comes from a modeled or survey-based age signal (basis inferred) when the campaign does not allow modeled age and the product’s seller cannot apply the campaign’s age range itself; the media buy still launches, without age targeting on that package. The same warning can appear for a storefront’s composed product saved before this release whose age came from such a signal, until the buyer discovers the product again. Sellers that relied on a survey-based or modeled claim can list an included age signal, declare age targeting support, or declare a verified or self-provided method. See the age targeting guide.
• Launch now also stops before dispatch when an HTML5 or display-tag creative has no size and the product offers several fixed sizes as separate formats, for example a 300x250 and a 728x90 option. The error names the creative and every size the product accepts, and the buy stays in Draft. Products where any of those formats accepts any size still launch.

​

5.1054.0 — October 12, 2026 at 9:55 AM UTC

• Creatives booked through managed sales agents now carry Interchange’s impression tracker, plus playback trackers on hosted video, wherever the seller’s format declares a slot for them.
• Agents using V3 search over MCP from a Buyer account need fewer retries when they leave out the advertiser. A search for catalogs, creatives, creative assets, collections, formats, sessions, event sources, property lists or wholesale products that names neither an advertiser nor a campaign now uses the account’s only active advertiser. When the account has several, the error names them, so the agent can pick one on the next call. Media buy searches and the HTTP API are unchanged.

​

5.1053.0 — October 12, 2026 at 9:34 AM UTC

• Creatives now reach storefront media buys that were placed under one of your seller accounts. Before this fix, the storefront could not find those buys when you sent a creative, answered “No media buy … on this storefront”, and the seller then refused the media buy update because it had never received the creative. To send a creative that was refused this way, attach it to the campaign again.
• Switching into an organization now opens Ask Apostra, with the organization’s settings in the left rail. An organization has only settings, so the rail no longer falls back to the advertiser menu, and the way back to another account is the account switcher at the top.
• The workspace pulldown next to the Apostra logo in the top bar is gone, because the logo already takes you home and the left rail handles switching between workspaces.

​

5.1052.1 — October 12, 2026 at 8:57 AM UTC

• V3 get_delivery no longer fails with an internal error for campaigns with a delivery goal.

​

5.1052.0 — October 12, 2026 at 8:16 AM UTC

• If your plan charges for brief responses, set up two things before enforcement is turned on for your storefront: an active Brief Acceptance policy in AI Business Rules, and a payment method, approved credit, or a plan with a monthly commitment on your organization. Once enforcement is on, a brief that arrives without both is refused before it runs, and the refusal names the step that’s missing. We’ll tell you before we turn it on, and until then nothing changes. Plans that waive brief responses are not affected.

​

5.1051.2 — October 12, 2026 at 3:45 AM UTC

• Fixed a bug where launching a campaign with a creative against a Meta-connected seller could fail with “the seller-library revision could not be verified,” even though the creative had already synced successfully. Retrying did not help before this fix; creatives now correctly register as synced so the media buy can launch.

​

5.1051.1 — October 12, 2026 at 3:09 AM UTC

• When a live delivery read for a media buy fails at the seller or adapter, the error response now includes the seller’s actual rejection reason (code, message, suggestion, and details) instead of a generic SERVICE_UNAVAILABLE message with no detail.

​

5.1051.0 — October 12, 2026 at 2:52 AM UTC

• sync_creatives now returns the seller’s specific rejection code on a failed creative instead of a generic one, when the seller provided one. A single-creative media buy that fails because its only creative was rejected before delivery now shows the seller’s specific rejection reason instead of a generic message, when one was available.
• V3 save_billing calls must now include operation: send "terms" with terms, "payment_terms" with paymentTerms, or "payment_authority" with paymentAuthority. Payment-authority calls must include their action.

​

5.1050.0 — October 12, 2026 at 1:26 AM UTC

• When you add an advertiser with a V3 agent, it now suggests the countries and channels it should cover, and you confirm or change them before saving.
• Saving one file from Murph can now use the title you supplied for the Library Draft. If the title cannot be used with the selected files, Murph explains which field to change so you can try again.
• New buyer accounts now start with the V3 beta experience turned on: Murph answers buyer questions through the V3 agent surface, Reliable Reporting status is available for your media buys, and the campaign seller scorecard is available for your campaigns. Buyer accounts created before this change keep their current setup, so there is nothing to change on your side. Ask us to enroll an existing account in the V3 beta if you want the same experience.

​

5.1049.0 — October 12, 2026 at 12:22 AM UTC

• Murph no longer refuses short replies such as “yes” or “do it”.
• V3 save_creative_session calls must now include scope: send "campaign" with campaignId, or send "advertiser" with advertiserId. Campaign promotion remains campaign-scoped and also includes advertiserId for the Creative Library owner.
• Release notes published before late August that were cut off mid-sentence now show their full text.
• Files you attach in chat stay available for the rest of the conversation, so you can answer a question before saving them.
• The seller docs now say what happens to new buyer accounts today. Every storefront accepts a new account automatically when it asks for net 60 or shorter terms, prepay, or no particular terms, and a net 90 request waits for your review. You can’t change this yet: PUT /api/v2/storefront refuses accountApproval and accountMaxAutoAcceptPaymentTerms, and its error now says your current setting stays in place instead of saying new accounts go to your review queue.

​

5.1048.0 — October 11, 2026 at 11:36 PM UTC

• When a seller rejects a cancel, pause, resume, or archive request on save_media_buy, the error response now includes the seller’s actual rejection reason (code, message, suggestion, and details) instead of a generic message with no detail, or in some cases no detail at all.

​

5.1047.0 — October 11, 2026 at 11:09 PM UTC

• Live certification no longer fails display and video use cases on the Trusted Match token, which only sellers that support Trusted Match can fill.
• Any teammate on your account can now change a campaign’s creatives on a storefront media buy and have the change reach the seller. Before this fix, the seller accepted creative changes only from the person who placed the buy, and refused everyone else’s as unauthorized, even though the change was saved on your campaign. To send a creative that was refused before, attach it to the campaign again. You don’t need to detach it first, and anyone on your account can do it.

​

5.1045.0 — October 11, 2026 at 10:07 PM UTC

• Integrations now clearly identifies connected service states, provider failure reasons, and connection controls.
• Creative sync and launches at third-party sellers no longer fail with an account linkage error after the seller’s capabilities refresh. The seller account we had stored for you is now kept across those refreshes, and accounts affected earlier are requested from the seller again automatically the next time you discover products or sync creatives, with no action from you.

​

5.1044.0 — October 11, 2026 at 9:45 PM UTC

• Scrappy builders and power buyers using the V3 beta can opt in by including reporting_webhook (an HTTPS URL and AdCP credential) in a completed direct media-buy mutation. The seller still receives that instruction, but the credential cannot live in ordinary media-buy data because later reporting delivery needs it without exposing it in readback. This change stores the credential privately with the buyer agent’s endpoint; webhook delivery follows in a later release. Buyers who omit reporting_webhook see no change. Queued approval requests do not create a binding, and their stored payloads redact webhook credentials. Sellers keep receiving the buyer’s AdCP instruction unchanged. An operator can no longer pass reporting_webhook through a direct mutation: the wrapper rejects it because the endpoint must have a registered buyer-agent owner. This does not change the seller request for buyer-agent mutations, and sellers receive no new delivery.
• You can now open Advertiser settings straight from the Advertisers list, using the new Settings action on each advertiser’s row, and from Edit advertiser under Settings → Setup & readiness. The form is now titled Advertiser settings, and each read-only field tells you why it can’t change.
• Video creatives built from MP4s in your Creative Library now reach your media buys with any seller whose product accepts the format. Before, they could only be delivered to a Meta destination, and attaching one to a campaign with other sellers was refused. Attaching a Library video Creative to a campaign now adds it to every media buy on that campaign whose product accepts its format, the same as any other creative.
• The V3 save_creative result no longer returns deliveryDeferredReason, because no Library composition is held back any more.

​

5.1043.0 — October 11, 2026 at 9:07 PM UTC

• The Delivery view’s totals now cover every media buy in your filtered list, not only the buys loaded on screen. Impressions, spend and ”% of booked budget” no longer change as you load more, and buys in different currencies are totalled separately instead of being added together.
• Keep seller media-buy timelines readable when unrelated reporting metadata has no delivery array.

​

5.1042.0 — October 11, 2026 at 8:44 PM UTC

• You can now see how each seller in a campaign did, on four scores ranked separately: delivery against an even pace (running ahead of pace ranks lower than on pace, just as running behind does), price per unit of your primary goal (per click for a click goal, for example, or per thousand impressions when the goal can’t be priced or there is no goal), performance against that goal, and quality, which isn’t scored yet. Request it with GET /api/v2/buyer/campaigns/{campaignId}/seller-scorecard, for the campaign’s whole reported life or a startDate and endDate you choose. Each score shows the seller’s rank on that score alone and who counted it: the seller, a measurement vendor, or your own measurement records. There is no blended score, so a seller that costs more but performs better reads as exactly that. Prices include the platform fee. The scorecard uses only your own media buys in the campaign, and a buy that includes products from more than one seller is listed separately and not scored. A score with no data shows as not reported, never as zero, and is not ranked, and a score based on too little delivery to compare is shown but not ranked. The scorecard is open to buyers enrolled in the V3 beta, and there is nothing to change on your side.
• The billing account (GET /api/v2/billing/account and the get_billing_account tool) no longer returns usage.intelligence, the AI token counts and provider costs grouped by feature and by day. Plan & Billing already showed Intelligence Unit (IU) usage instead, so nothing on screen changes. If an integration read usage.intelligence, use usage.iuActivity and usage.iuAccount, which carry your rated IU usage for the period.
• Campaign creative pickers now keep the additional Library pages you load visible instead of restarting at the first page.
• Look up brand now finds brands for Media Companies creating their own advertisers, and fills in the advertiser name. Before, it only found a brand that publishes its own brand file, so a brand listed in the AAO community registry (for example chalk-lines.com) showed “No registered brand found”, and even a found brand did not fill in the name. The lookup now matches the buyer form: it reads any AAO registry record, then enrichment data and the brand’s website.
• Agents calling save_advertiser with only resolveBrand get the same broader lookup. identity.source is still set only when the brand publishes its own identity, which is what publicBrand: true requires. A lookup still running after about eight seconds now returns a SERVICE_UNAVAILABLE error; call it again shortly. save_seller’s resolveBrand is unchanged. See Identity and brands.

​

5.1041.0 — October 11, 2026 at 8:05 PM UTC

• New creative-sync notifications use a Storefront and operation callback URL. Sellers that restrict callback paths must update their allowlist or new callbacks will fail; callback URLs issued before this release continue to work for seven days. The notification payload and frequency do not change.
• Make Murph approval cards describe the customer action and show clear expiry dates.
• The ChatGPT app package now downloads only once Apostra confirms it is ready. get_chatgpt_app_config returns submissionReadiness with ready, the missing prerequisites (live public address, active reviewer access, OpenAI domain proof, a buildable package) and one blockedReason, and bundleAvailable keeps meaning only that the package can be built. get_chatgpt_app_bundle_url and the download itself now refuse with that reason until reviewer access is active and unexpired on Apostra’s clock and OpenAI domain ownership is proven, so an agent no longer prepares a package the OpenAI submission cannot use.

​

5.1040.0 — October 11, 2026 at 7:40 PM UTC

• Business Manager is now a public plan. Any buyer organization can choose it in Plan & Billing, at the same price as Connect & Buy, to run up to 100 Buyer Accounts on one IU bill. Previously it was only available through a Commercial Offer. For organizations choosing a plan from now on, Storefront agent covers one account; Storefront agent + Distribution and Enterprise — Storefront agent still cover up to 5. Organizations already on a plan keep their current terms, including any extra accounts they already hold, until they accept a plan from the current Rate Card.
• Meta campaign reporting now preserves the built-in messaging optimization when a conversation campaign does not include a Page in its readback.

​

5.1038.0 — October 11, 2026 at 6:50 PM UTC

• The goal bar in your campaigns view now covers goals measured by a vendor, such as store visits or an attention score. You see whether the campaign is on track against your target, with the number in the vendor’s own unit rather than a percentage, and a line saying who counted it: the vendor’s values as the seller reported them, or your own measurement records.
• Product discovery against a third-party sales agent is faster on repeat requests. The seller setup that used to run before every request (finding the endpoint, listing its tools and reading its capabilities) is now reused for five minutes, so a warm request goes straight to the seller after its connection handshake.
• Review notes from your storefront assistant are now saved on chat-added Library Drafts and shown while you review them.

​

5.1037.1 — October 11, 2026 at 6:26 PM UTC

• Creatives now reach the seller when you create, duplicate, detach or archive them, or attach them through a creative collection, on a media buy with a direct storefront, for example a seller connected through Google Ad Manager. Before this fix, those changes were saved on your campaign, but the seller refused them as unauthorized, so the seller’s line item could stay without its creative. To send an affected creative again, detach it from the campaign and attach it again.
• Folder choices now clearly label full-drive, site-library, and Confluence-space imports. Before importing a whole source, you see its previewed file count and must confirm it.
• Hosted video products from Google Ad Manager sellers on a managed sales agent now list optional impression, start, quartile and complete tracking pixels in their creative formats. Your agent can see from the product itself that it may attach its own video tracking pixels, and they are passed to the seller’s ad server with the creative.
• When you accept or decline a buyer’s request and the Buyers view cannot reload afterwards, the buyer’s row now says “Saved. Refresh to see the latest status.” and offers Retry, instead of silently showing the old status.

​

5.1037.0 — October 11, 2026 at 6:06 PM UTC

• If you name your own event sources in conversion goals, map each one to its pixel, dataset or conversion rule on every seller account you buy on. Do this on the Connections page, or with sellerAccounts on save_event_source (audiences use save_audience). Saving asks the seller account to confirm right away, so a mapping moves from pending to synced, typically within a minute, and an audience shows the seller’s own size and match rate. The Connections page lists what is on each account. Storefront-specific objects, such as Meta Instant Forms leads sources, stay unmapped.
• Once mapped, a goal that names your source sends each seller its own pixel, dataset or rule instead of your id. A new media buy whose goal names an unmapped source fails before anything reaches the seller, with invalid_request (yours to fix) and one of: SELLER_EVENT_SOURCE_DESTINATION_AMBIGUOUS (the account has pixels and none is mapped), SELLER_EVENT_SOURCE_DESTINATION_MISSING (it has none, or the one you named is missing or does not accept your source’s event types), SELLER_DATA_SHARING_NOT_PERMITTED (the Conversion events switch is off for that storefront on Connections), or SELLER_OBJECT_TYPE_UNSUPPORTED (that seller cannot take event sources). Buys with no event goal, goals carrying a raw platform pixel id, and a Meta product’s explicit pixelId are unchanged, except that an explicit pixelId that differs from the mapped dataset is refused. Unmap with { "accountId": "...", "unmap": true }: nothing is deleted on the platform, and unmapping is refused while a live media buy uses the mapping. Apostra never creates a pixel or dataset. See Use your event sources and audiences on each seller account.
• Large XLSX Library uploads now preserve a bounded sample from every worksheet and show each sheet’s dimensions. The Library only suggests the rate-card import for rate-card fields, not delivery reports that include CPM, cost, or performance metrics.
• Calls from Apostra to your sales agent no longer include the buyer’s session or workflow identifiers. Apart from the credentials and headers you configured for the source, each call now carries only x-scope3-debug-id, x-request-id, and traceparent, so you can still quote a call back to us from your own logs. The internal x-scope3-mcp-session-id, x-scope3-run-id, x-scope3-workflow-id, x-scope3-skill-id, x-scope3-scenario-id, x-scope3-step-id, x-scope3-intent-hint, x-scope3-dispatch-group-id, and x-scope3-storefront-source-id headers are no longer sent. Nothing changes in your setup unless your agent read one of them. Because calls from different buyer sessions now look the same to your agent, Apostra can reuse one connection and its cached discovery across them, which means fewer repeated discovery requests to your agent.

​

5.1036.0 — October 11, 2026 at 5:28 PM UTC

• Show sellers their Library Drafts and report when the Draft read cannot load.
• On a storefront hosted here, a buyer’s goal that a measurement vendor counts now shows how it is doing instead of “not reported”. The buyer’s side reports a score for the buy and your storefront keeps it. The goal reading shows it with basis.kind set to buyer_reported: the score as performanceIndex (1 meets the buyer’s rate target), the days it covers, and when it arrived. The verdict follows the score: beat at 1.1 or more, on_track from 1, behind below 1. actual stays null, so you never see a rate built from the buyer’s data, and you never receive the vendor’s values, the impressions or the buyer’s measurement source. A buy with no score yet still reads as not reported. This applies only to buys where the buyer is in the vendor-goal score-back pilot. Nothing to change on your side.
• Release notes no longer end with internal issue-tracker references such as “Fixes” or “References” lines.
• Every V3 write tool except switch_account and manage_organization now accepts an optional expectedAccountId. When you send it, a write fails instead of landing in an account another conversation switched to. get_status gives you the account id. Send it on every write: it will become required for connections that can be switched to another account, meaning people signed in to a connector and personal legacy Scope3 API keys.

​

5.1035.0 — October 11, 2026 at 5:09 PM UTC

• Storefronts now pass on a brief that tries to instruct the Merchandising Agent how to classify it, in any language, instead of pitching it. The decision is recorded with the rule untrusted_brief_taxonomy.
• An advertiser whose brand.json uses the current AdCP house-and-brands layout now gets its brand kit and voice rules. The brand’s name, tagline, logos, colors, fonts and tone are read from the brand entry that matches the advertiser’s domain, falling back to the house’s master brand. Previously one field in that layout, such as a localized name or tagline, made us reject the whole file and store nothing. A single malformed field now drops only that field. Advertisers already linked to such a brand get it on their next brand read, with no relinking.
• Fix generated V3 OpenAPI and SDK types so they preserve the server’s validation rules. SDK users no longer receive types that accept payloads the server rejects, or reject valid server payloads. The TypeScript and Python SDKs retain reviewed old-to-new compatibility aliases and reject duplicate generated declarations. Creative-engine and creative-session branches now reject include where the server forbids it.
• generate_variants is now correctly documented as the buyer write at /tools/generate_variants, with its generate_variants operation ID, interchange:write scope, required Idempotency-Key, and typed request and response. It was previously misdocumented under get_status with read authorisation. Seller get_status integrations do not change: generate_variants remains unavailable to seller accounts.
• This release changes no runtime capability, pricing, entitlement, or billable unit. get_status remains the seller readiness and orientation read. generate_variants remains the existing buyer creative-session write, with its existing M2M write scope and stable Idempotency-Key requirement. Release verification is successful SDK code generation, packed-package import and type checks, and a stable-key generate_variants smoke call; any failure stops promotion.

​

5.1034.0 — October 11, 2026 at 4:47 PM UTC

• Measurement records for the same outcome type, source, geo and time window can now name different media buys. Uploading a second record for a window that already holds one no longer fails with 409 CONFLICT; each campaign, media buy and package keeps its own record, and re-uploading the same combination still updates it in place.
• Seller connection reads now report the setup step each advertiser owes on every seller, not only after activation has started: Complete advertiser setup for an advertiser with no country scope or channels, and Connect for an advertiser of a seller that needs your own account connection. Sellers you haven’t selected keep their row-level status.
• When you add folders from Integrations, the folder chooser now uses your existing connection instead of asking you to sign in again. Sync now continues when a routine sync update changes the source, and Refresh clears a resolved folder error.
• Managed sales agent products now preserve nested AdCP format parameters so buyers can discover their canonical creative formats.
• Live certification now counts tracker hits from sales agents that report their own media buy id.
• Media Partners now shows when a seller activates, suspends or closes your account for sellers running on the embedded sales agent, not only for sellers with their own agent.
• Embedded sales agent 1.64.2: name the tenant on FreeWheel request, sync and probe logs.
• The buyer directory now reports where each relationship stands. Each row in the list of buyer account relationships carries a relationshipState: its status (needs review, waiting externally, buying, rejected or new), who owes the next step, whether it needs setup, whether it has started trading, the first item that needs the seller, whether any source mapping has an issue, and whether the seller may map accounts. Agents and integrations read the same answer the seller sees.

​

5.1033.0 — October 11, 2026 at 4:03 PM UTC

• Every seller a buyer reads with V3 search or get now carries partnerStatus: ACTIVE, NEEDS_CONNECTION or AVAILABLE, the same three groups the Media Partners page shows as its tabs. search(kind: "seller") takes filter.partnerStatus, a list of those values, and searches every seller listed on Apostra, so you can ask for only the sellers you have not set up yet or only the ones that need your own login. It combines with filter.sellerType, filter.transactable, filter.channel and filter.region, but not with filter.ids. partnerStatus is read for your account; pass filter.advertiserId on search, or advertiserId on get, to read it for one advertiser instead. connectionState.status still reports the technical connection and is unchanged. filter.marketplace: true is deprecated and now means filter.partnerStatus with all three values; it will be removed with the other deprecated seller names no earlier than 9 December 2026. A search with neither filter returns the same default list as before. Nothing to change on your side unless you call filter.marketplace.
• Apply buyer-stated maximum CPM caps in every language when Chef can extract an unambiguous amount and currency.
• Confidential seller instructions now stay confidential when they are written in every language, including scripts without spaces.
• Seller material can now ground CJK and Thai buyer briefs without changing English retrieval.
• When a media buy is refused because its conversion goal’s event source isn’t matched to a destination on the seller account, reading the buy back now says you can fix it: the error is invalid_request, owned by you, with the reason (“name the destination to use for this account”, “set one up on the platform”, “turn on conversion events for this storefront”, or “this seller account does not accept this kind of object”). Before, it read as a platform error owned by Apostra. The pending message on an event source’s seller account also no longer says that only a media buy starts the check: saving the mapping starts it too.
• Buyers can now buy from their own organization’s Storefronts without listing them on the marketplace or selecting them first.
• Approved creatives now reach third-party sales agents that identify buyers by brand and operator rather than by an account ID. When a creative enters review, the storefront records the buyer’s brand and operator for those agents and sends them with the creative once it is approved, the same account the agent receives with the media buy. Previously these creatives were either turned away when submitted for review or failed after approval without reaching the agent.
• Buyer and seller reporting now show money as unavailable when a completed reporting day has no stored report, instead of showing a lower total. Package availability, delivery coverage, and delivery-grid totals make the same distinction; explicit zero reports remain zero. You do not need to do anything. Budget enforcement still uses the existing cached zero behaviour while its follow-up product decision is pending.
• Fixes AI-12779
• References AI-10629
• Large Library spreadsheets now keep the worksheet data that can be safely read instead of failing the whole file. Complete rate-card and avails-sheet tables continue to their existing review and save flows.

​

5.1032.0 — October 11, 2026 at 3:03 PM UTC

• A pass-through storefront, which passes buyer accounts to the seller’s own sales agent, must have exactly one active agent. If a storefront has more than one, Apostra no longer sends automatic account requests to each agent. It waits until the storefront has a single agent, matching how a buyer’s own account request on that storefront already fails with CONFIGURATION_ERROR.
• Proposal products now state the effective CPM of a flat-rate price. Each product’s ext.scope3_merchandise.effectiveCpms carries one entry per flat-rate pricing option: the AdCP v2.5 fixed-rate cpm price (rate per thousand impressions), worked out from the product’s summed net available impressions, or cpm: null with a reason (omitted_placements, unresolved_placement, no_price, no_available_impressions) when a partial delivery total would make it misleading. The proposal card shows this same number. Proposals captured before this change carry no entry and no longer show an effective CPM line.
• When a campaign with an age range launches, a product whose audience is fixed to a range inside the campaign’s (for example 18-34 for an 18-55 campaign) is now bought with the product’s narrower range instead of failing at the seller or being reported as “age not applied”. The launch response confirms what was sent with a new demographics_narrowed receipt naming the product and both ranges, which matters when a product was selected by id or the campaign’s range changed after proposals were reviewed. A product whose fixed audience reaches ages outside the campaign’s range is now refused at launch when its seller cannot apply the campaign’s range, because it would deliver to people the campaign excludes. Storefronts do not yet return narrower products in discovery; that follows separately.
• If your organization buys from sellers on consolidated billing, an organization administrator must now choose your payment terms before Apostra opens accounts with those sellers for you. Choose net 15, 30, 45, 60 or 90 in Buyer Setup, where net 60 is pre-selected and saving it counts as a choice, or send paymentTerms to PUT /api/v2/billing/info. If your organization was already buying on consolidated billing, net 60 is recorded as your choice and nothing is held. Direct-billed sellers and sandbox accounts are not affected.
• Until you choose, buyer readiness shows an incomplete Payment terms check, consolidated-billing sellers show needs_commercial_setup, and a buy from one is refused with the payment_terms blocker. Setup with a seller you have already connected waits, then resumes on its own once you save.
• When Apostra opens a consolidated-billing account with a seller for you, the request asks for your terms. The seller accepts them by approving the account, or rejects the account; there is no counter-offer, and Apostra does not retry on the seller’s default terms. Longer terms can mean more rejections. You can change your choice at any time but not clear it. A change applies to accounts opened afterwards; an account a seller has already accepted or rejected keeps its decision and its terms.
• To ask one seller for different terms, including prepay, set payment_terms on that seller’s entry in sync_buyer_storefront_accounts. Storefronts Interchange hosts or manages now accept the field instead of returning PAYMENT_TERMS_NOT_SUPPORTED.
• Sellers whose storefronts Interchange hosts or manages now see the buyer’s requested terms on each account request. Approving the request accepts those terms, and the account then reports them; if they don’t work for you, reject the request. Requests for net 60 or shorter, or prepay, are approved automatically unless your storefront reviews every new account. Net 90 always waits for your review.
• See “Your organization’s payment terms” in Buyer setup.
• Audio creatives built from files you upload to the Creative Library, and managed audio adoptions, now reach your media buys. Attaching one to a campaign adds it to every media buy on that campaign whose product accepts its format, the same as any other creative. Previously the creative was attached to the campaign but never reached its media buys, even though the attach succeeded. Audio creatives already affected are released. To add one to media buys that already exist, detach it from the campaign and attach it again. Uploaded audio and video can be delivered for 90 days after approval; after that, the creative is held back from sellers with a message asking you to upload the file again, instead of sending the seller a link that no longer works.

​

5.1031.0 — October 11, 2026 at 2:26 PM UTC

• Customer-knowledge demand extraction now constrains channel values to AdCP media-channel codes, preserving valid video supply requests as olv instead of dropping colloquial video output.
• AI features now fall back correctly when the primary model provider is unavailable.
• The Demand Inbox now uses the same won/lost rule as RFP performance reporting, so its results, Win rate and Booked YTD agree with your reports. A brief reads Won only for a recorded result of won, booked, delivered, or closed_won, and Lost only for lost, rejected, declined, or their closed variants. An accepted outcome no longer reads as a win, and a response with no offer no longer reads as lost. A won value of 0 now shows as 0. Nothing to change on your side.
• Launching a media buy now stops before anything is sent to the seller when an HTML5 or display-tag creative has no width and height and the product requires a fixed size. The media buy stays in Draft and the error names the creative and the size needed, so you can re-upload it with its size declared and launch again instead of losing the buy to a seller rejection.
• If your organization hasn’t chosen an IU plan, choose one in Plan & Billing: it’s the next action there, and Seller admins are also asked at every sign-in until it’s done. Until your organization has a plan you can’t add accounts, and dismissing the prompt no longer hides it. Organizations that already have a plan don’t need to do anything.
• For API consumers: defaultPlan on the IU plan state is now always null and deprecated, and suggestedPlan carries the plan we suggest to an organization with no plan.
• The release feed now lists each change once, instead of repeating it under later releases that carried it forward, and a change you have already seen no longer shows up as unread again.

​

5.1030.0 — October 11, 2026 at 1:42 PM UTC

• You can now see what is available to you, and what stage each feature is at, in the new Features tab in Release notes. It lists the features available to your role in three columns: Alpha (early access, still changing), Beta (ready to try, details may change) and Generally available (live and stable). A feature with limited access appears only once it is enabled for your account. Each card shows the feature’s newest update, how many recent updates it has and the date of the latest. Search matches feature names, descriptions and update text, and you can narrow by product area. Open a card to see the feature’s recent updates, up to five, and its guide when it has one. Opening Features does not mark anything as read. Nothing to change on your side. Feature titles elsewhere in Release notes now start with a capital letter.
• Chef now fences buyer briefs as untrusted data and prevents embedded instructions from changing brief-taxonomy classification rules.
• Approvals now decides which items are overdue or unowned on the server, using the escalation time on your own routing rule. If you set a shorter escalation time than the 24-hour default, an approval that was never routed now shows as Overdue once it passes your time, not after 24 hours. Approvals that already have a deadline are unchanged. An approval that was escalated stays in Overdue (and shows the Overdue badge, not Escalated) even if its deadline was later moved forward.
• search with kind: "work_item" accepts filter.queue (overdue or unowned) to list only those pending approvals, and each pending approval carries its queue state. Modular-source follow-ups have no queues, so a queue filter reports them as not searched. Nothing to change on your side.
• Storefront acceptance policies now come back from the API split into their two sections, briefAcceptancePolicy and creativePolicy, and creating a version accepts those two sections directly. The API now does the splitting and joining, so every tool and the AI Business Rules page store the same text for the same rules. Sending content works as before.
• Seller analytics now tells you whether your agent’s recommended negotiation posture is clearly winning or losing, instead of leaving you to compare two win rates. postureConversion.adherence carries a new verdict: following_wins, diverging_wins or no_clear_difference, or null until followed and diverged runs each have enough bookings and non-bookings to test. The dashboard’s advice to revisit your operating instructions now appears only when diverging from the recommendation booked clearly more often, not on any small difference.
• The storefront readiness response now includes goLiveProgress: the number of go-live steps required and completed, the next step to take, and the count of live problems. The seller setup widget now shows these server numbers instead of counting the checklist itself, so its “N steps from going live” line and progress bar always agree with the storefront’s live status. For a storefront that sells through its own third-party sales agent, a product-catalog step is no longer counted as a step to go live, which the live status already ignored.
• A Source’s connection status no longer turns to “needs checking” just because its last health check is older than the diagnostics window you picked. A check now counts as current for seven days, the same bound Apostra uses everywhere else, so a quiet but healthy Source keeps showing as working. The Source diagnostics API returns this verdict as a new connection object (state, healthFreshness, evidenceConflict), and the readiness response lists the checks that block going live in a new blockerIds array.

​

5.1029.0 — October 11, 2026 at 1:05 PM UTC

• The billing account document now reports setup progress. A new setupProgress field, returned by GET /api/v2/billing/account and get_billing_account, lists the four setup steps (terms, plan, billing details, payment method) with each one done, active or todo, so an agent or app can show where an account is in setup without working it out from the rest of the document. Plan & Billing now draws its setup steps from this field. Where the page could previously show the wrong step because billing details were hidden from the viewer, it now shows the step the server reports.
• Library documents now report one status, documentStatus (processing, incomplete, ready or archived), on get and on Library browse rows, and search(kind: "material") accepts filter.documentStatus to list live documents in any of the statuses you pass. An agent can now ask which documents are still processing or incomplete without reading each one. The status shown in the Library is unchanged, and nothing needs to change on your side.
• Material with a number that cannot be identified safely as non-pricing now stays out of reusable proposal content. This works the same way in every language and script. It can send more material, including dates or dimensions, to seller review; that is intentional because showing an unrecognised price is worse than asking for review.
• The sponsored buyers list no longer offers Reactivate for a buyer whose access was revoked. Each buyer in the list response now carries availableActions, the moves you can make on it now (empty once access is revoked), and the sponsored buyers widget shows exactly those buttons. Nothing to change on your side.
• Image and HTML5 display products from Google Ad Manager sellers on a managed sales agent now list an optional impression tracker in their creative formats. Your agent can see from the product itself that it may attach its own impression-tracking pixel to a display creative, and the pixel is passed to the seller’s ad server with the creative.

​

5.1028.0 — October 11, 2026 at 12:38 PM UTC

• Show buyers all locally eligible modular inventory instead of filtering it with English-only brief keywords.
• In the Apostra web app, Murph can now create and edit advertisers and campaigns for your storefront when you ask, matching the Advertisers tab and what Claude and other connected assistants already offer. Previously Murph said it had no advertiser tools, even though the same account could add advertisers from the Advertisers tab. Which storefronts can do this hasn’t changed, and Murph still checks your access on every change. Nothing to change on your side.
• Buyers’ own impression trackers now reach sellers whose display formats accept a pixel tracker.

​

5.1027.1 — October 11, 2026 at 12:09 PM UTC

• Buyer reporting status and seller diagnostics now identify a past-due reporting period with no revision as overdue. A reported zero-row revision remains complete.
• Fixes AI-12778
• References AI-10629

​

5.1027.0 — October 11, 2026 at 11:53 AM UTC

• Reading a seller RFP or one of its turns on the v3 API now returns commercial: the server’s reading of the RFP’s lifecycle, recorded result (won, lost, accepted or pending), result finality, and won value. It uses the same result taxonomy as RFP performance, so a client no longer has to interpret the free-form outcome itself. Outcomes count only for live, non-imported RFPs.
• Embedded sales agent 1.64.0: scheduled FreeWheel read-back and delivered-impressions close-out, give each buy its own Sentry issue for status-sync alerts.
• The IU plan state read (GET /api/v2/billing/iu-rate-card/v4 and the IU plan task) now says whether the plan choices are on display (showsPlanChoices) and whether the accepted private Partner entitlement continues to card capture (continuesPartnerCardPayment). Apps and agents read these two fields instead of working the rules out from the rest of the state, and the “offer shown” record is written only while showsPlanChoices is true.

​

5.1026.2 — October 11, 2026 at 11:15 AM UTC

• In the Apostra web app, saving the Advertising policies card on the AI Business Rules page now works. You can choose whether your listing shows your brief acceptance and creative policy text, or hide both. The save previously failed with “Advertising Policies were not updated.” Approval gates and policy text save exactly as before. Nothing to change on your side.

​

5.1026.1 — October 11, 2026 at 11:02 AM UTC

• Fixed a temporary conflict that could make staging a media buy fail when another campaign update completed at the same time. The save now retries the database transaction before returning a retryable conflict.

​

5.1026.0 — October 11, 2026 at 10:36 AM UTC

• Use Chef’s typed brief taxonomy for pitch, counter-pitch, and pass decisions in every language.
• Fixes AI-12728
• References AI-12215
• Reliable Reporting status and seller reporting receipts are now available to V3 beta buyers. Sellers with an authorised media-buy relationship can use receipts to reconcile buyer reporting. This beta capability has no separate charge and was unavailable to every buyer and seller before this release.

​

5.1025.1 — October 11, 2026 at 9:42 AM UTC

• Buyer and seller document reads now rank relevant sections for queries written in any language.
• Capability help now uses language-neutral metadata matching and shows a bounded catalogue when no safe match is available.

​

5.1025.0 — October 11, 2026 at 9:34 AM UTC

• Fixes AI-12741 References AI-12702
• Sellers already configured for delivery reporting can check reporting status for a media buy and request a scheduler refresh or a bounded replay from its timeline. Replays cover up to 31 days and 25 reporting items, with two requests per 24 hours. They never change final days, and the timeline explains when the replay request limit is reached. Buyers receive a corrected result through their existing reporting view; they have no new control or notification.
• This is included with configured delivery reporting and does not change pricing or packaging.
• Seller RFP plans now read audience age constraints in any language and ask for a structured age range when the reader is unavailable.
• Customer supply requests from knowledge extraction now use typed model fields, so they work in any language.
• Disclose when age targeting from a discovery brief could not be read with confidence, so buyers can send structured age targeting instead.
• Copy generation now rejects placeholder text in any language instead of relying on English phrases.

​

5.1024.6 — October 11, 2026 at 8:50 AM UTC

• get(kind: "connection") now continues to return an owned connection after its seller leaves connection search, and identifies that state as catalogVisibility: "hidden".

​

5.1024.5 — October 11, 2026 at 8:34 AM UTC

• Creating media buys no longer fails when discovery attachment runs with transaction timeouts enabled.

​

5.1024.4 — October 11, 2026 at 8:09 AM UTC

• Pitch composition now selects an independently checked, seller-confirmed case study for each proposal pass instead of matching English keywords in a buyer brief. Demand Exchange renders only that pass’s persisted selection.
• Leave campaign details unset when brief extraction is unavailable instead of inferring them from English-only patterns.

​

5.1024.3 — October 11, 2026 at 7:45 AM UTC

• Publisher declarations now return the roster that was saved by the request.

​

5.1024.2 — October 11, 2026 at 7:36 AM UTC

• When brief age targeting cannot be read, product discovery now tells buyers that any age requirement in the brief was not applied and directs them to structured age targeting.

​

5.1024.0 — October 11, 2026 at 6:56 AM UTC

• Proposals and pitches now pass a multilingual safety check in every language: the buyer’s request is checked before a proposal is generated, and the generated proposal is checked before it is shown or saved. If either check fails, the buyer gets a short, safe refusal instead of the generated text.
• Fixes AI-12740 References AI-12702
• Eligible sellers can see whether reporting for a media buy is waiting, healthy, delayed, needs action, or complete. They can ask for a scheduler refresh or a replay of up to 31 days and 25 reporting items, with two replay requests every 24 hours. A replay can add a later corrected revision that buyers see in their existing reports; final days remain unchanged.
• Prevent Enhanced Reporting updates from deadlocking with reporting syncs for the same account.

​

5.1023.0 — October 11, 2026 at 5:55 AM UTC

• Murph no longer changes replies based on English action or terminology phrases.

​

5.1022.0 — October 11, 2026 at 4:50 AM UTC

• Source diagnostics now show how a streamed reply from your sales agent finished. When your agent answers with response headers first and the reply afterwards, each request now carries streamCompletion (ended, errored, aborted or cancelled), when it finished, how long it took and how many bytes arrived. A request that Apostra stopped waiting for now reads as aborted instead of only as a successful HTTP 200, and its summary says the stream was aborted with no answer.
• The v3 seller fields now use Apostra names: apostraParticipation (PARTICIPATING or OPTED_OUT, the seller’s opt-out from being bought through Apostra) replaces marketplaceParticipation, transactable replaces marketplaceReady, unavailableReason replaces marketplaceUnavailableReason, and sellerType: "apostra_seller" replaces classification: "marketplace_seller". The search seller filters sellerType and transactable replace classification and marketplaceReady. Nothing breaks today: reads return both names, save_seller and search accept either, and a request that sends both names with values that disagree is refused. The old names are deprecated and will be removed no earlier than 9 December 2026, so switch to the new ones before then.

​

5.1021.2 — October 11, 2026 at 4:32 AM UTC

• Widgets and the web app now name the network “Apostra” instead of calling it a marketplace. The buyer browse view, its tab and its sidebar entry read “Browse media partners”; setup steps, the Listing page and Source diagnostics say “listed on Apostra”, “Apostra listing” and “Availability on Apostra”; account-type descriptions read “Buy media on Apostra” and “Sell inventory on Apostra”. All translations follow, and the product name stays untranslated.
• Chat replies that identify as a general assistant or model vendor are replaced before they reach buyers or sellers in every language.
• When a seller can enforce an exclusion list per property, buyers can execute a multi-property product without removing excluded properties from their list.

​

5.1021.1 — October 11, 2026 at 3:20 AM UTC

• Buyers syncing creatives to sellers that declare only legacy format references now either reach the seller with the seller’s declared format or receive a clear refusal before the buy launches. Seller note: publishing one unambiguous legacy format reference per product and format, or a canonical format catalogue, removes buyer-visible refusals caused by ambiguous or empty declarations.

​

5.1020.4 — October 11, 2026 at 2:10 AM UTC

• Fixes AI-10636 References AI-12659 References AI-12660
• Sellers can now understand reporting receipts, their acceptance states, and how to inspect them in the Media Buy Timeline. The guide explains that receipts are evidence of reporting input, separate from canonical revisions and finality.
• Render Markdown lists and hide internal tool identifiers without relying on English response text.

​

5.1020.2 — October 11, 2026 at 12:27 AM UTC

• Confluence attachment sync now requests downloadable files with a binary-compatible header.
• Classify Murph prompt safety and scope by meaning in every supported language.
• Listing a storefront on Apostra or the public web through the API, an MCP tool or the assistant now needs the same two steps the Listing page already requires: Identity (a saved brand domain) and What you do (a description, at least one channel, and countries or worldwide). A publish_discovery call or PUT on the Discovery publication for a storefront that is not listed yet and is missing either step returns a VALIDATION_ERROR with reason: "listing_prerequisites_incomplete" and missingSteps, and the message names each step to finish. Unlisting is never refused, and storefronts that are already listed stay listed and can keep republishing, so nothing changes for them.

​

5.1020.1 — October 10, 2026 at 11:40 PM UTC

• Murph, the V3 and v2 tool descriptions and the client skills now say “Apostra” instead of “the marketplace” when they talk about listings, seller discovery and availability. Tool names, field names and wire values are unchanged.

​

5.1020.0 — October 10, 2026 at 11:27 PM UTC

• V3 webhook endpoints now belong to the registered buyer agent that creates them. Existing customer-owned V3 endpoint records keep their current delivery behaviour but are no longer available in the Page. To register or manage an endpoint, use a registered buyer agent and create that agent’s endpoint.
• Fixes AI-12708 References AI-10633, AI-12687
• Certification now tells a seller up front when their ad format can’t carry a buyer impression tracker, instead of booking test buys that can never be measured.
• The documentation now calls it Apostra throughout. Pages that used to describe a “marketplace” now say “on Apostra”, “listed on Apostra” or “Apostra review”, and the glossary defines Apostra and Listed on Apostra.
• Fixed creative sync failing before reaching the seller after a media buy was restaged from a seller’s Storefront products to products from one of its inventory sources. The restaged buy now syncs its creatives to the seller, and the earlier sync result stays in its history.
• Fix Integrations folder actions so they work from the service detail screen and show an error beside the affected folder when an action cannot be completed.
• Fixes AI-12723
• Sellers that build products from a brief answer proposal requests again. For about a day, some of these requests came back with “This Seller could not build a response to the brief right now.” even though the seller was set up correctly. This hit requests made outside the seller’s own agent connection, such as buyer proposal requests, brief previews, and practice briefs. Nothing to change on your side; send the brief again to get products.
• The new Targeting stated in the brief section explains how sellers treat targeting written in a campaign brief, and why to put a hard requirement that has a structured field, such as an age range, in the campaign’s targetingOverlay while keeping the brief as written. The V3 buyer guide for agents now tells them to ask whether to set such a requirement in targetingOverlay, show the exact values, and save only after you say yes.

​

5.1019.4 — October 10, 2026 at 10:45 PM UTC

• Fixes AI-12660 References AI-10636
• Sellers can now review up to five reporting receipts in the Media Buy Timeline, three at a time. Each receipt shows its source ID, status, and received totals; it remains separate from canonical reporting and requires no action.

​

5.1019.2 — October 10, 2026 at 10:04 PM UTC

• Murph’s replies no longer drop words like “get” and “search.”
• The save_wholesale_product tool now says plainly that confirmName is only for deleting a product. Agents no longer send it when changing a product, which the tool rejects.

​

5.1019.0 — October 10, 2026 at 9:19 PM UTC

• Fixes AI-12659 References AI-10636
• Add the seller-scoped V3 reporting-receipts read and Timeline Glance contract.

​

5.1018.0 — October 10, 2026 at 8:02 PM UTC

• New agents must be registered and claimed in your organization’s Developer account. Buyer, Seller, and standalone accounts should switch to it—or create one from Accounts or with manage_organization—before setting up new agents. Existing agents and Seller inventory-source attachments are unaffected for now.

​

5.1016.1 — October 10, 2026 at 7:20 PM UTC

• Live Library documents with incomplete extraction now show Incomplete instead of Draft.

​

5.1014.2 — October 10, 2026 at 4:02 PM UTC

• Launching a campaign with a Meta, Snap, Reddit, Spotify or Amazon media buy booked straight from wholesale search no longer stops on “needs seller approval before launch” for a creative that hasn’t been sent to the seller yet. These sellers receive creatives at launch, so the warning didn’t apply. A creative the seller rejected, or one still in review, still blocks the launch. Nothing to change on your side.

​

5.1014.1 — October 10, 2026 at 3:45 PM UTC

• Step 3 of your Listing page now reads “Listed on Apostra” instead of “Listed on Interchange marketplace”, and the unlist confirmation, publish errors and docs use the same name. Nothing about how listing works has changed.

​

5.1014.0 — October 10, 2026 at 3:23 PM UTC

• In-chat apps in Apostra chat are now better protected from loading anything other than the app itself. In the TARS workspace, apps that save, upload or copy work again in current versions of Chrome.
• After you create or update an advertiser in Advertiser Setup, your Advertisers list now opens with the advertiser in it where your workspace can show it. The confirmation stays below with Switch into and Add another. Nothing to change on your side.

​

5.1013.0 — October 10, 2026 at 3:09 PM UTC

• The Channels picker on Create advertiser has a Select all action beside Clear, so a buyer can name every channel in one click instead of ticking each one. Naming channels also sets up seller accounts ahead of time, so selecting all of them does the same for every channel.
• The assistant no longer replies “I can’t share that” to ordinary account questions that mention an id.
• A buyer’s account request through the buyer API (POST /api/v2/buyer/storefront-accounts/sync or sync_buyer_storefront_accounts) is now decided exactly as it is when the buyer calls the seller’s AdCP endpoint. When a seller routes accounts to its own sales agent, the request, including any payment_terms, goes to that agent, and the seller no longer receives a review it cannot act on. If that agent cannot take account requests, the request fails with CAPABILITY_NOT_SUPPORTED (HTTP 422), and nothing is created until the seller fixes the agent. Requests to every other seller follow the seller’s account approval setting, as before.
• The Listing page now says plainly what happened when you look up your brand identity: it only says it read your identity when it found one, and otherwise tells you none was found at your domain and that setting one up is optional. Finished steps show a check, and the marketplace step shows a lock and “Complete steps 1 and 2 first” until your identity and what you do are filled in. Once it unlocks, an Off or Live label sits beside the switch so it is clear you turn it on yourself.
• Organization administrators can create their Developer account from chat with website approval, and organization inspection identifies Developer accounts.
• Two more Seller Setup steps now open in the chat instead of a new browser tab. Connect ad server opens your ad-server sources, and a brand domain that is waiting on verification opens the Listing page where you can review it. Steps that point at the approvals queue or a sample brief still open in a browser tab.
• Password resets are handled entirely on our sign-in provider’s hosted page. Requesting a reset and completing it there are unchanged. If you open an older in-app reset link that is no longer served, you are now taken to the “forgot password” screen to request a fresh link instead of landing on a blank page.
• Manual review requests for an account’s domain now need a reason. Submit stays disabled until you add one, so a blank request can’t be sent.
• Removing an inventory source no longer occasionally fails with “deadlock detected” when it overlaps the capability check that runs on that source’s agent.
• Every organization’s account list now shows its Developer account. An administrator can create the first Developer account at no cost, even when the plan has no spare account slots. See Account Access & Signup.
• When you create an advertiser, the reporting time zone list now shows each zone’s current GMT offset, such as (GMT+02:00) Europe/Berlin, so zones are easier to scan and compare. Advertisers keep the time zone they already have.

​

5.1012.0 — October 10, 2026 at 11:26 AM UTC

• Organization administrators can create a DEVELOPER account through the account-creation API. The first Developer account is included in every plan; additional Developer accounts use an account slot. A Developer account is always created inside an organization and does not change which plans cover it.
• Embedded sales agent 1.63.5: catch pending GAM buys that deliver during their flight, omit null optional product objects at transport boundary, omit null optional wholesale product objects.
• When a new user signs up and joins an existing organization, the “new user signed up” notice now goes to that organization’s admins instead of to the new user. New users no longer receive an admin-facing notice that was meant for someone else, and admins are emailed the same people the signup alert already reported as notified. Nothing to change on your side.

​

5.1010.3 — October 10, 2026 at 4:34 AM UTC

• Murph now uses attachment metadata instead of English wording to identify uploaded documents and retrieve earlier extraction context.

​

5.1010.1 — October 10, 2026 at 3:01 AM UTC

• When you attach files in Apostra chat and ask to add them to the Library, each file now arrives as a Draft for review. Files that mention another publisher or an older brand still save, with a review flag.

​

5.1010.0 — October 10, 2026 at 2:51 AM UTC

• The Creative Library no longer fails to open during a deploy.
• In Account → Integrations, the person who connected a service can review its folders, add more folders, refresh its status, reconnect it, or stop syncing it. Other members can view the connection but cannot change it.

​

5.1009.0 — October 10, 2026 at 2:20 AM UTC

• Keep chat-attached creatives in the Library Draft review flow until a buyer saves or assigns them.
• Opening Integrations from Settings now shows connected cloud drives and lets you retry if the page cannot open.

​

5.1008.0 — October 10, 2026 at 1:43 AM UTC

• Open storefront Listing previews through the same typed MCP Apps tool on Murph, Claude, and ChatGPT.
• Agents using V3 search over MCP need fewer retries. A Buyer account’s creative search without an advertiser or campaign now lists the creatives of its only active advertiser. When the account has several active advertisers, the error names them, so the agent can pick one on the next call. MCP search also reads a filter field sent at the top level of the request, such as advertiserId, as that filter instead of rejecting the call. The HTTP API still requires one owner on a creative search and every filter field inside filter.

​

5.1007.0 — October 10, 2026 at 1:19 AM UTC

• Changing an inventory source’s status, or having a newly registered source activate, no longer occasionally fails with “Failed to update inventory source: deadlock detected” when it overlaps the capability check that runs right after a source is registered.
• Source diagnostics for a third-party sales agent now list products whose creative formats cannot be mapped to an AdCP canonical format. The new creative_formats_unresolvable finding in the source health object lists up to five affected products and their format ids in unresolvableCreativeFormats, for example video_320x480 under https://creative.adcontextprotocol.org when the agent defines neither. Until the agent declares formats its creative agent defines, a buyer’s creative cannot be matched to those products and its sync is refused. Declaring only legacy format_ids is still supported: a product is listed only when none of its formats can be mapped. Nothing changes if no product is affected, and the finding clears when your agent’s catalog refreshes with corrected products. See Troubleshoot source problems.
• Murph now keeps buyer product and media-buy tools available based on your account and prior successful tool use, rather than relying on English wording. Agent and source diagnostic escalation now uses the page you opened, so the same behaviour works in every language.
• The AI usage tab is gone from Settings, and the Seller API no longer serves GET /api/v2/storefront/usage/by-model or GET /api/v2/storefront/usage/summary. Calls to those two endpoints now return 404 and there is no replacement. If you only used the tab, nothing else changes on your side. Your billable Intelligence Unit (IU) usage is still in Plan & Billing.
• Look up brand no longer says “No registered brand found” when the lookup only ran out of time. The brand card now returns pending: true with resolved: false while the lookup is still running, and the Create advertiser widget shows “Still looking up this brand…” with a Try again button. The form stays usable and the advertiser name isn’t filled in from that note.
• Requesting a password reset now sends a single email instead of two. Follow the reset link in that email to choose a new password. Nothing to change on your side.
• Creatives sent to Spotify now have their file type read from the file itself rather than from its link. MP3 audio at a link without a .mp3 extension is converted to the stereo WAV Spotify requires instead of being sent unconverted, and PNG images and QuickTime video are labelled correctly wherever they are hosted.
• Storefronts on the Storefront-built and Agent-supplied paths now apply an age requirement stated in a brief when the request is served at AdCP 3.2, as AdCP 3.2 requires. A brief such as “please target women 18-55” returns only products that can deliver that exact age range, and the response confirms how the brief was read in targeting_resolution.brief_targeting, so a misreading is visible and correctable. Products that cannot deliver the range are omitted rather than offered without age targeting. An age is applied only when it was read with confidence and is a closed range from 18 to 120; otherwise, and on AdCP 3.1, the brief is used for recommendations only and each product says so, as before. A brief whose age contradicts targeting_overlay.demographics.age, for example ages 18-55 in the brief and 21-64 in the structured field, now returns INVALID_REQUEST on brief. Apostra’s own proposal requests reach these storefronts at AdCP 3.2, so their results follow the same rules.
• When one creative in a sync cannot be converted to the seller’s format, the seller now still receives the creatives that can. The one that cannot is reported on its own with the reason, instead of every creative in the request failing.

​

5.1006.0 — October 10, 2026 at 12:23 AM UTC

• A campaign with an age range now launches on every seller. Where a seller cannot apply the age range, its packages are created without it and the launch response carries a new demographics_not_applied warning naming each affected product. Previously the age range was sent anyway: most built-in platform adapters rejected the media buy, and other sellers could silently ignore the range. Meta storefronts that approve media buys automatically still receive and apply the age range under AdCP 3.2. No warning is given when the selected product already targets exactly that age range itself.
• Campaign creative sync now checks each creative against the formats the seller declares for the booked product, even when the product’s formats could not be converted at discovery. Creatives that do not fit are no longer assigned to that package, and when the seller’s declaration names formats its creative agent does not define, the sync says so instead of failing inside the send.
• Fixed a bug where a seller’s sales agent refused a media buy because third-party display tags (for example, CM360 tags) reached it without a width and height. Display tags now carry their size when creatives sync to the seller, the same as HTML5 banners.
• Account admins can verify an account’s domain with a DNS TXT record. In your account’s domain settings, choose Verify with a DNS record, add the record Apostra shows, then choose Check now. Apostra reads the record directly from DNS, so there is nothing to sign in to. Verify via AAO, which asked you to sign in to AAO, is removed. Verify with an email on the domain or a DNS record, or choose Request manual review and Apostra staff will approve it. Approvals already made through AAO stay valid, so if your domain is already approved there is nothing to do. Once your account’s domain is approved, a matching brand domain verifies automatically. See Which domain is which.

​

5.1005.0 — October 9, 2026 at 11:31 PM UTC

• If your company’s domain still had an old Seller account that nobody uses, signing up to buy media now just works. Apostra retires the unused Seller account, frees your domain, and creates a standalone Buyer account that you administer, so you can accept the Terms of Service and invite colleagues straight away. Nothing is deleted, and your account is never linked to the old Seller account. A Seller account that is still in use, with an administrator, a live storefront, or billing activity, owns its domain and is never touched: signing up on that domain creates no new account. You are asked to request access to the existing account, and its administrators are notified.
• People whose Apostra access was approved are no longer sent to the request-access form when they sign in while an invitation to their approved account is waiting. Sign-in now tells them they have a pending invitation and to open the invitation email, or ask their organization administrator to resend it. Submitting the request form again after approval also explains that the request was already reviewed and points to the invitation email or the account selector.
• Storefronts on the Storefront-built and Agent-supplied paths now also return products that let the buyer set age targeting when a request carries an age range. For a request such as ages 18-55 sent in targeting_overlay.demographics.age, a product that declares age targeting support (overlay_support.demographics, within any demographic_targeting.age bounds it declares) is now returned, and the seller applies the range when the media buy carries it. Products whose fixed audience is exactly the requested range are returned as before. A product whose fixed audience is wider than or overlaps the range, such as 18-65, or that reaches people whose age is unknown when the request excludes them, is still left out, and so is one whose fixed audience is narrower, such as 18-34, until a media buy can carry that narrower range. Campaigns with a saved age range therefore get products from more sellers.

​

5.1004.0 — October 9, 2026 at 10:27 PM UTC

• From chat, a Developer account can register a sales or creative agent and update it.

​

5.1003.0 — October 9, 2026 at 9:50 PM UTC

• In the brand profile preview, an advertiser’s brand now reaches creative generation in full. Creative sessions build the logo, colors, voice, and tagline from the advertiser’s brand profile, and our own creative generator also follows the brand’s voice rules (do’s, don’ts, attributes) and disclaimers. Third-party creative engines still receive only the four AdCP brand fields, and sellers receive nothing from the profile. A V3 get of an advertiser with include: ["brandProfile"] returns a summary of the profile and says whether each value was published by the brand or inferred. An advertiser whose saved brand holds only a name and url is re-resolved the first time its profile is read. The preview is read-only. It is available to accounts with Creative Engines access; for every other account nothing changes.
• Restore legacy FreeWheel managed ad-server connection details when older stored records do not include a client ID.

​

5.1002.0 — October 9, 2026 at 9:02 PM UTC

• Reading a media buy right after reading its campaign no longer fails with an internal error. A buy that ended without delivering now also reports its real number of failed creative syncs in its warning, instead of saying the number could not be read.
• Confluence pages inside your selected space or page tree now import as Library Materials. Page edits add revisions to the same Material and keep the Confluence page link as source provenance.

​

5.1001.0 — October 9, 2026 at 8:35 PM UTC

• In Account → Integrations, you can connect a company cloud drive, choose a folder to sync, and review new files in the Library. Connections are read-only and new files arrive as Drafts.
• Confluence Library Sync now downloads PDF, text, and CSV attachments through Atlassian’s attachment API. The sync follows its signed media redirect without sending the Confluence access token to the media host, so attachments no longer fail and exhaust retries. Failed items now retain a safe call-and-status diagnostic for support.
• Fixed campaign creative replay so buyers do not get duplicate or mismatched creative approvals when a seller requires a specific ad format. Buyers do not need to change anything.
• Ground Murph’s required research sources through a typed, language-independent router decision.
• Microsoft 365 Library sync now retries unexplained Word conversion rejections and skips documents that Microsoft explicitly reports as unsupported. No action is needed.

​

5.1000.0 — October 9, 2026 at 7:40 PM UTC

• When you set or rotate a sales-agent source’s credentials in chat, or from the setup step in Source Diagnostics, the form now appears in the language your chat app is set to. That covers German, Spanish, French, Italian, Japanese, Korean, Dutch, Brazilian Portuguese and Simplified Chinese, including validation, save and authorization errors that previously appeared in English. Source names and endpoint addresses still show exactly as entered. Nothing to change on your side.

​

5.999.2 — October 9, 2026 at 7:11 PM UTC

• Creative sync now finds the booked product on older storefront media buys whose seller only accepts legacy { agent_url, id } format references. Before, every creative on those buys failed with “the selected seller product did not provide one unambiguous legacy format reference”, even when the product listed a matching format. Now each creative goes out on the reference the booked product lists. If the product lists references its creative agent does not define, the error names them. Re-run the creative sync for affected campaigns.

​

5.999.1 — October 9, 2026 at 7:00 PM UTC

• A media buy whose flight ends before the seller ever starts it no longer completes silently. When the seller still reports the buy as pending_start or pending_creatives and no impressions or spend were reported, get_media_buy and get_campaign now return a warnings entry that names the buy, the seller’s last status, and how many creative syncs to sellers failed for its creatives. You also receive one campaign.unhealthy notification per buy with reason: "media_buy_ended_without_delivery". The buy and its campaign still end as COMPLETED. See Diagnosing a stuck media buy.

​

5.999.0 — October 9, 2026 at 6:42 PM UTC

• Listing storefronts now accepts search as another name for the name filter, the same parameter listing advertisers uses. Before, GET /api/v2/buyer/storefronts?search=… (and the list_storefronts operation with params.search) ignored the filter and returned the unfiltered marketplace, so an agent searching for one storefront got every storefront back. It now returns only matching storefronts. When you send both, name wins. Calls that use name behave exactly as before, so there is nothing to change on your side.
• Developer-account administrators can use Build an agent in chat to view the Agents they own, start Sales or Creative setup, and review an unclaimed Agent. Buyer setup stays in the build guide for now. No action is needed until an administrator wants to build an Agent.
• Product discovery now distinguishes a source timeout from an eligibility skip or an empty catalogue. If a seller accepts a request but cannot finish within the wait, retry with a longer wait; the timeout does not mean no matching products exist.
• When your buyer agent answers in a Slack channel, bulleted lists inside a quote now show as bullets instead of raw dashes. If the agent’s answer has nothing Slack can display, such as a lone divider line, the thread now says the agent did not return a reply, and your next message in that thread gets a normal answer. Before, the thread could stop answering. Nothing to change on your side.
• Uploaded video and audio creatives now carry Apostra’s impression tracker, and its start, quartile, and completion trackers, to sellers whose format declares tracker slots for them. They are sent as AdCP pixel_tracker assets in the impression_tracker, start_tracker, first_quartile_tracker, midpoint_tracker, third_quartile_tracker, and complete_tracker slots. Playback events are sent as event: custom with custom_event_name set to start, first_quartile, midpoint, third_quartile, or complete until AdCP standardizes them. Advertiser impression trackers are sent in the same impression_tracker slot, after Apostra’s; if the seller’s slot cannot hold both, the advertiser’s trackers take it and Apostra’s impression tracker is left out. Sellers whose formats declare none of these slots see no change.
• In a new pilot, when a buyer’s own measurement records show how a seller’s media buy is doing on a vendor-measured goal with a minimum-rate target, the platform sends that seller a score on the buyer’s behalf. This is AdCP’s provide_performance_feedback, where performance_index is the buy’s rate divided by the target: 1.0 meets the target, and there is no upper limit. The seller receives the score, the vendor and metric, and the days measured. It never receives the buyer’s outcome counts, records or measurement source. A revised score names the one it replaces. Scores go only to the single seller behind a buy whose agent supports AdCP 3.2 and accepts performance feedback. Cost targets, campaign-wide results and buys split across sellers are never scored.

​

5.998.0 — October 9, 2026 at 6:08 PM UTC

• Product discovery now tells you when a media partner was skipped because your account with it is not connected, instead of calling it ineligible. In get_products, such a media partner’s storefront_results[] row now reports outcome.reason_code auth instead of eligibility, with a suggestion that says how to connect the account. The text summary names it and says how to fix it: open Media Partners, connect or reconnect the account, and map it to the advertiser. It is no longer counted as queried. discover_products and browse_discovery now list these media partners in connectionIssues alongside expired connections. request_proposals reports them as skipped with reason auth and the same fix, instead of eligibility or coverage. Media partners that are truly ineligible still report eligibility.
• If your organization has no admin, the Terms of Service screen now has a Request organization admin button. Select it to ask to become your organization’s admin. Apostra staff review the request, and once it is approved you get an email invitation. Accept the invitation, then accept the Terms for your team. Each person can file one request, and nothing changes if your organization already has an admin. Developers: POST /api/v2/accounts/request-organization-admin files the same request, and the current-user responses include a new organizationHasAdministrator field.

​

5.997.0 — October 9, 2026 at 5:32 PM UTC

• Review your company’s cloud-drive connections in Account → Integrations, including their status, owner, selected folders, and available files. No action is required for existing connections.
• Apostra now keeps your sales-agent call history with a 90-day limit on call bodies. Every call stays available indefinitely with its IDs, status, outcome codes and debug details, so a lookup by task, debug or correlation ID still finds it. The request and response bodies are removed once a call is 90 days old, and the Diagnostics Calls view and the agent debug calls API (bodyPruned: true) say so instead of showing an empty exchange. Account sync requests keep their bodies. Nothing changes on your side. See Apostra agent debug calls.
• A media buy that a seller rejected now reports errorCode: source_rejected (owned by the seller) with the message “The seller rejected the media buy.”, instead of platform_error with “Media buy execution failed before seller acceptance”. A buy the seller’s storefront refused before contacting its inventory, such as a product that is no longer available or an expired currency quote, now reports that specific code. When the seller’s own reason can’t be shown, contact support with the mediaBuyId.
• In inventory-source diagnostics, a failed creative sync now names its reason in sourceHealth.writes[].topFailure. When your sales agent fails a creative sync with an AdCP error code, that code is the errorCode, with the recovery class it reported. That holds whether a reviewed creative was being sent to it or a buyer’s creative sync was passed through. If it failed with a message and no code, errorCode reads source_sync_failed, and the message is in the operation’s details. Before, most of these failures had no code and did not appear in topFailure. Nothing to change on your side.
• Look up brand in the Create advertiser form now answers within a few seconds. A domain whose brand takes longer to read shows the usual “no registered brand found” note instead of a long wait, and looking it up again a moment later can return the details. Creating the advertiser still reads the brand in full.

​

5.996.0 — October 9, 2026 at 4:32 PM UTC

• The plan chooser in chat now names the plan your organization is on before an administrator chooses one, for example “You’re on Connect & Buy until you choose a plan.”

​

5.995.0 — October 9, 2026 at 4:08 PM UTC

• You can now switch on a Source served by your own sales agent without the retired production certificate. Offering that agent to other organizations still requires Partner Program certification.
• Direct AdCP 3.0 and 3.1 agents can now use an approved account on a seller that has moved to complete AccountKey mapping. Send the account’s opaque account_id on its own to list accounts, browse the seller’s catalogue, sync creatives, and create, read, update, cancel, and measure buys. Each call checks your organisation, advertiser, and current authority again, and refuses an account that is not yours. Accounts that one credential was already approved for keep working for that credential only, and a brand and operator that is not one of them is refused before anything is written. An account that mixes account_id with brand or operator is still rejected as invalid.
• Fixed a bug where a paced media buy whose flight ends before midnight UTC — for example, a flight set to end at 23:59 in Lagos or another time zone east of UTC — was rejected by the seller because its last package ended after the buy. Each package now stays within the media buy’s own start and end times.
• An organization with no accepted plan in force is now held to what its default plan covers when it adds, restores or moves in an account. For example, a Buyer organization on its default Connect & Buy plan needs an Agentic Media Company plan before it can add a Seller Account. Accounts it already holds are never removed. Organizations that no default plan covers, such as one holding Buyer Accounts beside a Listing-only storefront, are unchanged.

​

5.994.0 — October 9, 2026 at 3:37 PM UTC

• Verify via AAO in your account’s domain settings now works for seller accounts and for organization admins verifying a child account’s domain. Before, it was refused for anything but a buyer account. Sign in to AAO with an email on your registered domain and the domain is verified. Nothing else to change on your side.
• You can now connect a sales agent that authenticates with the OAuth client-credentials grant: set authenticationType to OAUTH_CLIENT_CREDENTIALS and pass an auth object with your token endpoint (public HTTPS), client ID, and client secret when you create or update an inventory source through POST or PUT /api/v2/storefront/inventory-sources or the storefront MCP tools. Apostra fetches an access token before it calls your agent and requests a new one at least every five minutes, or sooner if it is about to expire, so no one signs in and there is no refresh token to manage. Your client secret is stored encrypted and never returned. Supply the credentials when you create the source, because the in-chat credentials form can’t collect them yet. Existing inventory sources and other authentication types are unchanged, and you have nothing to do for them. Setup details, including optional scope, resource, audience, and client authentication settings, are in the “OAuth client credentials” section of the Create inventory source page.
• open_connections_page takes optional connectionId and accountId, so any agent or host can open Media Partners on one connected ad account. For accounts with event-source seller sync turned on, that account shows the pixels, datasets and audience lists the media partner already holds there, and each can be mapped to one of your own event sources or audiences, used to create a new event source, or left on that storefront. On V3, each accounts[] row of get(kind: "connection") carries inventorySummary for those accounts: its event source and audience counts and when it was last read.
• Approving your account’s domain now clears the “Brand domain” go-live check right away. Before, an approval made through Verify via AAO or an email-match save could leave the check pending until something happened to read your storefront, and there was nothing to wait for.
• Plan & Billing now names the plan your organization is on before an administrator chooses one. Instead of “No paid IU plan”, the Plan & pricing tab shows your default plan, for example Connect & Buy, with a note that nothing is billed under it until a plan is chosen.
• Selected sellers in the Merchandising Simulator beta can choose “Run this brief again on my current setup” from a Proposal Pass practice result to rerun the same brief on a fresh snapshot of their Playbook, rules, pricing and inventory, and see it next to their last completed run. Nothing to change on your side: runs never touch your live setup and buyers never see them.

​

5.993.0 — October 9, 2026 at 2:32 PM UTC

• When your sales agent manages buyer accounts, the Buyers view now shows the agent’s decision on each buyer: “Accepted by”, “Rejected by” or “Waiting on” followed by the agent’s name. The page opens with a line saying these are the buyers that came through your agent and its decision on each. A request that was already waiting on you still shows “Needs review”, and storefronts where you manage buyer accounts yourself look the same as before. Nothing to change on your side.

​

5.992.0 — October 9, 2026 at 2:05 PM UTC

• An organization with no accepted plan in force, because it never accepted one or its plan ended, is now on its default plan: the public plan with no monthly commitment that covers what it holds (Connect & Buy, Listing, Storefront agent or Developer). The v4 IU Rate Card read reports it as defaultPlan, and it is null while an accepted plan is in force or when no such plan covers the organization. Nothing is billed under a default plan, and nothing changes for organizations that already have a plan.
• Draft creative sync now uses the authenticated advertiser identity when it resolves a confirmed seller account.

​

5.991.0 — October 9, 2026 at 1:39 PM UTC

• When you edit an advertiser whose country scope has not been set yet, you now choose between All countries and Specific countries as a single decision. Switching to All countries no longer discards the countries you already picked - they come back if you switch to Specific countries again. Saving stays blocked until you make a choice.
• Confluence Library sync now imports supported attachments within the provider’s 64 MiB download limit and records larger attachments as unsupported instead of retrying them.
• Brand files that describe their voice in detail (voice, attributes, dos and don’ts) are now kept when a brand is linked to an advertiser, instead of the whole file being skipped; the API still returns the brand’s tone as the voice text. The Brand and Advertiser guides now also say that each advertiser keeps its own saved copy of its brand, which refreshes only when the copy is missing or you link a different brand.
• On a pass-through storefront, the storefront’s sales agent now always does buyer review. A buyer’s account request always goes to the agent, never to the seller for local review. If the agent can’t take account requests (it doesn’t list both sync_accounts and list_accounts, or it requires operator authentication), the request fails with CONFIGURATION_ERROR and a message saying so, rather than waiting on the seller. It’s terminal: buyers shouldn’t retry it. Sellers with such an agent should add those tools to it; account requests then go to it.

​

5.990.0 — October 9, 2026 at 1:17 PM UTC

• When a buyer agent asks a platform seller such as Meta, TikTok or Snap for its wholesale catalogue directly, any brief text sent with the request is now ignored, as AdCP requires. The seller returns its full catalogue instead of a shortlist planned from the brief. Requests that ask for brief mode, and wholesale search through Apostra, are unchanged. Nothing to change on your side.
• Buyer agents can be created and managed from your organization’s Developer account.
• Connected Library source responses now identify the signed-in provider account, group its folders together, and show whether the current administrator can manage that account. Existing folder responses continue to work unchanged; older connections remain separate and need reconnecting.
• Brief Acceptance now reads your written policy and submitted ads in any language. When it cannot reach a clear decision, the media buy goes to human review instead of being auto-approved.
• Embedded sales agent 1.63.4: close out ended GAM buys whose line items never had a creative, omit null optional product objects.

​

5.989.0 — October 9, 2026 at 12:46 PM UTC

• Eligible sellers can open the Merchandising Simulator from their agent interview and from a practice result.
• The Advertisers page now tells you up front that you can add sandbox advertisers right away, and that adding live advertisers needs your company’s identity confirmed in Buyer Setup. Add advertiser stays available.
• Seller and buyer setup messages now say Apostra instead of Scope3. This covers the domain attestation step, the settlement currencies and pricing Apostra can clear, seller source diagnostics, and the storefront readiness checks.
• Storefront readiness now reads billing only from your own sales agents. Before, a storefront whose agent requires operator authentication and declares operator billing could still be blocked by supported_billing_declared with “Declared billing: agent”, because a billing default we cached on our side overrode your declaration. The blocker now clears on its own, and buyers can connect with operator billing. You don’t need to do anything.
• The Creative Library now highlights Drafts waiting for review and opens the right Draft list.
• When “Verify via AAO” on your account’s domain settings doesn’t succeed, the message now says why. If the sign-in pop-up was blocked or closed, it tells you to allow pop-ups and try again. If AAO has no identity that can verify the domain, it points you to “Request manual review”. Only an unexpected failure shows the generic “try again” message. Nothing to change on your side.
• Agent inventory, pages, and docs no longer say you must register a production revision before we can test or certify your agent. Live certification judges each use case with sandbox test buys, tracker evidence, and seller reports; registration remains available for change detection.
• Refining, selecting, or saving a variant from the variant gallery now works for creative sessions that belong to an advertiser’s Library, which previously failed with “The action failed.” The gallery also shows the real reason when an action is refused, with what to do next, instead of a generic message.
• The in-chat Create advertiser form now explains Look up brand: it is optional, previews the brand for a domain and fills in the advertiser name, and you can edit everything. The result says what it found and whether it filled in the name, and a failed lookup says you can retry or skip it. Lookups for domains the registry doesn’t know yet now wait up to 70 seconds, instead of 20, before reporting a failure.
• The Advertiser name field in the Add advertiser form now shows a single required asterisk instead of two.
• Fixed a bug where launching a campaign with creatives could fail on a seller whose own sales agent books into its Google Ad Manager or FreeWheel account, with the error “seller-library revision could not be verified”. Retrying did not help. Creatives now sync to that seller, and the buy proceeds once the seller accepts them.
• Creatives and new media buys now reach third-party sellers that identify your account by your brand and operator domains, including when the request is made under your seller account on that storefront. Before, these requests failed with “This storefront account is not linked to an active account on the inventory source.” and nothing reached the seller. Now they send your brand and operator domains, as AdCP allows. Sellers that issue account IDs, either through sync_accounts or operator sign-in, behave as before. Nothing to change on your side: run the creative sync again for affected campaigns.
• The Submit request button in the domain verification review form now keeps its normal width instead of stretching across the full form.
• Microsoft 365 Library sources now import Word documents reliably. Nothing to change on your side. A document Microsoft cannot convert to PDF is skipped instead of being retried.
• Creative sync can now reuse a confirmed seller account for a draft buy before its seller route exists.
• Connected Library source cards now distinguish Materials still available from the selected source from retained copies whose source file was removed.
• Reviewed creatives now keep the sales agent account chosen when they are submitted. Approval no longer sends a Storefront account that the sales agent cannot recognise, and source account errors keep their original error code.
• When a seller rejects an update_media_buy request, the error response now includes the seller’s actual rejection reason (code, message, and suggestion) instead of a generic “seller synchronization did not complete” message with no detail.
• V3 search responses now match the output schema the tool publishes. Agents using MCP clients that check that schema, such as Claude, no longer get “Structured content does not match the tool’s output schema” in three cases: listing Library documents when every result fits on one page (including an empty or archived list), searching without kind, and loading a Library browse page. A last page now omits nextCursor instead of returning null. In the published schema and the generated SDK types, objects is now one of three shapes: a single kind’s page, a Library browse page, or the sections of a search without kind. SDK code that reads objects.results should first check objects.kind.
• Seller Setup steps now open their destination right in the chat instead of a new browser tab. Add publisher domains and Review publisher authorization open the Property Roster, Review AI Business Rules opens Business Rules, Review selling behavior opens the Playbook, and Add payout details and Fix payout currency open Plan & Billing. Steps that point at an ad-server source or the approvals queue still open in a browser tab.
• When your sales agent manages buyer accounts for your storefront, the Buyers view is now read-only everywhere, not just in the list. The agent reviews buyers, so the drawers no longer offer to approve, map an account, or assert or revoke billing readiness, and the API refuses those requests. A request that was already waiting on you before the agent took over can still be accepted or declined.
• Buyer Setup now asks for your company’s identity in plain terms: the domain of the company that runs your account, and whether this account is the whole company or just one team. Sellers use it to recognize you. Sandbox advertisers don’t need it; live advertisers and real buying do. Once you’ve confirmed it and created your first advertiser, the domain and your choice become read-only. The step is now called Company identity, and its status messages say what to do next. Nothing changes in how the step works, and there is nothing to do on your side.
• When a seller rejects a media buy launch with a structured AdCP error, the buyer-facing error now keeps the seller’s suggested fix and per-source detail instead of discarding them, and a managed-account-linkage rejection is attributed to the seller (not reported as a generic platform error).
• Embedded sales agent 1.63.3: book GAM video line items with a videoMaxDuration their creatives fit, book video-only GAM packages as VIDEO_PLAYER line items, clear new pydantic-ai and datamodel-code-generator advisories in Security Audit, report inventory sync as not applicable for adapters that don’t sync inventory, close out ended pending GAM buys that delivered nothing.
• You can now create a sandbox advertiser before you’ve confirmed your company’s identity, from the Create advertiser form or the v2 advertiser API. Before this fix, only v3 save_advertiser allowed it. If your identity isn’t confirmed yet, the form creates the advertiser as sandbox-only and links to Buyer Setup. Updating and archiving a sandbox advertiser work the same way on every surface. Live advertisers still need your identity confirmed first, and plan and Terms readiness still apply to every advertiser. Nothing to change on your side.
• Search connected cloud folders, pages, and spaces when choosing a Library source.
• Request manual review in your account’s domain settings now works for seller accounts and for organization admins managing a child account. Before, it failed with “Failed to submit request.” Your request now goes to Apostra support, the same queue as asking your agent, so someone reviews your domain and follows up. Use it when no one on the account can verify with an email on the domain. Nothing else to change on your side.
• Find Drafts, brief gaps, and the Library requirements checklist together at the top of Documents.
• Every seller now has Sessions: a timeline, for each buyer, of your RFP threads and your own Murph conversations about that buyer, opened from the buyer in the Buyers tab. Conversations between a buyer and their own agent stay private. Nothing to turn on.
• Creative sync and media buys on a seller’s own sales agent no longer stop with “account linkage required” when the seller already accepts your account. If no account is on file for you, we now ask the seller for it at that moment and carry on with the account it returns. You only see the linkage message when the seller turns the account down or holds it for approval.
• V3 save_media_buy no longer picks a price for you when you book products directly with sellerId and products. If a wholesale product offers more than one pricing option and you leave out pricingOptionId, the call is refused and the error lists the option ids, so you can choose one; wholesale_product search rows show them too. A product with a single pricing option still books without pricingOptionId, and accepting a proposal is unchanged.

​

5.987.0 — October 9, 2026 at 9:34 AM UTC

• Developer accounts now show their purpose and owned agents in V3 MCP, and you can switch into them.
• Agentic Media Company plans (Storefront agent, Storefront agent + Distribution, Enterprise — Storefront agent), Enterprise and Global Market Maker now hold up to 5 accounts under one organization. Business Manager still holds up to 100; Connect & Buy and the Listing plans hold one. Every account counts toward the limit, archived ones included. An organization that already holds more accounts than its plan allows keeps all of them, but cannot add another until it moves to a plan with room. The limits apply once your organization accepts the current Rate Card revision in Plan & Billing.

​

5.986.0 — October 9, 2026 at 9:22 AM UTC

• The Agent page now names the account check for what it measures, recognizes canonical and legacy creative-format declarations, and puts a missing required declaration such as sync_accounts first in Next step.
• Case studies added to Product Marketing now require a review that shows every saved detail. An assistant cannot add or alter a case study without your approval.
• Related to AI-12340: tighter case-study matching remains a follow-up.
• Related to AI-12341: sellers will be able to correct or withdraw a case study in a follow-up.
• Creative agent builders can run AdCP’s conformance tests from the Agent page at no cost. This does not change the seller experience.
• Organizations whose accounts are all Developer accounts can now choose the Developer plan in Plan & Billing, with no monthly commitment. It covers registering, testing and certifying your own agents, and the Agent page; buyer and seller tools are not included, and any IU-rated activity is billed at the standard overage rate of $5, €4.50 or £4 per IU. To operate agents for other companies you need the Certified Agent Developer plan, and to add a Buyer or Seller Account you need a plan that covers it. Nothing changes for an organization until it chooses the plan.

​

5.984.0 — October 9, 2026 at 7:56 AM UTC

• Build an agent now offers sales and creative agents. Buyer agents use buyer-agent setup. The V2 API continues to accept legacy Signal and Outcome agent records for compatibility, but they are not offered in Build an agent.
• Sellers with access to Sessions can identify evaluations and media buys by the work they ran, rather than opaque record IDs or generic saved-session labels.
• Buys and creative syncs on storefronts run by an Apostra-managed sales agent for Google Ad Manager now reach the advertiser the seller mapped. Before this fix, a buy from a mapped buyer account was sent with the Google Ad Manager advertiser ID as the account, and the sales agent rejected it with “Account not found”. Apostra now creates or updates the sales agent’s own account for the buyer, maps it to the seller’s chosen advertiser (the default or a dedicated one), and books on that account. Nothing is created in Google Ad Manager. This covers agent-billed accounts; operator- or advertiser-billed accounts on these sources are refused with source_account_not_bound rather than sent. Sellers see the buyer’s account active with that advertiser in their sales agent. No action is needed from buyers.
• Organizations whose accounts are all Developer accounts now report the DEVELOPER product in v2 billing and Rate Card reads (eligibleProducts and eligibleWorkloads), as announced in the previous release. Organizations that also hold Buyer or Seller accounts are unchanged.
• The product discovery card no longer gives up with “Results stopped updating after repeated connection errors” when storefronts are still answering a product search. When results are still being saved, the card now keeps waiting. When the search was started with get_products, the card now says to continue in chat, where get_products returns the complete results. browse_discovery on a get_products execution now returns 409 CONFLICT with reason discovery_read_requires_get_products instead of failing or starting a second search, so read those results with get_products and since_revision.
• When Apostra refuses an action because of your organization’s plan, the refusal now says the plan is the reason and shows how to switch plans. In the app, the Accounts pane and the restore-account dialog link to Plan & Billing → Plan & pricing. API and MCP refusals add details.planSwitch (nextStep: "switch_plan", who can act, and the Plan & pricing link) so an agent can tell you to switch plans instead of guessing. This covers account limits, plans that do not cover an account change, custom modular inventory sources, operating agents for clients, and Sellers who have not selected a plan. Error codes are unchanged.
• An organization can no longer lose its last admin. Removing or demoting the only admin of an organization, or of a standalone account that still has members, is now refused with a message that says to add another admin first. A SUPER_ADMIN counts as an admin, and two admins removed at the same moment can no longer both succeed. Through the tools API the refusal now comes back as a correctable INVALID_STATE (HTTP 422) instead of an internal error.
• Every organization now sees its IU (Intelligence Unit) account on Plan & Billing: the plan you are on, your included allowance and balance, usage this billing period, overage so far, and a month-end forecast. Before this, the panel was hidden for most organizations, so a plan you had accepted showed no balance or usage. Nothing changes about what you are charged, and there is nothing you need to do.
• When you sign a webhook to us with RFC 9421 message signatures and we can’t load your get_adcp_capabilities or brand.json, our response now tells you whether redelivering will help. A timeout, a connection failure, or an HTTP 5xx, 408 or 429 still gets a 503, so redeliver. Any other HTTP 4xx, such as a 404, now gets a 401: fix the document first, because redelivering won’t succeed until you do. HMAC-signed callbacks are unchanged. See Signing the webhooks you send us.

​

5.983.0 — October 9, 2026 at 6:38 AM UTC

• Upload a catalog as a CSV or JSON product feed file (up to 5 MB) through the V3 upload Task and it arrives as a Draft, with any rows that failed to parse shown before you save. Save the Draft to use it for building, delivery and your agent, or Discard it. Existing catalogs are unchanged.
• When your storefront starts using the newer buyer-account view, the buyer relationships you already had stay in the seller account list. You can still review requests, choose an account for each inventory source, download the existing export, and finish an export upload you prepared before the change. Nothing to change on your side. This does not affect sellers who have not started using the newer view.

​

5.982.0 — October 9, 2026 at 6:05 AM UTC

• The sign-up page now offers Build agents. Choosing it starts a Developer account on the Agents page. Link ?intent=developer from developer docs.

​

5.981.0 — October 9, 2026 at 5:14 AM UTC

• Files you upload through the V3 upload Task now arrive in your Creative Library as Drafts, with a suggested name and collections to check. Save a Draft to make it ready to use for building, delivery and your agent, or Discard it. Existing content is unchanged, and V2 Buyer tools still upload straight to the Library as before.
• Buyers can request seller accounts before they connect a storefront. If their account setup cannot be verified or is disabled, the request returns ACCOUNT_SETUP_REQUIRED with steps to fix it. Sellers may receive requests from buyers who were previously blocked; no seller setup is required.

​

5.980.1 — October 9, 2026 at 4:29 AM UTC

• Google Ads and OpenAI Ads conversion destinations discovered on a connected seller account can now be mapped to a buyer’s event source. Both adapters were reporting every destination as platform-owned, which silently blocked mapping even though the destination was something the buyer created in their own ad account.

​

5.980.0 — October 9, 2026 at 4:08 AM UTC

• You can test your sales agent’s product discovery from its Agent page without connecting it to a storefront first. It does not change what buyers see about sellers or seller storefronts.
• V3 search and get, in Murph and over MCP, refuse fewer buyer calls. A buyer account’s search and get no longer offer seller-only inputs such as sourceId, filter.sellerStatus, filter.buyerCustomerId, RFP filters, buyerCustomerId, workItemKind, or the listing, identity, and inventory-source includes, and their status and state lists hold only the values a buyer kind accepts. The buyer kind description now says which filter each kind needs, for example filter.campaignId for proposal. Some inputs whose meaning is clear are now accepted instead of refused: docsScope on a search with no docs is ignored, a creative_session search with limit above 100 returns 100 per page, and a filter.status sent with a campaign or buyer media_buy search is read as filter.campaignStatus or filter.phase when it names one of their values. Filter campaigns with filter.campaignStatus and buyer media buys with filter.phase; those are the typed fields. Accounts that span buyer and seller keep every input.

​

5.979.0 — October 9, 2026 at 3:25 AM UTC

• People invited to a Developer account now receive an invitation that says they are joining its Developer account to build and test agents, and land on that account’s Agents page after signup.
• Anyone signing up can choose to build agents and starts in a Developer account with the free agent-builder profile. This does not create a seller storefront or add a paid product. The API accepts this choice now; the sign-up page will offer it in a following release.
• Fixed a bug where launching a campaign with a creative attached could fail on an adapter-connected seller (Meta, Snap, TikTok, and other official adapters) with an internal “seller-library revision could not be verified” error, even though the creative and seller were both valid. Creative sync now correctly recognizes the seller’s own built-in adapter delivery path as a valid route.

​

5.978.0 — October 9, 2026 at 2:45 AM UTC

• Buyers can upload VAST XML tags as ready-made creative drafts in the Creative Library.
• Complete-key buyer account requests now follow the storefront’s existing account-approval policy and payment-terms ceiling. Requests that need seller review remain pending, and live consolidated-billing requests wait for the buyer organization to choose terms.
• The time_budget on the get_products request we send to your sales agent now reflects the time you actually have left when the request goes out. Before, it was calculated before we finished connecting to your agent, so it could be a few seconds longer than the time you really had. The deadline we enforce is unchanged and nothing needs to change on your side.

​

5.977.0 — October 9, 2026 at 1:49 AM UTC

• Media partners that sell through more than one kind of inventory source are now set up for your advertisers automatically, like other partners, instead of staying at Activation deferred. Every partner now decides new accounts the same way whether you connect yourself or Apostra connects for you, so a partner that reviews new accounts shows Waiting on media partner until it accepts.
• Your agent’s capability declarations now check that it can take buyer account requests. Storefronts don’t support operator authentication, so buyers declare their own accounts, and your sales agent must take those requests itself. It must list both sync_accounts, which receives a buyer’s account request, and list_accounts, which lets the storefront read the result back. An agent missing either one shows Takes buyer account requests as not met in the required capability declarations on its Agent page, and is not baseline‑eligible. The operator‑authentication check there now also reads your agent’s production implementation, not only its connected sources.
• Buyer Creative Library collections can now narrow Assets and Creatives to the items saved in your selected collections. Collection filters stay within the advertiser that owns the Library.
• The v2 OpenAPI specification now declares a new product value, DEVELOPER, for organizations whose accounts are all Developer accounts. It will appear in eligibleProducts and eligibleWorkloads, and in a plan’s publicListingApplicability, which now allows up to four products. No response returns it in this release; Apostra starts returning it in a later release. If you generate typed clients from the v2 OpenAPI specification, regenerate them before then so they accept the new value.
• Creative syncs to storefronts that run on the Apostra-managed sales agent go through again. Since the managed sales agent started refusing legacy webhook credentials on 26 August 2026, any sync_creatives call that asked for a completion webhook was rejected with “Legacy Bearer/HMAC webhook authentication is not supported”. Your webhook registration is no longer passed on to the managed sales agent, so the sync is accepted and the per-creative result comes back in the sync_creatives response. Because of that, the managed sales agent does not send a separate completion webhook for these syncs. If a creative is not yet approved in the response, check its status again later. Storefronts connected to other sales agents are unchanged and still forward your webhook and its credential. Nothing else to change on your side.
• Creatives now reach third-party sellers that identify your account by your brand and operator domains rather than issuing an account ID. Before, syncing creatives to one of these sellers always failed with “This storefront requires an account linkage before buys can serve creatives. Run sync_accounts…”, even though the seller doesn’t support sync_accounts and your media buy with them was live. Now the sync sends your brand and operator domains, as AdCP allows, and the seller receives your creatives. Sellers that issue account IDs, either through sync_accounts or operator sign-in, behave as before. Nothing to change on your side: run the creative sync again for affected campaigns.
• Clarify that an empty discovery selection cart means no products have been selected, not that discovery results were lost.
• Murph now calls the customer-facing platform Apostra in its prompts, skills, tool guidance, and fallback replies. This corrects an old Interchange brand reference for both buyer and seller conversations.
• Sales-agent certification now gives your agent 45 seconds to answer get_products, the same limit live buyer discovery uses. Before, an agent that answered in 35 seconds served buyers but failed its certification run on a 30-second limit. Your existing certification stays valid, and the next run uses the new limit. See “How long certification gives get_products” in the Sales Agent requirements docs.
• In the vendor-measured goals pilot, goal progress now judges a vendor-measured goal on your own measurement records when your measurement source declares that vendor and metric, and your records take precedence over the values sellers report. A minimum-rate target is judged on the outcomes your records count divided by the impressions delivered on the days those records cover, so a measurement that arrives weeks late is never set against days it did not measure. Records count for the campaign, media buy or package they name. Progress shows basis: advertiser_measured with the vendor, the metric and the impressions the rate divides by. Sellers never see your records. This applies to get_delivery (V3) and reporting metrics (V2).
• Product discovery no longer waits on a seller’s creative format list for every search. Sellers connected through a registered agent now use the list already stored for their source, and a list fetched during a search is saved for the next one.
• Meta delivery reports and campaign snapshots now recognise valid ad set reporting identifiers that previously caused report reads to fail. Existing API and MCP calls need no changes. Account ownership, package membership and reporting reconciliation checks still apply.
• Direct AdCP 3.0 and 3.1 storefront agents now tell you how to request a new account through the V2 buyer API or MCP tool when their complete account-key rollout cannot create a legacy account. Existing approved direct accounts keep working unchanged.
• get_products on a storefront that sells through several sources now asks up to four of them at the same time instead of one after another, so later sources are no longer left with less of your time_budget than earlier ones, or none.
• Each source still gets the full time remaining, and products come back in the same source order as before. A storefront with a single source behaves as it did, and sources beyond four wait for a free slot. Nothing to change on your side.
• When you change an advertiser’s or a campaign’s click-URL parameters (v2 utmConfig, V3 tracking.macroAdditions, or the campaign tracking-config resource), Apostra now re-sends every affected creative to each seller that already holds it on a live media buy, with the new parameters filled for that buy. You no longer need to re-save creatives to push a parameter change. The re-sync starts about a minute after the change, and edits within that minute go out together; if a seller is still reviewing an earlier copy of the creative, its re-sync waits until that review finishes. A creative whose click URL comes out the same, for example because the campaign or the creative itself already sets that key, is not re-sent. The update response includes creativeResync (creative_resync on the tracking-config resources) with how many creatives and sellers are being re-synced. Each seller decides whether the change needs re-review, and its decision shows on the creative just as it does after a creative edit; the copy already running keeps serving until the seller says otherwise. Draft and ended media buys are not touched. Nothing to change on your side. See “Click-URL parameters” in the Advertiser guide.
• Sellers now have 45 seconds to answer get_products when Apostra requests proposals for a campaign, and when a call to a connected seller is relayed through the partner-agent relay. Both used 30 seconds before, which cut off sellers that normally answer in 21 to 35 seconds once connection setup is counted. Other relayed tools keep their 30-second limit. Your wait for request_proposals does not get longer: it still schedules the sellers and returns, and a slow seller’s result arrives on a later read of the request.
• When Apostra closes a creative review itself, your creative’s status now says why instead of showing a generic rejection.
• Today this covers one case: a creative that declares no single format can never be delivered, so its review is closed with “Expired: this creative declares no single format, so it can’t be delivered. Resubmit it with a format.” That text appears as the rejectionReason on the publisher’s sourceSyncStatus[] entry, as platform_links[].rejection_reason on the creative, and as the message of its creative_rejected error. A rejection the publisher makes still reads “Creative was rejected by the storefront operator.” Nothing changes on your side; resubmit an expired creative with exactly one format.
• The Merchandising Simulator can create scenarios again for a storefront whose products declare the targeting buyers may set. Before, capturing that storefront’s inventory failed with “The storefront inventory could not produce a valid replay snapshot.”
• Source diagnostics no longer present a seller call that got an HTTP success but never answered as a fast success. Each tool request now shows what the call for the same session recorded (logicalOutcome, for example that it timed out), a plain-language summary such as “Response headers arrived after 200ms (HTTP 200), but the call timed out after 25.9s with no answer”, and whether its session was never closed (sessionTerminateMissing). These fields are added to the existing response; no existing field or value changes.
• V3 save_event_source and save_audience can now remove a seller account’s mapping. Send the account in sellerAccounts as { "accountId": "...", "unmap": true } instead of naming a sellerId. Unmapping ends Interchange’s mapping on that account only. It never deletes or changes the pixel or audience on the seller’s account, and it works after the connection has been disconnected. The account drops out of sellerAccounts on the next read, and you can map it again later, when it starts again as pending. Unmapping an account that is not mapped changes nothing. While a live media buy still uses the mapping, the unmap is refused with INVALID_STATE and names the media buys; unmap the account once they have ended or been canceled. Mappings you send without unmap work as before.
• Validation errors from storefront tools now name the failing field the way the AdCP specification does (idempotency_key rather than /idempotency_key) and list each problem separately with a JSON pointer. A request with very many problems reports up to 100 of them and says the list was cut short. Storefronts now report AdCP 3.2.3 as their 3.2 protocol version.
• get with kind: "billing" now answers members of an organization’s account instead of refusing them. Before, a member of an account whose billing is managed by its organization got Billing for <account> is managed by the <org> organization. Only an administrator of <org> can view or change it. as an access error, so agents and Murph treated it as a failure. Now the read succeeds and names the organization that manages billing and who can change it (an administrator of that organization), the same answer Plan & Billing shows. Organization administrators still get the full billing readiness read.

​

5.976.0 — October 8, 2026 at 8:09 PM UTC

• Fixed product discovery failing after account setup with sellers that use brand and operator account references. Discovery now preserves that reference instead of replacing it with an internal account ID the seller may reject.
• Source diagnostics now names the agent behind a managed ad-server source. A source that Apostra’s managed sales agent serves used to read “No agent is connected to this source”. It now names Apostra’s managed sales agent, and sourceHealth.identity.agent carries its tenant as id. A managed source whose connection is deactivated still names no agent. See Diagnose third-party sales agents.
• Source diagnostics reads more clearly in three places. When a health check, such as a stale cache, makes an operation degraded and the window counted no calls, the row now gives the check’s finding as the reason instead of “0 calls · 0 failed”. When an activated source shows Receives buyer requests next to Setup incomplete, a line explains that incomplete setup stops requests only until a source is first activated. And every time on the page now shows its time zone. See Diagnose third-party sales agents.
• Each operation in your inventory source diagnostics now names who runs the source in owner: apostra when Apostra runs it, operator when a third-party agent’s operator is named by a provider binding, or null when no binding names anyone yet. It tells you whom to contact about the source, not who caused a particular failure. Nothing changes on your side. See Diagnose third-party sales agents.
• In the v3 MCP tools, the search filter.status list contains every kind’s statuses, some in both upper and lower case. search now reads a listed value that differs from the requested kind’s own status only in case as that status. For example, search({"kind":"inventory_source","filter":{"status":"pending"}}) now returns pending inventory sources instead of an error saying the status must be uppercase, and a library-request search with OPEN reads as open. A value that is not a status of that kind in any case is still rejected, and a search kind with no status filter now says to remove filter.status. For get, the include field description now says that Seller products need a buyer advertiserId. When a call asks for products without one, the error says what to pass, or, in a Seller Account, to list your own products with search({"kind":"wholesale_product"}). Asking for products on any other kind now names the kinds that serve them.

​

5.975.0 — October 8, 2026 at 7:33 PM UTC

• Murph answers faster on accounts enrolled in the Haiku responder canary. On those accounts, Murph runs on Claude Haiku 5.5 instead of Gemini 3.8 Flash, which in our tests made fewer failed tool calls and answered in about a third of the time at the same quality. If Haiku is unavailable, Murph finishes the answer on Gemini with the same tools, so you still get a grounded answer. Nothing changes in how you use Murph, and the V3 tools are unchanged for every MCP client.

​

5.974.0 — October 8, 2026 at 6:31 PM UTC

• The Sales Agent docs now say when Apostra calls your Agent’s sync_audiences and sync_event_sources. If get_adcp_capabilities declares media_buy.audience_targeting or media_buy.conversion_tracking, we list the audiences or event sources on each account a buyer connects, about once an hour, in discovery mode, so nothing on your side changes. When a buy uses an event source a buyer mapped to one of yours, we read your list again to confirm it. Agents that declare neither are never called for this. Audience pushes still use sync_audiences with members, and we don’t forward log_event yet. Nothing to change on your side. See “Audiences and event sources” in Sales Agent requirements.
• If Apostra sends you a private offer link, open it, sign in or sign up with the exact email it was sent to (only administrators of the organization’s billing account can claim it), then add the offer. Plan & Billing then shows the offer and its proposal, on screen and as a PDF of the same version. Adding never accepts the offer, charges you or asks for payment; accepting and setting up payment are separate steps. Each link works once, only for its recipient, and expires after 14 days, or up to 30 if Apostra sets it. If a link fails, for example because it expired, was already used or was opened with a different email, the page says why and what to do next. If your organization doesn’t yet have the account the offer is for, the page says our team will follow up, and the link still works once that’s resolved.
• Browsing a seller’s full catalog now works for sellers that sell through their own sales agent. When you ask such a storefront for its wholesale catalog (buying_mode: "wholesale"), Apostra now forwards the request to the seller’s sales agent and returns that agent’s products as it lists them. Before, these storefronts returned no products. Sales agents that don’t offer a wholesale catalog still return none.
• Breaking change to source health owner and waitingOn.party values: the value that names Apostra is now apostra instead of scope3. If your integration reads or matches on scope3 there, match apostra instead. It changed in the source health object’s health[].owner, diagnosis.owner and diagnosis.findings[].owner, and in waitingOn.party on its operations and on pending media buy operations. The other values (seller, operator, buyer) are unchanged, and so is the deprecated top-level diagnosis.owner, which still says scope3. See Diagnose third-party sales agents.
• Each row of the V3 search for wholesale_product now carries pricingOptions: the product’s prices exactly as the seller declares them in AdCP (pricing_option_id, pricing_model, currency, fixed_price or floor_price). Pass the chosen pricing_option_id as pricingOptionId to save_media_buy when booking a product from the search, instead of the platform picking one for you.

​

5.973.0 — October 8, 2026 at 5:42 PM UTC

• If you haven’t chosen an account approval setting, your storefront now accepts new buyer accounts automatically when the buyer asks for net 60 or shorter payment terms, prepay, or no specific terms. Until now, every new account waited for your approval. To keep reviewing each one, ask Murph to set account approval to manual, or use PUT /api/v2/storefront with accountApproval: "manual". Longer terms still go to your review queue on the Buyer Account Mapping page, and requests already waiting stay there. Accounts you’ve already decided are unchanged. Media buy and creative approval are separate settings and still default to manual review.
• Buyer agents can now be granted and reach only advertisers your own organization owns. An advertiser another organization delegated to yours is no longer listed for an agent, and the agent can no longer select it, read it, read its campaigns or their delivery, or be granted access to it: those requests are refused with ADVERTISER_OUTSIDE_ORGANIZATION or agent_no_advertiser_access. An agent never reaches more than your organization’s own users can. Advertiser delegations themselves are unchanged for the people in your organization, and an existing agent grant on a delegated advertiser stays in place, inert, until an administrator next saves that agent’s access.

​

5.971.1 — October 8, 2026 at 4:50 PM UTC

• Empty discovery results now explain when a seller failed or has not finished, instead of incorrectly blaming missing connections or suggesting that you change the brief. Seller outcomes and available continuation steps remain available in the response.
• Approving a creative that can’t be delivered because of its format is now refused up front, instead of being accepted and then failing delivery.
• A creative must name its format with exactly one of a legacy format_id or a canonical format_kind. Some creatives submitted before format checks existed name neither, and a creative that names both can’t be delivered either. Approving one through the review queue, the API, MCP, or its approval work item now returns 400 VALIDATION_ERROR with field: "format_kind" and an explanation. No decision is recorded and the review stays pending. Ask the buyer to resubmit the creative with exactly one format, or reject it. Rejecting still works as before, and creatives that name one format are unaffected.
• Sales agents now have up to 45 seconds to answer a product discovery request, up from whatever was left of the 30-second buyer wait, which cut slow sellers off after as little as 19 seconds even though they normally answer in 21 to 35 seconds. The 45 seconds start when Apostra sends the request and include connection setup. It applies to progressive discovery (the default for discover_products in chat) when you set no waitSeconds or waitMode: "long". Your wait does not get longer: the first response still returns within a couple of seconds with the sellers that have answered, and a seller that answers after your roughly 30-second wait lands as a later revision. A waitSeconds you set is still used as given, so waitSeconds: 20 gives each seller 20 seconds. Discovery that is not progressive keeps your wait as the seller’s limit. The seller setup test and the storefront planning check also wait up to 45 seconds instead of 30.

​

5.971.0 — October 8, 2026 at 4:30 PM UTC

• Account presences now show what each pixel, dataset or audience on a connected seller account is, whether it works, and whether one of yours is mapped to it. Each row carries the seller’s name, a sellerReport in AdCP’s own shape (for an event source, its event types, action source and the seller’s EventSourceHealth; for an audience, its status, matched count, match rate and match breakdown), and mappedTo, the event sources and audiences of yours mapped to it on that account. Agents on V3 read the same list with get(kind: "connection", include: ["inventory"], connectionAccountId), 50 rows at a time. Names and reports appear after the account’s next hourly read.
• In Inventory Components, a product with its own targeting can now go back to your ad server’s default. Open the product, choose Use the ad server’s default in its targeting section and confirm. Buyers can then set everything your ad server supports again, and the product keeps following your ad server as its support changes. Only the product’s targeting changes. Nothing to change on your side.
• V3 search and get, in Murph and over MCP, now offer only what your account kind can use. Before, a seller account was offered buyer-only lookups such as creative_format or kind: "connection", and a buyer account was offered seller-only ones such as material or rfp. Those calls failed with “search is a buyer tool, and you are in a seller account” or with a filter error. Now neither is offered, so agents stop making calls that can only fail. Seller accounts keep the buyer-side campaign and creative lookups when they can run their own-supply campaigns, and accounts that span buyer and seller keep everything.

​

5.970.0 — October 8, 2026 at 4:09 PM UTC

• Creative sync and media-buy creation now reuse the confirmed seller account when an earlier request carried account details instead of an account ID. Buyers do not need to change their requests. Requests without a confirmed account still tell the buyer to run account sync.
• The V3 search for wholesale_product now returns productQueryId once every seller has answered (resultsComplete: true). Pass it as idempotencyKey to save_media_buy, with the product’s sellerId and productId, to book a product straight from the search without a proposal round. One search books into one campaign; search again to book into another.

​

5.969.0 — October 8, 2026 at 3:48 PM UTC

• Delivery reports are no longer discarded when an inventory source sends null for an optional field instead of leaving it out.
• A source that reported next_expected_at: null on its final delivery report — correctly, since a completed buy has no next report due — had that whole report rejected, including the impressions and spend it carried. The buy’s last delivery day never reached reporting, and because the same read reported the buy as completed, the platform stopped polling it. Affected buys showed delivery ending a day before their flight did.
• Optional fields sent as null are now read as absent, which is what they mean. A null on a required field is still rejected.
• Storefronts that sell only through their own sales agent are now treated as pass-through whenever the seller isn’t building products, even if the agent offers wholesale products or signals. Before, such a storefront stayed on the managed path until Apostra had recent proof that its agent supported neither. Now buyers reach that storefront through the agent’s own products and coverage. The agent, rather than Apostra, decides new buyer accounts, unless it requires operator authentication. Sellers with Merchandising who build products from a wholesale source or the marketplace pool keep the managed path, unless they have turned product composition off.
• Avails-sheet uploads now arrive as Drafts. Review availability changes before saving, then publish the sheet and apply its avails together.
• Sales-agent certification now checks the audience and conversion-tracking support your agent declares. If get_adcp_capabilities declares media_buy.audience_targeting, each certification run lists the audiences on your certification account. If it declares media_buy.conversion_tracking, the run lists your event sources and checks that one buyer-managed source can be mapped and found again. Keep at least one buyer-managed event source on your certification account, or the run fails. Agents that declare neither see no change. See “Audience and event-source certification checks” in the Sales Agent requirements docs.
• The ChatGPT step on the Listing page now gives you the plugin ZIP to upload to OpenAI and your submission notes as two separate downloads. Before, it downloaded one archive that held both, and OpenAI rejected that archive when it was uploaded. The submission-bundle URL takes part=plugin or part=notes to return one file; without part it still returns the combined archive.
• An audio file you uploaded to an advertiser’s Library can now be used in a creative. Before this fix, saving a creative whose source was an uploaded MP3 or WAV failed with “An internal error occurred”, even though the upload itself succeeded and showed in the Library. Save the creative again with the same uploaded audio; nothing else to change on your side. Uploaded video and audio delivered through a seller’s ad server are unaffected.
• Pass-through storefronts now send a buyer’s account request to their sales agent only when the agent can take it: it lists sync_accounts and list_accounts and doesn’t require operator authentication. For any other sales agent, the storefront reviews the request under its own account approval settings and the seller links it to one of the agent’s accounts in Buyer Account Mapping, so the request is never sent to an agent that can’t answer it. Once a seller’s agent adds sync_accounts, new requests go to it automatically.
• For sellers enrolled in complete-key buyer account mapping, AdCP 3.0 and 3.1 sync_accounts now reuses only the caller’s existing credential-owned request. A new or incomplete old-protocol request returns ACCOUNT_SETUP_REQUIRED before any local or upstream account work. Existing legacy account reads remain unchanged while their complete-key migration is scheduled separately.
• If you turned click tracking off for an advertiser (v2 click_tracker_enabled: false, V3 tracking.clickTrackerEnabled: false), creatives sent to sellers with a media buy, whether on launch, a creative sync or a media-buy update, now go out with the click-through URL you set instead of Apostra’s click redirect. Apostra still fills its own ids ({MEDIA_BUY_ID}, {CREATIVE_ID}, {CAMPAIGN_ID}, {PACKAGE_ID}) in that URL, and serve-time macros such as {DOMAIN} go to the seller as written for its ad server to fill. Inline creatives created with a media buy also skip Apostra’s impression tracker when impression tracking is off. Clicks on those creatives no longer reach Apostra’s click reporting. A click tracker generated when a creative was created, while click tracking was on, can still reach the seller. Advertisers that keep click tracking on see no change, and there is nothing to change on your side.
• When your organization hasn’t chosen an IU plan yet, the billing next step now reads “Choose your organization’s IU plan in Plan & Billing” rather than pointing you to an “Enterprise Rate Card”. The step that asks you to accept the governing agreement first now refers to choosing an IU plan in the same way. Nothing to change on your side.
• In the vendor-measured goals pilot, goal progress now judges a vendor-measured goal on the vendor’s values that sellers report in delivery, such as Placer’s store-visit rate. A minimum-rate target is judged on the vendor’s value per measured impression, weighted by the impressions the vendor measured, and needs at least 1,000 of them for a verdict. Progress shows basis: vendor_attested with the vendor, the impressions it measured and its coverage of what was delivered. A cost target is not judged, because the vendor defines the metric’s unit. A goal with no values yet still reads as not reported, never estimated. This applies to get_delivery (V3), reporting metrics (V2) and the seller record buyers use to compare sellers.
• V3 save_audience now accepts sellerAccounts on each audience: up to 50 pairs of a connected seller account’s accountId (from get with kind: "connection") and the sellerId of the audience already on that account, such as a Meta Custom Audience. Use it to record which audience on each seller account is the same list as yours. Saving records the mapping without contacting the seller, and an entry that only maps sends no members. The audience must already exist: map it once get lists it. An accountId that is not an active, connected account of yours, or an audienceId that does not exist yet, fails the save with REFERENCE_NOT_FOUND, and nothing is saved or sent. get with kind: "audience" now lists each audience’s sellerAccounts, with the seller’s own size and match rate for that account in match (AdCP matched_count, effective_match_rate, and match_breakdown). Every mapping reads status: "pending", with sellerId and match null, until Interchange can confirm it on the seller account; that confirmation is not available yet. Breaking for V3 callers: the save_audience response’s operationId is null when no entry sends members. Audiences saved without sellerAccounts are unchanged.
• Interactive Pages opened in Claude, such as Advertisers, Campaigns and the Creative Library, load their data again. Since Claude moved to the stateless MCP protocol in early October, these Pages opened but showed “Couldn’t load”, and actions such as Add advertiser failed. A Page opened without an MCP session is now authorized for the signed-in user who opened it.
• On the Partner page, each client source your sales agent powers now has a Diagnose action that opens that source’s health in the source diagnostics widget. You see health by operation, the diagnosis and open operations for one source at a time, with the same limits as the operator read. The action appears for sources the client still authorizes. The page’s per-source health, error, call, failure-rate and latency columns are gone; the summary counts and incidents stay. The GET /api/v2/provider/account response is unchanged. Nothing changes for clients, and there is nothing to set up.
• You can now save an approved voice or audio output from a Creative Session to the advertiser’s Creative Library. Approve the output, then call save_creative_session with operation: "promote_approved_output", or choose Save to library in the variant gallery. Promoting audio used to fail with “This approval predates promotion evidence” even straight after approval.
• The audio goes through the same inspection as an uploaded WAV or MP3 file. While that runs, the call returns operation: "promoting_approved_output" with a processingState. Repeat the same call in about a minute to get the Creative Asset. Audio you approved before this release has to be approved again before you can promote it.
• Embedded sales agent 1.63.0: let a wholesale product return to its ad server’s default targeting, open agentic-api release PRs with the sections commercialization review requires, send the daily uncapped-spend alert in production only.
• Restore queued source-account syncing for buyer provisioning.
• For buyers enrolled in complete AccountKey mapping, sync_accounts and list_accounts now use the same verified organisation, advertiser and current-lifecycle authority. Authorised colleagues and service tokens can see the same pending or approved seller account, while the request audit still identifies the actor. Buyers not enrolled in the cutover keep the existing account-request and list behaviour.
• Updating a campaign now saves utmConfig, frequencyCaps and dataDelivery even when the same request also updates media buys through mediaBuys. Before, a request that carried both kept the old values and returned them in the response.
• You can now stage seller proposals whose pricing includes a currency when the seller’s settlement currency is known. Proposals from multi-currency sellers still require clear settlement-currency evidence before they can be staged.
• Apostra’s click tracker no longer carries the axem and tmpx parameters, and your landing page no longer receives an axem parameter after a click. Ad servers left these placeholders unfilled on clicks, so they only added noise to your landing URLs. Impression trackers still carry both.
• The v2 docs and API reference now say plainly how utmConfig writes differ by level. On an advertiser, the array replaces the whole set. On a campaign, a write adds or updates keys unless deleteMissing: true is set. For one model at advertiser, campaign and creative level, and to remove an inherited key with null, the docs now point to V3 macroAdditions. The create-advertiser page also had the wrong utmConfig limit: it is 20 entries per request, not 50.
• Creating or updating a creative now warns you when its click-through URL already sets a query key that one of your click-URL parameters also sets, such as utm_source. The URL’s own value is kept and that parameter is not added. The warnings array names each key and whether it was set on the advertiser, campaign or creative. This applies to v2 create, update and bulk update, and to V3 save_creative. The creative is still saved; remove the key from the URL if you want the configured parameter instead.
• The help links in the Creative Library and the creative upload app now open the guide in a new tab. Before, clicking Learn how., Read how to bring your own creative., Save as a draft with a canonical format or Learn about audio uploads replaced the app with an error page until you reopened it.
• Links inside Apostra’s in-chat apps now open. Before, most links in apps did nothing when clicked in Apostra chat, because the app’s frame cannot open a new tab on its own. They now open in a new tab, and links to pages in Apostra open in place. This covers help and documentation links, creative and variant previews, landing-page links, reference links in escalations and product marketing, and the Library’s example pack. Documentation links that went to an old address and showed a missing page now open the current guide.

​

5.968.0 — October 8, 2026 at 1:53 PM UTC

• Every plan now includes one Developer account for your organization’s own agents, and it no longer uses one of your plan’s account slots. Building your own agent never forces a plan change. Additional Developer accounts still count toward your account limit.
• Creative sync now accepts draft media buys that mix direct and Storefront-composed products when every product has an active source route. Drafts still fail with an actionable error when a product route is missing, inactive or ambiguous.
• Account presences now list event sources the platform itself owns, such as its own on-site or in-app events, and each row carries managedBy. A seller source is shown so you can see it, but it can never be mapped to one of your event sources. We refresh an account’s audiences and event sources about once an hour.
• Embedded sales agent 1.62.0: report and alert on GAM line items that can spend past their budget, book a GAM buy only where every geo it targets overlaps, or refuse it, never report a media buy as live without its ad-server order, refuse an explicit overlay_support the product cannot declare.
• Requests are less likely to be refused with “The account type could not be resolved. Try again.” while the platform is briefly busy. When the check that confirms your account type runs out of time, it now tries once more before refusing the request, so a short slowdown no longer turns into a failed call. A request still fails closed if the check cannot complete on the second try. Nothing to change on your side.
• Switching accounts in one connected app no longer changes the account another connection acts on. switch_account (v3) and customer_switch (v2) now apply only to the connection they were called on: switching in the v2 connector leaves the v3 connector where it was, and a separately connected client keeps its own account. Reconnecting starts from your home account. After this release, a connection that had switched accounts starts from its home account once; switch again if needed.
• Your Media buys list now shows the real next step on buys that looked stuck. A failed buy the buyer cancelled or archived before it reached a source now reads canceled with no action needed, instead of asking you to recover it. A buy the source is holding for creatives that never reached it now names who can move it: the platform when the creative sync failed, or the buyer when no creative was attached. A buy still waiting on the source after its flight has ended now asks you to check it with the source and close it. Nothing to change on your side.
• Creative sync to a storefront seller that accepts only legacy format references now delivers each creative on the format reference the booked product advertises for its format kind. Before, these syncs failed for every creative. If the seller’s product declares format references that are not real AdCP formats, the sync still fails, but the error now names the product and the formats the seller has to correct.
• V3 now returns a typed media-buy error instead of leaving a write receipt uncertain when an underlying route returns its standard error envelope.

​

5.967.0 — October 8, 2026 at 1:05 PM UTC

• When a seller approves a creative change on a live media buy, the buy now shows the new creatives as soon as the change reaches the seller’s ad server. Before, a creative change that did not also change a budget could stay “pending approval” after the seller approved it, so the buy kept showing the old creatives even though the seller was already serving the new ones. Buys already showing that stale state will update when their next change is approved. Nothing to change on your side.
• Certification of a managed sales agent now sets up its sandbox account the way a real buyer’s account is set up: we call the sales agent’s sync_accounts for our test buyer with sandbox: true, and run the creative sync and certification buys on the account_id it returns. Certification no longer needs a no-charge test advertiser named through Buyer Account Mapping, and it no longer sends the ad-server advertiser id, which a Google Ad Manager sales agent refuses as an unknown account. A family is skipped with a named reason when the sales agent holds the account for approval, rejects it, returns it as a live account, or returns no account_id.
• Creative syncs to media buys with outside sales agents (such as Vox and pubX) reach the seller again. Since 1 October these syncs were refused before they were sent, with “assignments.0.creative_id: expected string”. Each creative is now sent with its own assignment to a package, in the AdCP format, so sellers receive it. Fields that some sellers allow only when a buy is created, such as product_id or pricing_option_id, are still left off.
• Forms inside Apostra’s in-chat apps now submit when you click their button or press Enter. Several did nothing when clicked. Examples are Save payment terms and Confirm operator identity in buyer setup, Accept terms and Save payout authority in Plan & Billing, conversation search, the Seller Accounts buyer search, creating and saving creative collections, the activity filter, and saving the merchandising context.
• Click-URL parameters (utmConfig in v2, macroAdditions in V3) that carry {DOMAIN}, {APP_BUNDLE}, {PAGE_URL} or another AdCP macro are now kept for every buyer; before, they were left off the click URL. There is nothing to change on your side. At click time, Apostra’s click redirect fills each macro with the value the seller’s ad server put on Apostra’s click tracker and removes any token it can’t fill, so a click through the tracker never lands on a literal placeholder. Whether a macro gets a value is up to the seller. If the advertiser has click tracking turned off, campaign-level creative syncs go out without Apostra’s click tracker, so only the seller’s ad server can fill them, and anything left unfilled reaches the landing page as written; creatives sent with a media buy always carry the click tracker. Saved parameters that were left off because they carry one of these macros appear from each creative’s next sync. See “Click-URL parameters” in the advertiser guide.
• You can file one live test buy request per Agent. Pressing Request a live test buy again shows the request you already filed, with its date, instead of filing another. Certification is moving to run automatically on live traffic, and we’ll let you know when your agent’s certification runs.
• In Account settings, the account’s own member list is now called Account members, so it can no longer be confused with Organization → Members. Sponsored buyers and advertiser-scoped access no longer see a Plan & billing entry in Account settings, matching the Organization section, which they already did not see.
• Apostra now tells you plainly that storefronts don’t support AdCP operator authentication. A storefront calls your sales agent with the credential you connected, for every buyer, and never passes a buyer’s own credentials through. If your agent declares account.require_operator_auth: true, its Agent page shows Accepts the connected credential for every buyer as not supported, and the source discovery test says so in its result. To sell through a storefront, accept the connected credential for all buyers and map each buyer’s account in Buyer Account Mapping.
• The product detail view now shows what each product lets you target, in plain words and grouped by geography, audience, device, time and content. A product whose seller lists no targeting says it doesn’t allow buyer targeting.
• In the vendor-measured goals pilot, a campaign goal can be a metric a measurement vendor counts, such as store visits measured by Placer. Save it on save_campaign (V3) or in performanceConfig.optimizationGoals (V2) as kind: "vendor_metric", naming the vendor’s domain and the vendor’s metric id, with an optional minimum-rate target. A cost target goes in bidding, as for every goal. Sellers whose products declare that vendor’s metric receive the goal; every other seller sees it in the brief as a result to report. Goal progress reads as not reported until the platform stores the vendor’s numbers.

​

5.966.1 — October 8, 2026 at 12:10 PM UTC

• The Campaigns Page, the Creative Library and advertiser reads in Apostra chat open again for advertisers whose saved brand domain was stored as typed, for example with capital letters. Previously these advertisers got an internal error instead of the page. The advertiser’s brandIdentity.brandRef.domain now reports the saved domain as a lowercase host without a scheme, port or path, and the brand field still shows the domain exactly as it was saved. If no valid domain can be read from the saved value, brandIdentity is null and the rest of the advertiser still loads. Nothing to change on your side.
• The V3 search and get tools now describe every field in plain words: what it means, which kinds it applies to, and the rule the server enforces. Agents calling these tools, including Murph and external MCP clients, get clear guidance where they used to see shorthand such as “query/kind; no” or single-word descriptions like “state.”, so fewer calls fail and need a retry. Tool names, fields, and behaviour are unchanged.

​

5.966.0 — October 8, 2026 at 11:43 AM UTC

• Certification no longer asks you to nominate a sandbox account. For a third-party Agent, we set one up through your sync_accounts with our test buyer, the way a real buyer would, and run the certification buys on the account_id your Agent returns. Your sync_accounts must accept a sandbox account for the test identity and return an active account with an account_id. Agents that require operator authentication can’t be certified yet. The certification sandbox account endpoints now answer 410 Gone with Deprecation and Sunset headers until 27 November 2026, when they are removed. The certificationSandboxAccountId input on save_inventory_source and the certificationSandboxAccount include on get are removed.
• When you open a creative in Murph or another AI assistant, its detail card now shows “Trackers to traffic”. It has one row for each package of each submitted media buy in the campaign, with that package’s impression and click trackers and a Copy button for each. Every Apostra ID in them is already filled in, so a seller can paste them straight into their ad server and the clicks and impressions are attributed to your campaign. A VAST or DAAST creative delivered through Apostra’s hosted wrapper shows the hosted tag instead, once it has been synced to that media buy. Until a media buy in the campaign is submitted, the section says there is nothing to traffic yet. The card no longer shows the tracker templates, which contain placeholders an ad server cannot fill. Nothing to change on your side.
• Creative sync and media-buy creation now reuse the checked discovery account when a request does not include an account.
• The Listing page no longer flashes an empty marketplace step and an editable domain field while it loads. The marketplace and Public distribution steps and the Distribution section show placeholders until your current settings arrive.
• A product request from an account that Apostra has not yet set up for product-request tracking is now recorded instead of refused. It goes to Apostra Support, you get a reference for it, and it appears as a support request in Your requests. Accounts that are set up keep the product route.
• Uploads now suggest tags from the attributes you’ve defined, and you confirm them when you save.
• In the Apostra web app, a campaign creative’s detail panel now shows “Trackers to traffic” in place of the impression and click tracker templates. There is one row for each package of each submitted media buy in the campaign, with that package’s impression and click trackers, each copyable. Every Apostra ID in them is already filled in, so a seller can paste them straight into their ad server and the clicks and impressions are attributed to your campaign. A VAST or DAAST creative delivered through Apostra’s hosted wrapper shows the hosted tag instead, once it has been synced to that media buy. Until a media buy in the campaign is submitted, the panel says there is nothing to traffic yet. The templates, which contain placeholders an ad server cannot fill, are no longer offered for copying. Nothing to change on your side.

​

5.965.0 — October 8, 2026 at 11:09 AM UTC

• If you operate a Sales Agent, its Agent page Overview now shows a Products missing AdCP channels notice when some of its products declare no channels. The notice gives the count and links to how to declare them. Before, the count appeared only inside the certification details on the Test Agent tab. Missing channels never change your certification result.
• When you ask Murph for a Demo Storefront, it now explains how to get one: Apostra sets it up for you, and you can ask through your Apostra representative or have Murph pass the request to Apostra Support. Previously it could offer to create one itself, or file the request as a product feature request that would never deliver a demo. The Demo Storefront docs now describe this route.
• Google, Spotify and TikTok products now declare their AdCP channels, so they appear when you filter discovery or route proposal requests by channel, and their delivery reports by channel.
• Google: Search campaigns are search, Display display, YouTube video olv, Performance Max search, display and olv, and Demand Gen olv and display.
• Spotify: audio ads are streaming_audio, plus podcast where they run in podcasts; video takeovers are olv; in-feed display is display.
• TikTok: search ads are search; every other product is social.
• Organization administrators can now review and accept an IU (Intelligence Unit) plan themselves on Plan & Billing. No invitation is needed. You see the public plans that apply to your organization: Listing and Storefront agent for sellers, Connect & Buy for buyers. Other plans still come through a direct offer. New seller signups can choose a plan during signup. Plans you already accepted are unchanged, and there is nothing you need to do.
• Scope3 is now alerted when a booked order changes in your ad server, when a buy that never went live may still have delivered, and when a buyer reports a reporting problem, so these get caught and fixed sooner. Nothing changes in how you sell, and you don’t need to do anything.
• When your sales agent fails a creative sync, the source’s health detail now shows the error your agent returned, such as its message and error code, instead of a generic “failed sync_creatives” line. This makes a rejected creative sync diagnosable from Seller Setup without asking us for logs.

​

5.964.0 — October 8, 2026 at 10:49 AM UTC

• Campaign creative sync now sends each creative only to the packages whose product accepts its format, along with the exact seller format it fits. Before this fix, a video creative synced to a seller that offers several video sizes could fail before reaching the seller. When none of a campaign’s creatives fit a media buy, or a creative’s chosen format no longer matches the seller’s offer, the sync now reports a clear error for that media buy instead of failing partway.
• New files from connected sources and new linked documents now wait in the Library for review before they are used. Existing synced documents are unaffected; only newly imported files wait for review.
• Creatives that a third-party seller accepts immediately during campaign launch are now recorded as accepted. Before this fix, a seller’s immediate acceptance could be recorded as a failure, which left the campaign in Draft even though the seller already had the creatives.
• IU plan selection reads more clearly. The accept button now names your choice as a plan, for example Accept the Listing plan, so it no longer reads like an instruction to list something. In the Get in touch form, the button that closes the form is now Cancel. It was Back to plans, although the plans never left the screen. Each Enterprise card now opens the help form wherever you click on it, not only on its Get in touch button.
• When your account is not yet set up for product-request tracking, a product request filed through Murph or save_ask now says exactly that, instead of a generic failure and an offer to retry. Retrying will not help, so Murph offers to pass the request to Apostra Support instead.
• Sellers with a Google Ad Manager ad server source can now read back what Google Ad Manager holds for one of the source’s media buys. The new get_esa_media_buy_gam_snapshot operation returns the media buy’s line items, and reads each line item’s targeted and excluded locations live from Google Ad Manager, by Google Ad Manager location id, type and name, with the AdCP geo targeting each stands for (for example 200501, New York, Nielsen DMA 501). When the locations can’t be read, the operation says why. It returns at most 50 line items and 100 locations per list, each with an exact count.
• Asking Murph or an agent for your “variants” now finds your saved Creative Session and opens its gallery instead of searching your product catalog.
• In Inventory Components, the targeting buyers can set now shows what buyers actually see. A new product starts with everything your ad server can apply ticked, and a product with no targeting of its own shows your ad server’s default with that label. Untick anything you don’t want to sell and save, and the product keeps exactly what’s ticked. Leave it unchanged and it keeps following your ad server as its support changes. Metro areas and postal codes are now offered with the systems your ad server supports, such as Nielsen DMA. Nothing to change on your side.

​

5.963.0 — October 8, 2026 at 10:21 AM UTC

• Products from Meta, Pinterest, Snap, LinkedIn, Reddit, Amazon and OpenAI Ads now declare their AdCP channel: social for the social platforms, retail_media for Amazon and sponsored_intelligence for OpenAI Ads. They now appear when you filter discovery or route proposal requests by channel, and their delivery reports by channel. Google, Spotify and TikTok products sell more than one channel and are unchanged for now.
• An opened variant gallery now fits the chat window without scrolling the conversation.
• Send request in IU plan selection’s Get in touch form now sends your request and shows the receipt. Inside Apostra it previously did nothing when clicked, so plan-help and Enterprise requests could not be sent from the app.
• Murph can now read your organization’s Agents when you’re an account admin working in your own account. Before, every Murph request to list or look up an Agent failed with “Only an organization account admin or an account-bound machine credential can read owned Agents”, even for admins. Anyone who still can’t read Agents (members who aren’t account admins, or people working in an account they switched into) is no longer offered Agent lookups in Murph or in V3 search and get, so they don’t hit that error.
• In Plan & Billing, Resolve now on the next-action banner now opens IU plan selection when your next step is to choose a plan, from any tab. It previously did nothing on the Plan tab. When the tab that resolves your next action is already open, the banner no longer shows a button that goes nowhere.
• A storefront’s AdCP capabilities now describe what actually serves it. get_adcp_capabilities lists wholesale in media_buy.buying_modes when the storefront can return a wholesale catalog: every adapter storefront, and any storefront with a source that supplies wholesale products. Before, every storefront advertised only brief and refine, so buyer agents that check capabilities first never asked for a wholesale catalog. Adapter storefronts whose provider requires the buyer’s own credentials now also say so with account.require_operator_auth: true.
• When you draft a product in Inventory Components, the channel is now suggested from your storefront’s own channel when your storefront sells exactly one, so a retail media storefront gets retail_media instead of display for a banner product. The format-based guess is still used when your storefront lists no channels, or when display is one of several it lists. The create-products guide also explains how to choose a channel: it’s the budget a buyer plans with, not the ad format or ad server.
• In the v3 MCP tools, get now reads listing, playbook, business_rules, coverage, distribution, and notification_config even when the call includes an id. Before, it refused those calls. Each of these kinds is one per account, so the id could never change which object came back: get now ignores it, returns the account’s own object, and adds a warnings entry saying it ignored the id. billing, and seller in a Seller account, still reject an id. When search for kind: "proposal" has no filter.campaignId, the error now says that proposals are listed one campaign at a time and points to search(kind: "campaign"). Agents that already omit id see no change.
• Storefronts now check every request they send to a third-party sales agent against the AdCP schema for that agent’s version, and stop a request that doesn’t match before it is sent. Before, such a request was sent anyway and the agent decided what to do with it. VAST tag URLs that carry unsubstituted ad-server macros such as [CACHEBUSTER] or ${GDPR} still pass, because AdCP 3.1 accepts them. A media buy’s total budget is now always sent as amount, the field AdCP defines, instead of also carrying a legacy total. If discovery from a source is stopped this way, the storefront serves that source’s stored catalog where it has one, without counting it against the source’s health. Nothing to change on your side.

​

5.962.0 — October 8, 2026 at 9:36 AM UTC

• Fewer proposals lose their written argument to the fact check. Before it trusts a batch of sentences, the fact check tests itself with two sentences it knows are true, one taken from your Library or catalogue and one from your Playbook. Those test sentences were sometimes malformed: a Playbook excerpt cut off mid-sentence, or a fact with an extra full stop added. A correct check could reject them and throw the whole argument away. They are now complete sentences taken word for word from your sources. The check is otherwise unchanged. Nothing to change on your side.
• Murph makes fewer failed tool calls on accounts that run on Gemini. When Murph answers with Gemini, its tool calls now have to match each tool’s published input schema before they are sent, so a call no longer fails because it carried a field the tool does not accept. Nothing changes in how you use Murph, and the V3 tools, their inputs and their validation are unchanged for every MCP client.
• Murph in a seller account no longer offers notification settings to accounts that don’t have them yet. Before, Murph could try to read your notification settings and get “notification_config is not enabled for this account yet.” Now Murph’s seller tools follow the same access check as the V3 MCP surface, so Murph only offers notification settings when your account has them.
• When a V3 tool call includes a key the tool does not accept, the error now lists every key that object accepts. Long lists are no longer cut off after 50 keys. When the key belongs in a nested object, the error also says where it goes: for example, a search filter field sent at the top level gets “filter fields go inside filter”. The error still never repeats the key that was rejected.

​

5.961.0 — October 8, 2026 at 9:09 AM UTC

• A reviewer access request that is still setting up can now be cancelled from the ChatGPT destination with Cancel request, so a request that never finished no longer blocks you from requesting again.
• Products now list the targeting they declare in supported_targeting, including targeting declared through AdCP 3.2 overlay_support.
• When a Meta media-buy readback is available, get(kind: "media_buy") now shows when the provider was checked, whether the result is current, and any open configuration drift or newly discovered creatives. No action is required.

​

5.960.0 — October 8, 2026 at 8:50 AM UTC

• Click-URL parameters (utmConfig in the v2 API, macroAdditions in V3) now accept every AdCP universal macro, including {DOMAIN}, {APP_BUNDLE} and {PAGE_URL}, so you can save a value such as utm_content={CREATIVE_ID}_{DOMAIN}{APP_BUNDLE}. Apostra fills only {CREATIVE_ID}, {CAMPAIGN_ID}, {MEDIA_BUY_ID} and {PACKAGE_ID} when a creative syncs to a seller, using its own ids. Every other macro is known only when the ad serves, so it has to stay in the click URL for the seller or Apostra’s click redirect to fill, and we are turning that on account by account. Until it is on for your account, a parameter that carries one of those other macros is left off the click URL on every sync, including campaign-level creative syncs, which used to send it with the macro as literal text. Parameters made only of literal text or Apostra’s own ids are unchanged, and you don’t need to change anything you have already saved. See “Click-URL parameters” in the advertiser guide.
• Campaigns with an age range now launch on Meta storefronts that approve media buys automatically. The age range is sent to Meta, which applies it, instead of the media buy being rejected. On other storefronts a campaign age range can still stop the media buy at launch, so remove it before launching there.
• Buyers are no longer shown a saved composed product that narrows a signal to specific values, or requires signals together, unless every one of its signals comes from a managed sales agent, the only source that can deliver that targeting. Refining such a product, or finalizing a proposal that includes it, now returns unable with the reason, instead of the media buy being refused later.
• If an advertiser locked your Buyer Account’s operator identity before you chose its account scope, you can now confirm it as one operating unit as well as the whole operator, with save_buyer_operator and the same operator domain. This lets a company that runs several buyer accounts under one domain, such as one per region, give each its own unit. A unit is refused while a seller account already holds your identity without a unit, and the error says which kind; support can move those accounts.
• Media buys for composed products that narrow a signal to specific values, or require signals together, now go through for every buyer, including buyers on AdCP 3.1 and media buys Interchange places for campaigns. Before, they were refused with an error asking for AdCP 3.2. Interchange now creates every media buy with a managed sales agent over AdCP 3.2, whatever version the buyer uses, so the targeting reaches the seller’s ad server as the product was built. A media buy keeps the AdCP version it was created with for its later updates and delivery reports, so buys already running are unchanged.
• Storefronts on the Storefront-built and Agent-supplied paths no longer refuse a product search because its brief states an age requirement, such as “please target women 18-55” or “exclude anyone under 25”. The brief now reaches the seller’s inventory, so the seller can recommend age-specific inventory or an age signal it sells. Age stated only in the brief is not applied as targeting: each product returned for such a brief says so in its description and explains how to apply it, by sending targeting_overlay.demographics.age on an AdCP 3.2 request. A structured age range is still applied exactly, and briefs that only describe the audience, state a preference, or contain budgets and durations come back with no note.

​

5.959.0 — October 8, 2026 at 8:08 AM UTC

• A rate card you upload now waits as a Draft; Save and update prices shows which prices change, and flags any below a floor, before anything goes live.
• Storefronts whose sales agent requires operator authentication now handle buyer accounts like ad-server adapters. Before, Apostra forwarded a new buyer’s account request to that sales agent, which doesn’t accept account requests that way. Now the storefront reviews the request under its own account approval settings, and the seller links the account to the sales agent’s own account in Buyer Account Mapping. Storefronts whose sales agent accepts account requests still forward them, as before.

​

5.956.2 — October 8, 2026 at 6:03 AM UTC

• The V3 campaign launch preview no longer warns that a creative “needs seller approval before launch” for Amazon, Meta, Reddit, Snap, and Spotify media buys when the creative simply hasn’t synced to the platform yet — syncing happens automatically after launch for these sellers, so the warning was never accurate. A genuinely rejected, in-review, or missing creative still blocks as before, for every seller.

​

5.956.0 — October 8, 2026 at 5:37 AM UTC

• Seller administrators can now confirm an owned Sales Agent’s product mode or correct the mode for their own binding to an unclaimed Agent through V3. This keeps existing connected inventory on the intended product path without a support request.
• Buyers have no new setup step or documentation to read. A correction can change the product path they receive for that one seller Source, but it does not change prices, availability, or which seller they can choose.
• This is included with the existing Sales Agent connection because it corrects the seller’s own inventory configuration. It is not a separate plan, metered capability, or way to differentiate sellers.
• You can upload several documents at once; each shows its own progress, and Save all saves the ones that are ready.

​

5.955.0 — October 8, 2026 at 3:47 AM UTC

• Certification creatives now go only to the source being certified. Other sources on the same storefront no longer receive them or get a creative review task.
• Documents you upload to the Library now arrive as Drafts, and your agent doesn’t use or cite a Draft until you save it. Each Draft has a suggested name, category and description, labelled by where it came from: the file name, the format, or the content. Review it in the Library, then Save it to make it Live, or Discard it to delete the upload completely. If you ask your agent to save a Draft, it opens the Draft for you to review and save; it can’t save or discard one itself. Rate cards and avails sheets are unchanged for now and still go through their price preview. The Library also filters by Live, Draft and Archived, and flags Live documents with no category.

​

5.953.0 — October 8, 2026 at 2:43 AM UTC

• Fixed a bug where saving a creative without an explicit template could report “could not be saved” even though the creative was saved successfully and attached to its campaign. Saving now succeeds normally in this case.
• Embedded sales agent 1.61.3: make media buy status follow GAM and close out ended buys that never went live, refuse to resume a GAM line item or approve its order when it has no budget cap.

​

5.952.0 — October 8, 2026 at 2:22 AM UTC

• Measurement records can now say which campaign, media buy and package they measure. Add campaignId, mediaBuyId and packageId to a record in POST /advertisers/{advertiserId}/measurement-records; each must belong to the advertiser, and a media buy fills in its own campaign when you leave campaignId out. Records come back with the same fields. A record without them still covers the advertiser as a whole. For now, a given outcome type, source, geo and time window holds one record, so a second record for the same window with a different media buy is refused with a conflict.
• More of your proposals now carry a written argument that cites your Library documents, instead of falling back to plain Library text. Every sentence of the argument is checked against the sources it cites, and that check never sees the buyer’s brief. So the buyer’s dates, budget, names and requests now appear only in “What we heard”, and the thesis states what your own sources say about the products that fit the brief, without general premises such as “a launch needs a big first-day moment”. The fact check itself is unchanged. Nothing to change on your side.
• The agent page no longer offers a transaction test that could not run for your account. A test that doesn’t start now says so and gives the reason, instead of telling you its status needs checking. Certification runs automatically on live traffic.
• Meta media-buy creation now returns a specific, actionable reason when the adapter rejects a request before dispatch — the field, value, or account-readiness issue at fault — instead of a generic “correct the request and submit a new one” with no field or reason. This covers eligibility checks (Messenger, WhatsApp, Lead Generation, Sales Website Value), budget/currency/DSA checks, and geo-region/geo-city targeting resolution failures.
• Proposals no longer lose their written argument when the proposal writer plays back more than three points from the buyer’s brief. “What we heard” now keeps the first three points, and the rest of the proposal is checked and written as usual. When a proposal still has no written argument, its diagnostic drop counts include the trimmed points under section_claim_limit. Nothing to change on your side.
• Updates, cancellations and delivery reports for a media buy with a managed sales agent are no longer refused when the caller uses a different AdCP version from the one the buy was created with. Each media buy now keeps the AdCP version it was created with for every later call, whatever version the caller uses.
• Embedded sales agent 1.61.2: apply buyer creative weights on GAM line items with MANUAL rotation, on every association path, refuse companion banners an ad server cannot traffic, before booking, on every adapter, translate click and domain macros to GAM without corrupting compiled trackers, validate creative rotation and refuse rotation an ad server cannot apply.
• Before a storefront rejects a buyer’s brand_id as unlisted, it now reads the brand’s registry record again if its stored copy is more than an hour old. A brand_id the brand has just added to its brand.json is accepted straight away instead of being rejected for up to a day. If the registry can’t be read at that moment, the request goes through.
• While your storefront is being set up, an inventory source that is waiting on you now names the step in the rail, such as Add products or Add credentials. Before, it showed an in-progress indicator even though nothing was running.
• Your inventory source diagnostics now include operationsTruncated in the source health object. On your read it is always false, because it lists only operations that are still open, so there is nothing to change on your side. An attempt’s bodies.reason can now also be not_read, which your read does not return today. When Apostra support looks at the same source, it also sees the operations that finished in the window, with each try’s error code, so the operation ID you quote matches theirs. See Diagnose third-party sales agents.

​

5.951.0 — October 8, 2026 at 1:08 AM UTC

• Reviewer access for directory submissions is ready as soon as you request it. Choosing Request reviewer access on a Public listing now sets up the no-spend reviewer login straight away, instead of waiting for Apostra to activate it, and Open reviewer login appears right after. You can request reviewer access up to three times a day for each directory.
• Confirming your storefront’s brand no longer fails with “the AAO registry is unavailable, try again” when the registry cannot read your brand.json live. You now see what is wrong with the file (it is missing, redirects to another domain, is over the 256 KB limit, or is not valid brand.json) so you can fix it. “Try again” is reserved for genuinely temporary failures.
• Storefronts now check a buyer’s brand_id on get_products, create_media_buy and sync_accounts before passing the request to the seller. A brand_id is accepted when the brand’s brand.json (or an owner-verified registry entry) lists it, when the buyer already holds a seller account on that storefront under it, or when the brand registry can’t be reached. Otherwise the storefront returns a VALIDATION_ERROR naming the field and the brand’s brand.json. Rejection is being turned on storefront by storefront; until then an unlisted brand_id is recorded and the request goes through.
• If Apostra sends you a private signup link for an Offer, you can now claim it. Sign in with the exact invited email as an administrator of your organization’s billing account; claiming connects your organization to that exact Offer so you can review it in Plan & Billing. Claiming never accepts the Offer, starts paid service or charges a card. A link works once and expires after at most 30 days. A link that was revoked, replaced, used, or whose published terms changed is refused with its reason. A claim from a different email, or from someone who is not a billing administrator, is refused, and some conflicts go to the Apostra team for review. A browser page for opening these links is still to come.
• If your integration reads tracking.impression_tracker_url or tracking.click_tracker_url from a creative manifest, switch to tracking.impression_tracker_url_template and tracking.click_tracker_url_template before 9 November 2026, when the old fields are removed. The new fields appear on the get creative response (GET /api/v2/buyer/campaigns/{campaignId}/creatives/{creativeId}) and on the create creative response. Until removal, the old fields return identical values and are marked deprecated in the OpenAPI spec and docs. If you don’t read them, nothing changes for you.
• The new names say what these values are: templates, not URLs ready to traffic. Each contains {MEDIA_BUY_ID} and {PACKAGE_ID} placeholders that only Apostra can fill, and the click tracker’s rurl can also contain {CREATIVE_ID} and {CAMPAIGN_ID}. A seller’s ad server cannot fill them. A template copied into an ad server by hand sends impressions and clicks with the placeholder text still in the URL, and they cannot be attributed to your campaign. Don’t give a template to a seller to traffic. When Apostra syncs a creative to a media buy, it already sends the seller trackers with those ids filled, so syncing needs no change. Serve-time macros such as {CACHEBUSTER} can stay in the URL for the ad server to fill. The “Tracker templates” section of the creative object guide explains the difference.
• Editing a creative that is live on a storefront media buy no longer sends the seller placeholder ids. The update now reaches that seller once for each media buy the creative is assigned to, with that buy’s media buy, package, creative and campaign ids filled in its trackers and landing page, so click and impression attribution keeps working after an edit.
• If your click-through URL contains {PAGE_URL}, shoppers who click your ad now reach your landing page with the address of the page where the ad ran, whenever the seller’s ad server provides it. When the seller doesn’t provide it, the token is removed rather than shown as placeholder text. Apostra uses the full address only to build the landing page link and stores only the page’s host with the click. This applies to creatives synced to a seller after the release; nothing to change on your side.
• Fixed campaign execution failing with “no upstream media buy” whenever a creative was attached to a media buy on a connected ad-platform seller (Meta, Snap, Reddit, TikTok, and other adapter-connected sellers). The buy now launches normally whether or not a creative is attached.
• MCP calls refused because they had no valid session appear in your API call history (GET /api/v2/activity/calls) again, with the X-Scope3-Activity-Id response header. This covers a call sent without a session, with an unknown session, or with another principal’s session; for example, a tools/list sent before initialize. If the call also carries an invalid X-Scope3-Run-Id or workflow header, the response reports that header error first, as it does for every other call. Nothing to change on your side.
• Murph now reads the whole of long documentation pages. It used to see only the first 20,000 characters of a page, so on 65 of our longest pages, including the glossary, source diagnostics, the tool reference and authentication, it answered later sections from short search snippets. It now fetches the exact section a search points to, and pages through long pages with an outline of their sections. Answers about anything near the end of a long page, such as how to verify our signed requests, now come from the full text.
• The published response schema for listing your account grants on a Storefront (GET /api/v2/buyer/storefront-accounts and the list_buyer_storefront_accounts MCP tool) now allows additional fields in ext.interchange, and ext.interchange.advertiser_activation is now optional there. Responses are unchanged today: when advertiser_activation is returned, it has the same fields and values as before. If you validate responses against a client generated from the schema, regenerate it so it accepts fields we add to ext.interchange later, and treat advertiser_activation as possibly absent. Nothing else changes on your side.
• A Demo Storefront’s synthetic managed source now shows its inventory sync as complete instead of asking you to run a first sync. The synthetic source has a fixed catalog and no ad-server inventory sync, so there was never a sync to run or retry.
• If you read a creative through V3 get with kind: "creative" and use resolvedClickUrl, switch to clickUrlTemplate. resolvedClickUrl is removed in this release with no alias, because V3 is in preview. If you don’t read that field, there is nothing to change on your side.
• clickUrlTemplate is the creative’s click URL with the click-URL parameter additions that apply to it, and with {CREATIVE_ID} always filled in. {CAMPAIGN_ID} is filled in when the creative belongs to one campaign. An advertiser library creative that isn’t tied to one campaign keeps {CAMPAIGN_ID} as a placeholder. {MEDIA_BUY_ID} and {PACKAGE_ID} always stay as placeholders, because they differ for each media buy and package. Apostra fills them when it syncs the creative to a media buy.
• That is why the field is called a template. If you copy it into a seller’s ad server by hand, the click URL will contain the literal text {MEDIA_BUY_ID} and {PACKAGE_ID}. Serve-time macros such as {DOMAIN} and {CACHEBUSTER} also stay in the URL for the ad server to fill.
• Syncing needs no change. Apostra already sends sellers click URLs with these ids filled in. The clickUrl field, which is the URL as you saved it, is unchanged. In the creative library, the destination panel row that was labeled “Delivered as” now reads “Click URL template”.

​

5.950.0 — October 7, 2026 at 11:20 PM UTC

• Products a storefront composes from a brief now list the targeting you can set on a package, as overlay_support. Each one carries the declaration of the inventory product it is built from, so brief results and wholesale results describe the same inventory the same way. A product whose inventory declares no targeting support still lists none.
• Update billing info now documents that your organization’s payment terms are writable. An organization admin sends paymentTerms (net_15, net_30, net_45, net_60, or net_90) to PUT /api/v2/billing/info; no approval step follows and the change is audited. It also explains how terms reach each seller account: consolidated-billing accounts ask for the organization’s terms, while direct-billed and sandbox accounts carry none and get the seller’s default.
• Buyer setup docs now state that payment terms can be requested for each seller account. Set payment_terms (net_15, net_30, net_45, net_60, net_90, or prepay) on an entry in sync_buyer_storefront_accounts, or omit it to accept the seller’s default. The organization-wide choice is separate and takes net_15 to net_90 only. The V3 hosted-agent tools set only the organization-wide choice.
• When your organization can’t add another account, Organization → Accounts now says why: the plan doesn’t include additional accounts, no longer includes them, or isn’t in effect yet. Before, all of these showed “Account creation is unavailable right now.” Organization inspection through MCP (manage_organization) now reports the same answer as account creation, instead of reporting that an organization without account capacity could add accounts.
• Organization members who are not administrators now see the organization’s accounts they belong to when they open the organization, instead of an empty buyer dashboard that showed no advertisers or campaigns. Open an account from the account switcher to work in it.

​

5.949.0 — October 7, 2026 at 10:05 PM UTC

• An advertiser now carries a brand ID only when the brand publishes it: the brand’s /.well-known/brand.json, or a registry entry the brand owner verified, must list that ID. A brand ID found only in community or enriched brand data is not stored, and the advertiser is identified to sellers by its brand domain alone. Interchange also rechecks each stored brand ID about once a week. If a brand stops listing an ID that sellers already know, Interchange keeps sending it so existing seller accounts stay intact, and flags it to Scope3 operations. Nothing to change on your side.
• Third-party impression trackers that use {DOMAIN}, {PAGE_URL} or {APP_BUNDLE} now run on Google Ad Manager sellers. Before, a tracker with any of these macros was left off the creative when it went to a Google Ad Manager seller. Now each macro is converted to Google’s own macro: {DOMAIN} to %%SITE%%, {PAGE_URL} to %%PATTERN:url%% and {APP_BUNDLE} to %%TAG_PARAM:msid%%. Google fills {APP_BUNDLE} only on video ad requests from apps (not on iOS or tvOS), so expect it to be empty elsewhere. A tracker that uses {CLICK_URL} is still left off, because Google would count a click every time the pixel loads. test_creative_macros shows the same conversions when you choose Google Ad Manager as the target.
• MCP requests now continue using the account selected with switch_account or customer_switch on later turns.
• When the web app fails to download its code while starting, it now retries once more after a short pause before giving up. If it still can’t load, the message says the page couldn’t finish loading and offers a Reload button, rather than pointing at a configuration problem.
• Buyers can stage media buys when a wholesale catalog product has an obsolete source-less duplicate alongside its sourced route.
• Delivery reads now return canonical revision finality and data-through when evidence exists, while clearly reporting unavailable evidence when it does not.
• get_products and request_proposals no longer hide a request that Apostra’s own pre-dispatch validation refused (for example, a brief that states a hard age targeting requirement). That seller’s storefront_results[]/perSeller[] row now reports status failed with a new local_refusal outcome carrying the original code, message, and a suggestion for correcting the request, instead of silently completing as an empty, successful catalogue. A seller refused this way is no longer counted as queried or searched.

​

5.948.0 — October 7, 2026 at 9:09 PM UTC

• Syncing a campaign’s creatives to its storefront media buys now fills each media buy’s own ids into the Apostra click and impression trackers and into the landing page they redirect to. Before, this sync sent {MEDIA_BUY_ID}, {PACKAGE_ID} and {CREATIVE_ID} as literal text, so clicks reached your landing page without the ids your attribution joins on. {PACKAGE_ID} is filled when the media buy has a single package and left empty otherwise.
• Reject impossible campaign and media-buy flight dates with a correctable validation error. get_status and flight-bearing saves now return UTC serverTime; refresh get_status before each relative-date calculation rather than reusing connection or save-receipt time.
• Managed FreeWheel connections now accept a buyer’s HTTPS VAST tag of any AdCP version, from 2.0 to 4.3, with no per-publisher enrollment. Previously only VAST 2.0 tags reached FreeWheel, and only on connections enrolled one by one; other tags failed creative sync with destination_profile_not_certified. The tag is sent to FreeWheel unchanged, and if FreeWheel refuses it, FreeWheel’s own validation error is returned on the creative result. Hosted video files still need a VAST tag for FreeWheel.
• Plan & Billing now shows how many accounts a plan allows, such as “Up to 100 accounts under this organization” on Business Manager, instead of an empty features line.

​

5.947.0 — October 7, 2026 at 8:24 PM UTC

• Adopt a direct provider’s active media-buy status when a materialised route is still pending.
• Sellers whose agents speak A2A can now discover Apostra’s request-signing keys from our agent URL. https://api.apostra.com (and https://api.interchange.io) serves an A2A agent card at /.well-known/agent-card.json and answers get_adcp_capabilities over A2A without credentials, with the same identity block it already returns over MCP and as a plain JSON GET. An A2A verifier that follows AdCP’s key discovery now finds our brand.json and signing key the same way an MCP verifier does.
• Automatic product selection now ranks sellers using only your own account’s completed buys with each seller. Other buyers’ results no longer move your ranking. Where you have no completed buys with a seller, its ranking rests on its product history alone, as it already does for a seller with no record.
• Billing links open Plan & billing on the tab they name again. For a live seller, a billing link from an email, a setup step or a plan offer opened Account settings → Plan & billing and then switched it to Overview, and could leave you on the home page with the pane closed. The pane now stays on the requested tab, including after you answer the Rate Card prompt with Not now; closing it returns you to your usual home. The admin and storefront billing links can now name a tab as well. Nothing to change on your side.
• A buyer agent with Read access to an advertiser can now run product discovery (get_products, discover_products), resolve a brand (resolve_buyer_brand) and preview creatives (preview_creative) for that advertiser through MCP api_call, and run discovery and brand resolution through REST. Before, api_call refused all four and REST refused discovery and brand resolution, treating them as changes because they are sent as POST. A hosted agent acting for a teammate with a Basic role gets the same reads. A catalog activation plan preview through api_call still needs Read and write.
• Saving a catalog activation plan through REST (POST .../catalogs/{catalogId}/activation-plan/preview with save: true) now needs Read and write access to the advertiser. A buyer agent granted only Read gets 403 ACCESS_DENIED and no plan is saved. Before, REST treated every preview as a read, so a Read-only agent could save a plan. Previews that do not save still need only Read.
• If your Buyer Account’s operator identity was locked by an advertiser before you chose its account scope, you can now confirm it as the whole operator yourself with save_buyer_operator, using the same operator domain. Previously this could only go through support, and the save failed. Once the scope is confirmed, new media partner connections can set up your advertisers’ accounts. A specific operating unit or a different domain on a locked identity still goes through support.
• Your Scope3 contact can now connect a shared Slack Connect channel to your account by asking Apostra in the channel, whichever organization created it. Until the channel is connected, Apostra answers there from public documentation only.
• request_proposals results are readable once a named seller answers. Each seller outcome includes the seller’s display name when it resolves, but the tool’s declared output schema didn’t list that field, so MCP clients that check responses against the schema got an error instead of the per-seller outcomes. The schema now declares sellerName.
• Activating an inventory source that a Sales Agent serves, before that Agent’s connection is ready, now returns a clear 409 CONFLICT with reason agent_connection_not_ready instead of an internal server error. The connection is ready when the Agent’s production certification is current and the connection passes its authorization, validation, health, and commercial checks. The source stays in its current status. Check certification on the Agent’s Test & certify page and the connection on the source’s diagnostics, then activate the source again. AAO compliance remains advisory and does not block this step.
• create_media_buys now advertises the request shape it actually accepts. The tool schema lists the inline campaign.create fields (advertiserId, name, flightDates, budget and mode: "discovery") and separate, closed shapes for proposal and product selections. A request that matches the advertised schema now passes validation. When a request is rejected, the error names the missing campaign.create fields instead of campaign: Invalid input, and an unknown key on a strict object lists the keys that object accepts.
• campaign.create.advertiserId, catalogId and each storefrontIds entry now take only a positive integer or a string of digits, such as 12345 or "12345", and the tool schema publishes exactly that rule. These fields used to coerce any value JavaScript’s Number() could convert, so true became ID 1 and [7] became 7. Values like true, arrays, "", "0", "01" or " 12" now get a 400 VALIDATION_ERROR that names the field and the accepted form. The same rule applies to POST /media-buys/batch, which create_media_buys calls. POST /campaigns is unchanged.
• Fixed storefront discovery so ordinary audience and content-suitability wording does not block discovery. If brief reading is temporarily unavailable, clearly stated age requirements still prompt buyers to use structured age targeting.
• Return a clear provider-read error instead of an internal server error when live campaign delivery cannot be read.
• Snap and Meta rejected media buys whose optimization goal names one of your own event sources. For buyers enrolled in the rollout, Apostra now sends the seller the pixel matched to that event source on the seller account (a Snap Pixel, Meta dataset or TikTok pixel) instead of your event source ID. If matching is still in progress, the buy is not sent yet; it is sent automatically once the pixel is matched, and the launch response lists it with SELLER_OBJECT_SYNC_PENDING. No action is needed while it waits. The buy fails instead with SELLER_EVENT_SOURCE_DESTINATION_MISSING when the seller account has no pixel or not the one you named, SELLER_EVENT_SOURCE_DESTINATION_AMBIGUOUS when it has several and you named none, or SELLER_DATA_SHARING_NOT_PERMITTED when the Conversion events switch is off for that seller in Connections. Create the pixel in the platform’s console or name one for each seller account with sellerAccounts on the event source, or turn the switch on, then create a new media buy. A seller that cannot use event sources, such as a managed seller agent or an AdCP agent outside Apostra, fails the buy with SELLER_OBJECT_TYPE_UNSUPPORTED. Seller-managed event sources and platform built-in events pass through unchanged, and the media buy keeps showing your own event source ID.
• If you administer a Partner organization with the paid or beta right to operate agents for clients, you can now check the health of any client source your sales agent powers in the source diagnostics widget, without a debug invitation. Call the open_partner_source_diagnostics MCP tool on the Storefront surface with the source’s bindingUid and, optionally, windowHours. The widget shows the source’s identity, health by operation, diagnosis and open operations. It is read-only: no finding offers a next step and there are no write outcomes. Findings owned by the client or Apostra show their code and owner with generic text, and an operation waiting on the client shows that it waits and since when, not what the client has to decide. A line says whether the client’s debug invitation is active and until when.
• Picking another window in the widget re-reads the source. The tool is listed only for administrators of organizations with that right.
• Nothing changes for clients, and there is nothing to do on your side. The REST read GET /api/v2/provider/account/connections/{bindingUid}/source-health was already available; this release adds the widget and the tool. See “Read one client source’s health” in the Partner account docs.
• save_event_source now accepts up to 50 seller accounts per event source in one save, up from 20, and at most 200 seller accounts across all event sources in one save. A save over 200 is refused with VALIDATION_ERROR before anything is saved. Each entry still names a connected seller account and the pixel to use on it.
• Products from a managed sales agent keep the demographic targeting the seller declares, such as supported age ranges, in its AdCP 3.2 shape. Buyers reading AdCP 3.2 product capabilities now see it for these products, as they already did for other sellers.
• On Google Ad Manager storefronts, a creative that a buyer assigns to specific placements now serves only on those placements. Before, the placement choice was accepted and then ignored, so the creative served across the whole package. If a storefront’s ad server can’t route creatives by placement, a buy that asks for it is now refused up front instead of serving everywhere. A media buy that fails while its ad-server order is being set up is now closed out cleanly instead of being left looking active. Signals a seller marks as exclude-only can now be used to exclude an audience in the newer signal-targeting format (AdCP 3.2), and are refused if a buy tries to include them. No action is needed.
• Embedded sales agent 1.61.0: audit MCP credential headers that adcp 9 will refuse.
• Embedded sales agent 1.61.1: send the buyer-visible status on account.status_changed webhooks.
• Campaign execution now reports attempted, successful, and failed media buys separately. mediaBuysExecuted keeps its published attempted-count meaning; use the new mediaBuysSucceeded count to identify successful executions. Proposal requests also preserve the local brief-validation reason when it blocks a round.
• Country-specific advertisers can now hold separate seller accounts under the same brand on AdCP 3.2. When Apostra syncs an account to a seller that speaks AdCP 3.2, the brand now carries the advertiser’s countries (for example ["NL"]), because AdCP 3.2 counts countries as part of the account key. Sellers on AdCP 3.1 or earlier still receive only domain and brand_id, and an advertiser with no country scope still sends none. Storefronts hosted on Apostra now accept brand.countries in sync_accounts for AdCP 3.2 complete-key accounts: two requests that differ only by countries create two seller accounts, while the same countries in a different order or case resolve to one. A request that sends brand.countries without negotiating AdCP 3.2 is still refused with adcp_3_2_account_identity_not_supported, and the former seller_account_country_identity_not_supported error no longer exists. Existing seller accounts and advertisers do not change, so nothing to do on your side.
• Offline conversions sent to Meta are now recorded as “other” instead of “website”, so Meta no longer reports them as website conversions. Meta accepts these events for up to seven days. An older offline or “other” event now comes back as its own entry in partial_failures with code META_EVENT_TOO_OLD, and the rest of the batch is still sent. Nothing to change on your side.
• When your agent rejects requests we signed, source diagnostics now say so. Previously the source was described as having “stopped responding, so its inventory can’t sell until it reconnects”, or as an error diagnostics “could not classify”. The diagnosis now:
• reads that your agent rejected our signed requests;
• shows your agent’s own reason in Technical details;
• tells you to fix your signature verifier;
• links the “Our signed requests rejected” troubleshooting section.
• The API response shape is unchanged.
• When your agent rejects a request we signed, your source diagnostics now show your agent’s own reason. Previously they showed a generic authentication message, and at one point told you to add an OAuth token. The diagnosis records your agent’s request_signature_* error code when it sends one, otherwise the text of its 401 response (code signed_request_rejected). This covers discovery, catalog refresh and the discovery test. A new troubleshooting section, “Our signed requests rejected”, explains how to fix your verifier, most often by resolving our signing key from our agent URL. Buyers still see only that the source rejected the request, never your agent’s text.
• When your agent rejects a media buy (create or update) or an account sync that we signed, your media buy timeline now shows your agent’s AdCP request-signing error code (or signed_request_rejected when it sends none) instead of a generic authorization failure or no code at all. We also store the text of your agent’s 401 response with each rejected attempt, so our support team can see your agent’s own reason. Buyers still see only that the source didn’t authorize the request.
• Wholesale catalog duplicates without a source are no longer retained when a sourced route is available.
• A newly created account, such as a new Demo Storefront, now appears in the account switcher of your other tabs as soon as you reload them. Before, it could stay missing for several minutes.
• The “Verifying our signed requests” guide now answers the questions sellers hit while building a verifier:
• How you know a request is from Apostra. Nothing in the request names the signer. You set us up once as agent https://api.apostra.com, and the signature’s keyid must resolve to a key in that agent’s JWKS.
• keyid is a bare key ID, never a URL.
• Two separate checks. The signature proves who sent the request. The brand’s authorized_operators says whether an agency may act for that brand. The agency named on an account never lists or vouches for the buying agent.
• Which direction. Verifying our requests needs no JWKS or brand.json of your own. Signing the webhooks you send us is covered separately.
• Check your setup. npx @adcp/sdk@latest resolve https://api.apostra.com shows each step of key discovery against our live agent.
• The identity documents page also clarifies that a brand.json listing an agent belongs to whoever runs that agent, not to the agency on an account.

​

5.946.8 — October 7, 2026 at 2:34 PM UTC

• Buyer MCP connections that select an advertiser can call every buyer tool their role allows again. Billing account, buyer readiness, buyer activity, storefront account and media-buy update calls no longer fail with “Tool is not available for this advertiser” when the connection names an advertiser. Your role and your access to that advertiser still decide what each call can read or change. Nothing to change on your side.

​

5.946.7 — October 7, 2026 at 1:54 PM UTC

• The V3 search for wholesale_product with include: ["executionResources"] now lists options for products from Meta, TikTok, Snap and LinkedIn. It used to answer “Wholesale product not found for this advertiser” for every product from those sellers, even when the productId came straight from your search.

​

5.946.4 — October 7, 2026 at 12:29 PM UTC

• Signals you’ve set up as a fixed key-value pair, or as a combined signal (several criteria that must all match), now work on media buys sent in the newer signal-targeting format (AdCP 3.2). Before, those buys were refused. Buys using your audience-segment and Google Ad Manager key signals work as before. No action is needed.

​

5.946.3 — October 7, 2026 at 12:03 PM UTC

• Approved creatives without an explicit format option can now use the media buy’s exact booked product format when the seller advertises AdCP 3.1, including alongside 3.2. Existing creatives can be delivered without being recreated, while modern routes without complete exact booking evidence keep their existing canonical format declaration.

​

5.946.2 — October 7, 2026 at 11:42 AM UTC

• save_media_buy on the v3 agent surface now accepts pageId, instagramActorId, welcomeMessageFlowId, leadFormId, and appId on products[] when staging a new media buy. These are the same provider resource choices a product’s execution readiness can report as required (which Facebook Page, Instagram account, Messenger/WhatsApp welcome flow, lead form, or app to use); previously only pixelId was available on v3, so buyers who needed one of these had to fall back to v2 create_media_buys.

​

5.946.0 — October 7, 2026 at 10:46 AM UTC

• Meta product discovery now returns only the campaign products Apostra has verified end to end. Fifteen products that are still being verified no longer appear in standard discovery: Leads (Instant Forms, quality leads, Messenger, Instagram, WhatsApp and Calls), Messenger and WhatsApp conversations, Instagram profile visits, event responses, the three App Promotion products, catalog and Shop sales. A brief that asks for one of them returns a clarification instead of a plan. The Meta compatibility guide shows each product’s current status.
• The V3 search for wholesale_product can now list the options behind a product’s execution readiness. Add include: ["executionResources"] with the product’s productId and a resourceKind such as platform_identity, and each row is one option you can choose, such as a Facebook Page or pixel, paged with nextCursor. The first call asks the seller and may ask you to poll until the list is ready.

​

5.944.0 — October 7, 2026 at 6:21 AM UTC

• Poll a pending Apostra API write by receipt ID to learn its operation state and next step.

​

5.943.1 — October 7, 2026 at 5:59 AM UTC

• The account switcher in the top bar now only switches accounts. It no longer shows an organization heading, an organization settings gear or an Add account button, and it appears only when there is an account you can open other than the one you are in, or an invitation waiting. Choosing another organization’s account opens that account, never a different one picked for you. Organization settings stay in Account settings → Organization. Administrators of a standalone account now add accounts from a new Accounts item in Account settings, which explains that adding one creates an organization for both accounts. No action is required.

​

5.943.0 — October 7, 2026 at 5:21 AM UTC

• When you connect an external Sales Agent, Apostra now links it to the one registered Agent with the same endpoint or origin when that Agent is ready to accept a new Source. If there is no single ready match, choose an Agent from the Source page instead. Existing Agent links do not change when you update an endpoint. This only changes seller setup; buyers do not see a change, and it does not change plans or billing.

​

5.942.0 — October 7, 2026 at 3:00 AM UTC

• Account admins can now create inbound email addresses for briefs and reports, optionally for one of their advertisers, and rotate or revoke them without contacting support. Each address has a readable prefix and an unguessable suffix. Mail to an unknown, rotated or revoked address is refused. An address tells Apostra which account an email belongs to, never who sent it. Mail that arrives is recorded privately in your account; Apostra does not read or act on it yet. Inbound email is in a limited pilot: today only enrolled accounts can create or rotate addresses. Any account admin can list and revoke them. For other accounts, creating or rotating an address through the API or MCP returns FEATURE_NOT_ENABLED. See Inbound email addresses.

​

5.941.0 — October 7, 2026 at 2:21 AM UTC

• If you reload a tab that was switched into an account you can no longer open, for example one that has been archived, the app now takes you back to your home account instead of showing an empty page for the old account.

​

5.940.1 — October 7, 2026 at 1:39 AM UTC

• An image Creative Session draft that names no size or aspect ratio now generates a square 1024 by 1024 image, so generate_variants no longer fails on it; the saved plan’s params shows that size. If a request is refused before any provider is contacted, the result now says so, says no provider charge occurred, and says how to fix it, for example by setting params.width and params.height. Nothing to change on your side. A draft that names only a width or only a height is still refused until it names both, and drafts saved before this change keep their saved request.
• Buyers who have no account yet with a seller get that seller’s live products again. We create the account with the seller automatically, as before, and reuse the seller’s account ID for later requests.
• Every storefront listed in the account switcher now shows its status line. Before, a storefront that appeared in the list because it shares your organization, without your being a member of it directly, showed no status. This affected a new Demo Storefront, for example.

​

5.940.0 — October 7, 2026 at 1:14 AM UTC

• Voice drafts now recognise the language and length you ask for in the brief (for example “a 15-second Japanese radio spot”), so they no longer show false “no language” or “no duration target” warnings. Nothing to change on your side.
• When you ask for proposals without naming sellers or setting a seller list on the campaign, Apostra now contacts only the media partners turned on for the campaign’s advertiser. Partners that are off are no longer contacted or reported one by one. If no media partner is on for the advertiser, the request ends with a message saying so and where to turn one on: open Media Partners for that advertiser, open a media partner, choose Controls, then set Availability to On. Nothing to change on your side.
• Your connected Sales Agent’s product mode now follows its declared AdCP buying modes after a capability refresh, so a wholesale declaration no longer needs a staff-set mode.
• Execute media buys with hosted-video creatives that match a seller’s selected format option.
• Storefront proposal requests with composed products now keep the proposal record needed to attach a pitch. Nothing changes in the products buyers receive, and sellers do not need to take action.
• A seller whose only open setup item is an ad-server go-live certification (such as the Google Ad Manager write canary or the FreeWheel booking certification) now stays visible to buyers. Buyers can search its products and add them to a buy they are planning; booking with it is refused with a message saying the seller has not finished going live, instead of saying the seller is off for the advertiser. Sellers see the certification as its own readiness item, esa_go_live_certification, and booking opens once it passes. Discovery now also names a seller that cannot be searched for any other reason as not available to buyers, rather than as off for the advertiser.
• Library Materials now support Draft review, including seller-confirmed descriptions and the media_kit category. Existing uploads continue to become Live; a later Library update will add upload Draft review. V3 search: the Material filter archived is replaced by materialState (live, draft or archived); update calls that used filter.archived.
• Administrators of a Partner with the paid or beta right to operate agents for clients can now read the health of any client source their agent powers, without waiting for the client to invite them to debug it. Call GET /api/v2/provider/account/connections/{bindingUid}/source-health. It works as long as the client still authorizes your agent for that source, and the connection does not have to be activated, so you can diagnose a source whose validation is failing.
• You get the same source health object the client sees (health by operation, diagnosis, open operations), with these limits:
• No finding offers an action. You act through your own agent, not on the client’s behalf.
• A finding the client or Apostra owns keeps its code, owner and severity, but its text is generic.
• An operation waiting on the client shows that it waits and since when, not what the client has to decide.
• writes is null, as in the client’s own read.
• Request and response bodies stay withheld unless the client has an active debug invitation for that exact source.
• Nothing changes for clients, and there is nothing to set up on your side. This is an API read for now, with no screen for it yet. See “Read one client source’s health” in the Partner account docs.
• Embedded sales agent 1.59.1: publish each undeclared product with the targeting its ad server applies, validate overlay_support with a resolver of its own on each request thread.
• From October 8, 2026, wholesale products you create on a managed sales agent, in Inventory Components or through your storefront agent, must declare their AdCP channels, such as display, olv, ctv, or streaming_audio. A create without them is refused, and the error names the field to add. The same date applies to avails feed rows: a row with no channel and no default channel on the request is refused with CHANNEL_MISSING. Until then, both are saved with a warning. Products and rows you already have keep working, and editing an existing product is not affected.
• Products from third-party sales agents are not refused for missing channels. The Product channels declared warning stays a warning, and certification never fails an agent for missing channels alone. This replaces our earlier note that channels would become required for external agents’ products. Whether they become required is for AdCP to decide: a proposal to require channels on every Product in AdCP 4.0 is open as adcontextprotocol/adcp#7869.
• Fixed creative sync and media-buy execution to reuse a seller’s resolved account ID and stop before launch when account linkage is missing.
• A creative delivery no longer stays “processing” after every seller it was sent to has accepted or rejected it. Interchange now checks for these deliveries every few minutes, sets each one to its final result, and sends your webhook the usual final update. Deliveries still waiting for a seller’s review are unchanged and stay open until the seller decides. Nothing to change on your side.

​

5.939.0 — October 6, 2026 at 11:43 PM UTC

• V3 save_media_buy now honours idempotencyKey on flight and budget updates, as its description promised. Retrying an update with the same key and the same request returns the first result instead of applying the change again (unless the buy has changed in between, in which case the retry is refused against its current state), which matters when a slow response is retried while the seller is still confirming. The same key with a different request is refused, and a key still in use returns a retry-after time.

​

5.938.1 — October 6, 2026 at 11:21 PM UTC

• Launching a media buy now stops before seller submission when every selected creative is excluded, explaining the creative and competing format options so the buyer can select an explicit format option.
• A source’s open operations, shown in its source health, no longer list creatives you have not approved yet. No source receives a creative before your review, so these creatives were listed against a source that had never been asked about them, some since July. They still wait in your creative reviews, and they appear on the source once you approve them and delivery starts. Nothing to change on your side.
• V3 save_media_buy can now change the budget of a media buy that is already live. Send the line item’s new total, including what it has already spent, in products[].budget (or a top-level budget on a buy with one line item). Pacing periods that have ended keep their budgets, the open periods share the rest in their current proportion, and the change waits for the seller to confirm as before. Before, a live buy’s budget change was refused once its packages were deployed. A total below what the ended periods hold plus what the open periods have spent is refused with that amount. When the same product appears as more than one line item, name the one to change with products[].lineItemRef.

​

5.938.0 — October 6, 2026 at 10:51 PM UTC

• Third-party sales agents now receive a debug ID on Interchange requests, so support teams can match a seller log line to the matching Interchange request.
• A creative delivered from the Creative Library to a sales agent is now sent once after the seller accepts it. Before this fix, routine background status checks on a seller’s sales agent could make Interchange send an already-accepted creative to that sales agent again, about every 15 minutes, and send the buyer’s webhook a fresh status update each time. A creative is still sent again when the sales agent it goes to actually changes, for example a new address or a different sales agent. Nothing to change on your side.

​

5.937.1 — October 6, 2026 at 9:58 PM UTC

• Voice clips for Chinese, Japanese and Thai scripts are now checked against the right expected length. Previously a long script in one of these languages could be accepted even when the generated clip was cut off after a second or two; those clips are now rejected as too short, like they already were for English.

​

5.936.0 — October 6, 2026 at 9:33 PM UTC

• Embedded sales agent 1.58.1: send each caller get_adcp_capabilities targeting in the shape its AdCP release defines.
• Discovery now requires exactly one existing seller account. If no exact account exists, or several accounts match, create, link, or resolve the seller account before retrying. Later account-scoped requests reuse its opaque account ID.
• On an inventory source’s diagnostics page, choose Source health to see one source’s health in one place: which seller account, source and Agent you are looking at and whether buyer requests reach it; the status of each AdCP operation Apostra performs against it, with its last success and last failure; each finding with its severity, who has to act and the next step; and the operations still waiting at the source, with who they are waiting on and since when. The window selector sets the period the counts cover. Nothing changes on your side, and the existing overview, setup and technical details are unchanged.

​

5.935.2 — October 6, 2026 at 8:34 PM UTC

• When the agent on your agent phone line answers a text, its reply is now added to the same conversation record as the text it answers, once for each reply. Like the texts, the reply is recorded without its words or the number it goes to. A reply to a text received before texts were grouped into conversations is not added. The record is still not shown anywhere and the agent does not read it, so nothing changes in how or when the agent replies.
• When a seller turns down a media buy after you submit it, or it never goes through, your create_media_buy task now always ends as failed. Before, a brief fault on our side at that moment could leave the task pending for good. Apostra now keeps retrying that update in the background until it lands.
• Nothing to change on your side.

​

5.935.1 — October 6, 2026 at 8:10 PM UTC

• A Scope3-funded creative preview that is refused before it reaches the provider now always gives its daily preview unit back, even if the database hiccups at that moment. Before, a brief database error could leave the refused request counted against your account and the global daily preview caps until the next UTC midnight.
• Retrying the same generation after such an error now completes the refund exactly once. Nothing to change on your side.
• Apostra pricing and documentation now use Enhanced Reporting consistently for the connected-account reporting activity at 4 IUs per eligible account and billing period.

​

5.935.0 — October 6, 2026 at 7:26 PM UTC

• Fixed legacy creative re-syncs so they can add the format route required for delivery without changing any other stored sync identity.
• When you update a media buy that a seller is already running, a property-list or collection-list reference you set on a package is now sent only if that seller declares it can apply that exact list field. If the seller doesn’t, the update stops with a validation error naming the package, the list field and the seller, and nothing is changed or sent. To proceed, remove the reference from the package or move it to products whose seller declares that field. Draft buys are checked when you launch them, as before.
• Saving a generated creative to your Library from the variant gallery still shows “Saved to your Library.” even if the host can’t record the matching chat activity, and a reload never posts that activity twice. We now report a failed or timed-out activity write so we can see it happening.
• V3 save_media_buy can now change the end date of a media buy that is already running. Send the buy’s current flight.startAt unchanged with the new endAt, and the start is left alone. Before, every way of sending a start was refused once the buy had started, so a running buy could not be extended or ended early through V3. A different start on a running buy is still refused.
• The docs now have a Get support page (/v3/support) explaining how to ask the in-product assistant and how to reach the support team, with what to include in a request. Apostra’s ChatGPT app listing links to it as its support page.

​

5.934.0 — October 6, 2026 at 6:40 PM UTC

• Texts sent to your agent phone line are now kept for 30 days. After that, Apostra deletes a text’s words and the number that sent it, except that a text the agent is still working on or waiting to answer keeps them until the agent has finished with it. Only the record that the text arrived, and what happened to it, remains. Ordinary texts from one number to one line are also grouped into a single conversation record for your Seller Account. The record holds neither the words nor the number. Opt-out, opt-in and help keywords are left out of it, and so is a text that arrives after its number has opted out. A text recorded before its number opted out stays in the record even if the agent never answers it. The record is not shown anywhere yet and the agent does not read it, so the agent still answers each text on its own, and nothing changes in how or when it replies.
• Fixed: a buyer agent calling list_campaigns or get_campaign through the MCP api_call tool could not read the campaigns of an advertiser another organization delegated to yours. The call was refused with agent_read_only even when the delegation included campaign.read. Both reads now work through MCP as they already did over REST, and each campaign read this way carries delegatedBy. The agent still cannot change anything on the delegated advertiser. Limited beta: available to organizations with the advertiser delegation entitlement.
• When a seller’s sales agent pauses a media buy create or update for more input (the AdCP input-required status), Apostra now fails it as soon as it sees the pause, instead of leaving it pending for up to seven days. The input the agent asks for is Apostra’s to give, and Apostra cannot supply it yet, so waiting would never move it.
• Buyers: a create the agent pauses fails straight away, either in the create_media_buy response or as a failed task if the pause comes later. Its notification carries errorCode: platform_error. A paused update fails the same way and leaves the buy unchanged.
• Sellers: on your media buy list, the buy shows errorCode: source_input_required, and its next action names the platform, so there is nothing for you to do. It no longer appears as open work in Pending Operations or in source diagnostics.
• Nothing to change on your side.
• Embedded sales agent 1.58.0: each product’s declared targeting is now checked when a buy is booked or updated, in report-only mode — what would be refused is logged and the buy books as before, until enforcement is switched on per seller. Products with no declared targeting are not checked. get_products filters by required_overlay_support. The sales agent now advertises only the targeting each ad server applies, and refuses targeting an ad server can’t apply instead of dropping it. Also: live GAM geo targeting in the GAM snapshot, the geo code systems each adapter reads for metro, postal and place targeting, an auto-provisioning account reported as active rather than pending_approval, and GAM’s legacy time zone ids resolved in the production image so read-backs compare flight dates.

​

5.932.0 — October 6, 2026 at 4:37 PM UTC

• The V3 search for wholesale_product can now tell you whether each product can be bought on the advertiser’s connected ad account. Add include: ["executionReadiness"] and each row carries an executionReadiness summary when its seller reports it (currently Meta, TikTok, Snap and LinkedIn): an overall status, plus each account resource the product needs, such as a Page or pixel, with what’s missing, the option already chosen, and how many options there are. Without the include, rows are unchanged.

​

5.931.0 — October 6, 2026 at 4:09 PM UTC

• Pending Operations now says who each pending item is waiting on, and lists more of what is waiting at your sources. Every approval, creative review, buy awaiting its source, and manual modular-source task carries waitingOn: who must act next (you, the sales agent’s operator, the buyer, or Apostra), since when, and the exact thing being waited for, such as your approval or the task id the sales agent returned. Behind Apostra’s managed sales agent, a buy held at the source is shown as waiting on you, because the review it is waiting for is in your own ad server. Two new groups list changes to live buys that a source has not applied yet (updatesAwaitingSource) and approved creatives a source has not accepted yet (creativesAwaitingSource). The Pending Operations Page shows each item’s “waiting on … for …” line and the two new groups. Nothing to change on your side.

​

5.929.0 — October 6, 2026 at 3:29 PM UTC

• When you launch a media buy, a property-list or collection-list reference you set on a package yourself is now sent only to a seller that declares it can apply that exact list field. If the seller doesn’t, the launch stops with a validation error naming the package, the list field and the seller, and nothing is sent, so a buy can no longer run with a list the seller was never obliged to apply. To proceed, remove the reference from the package or choose products whose seller declares that field. A collection-list reference also needs a product that allows collection targeting. Lists you manage on your advertiser and campaigns are unchanged by this release.
• Inventory source diagnostics now list what is still waiting at each source, and on whom. sourceHealth.operations on GET /api/v2/storefront/inventory-sources/{sourceId}/diagnostics was always null; it now lists every open media buy, update, creative delivery, manual work item, and account request at that source. Each entry says who it is waiting on (seller, operator, buyer, or scope3), since when, and the exact thing being waited for, such as your approval, the task id the sales agent returned, or the creative still to be delivered. An entry is listed for as long as it is open, from its first minute, rather than only after a time limit runs out. When you share diagnostics with an Agent’s operator through a debug grant, they see that an operation is waiting on you but not what you have to decide. Nothing to change on your side.

​

5.928.0 — October 6, 2026 at 2:31 PM UTC

• A buyer agent can now read the campaigns of an advertiser another organization delegated to yours, when that delegation includes campaign.read and the agent holds a READ grant on the advertiser. Pass the advertiser’s ID to list_campaigns, or read one of its campaigns with get_campaign. Each campaign read this way carries delegatedBy with the owning organization’s name. get_campaign_delivery returns the delivery Apostra last stored for that campaign, marked authority: "platform_mirror", rather than calling the seller live. The agent’s session stays on your account, and nothing on the delegated advertiser can be changed. A delegation with advertiser.read only is still refused, and the error now names the missing campaign.read. Limited beta: available to organizations with the advertiser delegation entitlement.
• Choose an IU plan now uses the same design as Plan & billing. The plan cards, the review-and-authorize step, and the renewal controls are redrawn on our current design system, the accept and Done buttons sit in a consistent bar at the bottom of the panel, and the loading and error states are drawn inside the panel instead of appearing as loose text.
• Nothing about the plans themselves changed: the same prices, terms, rollover, and renewal rules, confirmed the same way, against the same offer version you were shown.

​

5.927.1 — October 6, 2026 at 2:02 PM UTC

• Fixed Scope3-funded voice drafts failing on short radio spots. A correctly read one-line script, such as a six-second read for a 15- or 30-second slot, is now accepted. Generated audio is checked against how long your own script takes to speak, so near-empty or undecodable audio is still rejected. A failed voice leaf now names a short reason, such as generated_audio_too_short, in the generation result.

​

5.927.0 — October 6, 2026 at 1:24 PM UTC

• On the v2 Buyer MCP, opening the Campaigns Page now also returns an “Open in the browser” link in the text result, and as openInBrowserUrl in the structured result, whenever the Page has an advertiser: the one you name (once the server confirms you can read it), the launched campaign’s advertiser, or the advertiser your connection selected. Hosts that cannot show the Campaigns widget, such as Claude Code, Slack agents or a plain MCP client, can use that link to open the same Page in Apostra chat, focused on the campaign you named. A launch with none of these, or from a seller account, carries no link. Nothing to change on your side.

​

5.926.0 — October 6, 2026 at 1:10 PM UTC

• Buyers can reopen the Variant gallery for an existing Creative Session after search or get, including advertiser Library sessions and sessions whose text response was truncated.

​

5.925.0 — October 6, 2026 at 12:44 PM UTC

• Sellers can now edit their listing’s website, support, privacy policy and terms of service links from the media kit, under Your listing, What you do, Edit. These links appear on your ChatGPT app listing and your other channel listings.
• Confluence library syncs now accept documented response shapes, so sellers can import pages and supported attachments from affected spaces.

​

5.924.0 — October 6, 2026 at 12:13 PM UTC

• Sellers can now discover Apostra’s request-signing keys from our agent URL, as AdCP describes. https://api.apostra.com (and https://api.interchange.io) answers get_adcp_capabilities without credentials, over MCP and as a plain JSON GET. The response’s identity block names our brand.json and the origin of our signing keys, so a verifier that follows AdCP’s key discovery no longer fails with request_signature_jwks_unavailable or request_signature_brand_json_url_missing. The authentication docs now describe this path, and note that verifiers should resolve our key from our agent URL, not from the account’s operator.
• Keep your selected seller account available when a v3 MCP client reconnects, so you can continue using seller tools after switching accounts.
• Microsoft 365 Library sync now imports Word documents as readable PDF Material revisions.
• Seller agents can now set the listing’s subtitle, website, support, privacy policy and terms of service links through save_seller’s listing field, and read them back with get on the Seller with include: ["listing"]. These are the values the ChatGPT app listing and its submission package use.

​

5.923.0 — October 6, 2026 at 11:04 AM UTC

• V3 media buys now show a change that is not live yet. get(kind: "media_buy") returns pendingChange whenever a buy has a submitted change that has not reached the delivering buy: its status, where it is waiting, and how the end date, budget, and creatives will differ. Every other field still shows what is live. save_media_buy returns action: "pending_approval" instead of updated when the buy it reads back still has such a change, so your agent no longer tells a buyer a change is live before it is.

​

5.922.3 — October 6, 2026 at 10:34 AM UTC

• Murph now sends requests for radio spots, voiceovers, and other new audio creatives to Creative Engines generation instead of file upload. Eligible preview buyers without an ElevenLabs or AudioStack connection can leave the engine unset to use Scope3-funded ElevenLabs.

​

5.922.2 — October 6, 2026 at 9:55 AM UTC

• Storefront media buys now send creatives to the exact sales source selected for each product before the buy is submitted. Buys stop with a clear error when that source is missing, inactive, or ambiguous, instead of waiting indefinitely for creative delivery.

​

5.922.0 — October 6, 2026 at 9:30 AM UTC

• If you operate a Sales Agent, its Agent page now shows how many of its products declare AdCP channels, as an advisory note under the Catalog Product Quality certification requirement (for example, “Advisory: 9 of 12 products declare AdCP channels”). The count matches the Product channels declared readiness warning and covers up to 50 of the active third-party Sources you can see for the Agent (the page says when there are more). It never changes a certification result. Declaring channels on every Product, or applies_to_channels on each format option, is how you raise it.
• request_proposals results stay readable once sellers answer. A buyer agent whose MCP client checks responses against the tool’s declared output schema could get a schema error instead of the per-seller outcomes as soon as a seller’s answer was recorded, so it couldn’t see quotes, products or why a seller didn’t respond. Each seller outcome now contains only the fields the tool declares.
• An Agent’s required capability declarations now count the creative kinds that products from a managed sales agent accept, and they still load when a product reports no format options. Media-buy targeting checks now see the targeting a managed sales-agent product declares in overlay_support.
• When a media buy sets up a new account with a seller, the brand reference now carries a brand_id only when the advertiser’s brand declares one (in the saved brand reference or the brand’s brand.json). Earlier account setups could add a generated brand_id the brand never published, and sellers opened a separate account for it. Later product discovery for the same brand and operator could then fail with ACCOUNT_AMBIGUOUS.
• An account that a seller already holds under a generated brand_id keeps its identity:
• If Interchange can find that account, it updates it by its account_id.
• If it can’t look the account up, it sends the generated brand_id only when the seller’s acceptance of that identifier for the same account (same operator, same sandbox setting) is on record, so live buys stay on their account.
• Nothing to change on your side. A seller holding a duplicate account can remove it once no live buy depends on it.

​

5.921.1 — October 6, 2026 at 8:49 AM UTC

• Embedded sales agent 1.57.1: refuse GAM targeting the line item would silently drop, stop FreeWheel booking certification blocking go-live until publishers can run it.

​

5.921.0 — October 6, 2026 at 8:28 AM UTC

• The Library’s sections are now shown as tabs.
• Org admins of any organization, buyer or seller, can now save a card as the organization’s payment method in Plan & Billing → Payment & invoices. Saving a card charges nothing, and it doesn’t accept an IU Rate Card, select a plan or turn on paid entitlements. Eligible Apostra platform and IU charges are collected from the card only when the organization has an accepted IU Rate Card and its IU charging is enabled. Invoicing on payment terms is still available, media billing is unchanged, and no card processing fees are added. Only org admins can add, replace or remove the card; other members don’t see the option. Nothing to change on your side unless you want to pay by card.
• Recheck payment-terms-held seller-account setup through the buyer’s current billing organization within an hour, so a buyer reparented under an organization that has already chosen terms can continue setup automatically.
• Healthy external inventory sources remain discoverable when their public product catalog can serve buyers, even if another source has an ad-server setup or wholesale-pricing problem.
• Restore the verified audio_30s selection on the affected Draft Digital to Talpa media-buy route. The repair checks the exact source, route, package and archived product version before changing the historical snapshot; every other buy is left unchanged.
• When you launch a media buy, every package now tells the seller how to pace its budget. Packages had only carried pacing when you set it on the individual product line, so a campaign set to EVEN sent no pacing at all, and a seller could fall back to spending as fast as possible.
• Each package now uses the pacing you set on its product line. Without one, it uses the campaign’s budget.pacing. If neither is set, it uses even, AdCP’s default. The pacing you read back on a package is the pacing its seller applies.
• Meta does not accept a pacing field yet. An even pacing is left off Meta requests, because AdCP treats a missing pacing as even and Meta’s standard delivery already spreads spend evenly. A Meta buy on an ASAP or FRONTLOADED campaign still launches on that even delivery, and the launch response carries a pacing_not_applied warning naming the pacing you asked for and what Meta applies instead.
• Changing a campaign’s pacing does not change media buys that are already live. Update the package’s pacing directly instead. You do not need to change anything else.

​

5.920.0 — October 6, 2026 at 7:38 AM UTC

• Proposal requests now send a campaign’s saved demographic targeting to storefronts on the Storefront-built and Agent-supplied paths as the AdCP 3.2 targeting_overlay.demographics field, so those storefronts apply the campaign’s exact age range. Built-in platform adapters and external sellers still receive the brief only.
• Embedded sales agent 1.57.0: add a read-only GAM line item cap audit ops script, refresh each live package’s GAM readback on every scheduled read and flag spend-unsafe drift.

​

5.919.0 — October 6, 2026 at 6:07 AM UTC

• When a seller’s sales agent pauses a creative for more input (the AdCP input-required status) instead of accepting or rejecting it, Apostra no longer reports that the agent rejected the creative.
• Sellers: the creative’s delivery now fails as delivery_failed rather than source_rejected, so it no longer reads as a rejection the buyer must replace. If the agent pauses the creative after first accepting it, the delivery fails as soon as Apostra sees the pause, instead of waiting up to seven days. A sales agent that answers a buyer’s creative sync with submitted, working or input-required is no longer marked unhealthy in source diagnostics.
• Buyers: on a media buy, that creative’s sales-agent entry shows the delivery as failed with no rejection reason, instead of rejected by the sales agent.
• Nothing to change on your side.
• A media buy on inventory trafficked in Google Ad Manager through a managed sales agent now goes active only after Google Ad Manager confirms its line items hold the booked spend cap, pacing, price, currency and flight dates. Until then it reads pending_start. If a new buy or a resume leaves the line items without the booked budget cap or pacing, Apostra pauses them: a new buy stays pending_start, and a resumed buy stays paused with the resume failing as AD_SERVER_UNCONFIRMED. If a live buy’s line items are later changed in Google Ad Manager so they can spend past the booking, Apostra pauses them and alerts its operations team. If Google Ad Manager holds other different settings, Apostra’s operations team is alerted and works with the seller to correct them. Buys on other sources are unchanged.

​

5.918.1 — October 6, 2026 at 5:37 AM UTC

• list_buyer_storefront_accounts, and GET /api/v2/buyer/storefront-accounts, now also show whether the seller is on for an advertiser: the one you name with the new optional advertiserId, or the one your request selects. The answer is in ext.interchange.advertiser_activation, so an active account grant no longer looks as if the seller is in use for that advertiser. Product discovery for an advertiser now also says which sellers it left out because they are not on for that advertiser: get_products lists each one in ext.interchange.storefronts_not_searched with its reason, including sellers that cannot transact with you at all, gives the fix once, and names them in its text summary. Before, it only counted them. Two product-discovery skip reasons are also corrected. A seller that ran out of time now always reports failed with reason timeout, never skipped. A seller skipped for an eligibility reason now reports eligibility instead of coverage. Nothing to change on your side.

​

5.917.0 — October 6, 2026 at 4:35 AM UTC

• If your organization has accepted an advertiser delegation from another organization, you can now give a buyer agent read-only access to that advertiser. Nothing changes until an administrator grants it through the buyer-agent access API; the console’s advertiser picker does not list delegated advertisers yet. Grant READ; READ_WRITE is refused. The advertiser then appears in the agent’s advertiser lists, tagged with the owning organization’s name. The agent’s session stays on your own account, and the owning organization’s accounts are never listed or selectable. When the delegation ends, the advertiser drops out of the agent’s lists and every request for it is refused. Limited beta: available to organizations with the advertiser delegation entitlement.

​

5.916.0 — October 6, 2026 at 4:05 AM UTC

• You can now read the health of an inventory source from one sourceHealth object in the diagnostics response (GET /api/v2/storefront/inventory-sources/{sourceId}/diagnostics). It names the Agent that powers the source and whether buyer requests reach it. Each AdCP operation Apostra performs against the source, such as get_products or create_media_buy, gets a status of healthy, degraded or erroring, or null when nothing has been observed. It also lists each problem found with who has to act (you, the operator of the Agent behind the source, or Apostra), how serious it is, and the next step. The inventory source diagnostics page in the docs lists every field.
• No action is needed now. sourceHealth is additive, and the source.health, source.capabilityHealth, diagnosis.severity, diagnosis.owner and diagnosis.issues fields are deprecated in its favour. They are still returned unchanged. Move to sourceHealth when you next update your integration.

​

5.915.2 — October 6, 2026 at 3:41 AM UTC

• A media buy whose seller confirms it as already paused or completed on its very first response now gets its internal activation timestamp recorded, the same as a buy that confirms active. Previously this timestamp was only recorded for the active case, which could cause unrelated reconciliation checks (including update_media_buy’s failure reporting) to behave incorrectly for a buy created this way.

​

5.915.0 — October 6, 2026 at 2:58 AM UTC

• A pause that a seller accepts but has not applied yet is no longer shown as paused. When a seller answers with “accepted, still processing”, pausing a media buy now returns 202 Accepted with pauseRequestedAt, and the buy stays ACTIVE (it may still be delivering) until the seller reports it paused; GET /media-buys/:mediaBuyId shows pauseRequestedAt until then. A campaign pause waiting on such a seller returns 503 and keeps the campaign ACTIVE, then shows it PAUSED on its own once every media buy confirms. Apostra’s operations team is alerted if a seller has not confirmed within two hours. Resuming works the same way: a resume the seller is still applying returns 202 with resumeRequestedAt, and the buy stays PAUSED until it is delivering again. A pause or resume confirmed straight away still returns 200 as before. On the V3 preview, save_media_buy with isPaused reports these as the new actions pause_requested and resume_requested, keeping the buy’s live status and adding a pendingChange with the status it moves to.

​

5.913.2 — October 6, 2026 at 1:38 AM UTC

• Pausing a media buy on an ad-platform storefront now works even while an earlier change to the same buy is still pending, for example a budget change waiting for the seller’s approval. This includes an agent calling the storefront’s AdCP update_media_buy with paused: true directly, which was previously refused with CONFLICT (mutation_in_flight). The earlier change keeps its place, and when it is applied the buy stays paused. If a seller or ad platform refuses or fails a pause, you still get an explicit error, and Apostra’s operations team is now alerted. Nothing to change on your side.

​

5.913.1 — October 6, 2026 at 1:04 AM UTC

• update_media_buy no longer reports a sync failure to a buyer for a confirmed seller change on a media buy whose record is missing an internal activation timestamp. The seller’s own confirmed response is now trusted for that one confirmed-safe case; every other mismatch still fails exactly as before.
• If you turn a media partner off for an advertiser after searching, a saved search for that advertiser no longer shows that partner’s products, and adding one of them to a buy, directly or by applying a proposal, is refused right away with a message saying where to turn the partner back on. Previously the products stayed visible and the buy was only refused when you created it. Media-buy creation now gives the same message, including when a partner is excluded for your whole account. Nothing to change on your side.

​

5.913.0 — October 6, 2026 at 12:19 AM UTC

• Document Apostra as the default assistant identifier, preserve the Murph migration path, and add production adoption views for retained identifiers.
• Add canonical Apostra MCP endpoints, tool discovery, and UI resource aliases while keeping the existing Murph MCP endpoints available without redirects.
• Add Apostra REST API paths alongside the existing Murph paths, with equivalent authentication, authorization, rate limiting, conversation, and error behavior.
• Add /api/v2/apostra as the canonical REST path family for the assistant while keeping existing /api/v2/murph clients fully compatible.
• Storefronts on the Storefront-built and Agent-supplied paths no longer refuse a product search because a number in the brief looks like an age. A budget or duration such as “Budget 2500 EUR over 20 dagen”, or a description such as “our customer is generally in her 30s”, now goes through to discovery without restricting delivery. Hard age targeting now belongs in structured fields: these storefronts accept the AdCP 3.2 targeting_overlay.demographics.age field, and a brief that requires or excludes an age range, such as “target ages 25-54”, is refused with INVALID_REQUEST and an instruction to send the range in that field or to say in the brief that it is a preference, not a hard requirement. This is read however the brief is worded, including in words or another language. If the brief cannot be read at that moment, the search returns a retryable error. Built-in platform adapters such as Meta and TikTok are unchanged.
• Third-party sales-agent storefronts can read and update their durable certification sandbox-account nomination reliably. When the read fails, the inventory source now shows the underlying error code.
• Your ChatGPT app download now works with OpenAI’s plugin submission flow. It contains one plugin ZIP you upload to OpenAI unchanged. That ZIP pre-fills your listing, starter prompts, review test cases, and release notes, and for buyer apps it includes the current skills. Every download carries a higher version, so you can upload a fresh one to the same plugin in OpenAI as an update. OpenAI limits plugin names to 30 characters, so a storefront name longer than that now blocks the package until you shorten it.
• Agent and machine-to-machine (M2M) tokens issued for https://api.interchange.io/mcp or https://api.apostra.com/mcp are now accepted on both hosts. Existing integrations keep working as Apostra moves its default API host. No action is needed.

​

5.912.0 — October 5, 2026 at 11:42 PM UTC

• If your integration reactivates campaigns, handle an error from the reactivate call: a campaign reactivate now returns 503 with each media buy’s outcome when any media buy fails to resume. This applies to POST /api/v2/buyer/campaigns/:id/reactivate and to setting isPaused: false on a campaign. Before, the call returned success even when some media buys stayed paused. Media buys that resumed stay active, and the error lists the ones still paused, with the seller’s reason where one was given; resume those one by one with reactivate media buy. A campaign now always shows ACTIVE while any of its media buys is delivering and PAUSED only when all of them are paused. Campaigns that were left showing PAUSED while a media buy kept delivering are corrected to ACTIVE; no media buy is paused or resumed by this correction.

​

5.911.0 — October 5, 2026 at 11:15 PM UTC

• Product discovery now lists the targeting a seller declares under Targeting buyers can set in a product’s supported_targeting, using AdCP dimension names such as geo_countries and frequency_cap. Before, a product that declared targeting this way showed no supported targeting to buyers.
• Embedded sales agent 1.56.0: apply update_media_buy pacing changes to GAM and confirm them, cap every AdsWizz campaign at its booked budget, pace it as the buyer booked and read it back, paid Broadstreet buys now need the seller’s Broadstreet account in manual mode; automatic and confirmation-required Broadstreet buys are refused before anything is booked, because ESA cannot set a budget cap in Broadstreet, refuse creative-side writes to a GAM line item that has no goal to stop it, refuse FreeWheel booking terms that would not stop delivery at the booked budget.

​

5.910.0 — October 5, 2026 at 10:39 PM UTC

• Third-party sales-agent sources now retain their recorded certification sandbox-account selection when the source is disabled.

​

5.909.0 — October 5, 2026 at 10:16 PM UTC

• Slack now presents Apostra consistently in app setup and Product Update copy. The canonical /apostra command is promoted even when a saved /murph shortcut is used; /murph remains available during the documented migration.

​

5.908.0 — October 5, 2026 at 8:57 PM UTC

• Rolling out account by account: when you create a media buy whose optimization goal names one of your event sources, Apostra now binds that source to an existing pixel (a Meta dataset or Snap Pixel) on each seller account the buy runs on. The pixel ID is not yet included on the media buy sent to the seller, so sellers do not optimize against it yet. Read each account’s sellerId (the pixel ID), status and blocker under sellerAccounts on the event source. Binding needs the Conversion events switch on for that seller in Connections; otherwise the blocker is SELLER_DATA_SHARING_NOT_PERMITTED and nothing is sent. Apostra never creates a pixel. If an account has several and none is named, the blocker is SELLER_EVENT_SOURCE_DESTINATION_AMBIGUOUS; name one with sellerAccounts in save_event_source. If it has none, the blocker is SELLER_EVENT_SOURCE_DESTINATION_MISSING. The media buy never waits for binding.
• Source diagnostics now show transport evidence for ad server sources. Each outbound request Apostra sends to the sales agent behind your ad server source, such as a media-buy create, now appears in transportRequests with the same redaction as a third-party sales agent. Before this change, those requests were missing from that list. For these rows destinationOrigin is null, because the request goes to a service Apostra runs internally.
• Source diagnostics in Murph now uses the same card, header, buttons, status labels and form fields as your other storefront pages. What it shows and what you can do there is unchanged: you still see whether each inventory source’s connection is working and the one next step, open Technical details for the endpoint, authentication and request-signing evidence, check the connection, update credentials, run discovery and validation tests, and connect a new sales agent. Nothing to change on your side.
• Reading a campaign with V3 get now returns its optimizationGoals, primary goal first, in the same shape save_campaign takes, so you can read a campaign’s goals and send them back unchanged. A cost or return target still reads as bidding, not on a goal. Reading an event source now also returns health on each sellerAccounts[] entry: the seller’s own assessment of the confirmed pixel on that account, in the AdCP EventSourceHealth shape. A pixel that is set up but has not received events yet shows events_received_24h: 0 with no last_event_at, so you can see it needs events before you rely on it for optimization. It is null until a pixel is confirmed or when the seller gives no assessment.

​

5.907.0 — October 5, 2026 at 8:04 PM UTC

• Embedded sales agent 1.55.0: paid Google Ad Manager line items booked through an embedded sales agent are now capped at their booked budget and paced the way the buyer booked them, with even pacing when the buyer asks for none, so a buy can no longer deliver past its budget. After every create, update, and pause, the embedded sales agent reads the line item back from Google Ad Manager and reports the settings Google Ad Manager actually applied. Products whose Google Ad Manager spend settings an older version filled in automatically are corrected when this version deploys, so they can be booked again. Spend settings a seller wrote are left unchanged; a product with no spend cap configured cannot be booked until the seller sets one. When a product’s own delivery setting books a package slower than the pacing the buyer asked for, the create response now includes a warning that says so. Nothing to change on your side.
• Return a retryable reporting-store failure and release every durable modular booking during a media-buy cancellation.

​

5.906.0 — October 5, 2026 at 7:24 PM UTC

• The advertiser form now states the scope an empty list actually means. Leaving channels blank reads as All channels, the same way an empty country list already reads as All countries, and you narrow either one from the same picker. The old “Select at least one channel to manage sellers” note is gone — it described a rule the platform no longer applies.
• An advertiser created before country scope was recorded can no longer be saved with the question unanswered. Editing it asks you to name its countries or confirm it works in all countries before Save is enabled, so the advertiser reaches sellers on a scope you chose rather than on a blank.
• Nothing changed about what the API accepts: an empty array is still valid and still means “all”.
• If your integration pauses campaigns, handle an error from the pause call: a campaign pause now returns 503 with each media buy’s outcome when any media buy fails to pause, and the campaign stays un-paused. This applies to POST /api/v2/buyer/campaigns/:id/pause and to setting isPaused on a campaign. Before, the call returned success and showed the campaign as PAUSED even when some of its media buys were still delivering. Media buys that did pause stay paused, and the error lists the ones that may still be delivering, with the seller’s reason where one was given. Retrying is safe, because a pause only targets media buys that are still active. When every media buy pauses, nothing changes: you get 200 and the campaign is PAUSED.
• On storefronts that forward to a sales agent, resuming a paused media buy on its own no longer waits for seller approval: a resume with no other change restores terms the seller already approved. A resume that comes with any other change, such as a budget, date, or package edit, still goes to the seller for approval. On ad-platform storefronts with manual review, every resume still waits for the seller. The buyer media-buy and reactivate pages and the seller approvals guide now describe this. Nothing to change on your side.
• Products the Merchandising Agent builds can now require signals together, not only as alternatives. A product for decision makers at small and mid-sized businesses targets people who are decision makers AND work at a company of either size, instead of anyone in any one of those segments. The agent adds a requirement only when the brief calls for it, since each one narrows reach, and the seller’s ad server receives that structure unchanged. A product that requires signals together can only be bought with AdCP 3.2; an AdCP 3.1 media buy for it is refused with an error that says so, rather than sent as one broader either-or audience. The agent also no longer offers a product that lists a seller’s Google Ad Manager key-value signal and an audience segment as alternatives, which Google Ad Manager cannot deliver, when the seller’s ad server connection identifies which kind each signal is. Products built before this release are unchanged.
• When you search for products for an advertiser, only the media partners turned on for that advertiser are searched, and partners that are off are no longer counted as failed sellers. If you name a media partner that is off for the advertiser, its result now says it wasn’t searched and where to turn it on: open Media Partners for that advertiser, open the media partner, choose Controls, then set Availability to On. A partner excluded for your whole account is changed in the account view instead. If no media partner is on for the advertiser, the search says that instead of reporting that no connections are configured. Nothing to change on your side.
• People without a Gravatar account now show a coloured initials tile instead of a generated geometric pattern. Team rosters, user management, and activity feeds read as names at a glance rather than as abstract shapes, and anyone who does have a Gravatar still sees their own photo.
• In Media Partners, an advertiser’s status at a seller whose agent lists its accounts now follows that seller’s later decisions. An account the seller is still reviewing shows Waiting on media partner until the seller approves it, then shows Active. An account the seller later suspends, closes, or rejects stops showing Active. Apostra re-checks every few hours, and every 15 minutes while an account is under review. If two of a seller’s connected sources list the same account with different statuses, that account keeps its last status until they agree. Nothing to change on your side. The seller still decides whether to accept a buy on an account it has suspended or closed.
• Embedded sales agent 1.54.1: re-include excluded ad units by their history, not only a 7-day timer, re-judge a package’s ad unit exclusions when its goal changes, read back booked GAM line items and record drift per package, record ad unit attribution coverage on every placement optimization pass, return GAM-confirmed settings after create, update and pause, cap every paid GAM line item at its booked budget and pace it as the buyer booked, report a day still without data past the worst-case lag as nothing delivered, stamp the tenant status cache entry when it is stored, store the booked package budget and test generated GAM defaults through the buy lifecycle, stop the GAM write canary blocking go-live until publishers can run it.
• The Discord setup guide now explains how an existing installation can be renamed to Apostra while keeping its connection and access. Your administrator must complete the provider change.

​

5.904.0 — October 5, 2026 at 5:45 PM UTC

• Buyers can keep discovering products from healthy inventory sources when another source has an ad-server setup or wholesale-pricing problem. Products from the affected source stay unavailable until the seller fixes that source; existing campaigns do not need to be recreated.

​

5.903.1 — October 5, 2026 at 4:54 PM UTC

• Pausing a media buy now stops delivery straight away, even when the seller’s storefront reviews every change manually, and on guaranteed buys too. A pause no longer waits in the seller’s approval queue while the ad server keeps serving. The pause response now says whether the seller’s storefront confirmed it: a 200 means delivery stopped, and an error means it was not confirmed and the buy may still be delivering. A pause never returns a 409 because it is waiting for approval. Sellers get a new storefront.media_buy_buyer_paused notification when a buyer pause takes effect on their inventory. It asks for no action. A pause does not change the buy’s budget, flight dates, or terms. Resuming a paused buy still follows the storefront’s normal approval rules. Nothing to change on your side.

​

5.903.0 — October 5, 2026 at 4:01 PM UTC

• Managed sales-agent sources now use the certification buyer’s admitted sandbox storefront account for live-traffic certification. Sellers name a no-charge test advertiser in their ad server through the normal Buyer Account Mapping decision, using an active dedicated binding; they do not choose a separate certification sandbox account for those sources.

​

5.902.0 — October 5, 2026 at 3:34 PM UTC

• Agent text lines can now send RCS with POST /api/v2/communications/rcs/messages. It takes the same request ID, line, recipient and text as POST /api/v2/communications/messages, which still sends SMS only and is unchanged. RCS shows your verified business name and logo in RCS messaging apps such as Google Messages. It only works after Apostra binds a verified RCS agent to your line; until then the command returns 400 and SMS keeps working. RCS uses the same queue, opt-out record and sending limits as SMS. A 202 response means the message is queued, not delivered, and RCS never falls back to SMS.
• Restore Confluence source previews by respecting Confluence’s per-request page limit while continuing to preview up to 500 items.

​

5.899.0 — October 5, 2026 at 2:10 PM UTC

• When you list campaigns without a status filter, the response now tells you how many campaigns the default filter (active, draft, paused) left out, broken down by status, and that status=ALL includes them. An empty campaign list for an advertiser whose summary shows campaigns now explains the difference: those campaigns are completed or canceled. Nothing to change on your side; lists that send status are unchanged.
• Buyer agents now get access to advertisers that another organization has delegated to their organization. These agents include hosted agents, API-key agents, and WorkOS machine-client agents. Before this fix, the check looked up the wrong organization, so an accepted delegation never applied to the agent.
• Buyer agents connected to the Buyer MCP server no longer get an account switcher they cannot use. Their tool list leaves out customer_switch, and list_accounts now returns the account the agent is working in (marked current: true) plus each account that owns an advertiser you granted it, instead of every account of the person the agent acts for. Buyer agents still cannot switch accounts, and grants work as before. People and API keys keep customer_switch and the same account list. Nothing to change on your side.
• Failed media buys now explain when a selected product needs seller correction or when buyer targeting is invalid. The response keeps the specific correction and identifies who should act instead of reporting a platform error. Retrying the same structurally invalid buy is not recommended.
• Seller approvals received after an earlier media buy fails now carry over to later buys that use the same unchanged creative. Edited creative content still requires a new approval, and buyers do not need to take action.

​

5.898.1 — October 5, 2026 at 1:41 PM UTC

• When Meta refuses an audience that a data partner such as LiveRamp shared into your ad account, create_media_buy now returns PERMISSION_DENIED with reason partner_audience_sharing_required and tells you to remove or replace that audience. Previously it returned SERVICE_UNAVAILABLE, which looked like a temporary outage, and the media buy was retried automatically even though Meta refuses it every time.
• When Meta refuses an audience change in update_media_buy because a data partner such as LiveRamp shared that audience into your ad account, the update now returns PERMISSION_DENIED with reason partner_audience_sharing_required, says no changes from the update were kept, and tells you to remove or replace that audience. Previously it returned SERVICE_UNAVAILABLE, which looked like a temporary outage. If we can’t confirm that every change from the update was undone, you still get the existing “do not retry, reconcile first” error.

​

5.898.0 — October 5, 2026 at 1:20 PM UTC

• You can now dictate messages to the assistant in the Apostra web app instead of typing them (the assistant appears as Murph on accounts not yet switched to Apostra branding). Select the microphone in the message box, speak, then select it again to stop. A recording also stops on its own after two minutes and is transcribed. Your words appear at your cursor so you can check or edit them. Nothing goes to the assistant until you send the message. The microphone appears only in browsers that can record audio, and your browser asks for microphone permission the first time. The recording is sent to Apostra and transcribed by Google Cloud Speech-to-Text in the United States, in the language you chat in; Apostra does not store it. If the recording has no speech in it, nothing is added to your message. To help spell names correctly, the transcription request includes your account’s own advertiser, campaign and storefront names, and names are never shared across accounts. Dictation is unavailable once you reach your daily usage limit, until it resets. Nothing to set up on your side.
• Choose payment terms before Apostra opens a seller account for a consolidated-billing purchase. Until then, discovery uses public seller products when available instead of account-specific pricing. Saving terms immediately restarts held setup for the billing organization and its current direct children; direct-billed and sandbox purchases are unchanged.
• In Media Partners, when a seller that sets up accounts automatically declines an advertiser’s account, the advertiser no longer shows Active. If the seller rejects, suspends, or closes the account, the advertiser shows Failed. If the seller needs payment, it shows Action required, and you settle that with the seller. Accounts the seller reports active, or still under its review, show as before.
• Verified Buyer signup can create a Buyer account on an eligible archived Seller domain without waiting for manual account preparation. Existing Seller access and storefront history remain intact; domains with active Seller ownership or commercial activity still require review.

​

5.896.0 — October 5, 2026 at 12:01 PM UTC

• Reading campaigns with V3 get or search now returns each campaign’s bidding policy, the cost or return target on the primary goal, in the same shape save_campaign takes. A target set through V2 reads back the same way, with a missing strength shown as cap for a cost target and target for a return target. In V2, each row of GET /api/v2/buyer/campaigns now includes the campaign’s performanceConfig (its optimization goals and their targets) when it has goals, so you no longer need a second read to see a campaign’s goals.
• Ask your agent to open your dashboard and Seller Dashboard now opens. Before this, an agent on the v3 MCP endpoint, including Murph, had no way to open it and could open a different Page instead. While your account has an active Demo Storefront, the Dashboard opens on the Demo Storefront evaluation view of your practice runs, and your Demo still reads “Paused before going live”. Every other seller sees seller analytics.
• Agents and SDK clients use the new open_seller_dashboard operation. It takes no arguments and is available only to Seller Accounts. Nothing to change on your side.

​

5.895.0 — October 5, 2026 at 11:43 AM UTC

• If your inventory comes from a managed sales agent, you can now choose an active sandbox account for live-traffic certification. Nothing changes for other sources.

​

5.894.2 — October 5, 2026 at 11:05 AM UTC

• Hosted ElevenLabs previews now send quoted voiceover copy, retain playable audio MIME types, and reject implausibly short generated audio before it is shown as complete.

​

5.894.0 — October 5, 2026 at 10:20 AM UTC

• Seller source managers, including staff acting in the seller account, can choose or clear the certification sandbox account with clearer inventory-source API and agent wording.

​

5.893.2 — October 5, 2026 at 10:00 AM UTC

• Media buys that use a seller’s ad-server signal now reach the seller when that signal omits its optional inclusion mode. Explicit exclusions and invalid signal settings still behave as before. Nothing to change on your side.
• Approved creatives created before format-option pins were stored can now use the media buy’s exact package selection when being delivered to a legacy sales agent. This restores delivery without recreating the creative or media buy.

​

5.893.1 — October 5, 2026 at 8:54 AM UTC

• New Apostra documentation, generated API contracts, SDK clients, and agent setup instructions now use api.apostra.com by default. Existing api.interchange.io integrations keep working and need no changes.

​

5.892.0 — October 5, 2026 at 2:52 AM UTC

• In the Webhooks Page, you can register a public HTTPS endpoint, prove that you control it, and rotate or disable its signing key. Copy each new signing secret when the Page shows it: it is not shown again. Event subscriptions remain a separate setup step.

​

5.890.0 — October 5, 2026 at 1:24 AM UTC

• A Demo Storefront’s seller rail shows Dashboard again, under Operate. It opens the Demo Storefront evaluation view of Seller Dashboard, where your practice runs appear as synthetic evaluation data. Opening it does not mark the Demo as live: it still reads “Paused before going live”. Storefronts that are not live and are not a Demo still see no Dashboard row. Nothing to change on your side.
• Flag saved Library responses when a cited document changes and let sellers re-run the saved brief.
• If you switch into another account that no longer has Buyer or Seller access, the app now takes you back to your home account and keeps you signed in. Before, it signed you out and showed the sign-up form.
• You can now see your record against the goal commitments you have made on completed buys. Ask for it with include: ["commitmentRecord"] on your own seller read (get with kind: "seller"). For each goal objective and commitment kind (guaranteed, best_effort, report_only), it shows how many completed buys were judged, how many beat, met or missed the commitment, the hit rate, and the median distance from target. It is judged the same way buyers see goal progress on their own buys, and it never names a buyer, a campaign or a media buy.
• Buyers will later be able to read this record when choosing a seller. They will see a figure only when at least 3 distinct buyers and at least 5 judged buys stand behind it, and never who those buyers are. We will tell you before buyer access opens.
• The Set Up a Campaign skill (version 1.7.0) now tells your agent to put a cost or return target in the campaign’s bidding policy, and to ask how firmly sellers should hold it, instead of putting the target on a goal, which V3 save_campaign now refuses.
• V3 save_campaign now takes a campaign’s cost or return target as an AdCP 3.2 bidding policy on the primary goal: bidding: { cost_per: { amount, strength } }, where strength is cap or target, or bidding: { roas: { value, strength } }, where strength is floor or target. strength says how firmly sellers should hold the number, and you must give it. Breaking change for V3 callers: a cost_per or per_ad_spend target on any goal is now refused, and the refusal tells you to use bidding. Goal targets such as a minimum rate or “as much as possible” are unchanged. V2 campaign calls are unchanged. A cost target set through V2 on a secondary goal stays in force when a V3 save sends that goal back unchanged; if the save removes or changes that goal, the response names the target it removed.

​

5.889.0 — October 5, 2026 at 12:19 AM UTC

• A card you add on Plan & Billing is now saved as your payment method once it’s confirmed. Before this fix, a confirmed card could be marked confirmed without being saved, so Plan & Billing asked you to add a card again.
• The Campaigns view now shows each campaign’s and media buy’s progress against its goal: what you asked, what the seller committed to, what has been delivered, and whether it is on track, behind, or beat target.
• Plan & Billing no longer offers to add a card when it can’t check on a card you already submitted. If the card confirmation status fails to load, the Payment method section now says so and offers a retry, so you don’t submit the same card twice. If your session has expired, you’re sent back to sign in.

​

5.888.1 — October 4, 2026 at 10:15 PM UTC

• A newly created seller account, including a new Demo Storefront, now shows its status line in the account switcher straight away. Before, the line could be missing for several minutes after the account was created.

​

5.888.0 — October 4, 2026 at 10:02 PM UTC

• The seller rail now reads “Paused before going live” for a Storefront that is paused and has never gone live, including a new Demo Storefront. Before, it read “Setting up” even when every required step was done. Once every final validation step is done, the rail also stops listing that group, so a full count such as “15 of 15” no longer appears beside a step that looks outstanding. Select the count to see the complete checklist.
• Generated image variants now show an automated brief-match result before a buyer chooses or refines an output. A failed check prevents finalising that output, while warnings stay available for human review.

​

5.887.1 — October 4, 2026 at 9:36 PM UTC

• When your Sales Agent returns an account_id from sync_accounts, Apostra now stores it and sends account: { account_id } on later get_products and create_media_buy calls for that account, instead of the brand and operator. A buyer’s discovery or buy now reaches the account you named, even when the same brand and operator match more than one account on your side. Agents that return no account_id keep receiving the brand and operator as before. Nothing to change on your side; see Sales Agent requirements for the recommended practice.

​

5.887.0 — October 4, 2026 at 9:22 PM UTC

• When you tell Murph about a problem with the API key form or field, it now answers your question. Before, mentioning the API key form could make Murph reply only with a link to the secure credential form. If you offer to send Murph an actual API key, it still sends you to the secure form and won’t take the key in chat.
• Brand references that Interchange sends to a Sales Agent now contain only the fields that the Agent’s AdCP version defines: domain, brand_id, and, from AdCP 3.1, industries, data_subject_contestation and brand_kit_override. This applies to get_products, sync_accounts, create_media_buy and update_media_buy, in both brand and account.brand. The advertiser’s brand countries stay inside Interchange and are never sent. Some AdCP 3.1 Sales Agents had rejected product discovery when a brand carried countries; that request now validates. Nothing to change on your side.
• Sellers behind an Apostra storefront now receive an advertiser’s property lists when they support them. For a product sold through a storefront, Apostra checks whether the sales agent behind the storefront declares property_list or property_list_exclude in its AdCP capabilities. Before, it checked the storefront’s own capabilities, which never declare lists, so these sellers never received one. When the sales agent declares support, the include and exclusion lists go with each new buy and with every later list change, and the storefront passes them to the agent unchanged. Sellers that don’t declare support, and managed sales agents, receive no list, as before.

​

5.884.0 — October 4, 2026 at 4:36 PM UTC

• Webhooks you sign with RFC 9421 message signatures now resolve your signing keys from your agent’s get_adcp_capabilities. We use the identity.brand_json_url your capabilities declare. If you are an AdCP 3.x agent that declares none, we fall back to /.well-known/brand.json on your agent’s origin, so your current setup keeps working. Your agent must answer get_adcp_capabilities without credentials, over the protocol you registered with us, for a signed delivery to verify. If we cannot fetch your capabilities, brand.json or JWKS, we respond 503 so you can redeliver. HMAC-signed callbacks are unchanged. See Signing the webhooks you send us.
• Products the Merchandising Agent builds now say exactly how they use each signal, and that selection reaches the seller’s ad server unchanged. For a key whose values are chosen per buy, such as a Google Ad Manager site-section key, the agent picks the values that fit the brief; for a numeric signal it picks a range; audience segments are included or excluded as before. Products that use such a key can now be bought with AdCP 3.2; before, the ad server refused those buys. This does not yet cover a signal the seller set up as one fixed key-value pair, or a signal combining several conditions: the seller’s ad server connection still refuses those over AdCP 3.2, and they keep working only over AdCP 3.1 until that connection is updated. A product that narrows a signal to specific values or a range can only be bought with AdCP 3.2: an AdCP 3.1 media buy for it is refused with an error that says so, rather than sent without the values. Products built before this release keep their old signal delivery; one that uses a per-buy key still cannot be bought with AdCP 3.2 and needs to be rebuilt from a new brief.
• Account administrators can now convert a standalone account into an organization without adding a second account. In Settings → Account configuration, select Convert into an organization. The account becomes the organization’s first account: its contract, billing authority, plan (with its feature access and account allowance) and any sales agent offering move to the organization, and you become an organization administrator. The storefront, advertisers, campaigns, history and members stay with the account, and other members stay account-only unless invited to the organization. Converting can’t be undone in self-service. Nothing changes for an account unless an administrator converts it.
• Coaching reruns, Run again, and revision turns in Proposal Pass now keep the original request’s budget, flight, targeting, and constraints, and a coached practice rerun keeps the original truth rules for unsupported claims and custom fulfilment. Before, the new response was built from the brief text alone, so it could drop the dollar amounts and the buyer’s guardrails while looking like an improvement. On a Demo Storefront practice run, coaching now changes the proposal only through the AI model, as it does for every seller; the fixed “Confirm the allocation” next ask added in the previous release no longer replaces it, and the comparison says plainly when a rerun produced no visible change.

​

5.883.0 — October 4, 2026 at 3:10 PM UTC

• Uploading a creative from ChatGPT now completes instead of stopping at storage.

​

5.882.0 — October 4, 2026 at 12:48 PM UTC

• get_delivery now limits storefront reporting to the requested media buy. Buyers asking for one media buy no longer receive delivery results from other media buys in the same storefront.

​

5.881.1 — October 4, 2026 at 5:55 AM UTC

• You can now create native in-feed products on a Google Ad Manager source in Inventory Components. When you choose native in-feed (or a sponsored placement, image carousel or responsive format) on Google Ad Manager, the draft form and the product editor ask for the Google Ad Manager creative template ID that renders it, and send it with the product so its line items book against your template. The ID is required and must be a whole number. A 1×1 Google Ad Manager slot now preselects native in-feed. If a product already has one of these formats with no template ID, the editor warns that it can’t be booked until you add one. Other ad servers don’t need a template ID.

​

5.881.0 — October 4, 2026 at 4:57 AM UTC

• When you edit a product in Inventory Components, you can now choose the targeting buyers may add to a package after they find it, such as countries, regions or audiences. Only the targeting your ad server can apply is offered, and you can set how many countries one package may target. Your prices and floors still apply to every selection you allow, so turn on only targeting you’re happy to sell at those prices. Targeting you don’t change stays exactly as it is. Nothing to change on your side.
• When you draft a product in Inventory Components, you can now choose the targeting buyers may add to a package after they find it, such as countries, regions or audiences, just as you can when editing a product. Only the targeting your ad server can apply is offered, and you can limit how many countries one package may target. Targeting is optional: leave it off and the product declares none. Your prices and floors still apply to every selection you allow. Nothing to change on your side.
• Editing a property list no longer sends that list to sellers that never said they support it. When an advertiser’s or a campaign’s include or exclusion list changes, Apostra pushes the new list to every active buy, but only to sellers that declare support for that kind of list, the same rule a new buy already follows. Before, the include list went to every seller, and a seller that doesn’t support it could reject the whole update, so the edit failed on that buy. A buy whose seller can’t take the change keeps running without it, and the skipped change is logged. Pausing those buys and telling the buyer is a separate change.

​

5.880.0 — October 4, 2026 at 3:29 AM UTC

• Seller Account Admins can nominate the sandbox account used for live-traffic certification from the inventory-source API or v3 inventory source save.
• When a product in Inventory Components has a video format, you can now say where its video ads play: in-stream, accompanying content, interstitial or standalone. Pick as many as apply, both when you draft a product and when you edit one. Buyers see the types you choose. Leave them all unticked if you don’t want to say. A stored value that isn’t one of these types stays as it is until you change the selection. Nothing to change on your side.
• The Inventory Components draft form no longer offers CPM while it is still finding out which pricing models your ad server accepts. The pricing section shows that it is loading until your source answers, and if the source can’t be reached it says so and offers Try again, instead of falling back to CPM. CPM-only pricing now appears only when your source answers that it reports no pricing models.

​

5.879.0 — October 4, 2026 at 2:29 AM UTC

• You can now add an API key or bearer token to a sales agent you saved with “No auth”, without creating a new source. Open the source’s diagnostics, expand Connection details and choose Add credentials. The same action appears at the top of the page if a connection check fails with an authentication error. Saving switches the source from No auth and stores the secret in one step.
• When an Apostra buyer’s campaign sets an explicit strength on its primary cost goal, an AdCP 3.2 seller now receives the cost target in the proposal request at that strength. A goal marked target reaches only sellers that accept a media-buy cost_per target, rather than always being sent as a cap. Cost goals with no stated strength are unchanged and still arrive as a cap.
• Proposal Pass now lists a proposal file (JSON, HTML, PDF or PowerPoint) as soon as your request is accepted, even if the page’s next refresh fails or comes back before the file appears.
• When you ask Murph to file a support request about your sales agent’s credentials, it now shows you the request and asks for approval as normal. Before, its approval prompt could be replaced with a link to the secure credential form, so you could approve without seeing what was being filed. Murph still sends you to the secure form, and won’t take the secret in chat, when it asks for a password or token.
• Sellers on AdCP 3.2 that accept a package bidding policy now receive a campaign’s cost or return target in AdCP 3.2’s shape. When a seller declares the mode and strength in features.bidding_policy.package.fixed, each package carries the primary goal’s target as bidding.cost_per (amount and strength) or bidding.roas (value and strength), and the goal itself carries no target. A cost target with no strength is sent as cap, so the seller keeps the average cost at or below it. Every other seller receives the target on the goal exactly as before, as does any package that carries a bid price or a cost target on a secondary goal. The amount does not change.
• For buyers in the product-scoring pilot, auto-select now favours sellers that keep their goal commitments. When it ranks products, a seller that has met or beaten the cost or rate targets it committed to on completed buys ranks above an otherwise identical seller that missed them. A seller with too little completed history keeps the place its other results give it. A guarantee counts fully, a best-effort answer counts half, and a report-only answer does not count. Buyers outside the pilot see no change.

​

5.878.0 — October 4, 2026 at 1:30 AM UTC

• If your storefront’s sales agent uses a supported partner contract and its connection is current, it can now receive briefs and bookings through a linked storefront source. Storefronts with a revoked, incomplete, or unsupported partner connection remain unavailable until that connection is ready. There is nothing to change on your side.
• When you select a media partner on Media Partners, each of your advertisers is now set up with that partner automatically. The partner’s card moves from Activation deferred to Provisioning and then Active, with no support request. Partners on ad platforms where you connect your own account still need you to connect or map that account, and a partner that asks you to accept its billing terms still needs that acceptance; the card shows the action in both cases. You can also turn a partner on or off for a single advertiser on every buyer account. Nothing else to change on your side.
• Advertiser-scoped Creative Sessions can again be found and opened in search, and their generated variant gallery now renders when the session is large.
• Click-through URLs that use {CREATIVE_ID}, {CAMPAIGN_ID}, {PACKAGE_ID} or {MEDIA_BUY_ID} now reach your landing page with the real ids filled in. Before this fix, a click passed through our click tracker arrived with those placeholders still in the URL as literal text, so attribution parameters built from them (for example utm_content={CREATIVE_ID}) recorded the placeholder instead of the id. {PACKAGE_ID} can be left empty, because one creative can be assigned to several packages. The fix applies to creatives synced to a seller from this release on; clicks already recorded keep the values they arrived with.

​

5.877.0 — October 4, 2026 at 12:08 AM UTC

• When you edit a product in Inventory Components, its ad units and placements are now listed with a Remove control, and you add more by searching the inventory loaded on the Components tab. Publisher coverage works the same way: remove a publisher, or add one of your source’s coverage options. A product keeps at least one ad unit or placement and at least one publisher. The editor no longer has any JSON fields: channels, formats, pricing, placements and coverage all use guided controls, and what the controls can’t show stays as saved. Nothing to change on your side.
• Embedded sales agent 1.53.2: keep products with unknown channels in channel-filtered get_products, publish the overlay_support schema once in the tenant-management OpenAPI, reject products the buyer can’t see in create_media_buy, verify GAM line-item creative associations before update_media_buy reports completed, write the approved click-through into GAM HTML5 bundles’ clickTag.

​

5.876.0 — October 3, 2026 at 11:10 PM UTC

• Uploading a file from inside the Creative Library now finishes instead of stopping at verification.
• When you edit a product in Inventory Components, each pricing option is now a card with the same fields as a new draft: delivery type, pricing model, fixed price or auction, rate or floor, and currency. You no longer edit JSON. Only the models your source can book are offered, and pricing stays read-only until your source’s pricing models have loaded. You can add and remove options, but a product keeps at least one. An option you don’t change is saved exactly as it was, and an option in a model the cards can’t show, such as CPP, stays as saved unless you remove it. Nothing to change on your side.
• On Media Partners, a partner marked Activation deferred now reads “Setup hasn’t started yet; no action needed” instead of saying activation is paused. Deferred means automatic setup for that advertiser hasn’t run yet, for example while the platform confirms which of the partner’s connections to use. Nothing was paused on your side. Partners that need an action from you still show that action instead. Nothing to change on your side.
• Embedded sales agent 1.53.1: classify GAM faults from their documented type and reason, classify GAM flight-date sync failures and keep FreeWheel binding text out of buyer errors, mark acceptance-test traffic in tenant-management logs and Sentry, read GAM video completions from the column GAM returns, keep each GAM tenant’s 30-day per-ad-unit delivery history, publish viewable rate and completed views ranges in GAM product forecasts, start GAM goal line items with history’s low-performing ad units excluded, store and project AdCP 3.2 overlay_support on wholesale products, store and return video placement types on wholesale products, apply template visibility to dynamic product variants in get_products, keep application loggers enabled when Alembic runs in-process, type FreeWheel clients against a request protocol instead of ignoring errors, book GAM template-rendered formats against a real creative template, echo applied signal_targeting_groups on update and idempotent create replay, keep deprecated targeting_capabilities and publish the AdCP overlay_support schema, report each adapter’s own pricing models in inventory capabilities, target GAM audience-segment signals through customTargeting and signal_targeting_groups.

​

5.875.0 — October 3, 2026 at 10:00 PM UTC

• Apostra SDKs now verify signed V3 webhook deliveries with rotation support.
• People choosing Buy media on a domain with a recoverable Seller account can request Buyer access for review. Signup keeps the Seller account and storefront history intact and blocks a second standalone Buyer account from being created without an authorized invitation.
• When you edit a product in Inventory Components, you now choose its formats from the same checklist you use for a new draft, including 15-second, 30-second, or custom video lengths, instead of editing JSON. Saved formats keep everything else exactly as saved. A saved format your source no longer offers stays on the product unless you remove it. On a Google Ad Manager source, native can’t be added yet, but a native format already on a product stays as it is. Nothing to change on your side.

​

5.874.0 — October 3, 2026 at 8:22 PM UTC

• When you edit a product in Inventory Components, you now choose its channels from the AdCP channel list instead of typing JSON, and the editor won’t save a product with no channels. Older products saved with audio or video show them as Streaming audio and Online video. In both the editor and the create-product draft, the channel picker now shows how many channels you’ve chosen and lists them by name beneath it; open the picker to add or remove one. While a product has pricing options, the editor shows the delivery type those options set instead of a separate product-level choice. Targeting capabilities now appear read-only and are never sent, so an edit can’t change them. Formats, placements, and pricing are still edited as JSON for now. Nothing to change on your side.

​

5.873.0 — October 3, 2026 at 7:20 PM UTC

• V3 save_event_source now accepts sellerAccounts on each event source: up to 20 pairs of a connected seller account’s accountId (from get with kind: "connection") and the sellerId of the pixel to use on it, such as a Meta dataset or Snap Pixel. Use it to choose the pixel on a seller account that has more than one. Saving records your choice without contacting the seller. search, get, and the save response list each seller account in sellerAccounts, with status: "pending" and sellerId: null until Interchange confirms the pixel on that account; the pixel you named is not echoed back. Changing the pixel on an account that already has a confirmed one keeps the confirmed pixel in use and in sellerId, with status: "pending", until the new one is confirmed. Naming a pixel again for an account whose sync failed, expired, or was removed returns it to pending so it can be retried. A save that changes only an event source’s seller accounts reports updated. An accountId that is not an active, connected account of yours fails that entry with REFERENCE_NOT_FOUND, and the source is not saved. Event sources saved without sellerAccounts are unchanged.

​

5.872.0 — October 3, 2026 at 5:34 PM UTC

• In Inventory Components, Draft product now accepts your selected suggested matches and opens the draft form in one click, replacing the separate accept and draft steps. The form asks for channels (buyers filter discovery by channel), guaranteed or non-guaranteed delivery, and pricing. Pricing offers only the models your ad server can book, such as CPM, vCPM, CPC, or flat rate on Google Ad Manager, or CPM alone if the source doesn’t report its models. CPM and vCPM can be an auction with a floor or a fixed rate; for a CPM auction you can leave the floor blank and the sales agent derives one. Other models are fixed only, and fixed prices are in your storefront’s settlement currency. Video formats take 15 s, 30 s, or a custom whole number of seconds, and formats are preselected when their size exactly matches your selected inventory or their kind matches the media it declares, such as video. Each saved product on the Products tab now lists its formats, for example “Image 728×90, Hosted video 15 s”, so you can confirm what saved without opening the JSON editor. Native in-feed isn’t offered on Google Ad Manager sources yet, and the form says so.
• sync_event_sources now returns each event source’s own platform ID in seller_id for Meta, Snap, Pinterest, LinkedIn, Reddit, Universal Ads and OpenAI Ads storefronts. Previously these storefronts returned the ad account ID there. The new value is the Meta dataset ID, Snap pixel ID, Pinterest conversion tag ID, LinkedIn conversion rule ID, Reddit pixel ID, Universal Ads pixel ID or OpenAI Ads conversion event setting ID, matching AdCP. TikTok and Spotify already returned the source’s own ID and are unchanged. If you read seller_id as the ad account, use the account from your request instead.
• In Inventory Components you can now reach every ad unit and placement your ad server has synced, not just the first 50. Choose the inventory type to browse (for Google Ad Manager, placements or ad units), search by name or source ID, and load more from your ad server 50 at a time. Every row shows its source ID. Accept, hide and remap decisions and your selections stay in place while you search or switch type, so one product draft can combine components from different searches; switching to another ad-server source still clears them. Nothing to change on your side.

​

5.871.0 — October 3, 2026 at 4:19 PM UTC

• External AdCP buyers can create and update media buys on any commercially ready Apostra storefront without Scope3 first setting a spend cap for that buyer and storefront. Since 2 October these buys were refused with “This buyer is not provisioned for governed external AdCP campaign creation on the storefront”, including buys a curated storefront placed with its underlying sellers. Where Scope3 has set a cap, its currency, per-buy limit and total exposure limit still apply. Where none is set, the seller’s own terms, payment authority, rate card and approval policy decide.
• Uploading an image or video from the Creative Library in the web app now completes instead of stopping with a storage error.
• When an Apostra buyer requests proposals from a seller on AdCP 3.2, the seller now also receives the campaign’s primary cost goal as a structured criteria.outcome_target, if it declares media_buy.outcome_target and accepts a media-buy cost_per cap in features.bidding_policy. The target names the goal metric and the most the buyer will pay per result (cost_per with strength: cap in the buy currency). It never carries a volume or the campaign budget. Sellers that don’t declare both keep receiving the goal in the brief text only.
• Pages in the web app now always act on the account the web app shows, even after you switch accounts in Claude or ChatGPT.

​

5.870.0 — October 3, 2026 at 2:49 PM UTC

• Opening a Creative Library link from chat now lands on that advertiser’s library even when your advertiser picker is set to All advertisers.
• Inventory capabilities for an ad-server source now list the pricing models that source’s ad server can book, in pricingModels. Before, the field was always missing, so agents and product forms couldn’t tell which pricing models a source accepts.
• If you build your own sales agent, the launch checklist and the Sales Agent best practices now ask that every Product declare its AdCP channels, such as display, olv, ctv, or streaming_audio, or applies_to_channels on each format option. Live-path certification now reports a Product that declares neither as skipped with the reason missing_channels, and a format that declares no channel on an otherwise per-format Product as missing_channels:<format_kind>; before, both were left out without a reason. It also certifies a Product whose formats declare applies_to_channels on those channels, where before only the Product’s own channels counted. A missing channel is still only a warning and never blocks your agent. Channels will become required for external agents’ Products in a later change, announced before it takes effect.

​

5.869.0 — October 3, 2026 at 12:56 PM UTC

• A campaign can now keep its own property lists on top of the advertiser’s. Set campaignPropertyListId (include) or campaignPropertyListExcludeId (exclude) on save_campaign or on the v2 API’s POST /campaigns/{campaignId}/property-lists. The campaign stores them, its active media buys are updated, and every buy launched later carries them too. Exclusions add to the advertiser’s, and a campaign cannot drop an advertiser exclusion. An include list narrows the advertiser’s include list, so a site must be on both. get(kind: "campaign", include: ["propertyLists"]) shows the campaign’s own lists (campaignLists) and the combined lists in effect (effective).
• Breaking change on both save_campaign and the v2 endpoint: propertyListId: null is now refused with a validation error. It used to remove property-list targeting from the campaign’s live buys, leaving them without the advertiser’s lists. To clear a campaign’s own list, send campaignPropertyListId: null; the advertiser’s lists keep applying. propertyListId itself is deprecated in favour of campaignPropertyListId: until 2026-12-31 a non-null value keeps doing what it did (it applies one of the advertiser’s include lists to the campaign’s active buys) and responses include a notice naming the replacement. After 2026-12-31 it is refused.
• When you edit a product in Inventory Components, the save now only sends fields your ad-server source can store. Video placement types are shown read-only, so the editor no longer reports a change as saved when the source kept the old value. Pricing options now show and save only the fields the source accepts: model, currency, delivery type, fixed or auction, rate, price guidance (which holds an auction option’s floor), and minimum spend. The source still assigns each option’s ID, and you can see the IDs under “Pricing options as the source reports them”. Nothing to change on your side.
• Inventory components in Murph now uses the same card, header, tabs, table, buttons and form fields as your other storefront pages. What you can do there is unchanged: you still review, accept, hide and remap inventory components, draft and validate a product from them, and edit, archive or delete saved products in place. Nothing to change on your side.
• If you add your own signal targeting groups to a package for a seller-composed product, those groups now reach the seller’s ad server alongside the product’s own signals. Before this fix, they could be replaced by the product’s signals without any error, so a buy ran without the targeting you asked for. Your groups and the product’s groups must all match, so your groups narrow the product’s audience. A package whose signal_targeting_groups is not a group set (root operator all with a list of groups) is now refused with an invalid_signal_targeting_groups error that names the field, instead of being dropped. Nothing to change on your side.
• Direct Storefront connections in Claude no longer offer a creative upload that would stop before the file reached storage. In Claude, upload through the Buyer V2 or V3 connector instead. ChatGPT Storefront connections keep the upload.

​

5.868.0 — October 3, 2026 at 11:32 AM UTC

• Products a storefront composes to your brief now declare their AdCP channels, such as display, olv, or ctv. Each lists every channel declared by the seller inventory it combines. You can filter them by channel in discovery, and their delivery is reported by channel. A composed product declares a channel only when the seller’s inventory does, never guessed from its creative formats. Composed products you discovered before this change show their channels the next time you discover that storefront.
• Widgets in ChatGPT now receive their declared content policy, so ChatGPT loads the widget’s images and files from our domains instead of blocking them.

​

5.867.0 — October 3, 2026 at 10:59 AM UTC

• Sales-agent certification requests in Murph now reach the Scope3 team to arrange a live test buy instead of entering the retired fixture evaluation path.

​

5.866.1 — October 3, 2026 at 8:21 AM UTC

• Resolve Storefront-owned sales-adapter routes before creative delivery so approved creatives reach the exact active source and blocked draft buys can continue once their matching acceptance is recorded.

​

5.866.0 — October 3, 2026 at 3:47 AM UTC

• request_proposals now honors seller targeting from two sources: the sellerIds field on the call itself, and the seller list set on the campaign via save_campaign. Existing calls that supply sellerIds now narrow the round to that list. When both are provided they are intersected — only sellers in both are contacted. When only sellerIds is provided on the call those sellers are contacted directly. An empty list is rejected. When sellerIds is supplied, any requested seller that is unavailable or outside a campaign list or authorized seller scope refuses the whole round with CAMPAIGN_SELLERS_INELIGIBLE and contacts nobody. In contrast, a campaign-only seller list, with no sellerIds on the call, dispatches to its eligible subset and reports unavailable campaign sellers. To broadcast to all eligible sellers, omit both selectors and pass confirmBroadcast: true. The result reports the applied cohort and bounded seller IDs contacted.
• VAST and DAAST tag buys now send sellers a hosted wrapper that records impression, click, and playback progress events.

​

5.865.0 — October 3, 2026 at 3:17 AM UTC

• Forward canonical package selections to legacy inventory sources using their persisted legacy format references when the selections cannot be completely resolved.
• An advertiser with no markets set is now treated as working in every market, and one with no channels set as buying every channel. Product requests and media buys for that advertiser reach every Market Maker that qualifies in any market or channel, instead of no automatic sellers at all. Seller accounts are still not created ahead of time for an advertiser whose markets or channels are blank; set them to narrow automatic selection to where the advertiser operates.

​

5.864.3 — October 3, 2026 at 2:36 AM UTC

• If you have set a price on a signal, products the Merchandising Agent builds with that signal now include it. The surcharge is added to the product’s price floor: a product on inventory sold at 5 EUR CPM that uses a +1 EUR CPM signal is quoted at 6 EUR CPM or more. Before this release, signal prices were saved but left out of quotes. Signals a product includes together are charged once at the highest surcharge, so three +1 EUR segments add 1 EUR, not 3. A buyer discount cannot reduce the surcharge. A surcharge in a different currency from the product, a flat, per-unit or custom fee, or a price that is not a valid AdCP pricing option is not added to the quote, and the intelligence run’s pricing breakdown records why. Quotes built after this release include the surcharge. Nothing to change on your side.
• Delivery reporting now converts cross-currency spend at the rate locked onto the media buy when you booked it, taken from the storefront you booked the buy with. Previously, buys whose storefront assigned its own media buy id missed their locked rate and were converted at the rate of the day for the buy’s creation date instead, reported as deliveryFxConversion.source: "snapshot". Those buys now report source: "booked" with the locked rate and its date, so their converted spend can move by the difference between the two rates. When we cannot tell which storefront a buy was booked with, it keeps using the rate of the day rather than borrowing another storefront’s locked rate. Same-currency buys are unchanged.

​

5.864.1 — October 3, 2026 at 1:05 AM UTC

• Creative delivery now reports missing image, HTML5, or VAST destinations per Creative and warns buyers before seller delivery.

​

5.864.0 — October 3, 2026 at 12:18 AM UTC

• Keep a connected Library file in one document when its provider name or content changes. Renames now update the document name, and content changes add a new revision instead of creating a duplicate document.
• When this delivery origin is enabled, browser video players can fetch VAST we host with credentials: our VAST delivery endpoints return the calling page’s origin with credentialed CORS and answer preflight requests.
• When your campaign’s primary goal is on viewability or video completion and has a target, you can now see before booking how each product is expected to perform against it. goalCoverage on proposal goal answers, on the proposal-less products request_proposals returns, and on every product auto-select picks now carries expected: the product’s expected rate from the seller’s forecast (low, expected and high), the rate your target needs, and a verdict of likely, possible or unlikely. For example, “expected 78%-88% viewable vs your 70%”. A cost per completed view or per viewable impression is judged at the product’s CPM. Auto-select now prefers products where your target is likely, then possible, then products with no forecast range, then unlikely, among products that can optimize to your goal, and keeps its usual score or price order within each group. It never drops a product for this. Wholesale-priced products now keep the seller’s viewability and completion ranges in their forecasts. Click goals get no expectation, because click-through rates do not carry over between advertisers.

​

5.863.0 — October 2, 2026 at 11:28 PM UTC

• You can now save a property list without applying it to every campaign. Create it with appliesToAllCampaigns: false on save_property_list (or POST /property-lists): the list is saved for the advertiser, but the advertiser’s current lists and active media buys stay as they are. The default, true, works as before: the new list becomes the advertiser’s list for its purpose and is applied to every campaign. get and search show which kind each list is.

​

5.862.0 — October 2, 2026 at 9:11 PM UTC

• Fixed media-buy updates so an unknown governed media buy identifies the requested media buy and confirms that no change was sent. FreeWheel sandbox cancellations now release booked capacity when no upstream campaign is configured.

​

5.861.1 — October 2, 2026 at 6:32 PM UTC

• Restore proposal-only Storefront media buys and MCP validation coverage after #17903 made durable buyer-campaign prerequisites universal.

​

5.861.0 — October 2, 2026 at 6:00 PM UTC

• Creative uploads from the web app’s Creative Library and from Murph now finish. Before this fix, the upload stopped after preparing, with “The creative did not reach private storage.” Choose the file again to upload it.
• If you upload avails feeds to a modular inventory source, give every row an AdCP channel, such as display, olv, ctv, linear_tv, or streaming_audio. Use a channel column, or a default channel on the request. Rows with a channel that isn’t an AdCP code, such as broadcast or Home Screen, are now rejected with INVALID_CHANNEL. Choose the AdCP channel that describes how the inventory is delivered: broadcast television is linear_tv, and a connected-TV home screen is ctv. CTV, Connected TV, video, and audio are still accepted and stored as ctv, olv, and streaming_audio. A row with no channel is accepted with a CHANNEL_MISSING warning for now. We will start rejecting those rows after a separate announcement, at the same time as products created without channels. Rows you have already committed keep working. The publisher avails templates now use AdCP channel codes.

​

5.860.10 — October 2, 2026 at 5:38 PM UTC

• When your administrator publishes the versioned Microsoft Teams or Microsoft 365 Copilot package, the app presents Apostra with the registered Apostra mark. Existing app registrations, permissions, and conversation bindings stay in place; your administrator updates the existing app instead of creating a new one.

​

5.860.9 — October 2, 2026 at 4:59 PM UTC

• When a seller’s agent rejected a creative on a media buy that was still waiting to start, we could keep sending the same creative to that agent every minute or two. We now stop sending it once the agent has rejected that version for that media buy. Sellers’ agents no longer receive the repeated submissions. Buyers can still send the creative again with sync_creatives, and an edited creative is delivered as usual.

​

5.860.7 — October 2, 2026 at 3:12 PM UTC

• Media-buy updates forwarded to a seller’s agent no longer carry the storefront’s own revision number. That number tracks the storefront’s copy of the buy, not the seller’s, so an agent that checks revision could reject a valid update or compare it against the wrong version. Updates now arrive without a revision.

​

5.860.6 — October 2, 2026 at 2:55 PM UTC

• Release update notifications now call the product Apostra. The deployment summary and the “what’s new for you” message you receive when a release ships previously still said “Interchange”; they now match the Apostra name used across the rest of your experience.

​

5.860.5 — October 2, 2026 at 2:38 PM UTC

• Embedded sales agent 1.52.0: Google Ad Manager products can now apply an advertiser’s site and app lists through your GAM domain key-value. An exclusion list becomes domain is-not targeting on the line item, alongside the product’s own key-values. This keeps your products eligible for advertisers with property lists once Interchange starts sending them, and it needs a custom-targeting key named domain in your GAM network. Buyers on AdCP 3.2-rc.7 can now connect; 3.1-beta.5, which had stopped working, is no longer advertised. Deactivated tenants no longer run scheduled syncs.

​

5.860.4 — October 2, 2026 at 2:15 PM UTC

• Asking your agent or Murph what you sell now includes the products your modular inventory sources offer, next to the products you author on an ad server. Each product shows its price, and Demo Storefront sample products are labelled synthetic.

​

5.860.3 — October 2, 2026 at 1:49 PM UTC

• Embedded sales agent 1.51.0: add Reliable Reporting Core, publish AdCP channels and applies_to_channels on every product.

​

5.860.2 — October 2, 2026 at 12:47 PM UTC

• Rate-card previews now recognise fixed prices from managed ESA products, and matching hard floors apply when proposals use those products.

​

5.860.0 — October 2, 2026 at 11:53 AM UTC

• External AdCP buyers may buy on any commercially ready seller storefront, including Meta and sales-agent storefronts. Sellers retain control through their terms, payment authority, rate cards, and approval rules. Distribution gates public discovery only.
• Organization administrators working in one of the organization’s accounts now get the organization’s full Plan & billing page right there, without switching accounts. Payment methods, plan selection, contracts and media billing changes apply to the organization. Payouts stay per storefront: the Payouts tab shows the account’s own payouts, notes that the organization manages them, and offers a switch to the organization to change them. Older billing links and the setup checklist’s Payment & billing row now open Plan & billing in one step. Media billing requests made from one of the organization’s accounts now read and change the organization’s media billing entities, and require administrator access to the organization. No action is required.
• External AdCP buyers can continue updating historical route-based media buys while seller storefronts retain the same Distribution profile selection and approval controls.

​

5.859.2 — October 2, 2026 at 11:30 AM UTC

• On a Demo Storefront practice run, saving coaching in Proposal Pass and running the test again now visibly changes the proposal’s next ask, as the guided rehearsal does. Before, a rerun started from the page lost its practice settings, so the coached change never appeared.
• On the Media Partners page, a media partner you haven’t selected now shows the billing that would apply when you select it, instead of reporting its billing as unsupported. The consolidated or direct choice and Approve direct billing appear once you select the partner. A partner that declares no billing Apostra can use shows No supported billing instead of claiming consolidated billing. Agents reading sellers through the API see the same billing policy. Nothing to change on your side.

​

5.859.1 — October 2, 2026 at 10:59 AM UTC

• Business Manager plans now open for review and acceptance. The plan review no longer fails with “Couldn’t load IU pricing” when a plan’s entitlements grant only an account limit, and it shows that limit, such as up to 100 accounts under the organization.

​

5.858.5 — October 2, 2026 at 7:32 AM UTC

• The Connect support settings now say notifications route “from your account” instead of “from your storefront,” so the copy reads correctly for buyer accounts as well as sellers.

​

5.858.4 — October 2, 2026 at 7:08 AM UTC

• Creatives added to active campaigns now continue to seller delivery after the seller approves the media-buy update. Buyers do not need to change their upload or approval workflow.

​

5.858.3 — October 2, 2026 at 6:38 AM UTC

• A new Demo Storefront now reads “Paused before going live” in the seller rail and the account switcher, instead of “Live — critical”. Its sample confirmed booking is synthetic, so it no longer counts as a real transaction when we decide whether a Storefront has gone live. The sample booking and its delivery still appear on Media buys, Demand, and the Demo Storefront page. Storefronts with real transactions see no change.
• Proposal Pass no longer leaves its feedback, revision and proposal-file buttons disabled when you open another turn while a save from the previous turn is still finishing.

​

5.858.2 — October 2, 2026 at 6:08 AM UTC

• Synthetic inventory sources in an active Demo Storefront no longer show an “Ad Server Configuration” blocker in the seller rail or on the synthetic managed source. That source has no real ad server by design, so its ad-server connection step now counts as complete while the Demo is active. Every other setup task still reports normally, and sellers with real ad servers see no change.

​

5.858.1 — October 2, 2026 at 5:47 AM UTC

• Proposal Pass now keeps checking a requested proposal file (JSON, HTML, PDF or PowerPoint) for up to five minutes, and every new request starts its own check. A file that takes a few minutes to render now shows as ready on its own, instead of stopping at “Live updates paused” and waiting for you to press Refresh.

​

5.858.0 — October 2, 2026 at 4:58 AM UTC

• Sellers can upload rate-card documents that apply only to a matching buyer.

​

5.857.0 — October 2, 2026 at 3:11 AM UTC

• When your campaign has optimization goals, you can now see before booking which goals each product cannot optimize to. Proposal goal answers, the proposal-less products returned by request_proposals, and every product auto-select picks carry a goalCoverage: whether the product can optimize to your primary goal, and each goal it cannot, with a reason code. Auto-select now prefers products that can optimize to your primary goal, ranking them ahead of products that cannot and keeping its usual score or price order within each group. It still picks a product that cannot when the budget reaches past every product that can. Sellers still receive your brief, you can still book any product, and a product that declares no optimization capability counts as unable to optimize to any goal.

​

5.856.0 — October 2, 2026 at 2:17 AM UTC

• Apostra SDKs now expose typed human-handoff helpers that retain the returned URL, expiry, and safe resume instructions.
• Sellers can add an avails sheet to the Library, check its Inventory Feed preview, and commit accepted availability rows to a modular source.
• Changing a Meta media buy’s start or end date now verifies that Meta actually applied the change before reporting success. Previously, a flight-date update could be reported as successful even when Meta silently did not apply it, because nothing compared Meta’s response back to what was requested — unlike budget and targeting updates, which already do this check. A date change Meta doesn’t apply now returns an error instead of a false success.
• Updates to media buys now reuse the account accepted when the media buy was created. Buyers do not need to send an account again when changing a budget or schedule.
• Fixes AI-9719

​

5.855.1 — October 2, 2026 at 1:30 AM UTC

• When a seller refuses your requested payment terms, the account request now reports the refusal instead of opening an account on the seller’s default terms. Accounts already accepted by the seller keep their agreed terms and remain usable.
• Notification emails now declare a light-only color scheme so dark-mode mail clients preserve the Apostra palette instead of force-darkening the template.
• Storefront media-buy routes with an immutable FX lock now have their stored buyer currency repaired from that lock, so seller-account money views do not label buyer-currency spend as USD when the buyer transacted in another currency.

​

5.855.0 — October 2, 2026 at 1:13 AM UTC

• Apostra now signs its AdCP calls to A2A sales agents as well as MCP agents, for every operation the agent lists in request_signing. The inventory source page no longer warns A2A agents that their calls arrive unsigned, and the authentication docs no longer limit signing to MCP. An A2A agent that required signatures can stop accepting a fallback credential from Apostra once it sees our signed calls verify.
• Buyer agents can record the payment terms sellers receive for consolidated billing when payment-terms rollout is enabled.
• If your inventory source is configured in Apostra as selling wholesale but your agent does not declare wholesale in its buying modes, Apostra now follows your agent’s declaration. It stops requesting your wholesale catalog and shows the catalog as empty, so your wholesale products no longer appear to buyers until you declare it. Your source is marked degraded, and its diagnostics name the fix: add wholesale to media_buy.buying_modes in get_adcp_capabilities. The next catalog refresh after that fills the catalog again. Buyer briefs still reach your agent, and a storefront that is already live stays live.

​

5.854.0 — October 1, 2026 at 11:57 PM UTC

• Apostra SDKs now provide cached OAuth client-credentials token providers for deployed backend integrations. Existing credential options continue to work unchanged.
• Organization administrators now find API keys and Advertisers under Organization in Account settings when working in the organization, and administrators of a standalone account find both in their Account settings. The API keys and Advertisers pages open the matching settings pane directly. Child accounts and members who are not administrators keep what they use today. No action is required.

​

5.853.1 — October 1, 2026 at 11:23 PM UTC

• Restore Agent behaviour baseline evaluations so Agent pages receive current Source baseline results.

​

5.853.0 — October 1, 2026 at 11:09 PM UTC

• Apostra SDKs can now retain a successful call’s server request ID and response headers through generated response variants. Existing method calls still return only data.
• Create Meta media buys with supported Facebook signal audiences.

​

5.852.0 — October 1, 2026 at 10:42 PM UTC

• Apostra SDKs now retry transient requests safely and provide receipt settlement helpers for caller-keyed writes.

​

5.851.1 — October 1, 2026 at 10:08 PM UTC

• Prevent AGENT-source creative syncs from sending create-only package fields.
• Read Meta flexible audience specifications back as signal targeting groups.
• When an organization administrator opens their organization, it now opens Organization members in Account settings instead of a separate organization settings page. Older Organization settings links go straight to the matching Account settings pane. Organization members who are not administrators keep their organization dashboard. No action is required.

​

5.851.0 — October 1, 2026 at 9:15 PM UTC

• Apostra SDK clients now read their API key, account ID and base URL from environment variables by default, so a status check can start with no constructor or empty input arguments.
• A Seller Account created without choosing a seller product now starts on the one your organization’s plan covers. On an Agentic Media Company plan it starts as Agentic Media Company instead of being refused; on a Listing plan, or without a paid plan, it starts on Just list as before. A seller product you choose yourself is kept, and is still refused when your plan doesn’t cover it.
• Pre-submit creative syncs for draft buys no longer send an invalid account to agent inventory sources before a source route exists.
• Adding, moving, restoring, or switching an account now checks your organization’s plan first. If the plan doesn’t cover the change, Apostra refuses it before anything is created and tells you which plan it needs and what to do next. For example, adding a Buyer Account to a Listing organization asks you to switch the seller product to Agentic Media Company, then choose an Agentic Media Company plan. Organizations without a paid plan can still add any account. The Account Access and Signup guide lists which plan holds which accounts.

​

5.849.0 — October 1, 2026 at 7:43 PM UTC

• Use @scope3/agentic-contracts/apostra and @scope3/agentic-contracts/apostra/sessions for canonical Apostra contract names. Existing Murph package imports continue to work unchanged.
• Google Drive folders shared with your connected account now keep their Library content current when files are renamed, moved, edited, or deleted. Nothing to change on your side.
• Buyer Setup now lets an organization administrator choose the payment terms Apostra asks new seller accounts to accept. The default is net 60, but it takes effect only after the administrator saves it. Longer terms can take longer to approve or be rejected because sellers carry the credit risk.
• If your agent requires an account for get_products, the source discovery test now sends one instead of failing with “account required”. The test buys as a test persona shaped like real demand: brand test-brand.apostra.com, operator test-agency.apostra.com (the agency holding the seat), and Apostra as the agent. It first registers that account with sync_accounts, using a billing mode your agent supports. When your capabilities declare account.sandbox: true, the account is marked as a sandbox account; otherwise the test result says it ran on a live account. Either way it sends only a no-spend get_products. Agents that assign their own account IDs still get the account-required result, since the test has no operator credential to use.
• When creating a Meta draft with save_media_buy, set budgetAllocation.mode to seller_optimized for one shared campaign budget or fixed for separate ad set budgets. If you omit the mode, the tool asks you to choose before creating the draft.
• Keep creative sync working when a buy’s selected products differ only by legacy video dimensions.
• Scope3-funded Creative Engine voice generation now reaches the selected voice provider instead of failing before generation begins. No change is needed to buyer-provided engine connections.
• If Apostra invites you to administer a new Buyer Account with a custom IU plan or discount, your account invitation can arrive with a Commercial Offer already prepared for your review. Verify the invited email and join the account, then review and accept the Offer separately. Receiving the invitation does not accept its price or subscription terms for you.
• When you reset a password in Apostra, the recovery screens now match the sign-in experience from the first reset request through confirmation. Nothing changes about how you request or complete a password reset.
• Murph now recognises more ways of sharing a secret in chat and sends you to the secure credential form instead. That covers API keys, plurals such as “passwords” or “tokens”, and wording such as “I’m sending” or “I pasted”. Before, a message like “I’m sending my API key now” didn’t trigger the secure-form redirect.
• Embedded sales agent 1.50.0: classify ad-server failures for buyers and log vendor detail for operators, serve AdCP 3.2-rc.7 on adcp 8.0.0rc3.
• If you create or read event sources through the V3 API, use save_event_source and search/get with kind: "event_source". The duplicate save_measurement_source tool and the measurement_source search and get kind are removed from V3 MCP, the V3 HTTP API, and the Apostra SDKs. Calls to them now return an unknown-tool or invalid-kind error. Your event sources and the campaign goals that reference them are unchanged: an event source’s eventSourceId is the same value on both paths, so existing campaign optimization goals keep resolving. The V2 REST event-source and measurement-source endpoints are not affected.
• When a storefront’s creative library held two versions of the same creative, the storefront could alternate between them, creating a fresh delivery for each about once a minute and sending callbacks for the older version’s operation. That alternating has stopped, so your callback endpoint no longer receives those repeated callbacks. Submitting creatives with sync_creatives works exactly as before.
• Rate cards no longer show a selling-point suggestion containing their prices.

​

5.848.0 — October 1, 2026 at 5:26 PM UTC

• Campaign creative resync now continues for eligible media buys when another buy is still waiting for a route. You can also archive failed, canceled, and rejected media buys without sending another seller cancellation.
• Rate-card hard floors now apply to every price, and the rate-card preview says when a row will not apply.
• Connected Library sources: Sync now now also retries files that failed to import, instead of leaving them until the file changes in Google Drive, SharePoint or Confluence. Use it after fixing whatever stopped the import, such as restoring access.
• A product that declares no optimization capability no longer receives optimization goals on its package. The seller still sees every goal in the brief, and each withheld goal is reported in the optimization_goals_dropped execute warning with its reason.

​

5.847.0 — October 1, 2026 at 4:27 PM UTC

• Apostra SDK writes now align generated body idempotency fields with the caller-owned request key.
• Apostra SDK errors now provide typed classes, stable codes, recovery guidance, retry metadata, and request IDs.
• The Archive account row in a buyer account’s Settings → Danger zone showed a button that could never be used and told you to contact support. Organization administrators now get Open organization accounts, which switches to the organization and opens its account list, where you can archive the account. Other members of the account see that an organization administrator archives it. Standalone buyer accounts no longer show a Danger zone, because only accounts inside an organization can be archived.
• Keep legacy creative-format routing available for wholesale media buys when a legacy seller has no projection catalog.
• When Apostra rejects a LinkedIn create_media_buy or update_media_buy before sending anything to LinkedIn, the error now carries details.mutation_outcome: "not_dispatched". Retrying such an update with the same idempotency key now runs it again instead of replaying the saved failure; a create retry does the same when the error is correctable (recovery: "correctable"). Errors after LinkedIn received a change keep the key and replay as before. Nothing to change on your side.

​

5.846.0 — October 1, 2026 at 3:04 PM UTC

• When a sender texted your agent phone line again while the agent’s reply to them was being sent, that reply could fail and be marked with an unknown delivery outcome, even though it was never handed to the carrier. The reply now sends normally and the new text is still received. Texts from other senders to the same line are also no longer held up while a reply is being sent. Nothing to change on your side.
• Archiving a sandbox advertiser now releases its brand identity, so you can create a new sandbox advertiser for the same brand, countries, and currency instead of restoring the archived one. Only one active sandbox advertiser can hold a brand identity at a time: restoring an archived sandbox advertiser whose brand identity another active sandbox advertiser now holds returns 409 CONFLICT with reason: brand_identity_exists and that advertiser’s advertiserId. Non-sandbox advertisers are unchanged: an archived one still holds its brand identity.
• Apostra app and agent icons now use the centered official apostrophe mark.
• The app now defaults to the Apostra-branded presentation without requiring a product-brand flag, gateway hostname, query parameter, or local preview setting.
• Meta media buy creation now rejects a product that is still in testing, even when the buyer holds a product ID from an earlier discovery. The request fails with UNSUPPORTED_FEATURE before anything is sent to Meta, so no campaign is created. Select a product returned by a current get_products call instead.
• When you open Plan & Billing from inside a Seller Account that belongs to an organization, it now says that billing and payouts are managed by the organization, by name. If you administer the organization, Open billing takes you to the organization’s billing, where you can make changes; in the web app this also switches you to the organization. If you don’t, the page names the organization and says that one of its administrators makes these changes.
• Proposals now use the seller’s public listing name.

​

5.845.0 — October 1, 2026 at 1:29 PM UTC

• Connected Library sync now skips empty Google Drive files safely and continues importing healthy files when one file needs a retry.
• When you try to change payouts or billing from a Seller Account that belongs to an organization, the refusal now names the organization that manages billing, for example “Payouts for Azerion are managed by the Azerion Admin organization.” If you administer that organization, it tells you to switch to it; otherwise it tells you that one of its administrators has to make the change. API and agent integrations also receive the organization and the next step in the error details.
• Embedded sales agent 1.49.6: let the GAM write canary traffic as booking does when no trafficker is set.
• If you create products on a managed inventory source, include channels on every new product, such as display, olv, ctv, or streaming_audio. save_wholesale_product and the product API now warn when a new product declares none, and we will start refusing those creates after a separate announcement. Any channel code that isn’t an AdCP channel is refused now, on creates and on changes. Changes to existing products work as before: leave channels out to keep the ones a product has, or send a list to replace them. Declared channels are how buyers find your products in channel-filtered discovery, send you the right proposal requests, and see your delivery by channel. Products saved before this change keep working as they are.
• Breaking change on the v3 MCP endpoint: in media buy live status (get with kind: "media_buy" and include: ["liveStatus"]), liveStatus.adcpMediaBuyId is renamed to liveStatus.storefrontMediaBuyId. The old field is no longer returned, so agents that read liveStatus.adcpMediaBuyId must switch to liveStatus.storefrontMediaBuyId. The value is the same: the storefront’s id for the buy, null until the buy is submitted. The rest of the live status is unchanged. The v2 REST and MCP APIs do not change; Get media buy status still returns adcp_media_buy_id.

​

5.843.0 — October 1, 2026 at 12:04 PM UTC

• Murph now answers questions that mention credentials instead of replying only with a link to the secure credential form. Before, asking something like “what auth type does my sales agent use?” alongside words such as “send” or “enter” could get every answer replaced with that link, even when you weren’t trying to share a secret. Murph still sends you to the secure form, and won’t take the secret in chat, when you offer to share a password or token with it or paste one into the conversation.
• Library responses show the document passage or rate-card row behind each block.

​

5.842.0 — October 1, 2026 at 11:35 AM UTC

• Add notes to the Library for information that is not in a file. Give a note a short title and save it for your storefront agent to cite. Open a note to see its author, date, and current revision.
• Embedded sales agent 1.49.5: when a buyer updates a Google Ad Manager media buy, the line item’s custom targeting is rebuilt from the product’s own targeting keys plus the buyer’s new targeting. Before, an update could drop the keys that define the product, so the line item delivered more broadly than what was sold, and criteria the buyer removed could stay on. HTML5 ZIP creatives now upload to Google Ad Manager as native HTML5 creatives.

​

5.841.0 — October 1, 2026 at 11:09 AM UTC

• When an external sales agent needs a credential or an OAuth grant, Murph and V3 agents are now pointed to that source’s own connection form, where you can enter it. Before, they were pointed to the ad-server connect page (Google Ad Manager, FreeWheel and so on), which can’t reach a sales agent, so you were left with nowhere to enter it. A sales agent saved with “No auth” is still treated as connected and is never asked for a credential.

​

5.840.0 — October 1, 2026 at 10:30 AM UTC

• Embedded sales agent 1.49.4: apply only the sent fields in the SpringServe, FreeWheel and AdsWizz settings PUTs.

​

5.839.4 — October 1, 2026 at 10:01 AM UTC

• Talpa’s approved 30-second audio creative can reach Triton again, and future catalogue refreshes keep its reviewed format route intact. The existing creative will be retried without changing its media or format selection.

​

5.839.3 — October 1, 2026 at 8:58 AM UTC

• Campaign creative syncs now include HTML5 display dimensions in the creative format parameters sent to managed storefronts. Existing ZIP-backed creatives can be retried without re-uploading, so approved campaigns no longer stop before ad-server delivery because width and height are missing.

​

5.839.2 — October 1, 2026 at 8:09 AM UTC

• Changing a media buy’s start or end date now waits for the seller to confirm the change before reporting success, matching the existing behavior for budget and targeting updates. Previously, a flight-date change could be reported as successful immediately, before the seller had accepted it — so a rejected update (for example, a date change on a paused campaign) could leave the live campaign unchanged with no error surfaced. A rejected date change now returns an error instead of a false success.

​

5.839.1 — October 1, 2026 at 7:11 AM UTC

• Approved creatives for an unsubmitted media buy now reach its selected seller source before the buy is sent. Existing drafts recover automatically, and buyers do not need to recreate them.
• Fix Meta create/update media buy and region/city targeting search intermittently failing with a generic upstream error. Meta rewrites the pagination continuation link it returns to its current default API version regardless of the version the request used; the adapter was rejecting that link as untrusted instead of following it.

​

5.839.0 — October 1, 2026 at 5:10 AM UTC

• Buyers can generate and save approved Creative Engine outputs directly to an advertiser’s Creative Library without creating a campaign first.

​

5.838.0 — October 1, 2026 at 3:56 AM UTC

• The Apostra TypeScript and Python SDKs now include generated guidance for every operation and documented field, helping developers and agents understand API calls directly in their editor.

​

5.837.0 — October 1, 2026 at 3:33 AM UTC

• The Apostra TypeScript and Python SDKs now use stable, meaningful V3 schema type names instead of positional generated aliases.

​

5.836.1 — October 1, 2026 at 3:04 AM UTC

• Apostra Buyer invitation emails now link to the quickstart guide, so invited teams can start setting up their account after joining.

​

5.836.0 — October 1, 2026 at 2:50 AM UTC

• A creative now attaches to a product that offers its format at several sizes or lengths, as long as its uploaded asset matches exactly one of them. Before, a 1920x1080 video sent to a product offering 1920x1080, 1280x720 and 640x360 video was rejected as “ambiguous canonical identity matches 3 distinct product options”, even when you also passed the matching format. If the asset matches none of the options exactly, or hasn’t been measured yet, it is still rejected and you can name the option with format_option_refs[].
• When your campaign has optimization goals, each seller package now carries only the goals that product says it can optimize, so a goal a seller cannot act on no longer causes that seller to reject the whole buy. Goals left off a package are listed in an optimization_goals_dropped warning when the campaign executes, with the product, the goal and why it was not sent. Sellers still see every goal in the brief, products that declare nothing still receive every goal, and nothing changes on your side.

​

5.835.0 — October 1, 2026 at 2:01 AM UTC

• Prices are now edited in your Library’s Rate card document, and the Playbook shows the current rate card with a link to edit it.
• Validate V3 Creative Session saved and promoted results against the existing public contract.

​

5.834.0 — October 1, 2026 at 1:16 AM UTC

• Sales Agent owners can see the stored baseline declarations for Agent eligibility and whether property-list buys are eligible on the Agent Page.
• If Apostra has provisioned an agent voice line for your Seller Account, inbound calls to that number are now answered — nothing to set up on your side. Callers hear, before anything else, that they have reached an automated agent rather than a person, then the call ends; the line cannot carry a conversation yet. Apostra keeps a record that the call arrived, was answered, and was disclosed, but never stores the caller’s number or the number they dialed. Call recording and transcription stay off, unchanged by this.
• Each step of the call is durable work, so a restart part-way through retries rather than abandoning a caller, and a retry never answers or speaks twice. If your line is turned off mid-call, the call is ended rather than left open and silent.
• Voice lines are in limited rollout and provisioned by Apostra — there is no self-service setup yet. Contact Apostra if you would like one for your storefront agent.
• Breaking change: the old one-source-per-call V3 save_event_source request no longer works. Update your calls to send one advertiserId, one idempotencyKey, and an eventSources list of up to 50 entries, each keyed by your own eventSourceId, to create, update, archive, or restore a source in a single call. name is still required when an entry creates a source, and allowedDomains, integrationPlatform, mapping and testEventCode are no longer accepted on V3. Each entry returns its own result, so one failed entry does not stop the rest, and failures come back as AdCP-shaped errors. The event source object also drops the separate id field, using eventSourceId as its only id, reports health in the AdCP EventSourceHealth shape, and lists sellerAccounts instead of a single sellerId; sellerAccounts is empty until seller-account sync ships.
• Storefront readiness now catches a sales agent whose billing declaration leaves buyers no way to pay. If your agent’s AdCP capabilities declare account.supported_billing with only advertiser, or your agents declare billing models with nothing in common, readiness shows a supported_billing_declared blocker, and buyers can’t connect to the storefront until it clears. To fix it, include agent (consolidated billing) or operator in the declaration (an agent that requires operator authentication must include operator), then refresh its capabilities from source diagnostics. The blocker clears on its own. Agents that don’t declare billing at all use consolidated billing and need no change, and platform adapter storefronts are unaffected.
• Campaigns now follows your language. The campaign list, campaign details, statuses, filters, dates, amounts and error messages appear in German, Spanish, French, Italian, Japanese, Korean, Dutch, Brazilian Portuguese or Simplified Chinese, and switch when you change the language in Apostra, Claude or ChatGPT. Campaign names and other text from your data are shown as entered.
• Creative review callbacks no longer fire for a sync_creatives operation that a later submission of the same creative has already replaced. The outcome arrives on the callback of the newer operation, so your webhook endpoint stops receiving stale results for work it has already re-submitted. A callback your endpoint rejected permanently stays parked and is not re-sent.
• Proposals now draw on your Library documents for full-length briefs. Previously a passage had to contain every word of the brief before the agent could cite it, so most briefs found nothing to cite.
• Fix account-scoped bookings for complete-key seller accounts. These bookings no longer try to write a complete-key seller-account identifier into legacy numeric route fields.
• Media Partners no longer shows Add media partner on the card of a media partner you have already connected. The card now shows that connection’s next step: Choose account, Reconnect, Map advertiser, or Manage. In an advertiser’s view, Map advertiser and Manage reflect whether that advertiser is mapped.
• Agents can answer the same question: each result from search(kind:"connection") now includes mappedAdvertiserIds (up to 100 advertiser ids, ascending) and mappedAdvertiserIdsTruncated alongside mappedAdvertiserCount.
• Storefront product discovery no longer refuses a brief because it contains ordinary numbers such as “over 3 months”, “up to 10 euro”, “at least 12 months” or “500+ leads”. Those briefs previously came back with no products and a request to clarify age targeting. A brief that states an age with only one bound, such as “people over 35” or “18+”, still asks for both bounds before any product is returned.
• The storefront Buyers directory now loads month-to-date spend instead of showing unavailable values when delivery data is present. Currency handling and zero-spend filtering are unchanged. No action is required.
• Buyers using MCP assistants can now switch from an Organization to a Buyer Account and continue the same task without reconnecting.
• Agents can switch into an Organization account, check its status, and switch back to a Buyer Account. Signed-in administrators can also find Organization tools in an MCP connection that keeps its initial tool list. Each action still uses the permissions of the selected account.
• When a seller on AdCP 3.2 answers your cost goal, the proposal and the booked media buy now record the cost it can plan to. A 3.2 seller states that cost in commercial_terms.bidding.cost_per, so a cap of 3 it can only plan at 4.50 now shows as a best-effort answer of 4.50 that misses your ask, instead of an unanswered goal. Sellers on earlier AdCP versions read exactly as before.
• Opening Plan & Billing, or another organization-level page, no longer signs an organization admin out to the “Request access” page. The organization itself stays open so you can review billing or choose an account. Nothing to change on your side.
• When a linked storefront source sends a booking, update, delivery read, or creative request to a partner, the partner now sees your storefront as the buyer. Your buyer’s account stays on your own booking and is not shared with the partner. Nothing to change on your side. If a partner requires its own buyer account, the booking returns a clear error instead of using your buyer’s account.
• If you administer a buyer or seller organization with child accounts, you can now open Account settings → Organization from the organization or a child account to manage accounts and members and review the organization’s billing and contract details without switching accounts. Members with access only to a child account see a notice naming the organization that manages billing; they cannot see its accounts, members, contracts, rates, or payment information. No setup is required.
• A V3 request_proposals round on a campaign with channel groups now asks only the sellers that can match those groups, so an audio-only campaign no longer contacts display-only sellers. Nothing to change on your side. A seller counts as a match when at least one channel it declares matches a group, and aliases match (a seller listed as audio matches streaming_audio). A seller that declares no channels is still asked, and official platform integrations use the platform’s own channel coverage. Campaigns without channel groups, and rounds already running, are unchanged.
• Each seller asked receives the union of your groups’ channels as its AdCP channels filter. Returned products whose channels or creative format kinds fit none of your groups are dropped, along with any proposal that allocates budget to them, and the seller’s outcome reports the count as channelExcludedProductCount. Products that declare no channel or format are kept.
• The response lists eligible sellers that were not asked in skippedSellers (up to 25 named, with a total), each with the channels it declares and the reason channel_mismatch. If no eligible seller matches, the round fails with NO_ELIGIBLE_SELLERS. Seller narrowing applies only when every channel group names at least one channel; if any group names none, every eligible seller is asked and no channel filter is sent. A round whose one seller is fixed by your account, such as a sponsored-buyer or own-supply sandbox campaign, never skips that seller. To include a skipped seller, add a channel group for its channel and start a new round.
• Your coding agent can now prepare credential setup for an existing external buyer agent. Complete setup in Settings → API keys → Manage buyer agents, then store the one-time secret directly in your runtime’s secret store. Your coding agent receives only a non-secret reference and server-verified setup state.
• The reference is bound to the administrator, organization, and buyer agent, and expires after 15 minutes if unused. An active credential does not confirm that the runtime stored it or authenticated. Advertiser access still requires separate grants.
• A text that an agent line refuses before it reaches the carrier, because the recipient opted out after it was queued or the line is no longer active, no longer counts toward the line’s rate or daily spend limit. Queued texts to opted-out recipients can no longer hold back the line’s other texts.
• Apostra-managed sales agents on SpringServe and Triton now refuse a buy whose targeting they can’t apply, instead of booking it and silently ignoring that targeting. This covers audience signals and signal groups (including exclusions), dayparts, devices, language, metro targeting outside Nielsen DMA, and other fields those ad servers don’t support. A refused launch names the targeting the seller can’t apply, so you can remove it or choose another seller. Nothing already running changes.
• Creative Session saves and generation work again after a storage change.
• Apostra-hosted applications retry a transient runtime configuration failure during startup before showing the secure configuration error.
• Sales-agent developers can now read Apostra’s required declarations, live-behaviour standards, and integration best practices in one guide.
• Settings now always opens in place: the left rail switches to the settings navigation and the section you pick fills the conversation area. Previously the Settings gear on the collapsed rail opened a separate window over the page, while the Settings button on the open rail and every settings link expanded in place — the same screen behaved two different ways depending on where you opened it from. On a narrow screen the sections were a horizontal strip you scrolled sideways; they are now the same grouped list you see everywhere else.
• The “Receive Murph announcements” switch also now tells you when it fails. It used to move on click and stay moved even if the save failed, so the setting could read as on while it was still off. Now a failed save puts the switch back and shows an error.
• The inventory source page now shows how your agent handles request signing. Technical details reads the request_signing block from your agent’s get_adcp_capabilities response and lists each category it declares: the operations it requires signed, the ones it checks without enforcing, and the ones it verifies when a signature is present. If it declares no signing, the row says so. Next to the authentication choices, the connection form now explains that request signing is not a credential and has no setting there. Apostra signs the operations an MCP agent lists; calls to A2A agents are not signed yet, and an A2A agent that requires signing now sees a warning on the page. The authentication docs now state this boundary. The source diagnostics API returns the same declaration as source.capabilities.requestSigning.
• Dimension save results now provide typed action, identity, and usage fields in the Apostra TypeScript and Python SDKs while retaining provider extension fields.
• If your storefront uses a third-party sales agent, Setup now shows a Product channels declared warning when some of its products declare no AdCP channels (such as display, olv, ctv, or streaming_audio), with a count for each agent. Buyers filter discovery, route proposal requests, and report delivery by channel, so those products are missing from channel-filtered discovery. The warning does not block your storefront or stop the agent from receiving requests. To clear it, ask the agent’s operator to add channels to each product, or applies_to_channels to its formats. Channels will become required for external agents’ products in a later change, announced before it takes effect.

​

5.833.0 — September 30, 2026 at 8:29 PM UTC

• Choosing your organization’s payment terms is now a go-live step for sellers on consolidated billing. Until an organization administrator chooses them, buyer readiness shows an incomplete Payment terms check, those sellers show needs_commercial_setup, and a buy from one is refused with the payment_terms blocker. Direct-billed sellers aren’t affected. Set paymentTerms with Update billing info (PUT /api/v2/billing/info), even if you want to keep the default. Once chosen, terms can be changed but not cleared: paymentTerms: null is refused. See “Your organization’s payment terms” in Buyer setup.
• You can now cancel a single media buy with save_media_buy by sending isCanceled: true, and its campaign and the other media buys on it stay as they are. Cancellation can’t be undone, and if the seller has to confirm it, the response says the cancel is pending seller confirmation.
• Keep package assignments when creatives are re-synced to an existing media buy, so seller-approved creatives reach the intended ad-server line item.
• Discovery now removes excluded publishers from multi-publisher products while retaining the remaining eligible inventory.
• Organization settings now shows active and archived accounts separately, keeps Add account visible to administrators, and explains when account creation is unavailable. Billing & contract can load while account setup is pending.
• When you sign up as a seller, the plan list now shows every public plan that applies to sellers, including the Storefront agent plans, instead of leaving them out. The plan you accept sets your starting seller product: a Listing plan, or no paid plan, starts you as Listing only, and a Storefront agent plan starts you as an Agentic Media Company. A paid plan you choose is accepted as part of signup once your email address is verified, and takes effect when signup completes. Only an accepted plan sets your starting product: if your email is not yet verified, or the plan you picked stops being offered while you are signing up, you finish on the free pass-through terms as Listing only and choose a plan again. Your account is saved with its product, so Plan & Billing shows the plans that match it after you sign up. You can change your seller product later in Settings. Nothing to change on your side.

​

5.832.0 — September 30, 2026 at 7:38 PM UTC

• The default payment terms for your organization are now net_60 instead of net_30: until you choose, net_60 applies and sellers are asked for it. On storefronts Interchange hosts or manages, only net_60 is approved automatically; any other terms, shorter or longer, wait for the seller’s review. See “Your organization’s payment terms” in Buyer setup.
• In a Demo Storefront, the Product Marketing practice card no longer asks you to review or confirm proposed facts from the sample teaching documents. Proposals quote those documents directly, so there is nothing to confirm. After you prepare the samples, the card says they are still processing and offers the held-out synthetic buyer brief once they are ready. Nothing to change on your side, and your own documents are unaffected.

​

5.831.0 — September 30, 2026 at 7:27 PM UTC

• Campaign launches now identify the affected media buy when campaign targeting conflicts with a selected package and explain how to correct it. The same safe reason remains visible on the failed media buy, while raw seller error text stays hidden.
• Demo Storefront evaluations again open their synthetic buyer brief after the teaching sources are ready. The demo keeps its approval flow and all three synthetic inventory sources.
• Canonical VAST creatives now reach legacy sellers through managed storefronts as well as direct seller connections. No storefront changes are required.
• In the Generated variants gallery, select Save to library to add the selected, approved output to that advertiser’s Creative Library as a Creative Asset revision. Use in campaign remains separate, so saving to the library does not create or change a campaign Creative. If the library save is refused, the approved output remains available to try again. This is available to buyers enrolled in Creative Engines.
• Media buys for legacy-only sellers now retain the seller’s declared legacy format ids when no canonical option-to-legacy mapping is available, so those buys can dispatch.

​

5.830.0 — September 30, 2026 at 6:41 PM UTC

• API guidance, connector confirmations, schemas, and localized next steps now use Apostra and Apostra Support consistently while preserving legal and compatibility identifiers.
• Account setup, marketplace, connections and operator guidance now use the Apostra name in every supported language. Legal Scope3 references and registered Scope3 provider identities are unchanged.
• Apostra Slack messages now use Apostra wording in account-access, App Home, and assistant greeting copy.
• In-chat widgets now use Apostra for platform, operator and support naming while preserving stable identifiers and customer-provided content.
• Adding a Seller Account now asks How would you like to sell? — Just list or Create an AMC account — and the new storefront starts with that choice. The answer decides which seller plans your organization is offered and which workspaces the account shows. You can still change it later in Settings → How would you like to sell?
• Your organization can now choose the payment terms Apostra asks sellers for: net_15, net_30, net_45, net_60, or net_90. Nothing changes unless you set them, and net_30 applies until you do. Set paymentTerms with Update billing info (PUT /api/v2/billing/info); the choice covers every advertiser in your organization.
• When Apostra opens an account with a seller for you, such as when you turn a seller on for an advertiser or buy from a seller for the first time, the request asks for your terms. The seller accepts them by approving the account, or declines the account; sellers never change the terms. On storefronts Interchange hosts or manages, only net_30 is approved automatically, so longer terms wait for the seller’s review, and some sellers decline them because they carry the credit risk.
• Accounts a seller has already accepted or rejected keep their decision and terms; a new choice applies to accounts opened afterwards. For now, a seller that doesn’t take requested terms gets the request again without them, so the account opens on that seller’s default terms. See “Your organization’s payment terms” in Buyer setup.
• Canonical VAST creatives pinned to an unconstrained product format can now be delivered to sellers that still use the older AdCP creative format. Exact seller mappings continue to take priority, and no action is needed on your side.
• In a Demo Storefront Library, after you select “Prepare synthetic teaching materials”, the Library now says the sample documents are still processing and keeps checking until they are ready. It then shows “Open held-out synthetic buyer brief” without a reload. Previously it could stop at “0 proposed facts still need review.” with no way forward. If processing takes longer than five minutes, the Library stops checking and offers “Retry synthetic evaluation”. Nothing to change on your side, and your own documents are unaffected.
• Let seller delivery resolve legacy creative format refs instead of pinning migrated product options.
• Send property-list include filters to sales agents that declare discovery filtering support, and avoid sending unsupported exclusion filters during product discovery.
• Fix storefront media-buy updates that fail after a source has accepted them: the buyer update is kept for seller readback instead of being closed as safely rolled back.
• When a linked partner storefront leaves the marketplace, it cannot receive new briefs, media buys, budget increases, or new packages. Existing linked bookings continue to support delivery, cancellation, decreases, creative sync, and approvals while the partner storefront still exists.
• Pages such as Campaigns and the advertiser roster open faster in the Apostra web app: the page starts loading while its access check is still running, instead of waiting for the check to finish first.
• Account-scoped media buys now keep the account relationship that authorised them when they are sent to a seller. Delivery reads for that same account can find those buys; other accounts and customer-wide reads remain separate.
• Every new storefront now starts with a seller product, so seller plans are offered for Seller Accounts created outside supply-side signup. Accounts added with Add account or POST /api/v2/accounts/create-child, and storefronts created with POST /api/v2/storefront, start on Just list unless the request sends operatingMode: "AGENTIC_MEDIA_COMPANY". Storefronts Apostra provisions for an Apostra-managed ad server start as Agentic Media Company. You can change the seller product at any time in Settings → How would you like to sell?
• Support controls, activity and guidance now use the Apostra Support name. Existing access permissions and customer controls are unchanged.
• Apostra’s signing identity is now https://api.apostra.com. If your sales agent verifies the RFC 9421 signatures on our calls, you can configure it with https://api.apostra.com: its /.well-known/brand.json now lists that agent URL, pointing to the same request-signing key we already use. Verifiers set up with https://api.interchange.io keep working, because that URL stays listed with the same key. To have us sign calls to your agent, declare request_signing in your get_adcp_capabilities; the Authentication docs describe the steps.

​

5.829.0 — September 30, 2026 at 5:26 PM UTC

• Accepting an IU plan from Plan & Billing no longer fails with a generic error when the Rate Card includes an activity at no charge, such as Enhanced Reporting included on the September plans. The accepted plan shows that activity by its standard name and records it as included. If an earlier attempt failed, accept the plan again. Nothing else changes.
• The Advertisers Page filter row is easier to read and use. The Dimensions filter now shows how many values you have selected instead of listing each one, so it keeps a single fixed width and no longer pushes the search field aside. The search field is wider as a result. Each advertiser row’s action — “Open”, “Review 2 proposals”, “Create first campaign” — is now a real button, so it can be reached and activated from the keyboard. Clicking anywhere on the row still opens the advertiser.
• Your agent phone line no longer answers a text that is more than 15 minutes old by the time the agent reaches it, so a sender never gets a late reply to a stale question. Blank texts and texts to a line whose storefront is archived, replaced, or in adapter mode are also left unanswered instead of being retried. A text from a number that has opted out never reaches the agent, even when the opt-out arrives while the text is waiting. The agent answers at most 5 texts per sender every 15 minutes and 60 per line every hour, so two automatic responders cannot keep a line texting indefinitely. A text the agent is answering when the service restarts is finished or safely set aside, and it is never answered twice.
• Buyers can read live delivery for their own campaigns on any storefront, including external AdCP storefronts without a seller Distribution profile. Buyer authorization and tenant scope are unchanged.
• When Creative Sessions cannot complete an image generation, Murph now receives a clear generation result instead of an unexplained internal error. Leave the engine blank to use the funded default unless you choose a specific provider. Nothing to change on your side.
• Selecting Branding & distribution from the seller setup rail now opens the page after publisher domains are added. Payment & billing and other setup pages are unchanged, and there is nothing to change on your side.
• Murph in Slack now keeps processing messages that arrive together while it refreshes its connection to your workspace.
• Media buys accepted by a seller are now saved before follow-on lifecycle evidence is recorded, so a local evidence-write failure cannot make an accepted seller buy look failed or disappear from Apostra.
• Creative reviews now reject products that are missing an exact format mapping for an older sales agent before approval. Approved creatives also show delivery failures separately from the approval decision, so sellers can refresh the product route and retry instead of seeing a pending or completed state.

​

5.828.1 — September 30, 2026 at 4:25 PM UTC

• Searching your Library now finds text in your documents that previously did not appear in results.
• Campaigns now loads a smaller page after an account switch by leaving unrelated widget translations out of its download.
• Embedded sales agent 1.49.2: bump urllib3 to 2.8.0 past new security advisories.
• The sign-in and sign-up pages now appear as soon as they load when you aren’t signed in, instead of showing a loading spinner while the app checks for an existing session. If you are already signed in, you are still taken straight to your account, and nothing changes on your side.

​

5.828.0 — September 30, 2026 at 3:40 PM UTC

• Archive and restore seller Library documents from the Documents list.
• In Media Partners, a connection whose sign-in didn’t finish now shows Finish connecting, so you can retry that same login without removing it first. Clicking Add connection again reuses the unfinished connection instead of adding another empty one, and the list shows at most one unfinished connection per media partner.
• Campaigns now loads advertiser currency and time-zone settings reliably after account switches, including for advertisers with older metadata. Nothing changes on your side.
• On the Media Partners page and in the Media Partners widget in chat, the confirmation dialogs (Remove connection, turning a media partner on or off, data sharing, direct billing) now open in the part of the page you can see, so Confirm and Cancel are always reachable. Before, with a connection expanded, the Remove dialog could open partly below the visible area and could not be scrolled into view, so the connection could not be removed. When the widget area is short, the dialog now scrolls on its own. Nothing to change on your side.
• When save_advertiser cannot link, unlink, or update an advertiser’s partner account, it now returns the error code and the actual reason, such as the account not being found or its currency not matching the advertiser. Before, every failure came back as a generic “Account assignment failed.”. Internal failures still return a generic message. Accounts on a connection you authorized, such as Spotify, Google Ad Manager, or Meta, are linked with save_connection and advertiserMapping, using the account id from get(kind:"connection"). The tool text and the not-found error both say so. Advertiser-level Seller activation (save_connection advertiserActivation) is in limited rollout, and the docs now say what its ACCESS_DENIED error means. Nothing to change on your side.
• For organizations with the new settings group, administrators can use Account settings → Organization to add, archive, and restore child accounts, manage organization members, and review billing and contract details. The account switcher lists switchable accounts and pending invitations.
• When Apostra rejects a Pinterest create_media_buy or update_media_buy before sending anything to Pinterest, the error now carries details.mutation_outcome: "not_dispatched". Retrying such an update with the same idempotency key now runs it again instead of replaying the saved failure; a create retry does the same when the error is correctable (recovery: "correctable"). Errors after Pinterest received a change keep the key and replay as before. Nothing to change on your side.
• Embedded sales agent 1.49.1: prove GAM write permissions per tenant with a no-spend canary, bump oauthlib and pyjwt past new security advisories, declare brief and wholesale media buy buying modes.
• Connection save results now validate stable action, browser handoff, and mutation receipt fields while preserving provider-owned metadata.

​

5.827.2 — September 30, 2026 at 2:21 PM UTC

• The media partner connections widget now shows two cards side by side at narrower widths. Previously the grid dropped to a single column below 768px, which left a column of wasted space in narrower chat panels; it now keeps two columns down to 640px.

​

5.827.1 — September 30, 2026 at 1:37 PM UTC

• When Apostra rejects a Snap create_media_buy or update_media_buy before sending anything to Snap, the error now carries details.mutation_outcome: "not_dispatched". Retrying such an update with the same idempotency key now runs it again instead of replaying the saved failure; a create retry does the same when the error is correctable (recovery: "correctable"). Errors after Snap received a change keep the key and replay as before; a create that Apostra deleted from Snap after a later step failed now reports details.mutation_outcome: "rolled_back". Nothing to change on your side.

​

5.827.0 — September 30, 2026 at 1:06 PM UTC

• The reporting docs now describe the views metric correctly. views counts content views as the seller reports them: a video view such as 30 seconds or the midpoint, an audio stream start, or the view event set by the package’s pricing model. It is the unit CPV pricing bills on. Earlier docs said views counted viewable impressions and could be divided by impressions to get a viewability rate. That was wrong. Don’t use views to estimate viewability. The numbers themselves haven’t changed, and there’s nothing you need to change.
• Meta wholesale get_products now stamps ext.scope3_execution_readiness on every product when the buyer’s Meta ad account is connected, not only the app, lead-messaging, catalog, Shop and Event products. Pixel-based products such as Sales, Website Leads and Landing Page Views now show at discovery time whether the account has a Pixel, instead of failing later at create_media_buy. Page candidates are now the Pages the selected ad account can promote, the same Pages a media buy accepts, so discovery no longer offers a Page that create_media_buy would refuse.

​

5.826.0 — September 30, 2026 at 12:03 PM UTC

• Fixed linked storefront source discovery so an active partner storefront stays connected while it responds to a buyer brief. Pilot storefronts can receive their partner’s offers again without reconnecting or retrying.

​

5.824.0 — September 30, 2026 at 11:03 AM UTC

• Organization admins can manage members and membership settings from child accounts they administer. Member lists and settings now check direct admin access to the requested account or its parent organization. An organization admin in a child account can also accept the organization’s billing terms after confirming them in Plan & Billing; the acceptance belongs to the parent organization.

​

5.823.0 — September 30, 2026 at 10:27 AM UTC

• Organization administrators can now ask their agent to create a Buyer Account under their organization, including from a text-only host. Nothing to change on your side; existing Accounts and calls behave as before.
• The agent first calls review_buyer_child_account, which is read-only and shows the name, Buyer role, remaining account capacity and inherited access. It then calls request_buyer_child_account, which returns approval_required with a link. Nothing is created until an administrator of the organization opens the link, signs in on our site and approves. That can be a different administrator from the one who asked. The request expires after 24 hours. Repeating it with the same idempotencyKey returns the outcome, including the new Account ID.
• Creation sends no invitations, grants no direct membership, changes no feature flags and creates no media buy. Organization administrators inherit access. The Account is not ready to transact until Buyer Setup is done.

​

5.822.0 — September 30, 2026 at 10:05 AM UTC

• The Library no longer asks you to review selling points; the agent cites your documents directly. It also no longer creates wholesale-product proposals from document prose.
• Pilot storefront owners’ active linked storefront sources now receive buyer briefs and bookings. When a buyer’s brief reaches your storefront, it is forwarded to the partner storefront, and the partner’s offers come back unchanged, with no markup. Pass-through only: the buyer pays what you pay the partner, and you keep 0% on the platform. There is nothing to change on your side. Sources you already activated start routing as long as the partner’s consent is still current.
• Storefronts outside the pilot see no change.
• Only active linked storefront sources with current partner consent receive new briefs and bookings.
• When one booking spans several linked partners, each partner receives only the packages chosen from its own offers.
• Pending, disabled, archived, and no-longer-authorised links get no new briefs or bookings. Existing bookings keep their recorded terms for reporting and cancellation.
• Active linked storefront sources now report selectable: true.

​

5.821.0 — September 30, 2026 at 9:07 AM UTC

• Your storefront now opens on your work, not on last quarter’s numbers. Where a live storefront used to land on Seller analytics — RFP win rate, booked budget, response rates — it now opens the operations home: your active buys, ranked by what needs you, with up to three flags on each. A task waiting on you. Delivery that is not moving as the flight implies. The buyer’s goal being missed. Money the flight will not deliver comes first — the budget minus what your current spend rate projects over the whole flight, not the hole so far — then work waiting on you, then a goal behind, then everything on track. Within the first group, buys are ordered by the share of their budget at risk rather than the raw amount, so a large number in a small currency does not outrank a buy that will miss half its budget. The Media buys entry in your rail opens in the same order: it is the same page over the same buys, and ordering them differently by how you arrived would rearrange the list with nothing to explain it. The three flags stay separate on purpose: “spend 200 a day at 80% viewable” is two answers, and one combined score would tell you to act without saying what to act on. Red is earned by a running flight and means the promise is not being kept; yellow is worth acting on; a verdict we cannot support yet reads “not enough data yet” in neutral and never in red. Seller analytics has not gone anywhere — it keeps its place in the Operate rail, one click below Media buys, and a saved ?view=dashboard link still opens it directly. API callers get the same ranking with sort=attention on GET /api/v2/storefront/media-buys, and an attention block on every row wherever the list is read. Pass activeOnly=true to drop buys that are finished and cannot need anyone — the operations home does, because the list is newest-first and a buy that settled yesterday would otherwise take a slot from an older one still running. That ranking orders one hydrated page — its tiers come from delivery and goal verdicts that only exist once a page is read — so it is available only with skip=0; asking for it on a later page returns 400 rather than quietly serving urgency order, and the response echoes attentionRanked either way.

​

5.819.0 — September 30, 2026 at 7:07 AM UTC

• If your seller account is set to Just list, the left rail now shows the Inventory workspace alongside Buyers and Agents. Inventory is where you follow your sources, media buys, approvals and activity. Advertisers and the Merchandising tools stay part of an Agentic Media Company account, and so does connecting an ad server through an Apostra-managed sales agent. To use those, switch in Settings under How would you like to sell? Nothing to change on your side.
• Source diagnostics now show the request and response exchanged with your agent, including the complete A2A message, task status, and artifacts, instead of collapsing nested content into [REDACTED_DEPTH]. You can read the exact call we sent: its AdCP version, buying mode, account reference, and the buyer’s brief, all of which your agent already received. Credentials, tokens, API keys, authorization headers, and personal data such as email addresses and phone numbers stay masked. A single value over 8,000 characters, or a body over 1 MB, is shortened and marked as truncated.

​

5.818.0 — September 30, 2026 at 6:45 AM UTC

• When your storefront agent answers a brief, it can now use passages from your processed, unarchived Library documents right away and cite the exact slide, page paragraph, or sheet range it used. Prices still come only from your rate card and products.
• Pilot storefront owners can now set pass-through terms on a pending linked storefront source and activate it. With pass-through, the price the buyer pays is exactly what you pay the partner, you keep 0% on the platform, and you settle with the partner outside the platform. Activation re-checks that the partner storefront still consents and needs terms in place first. If either check fails, the source stays pending. Nothing changes for your existing sources until you set terms and activate them.
• Active sources don’t receive briefs or bookings yet. Routing to active linked storefront sources comes in a later release.
• Pass-through (pass_through) is the only pricing mode today. Other modes may come later.
• You can change terms after activation. Each change creates a new version.
• Every booking made through a source records the terms in force when it was booked. Changing terms or disabling the link later leaves existing bookings as they were.
• Who collects the buyer’s payment (the platform, which then pays you, or you directly) comes from the buyer account’s existing approved billing setting. It is recorded on each booking.
• Your rate card now appears in your Library as a document; editing prices saves a new version of it.
• The storefront media-buy list (GET /api/v2/storefront/media-buys) now carries delivery for every buy on the page, not only when you filter the list to one buyer relationship, and buys your ad server manages carry delivery at all for the first time — they previously always read delivery: null. Each row gains the counts a buyer’s goal is judged on (clicks, views, completedViews, conversions, leads), each null when the source reported no value rather than a zero that would read as a total miss. delivery.pace measures spend against how much of the flight has run instead of against the budget alone, and returns on_pace (within 10% of the even-pace line), behind or ahead, or a named reason when there is no verdict. A new reporting block says whether delivery can be expected at all: reported, awaiting_first_report, or blocked, where blocked always carries a detail naming what is in the way — so an ad server that has not granted us reporting access reads as blocked instead of sitting on “awaiting first report” forever. A source that never answered the question reads null rather than claiming either. A buy your ad server manages reports impressions and spend together or not at all, and arrives in a new adServerDelivery field rather than in delivery, because an ad server states a running total without naming the day it runs through and delivery has always published a lastDeliveryDate. delivery therefore keeps its exact published shape, lastDeliveryDate included and still a required string, and source-managed buys read delivery: null there exactly as they always have. views is content views, the quantity CPV pricing bills on, and is never a count of viewable impressions. Delivery is an enrichment, never a reason the list fails: if delivery reporting cannot be read at all, every row’s delivery, pace and goal read empty, a response warning says so, and the buys themselves are unaffected. reporting is null in that case rather than awaiting_first_report — the latter is a positive claim that nothing has been reported yet, and “we could not read it” is not that. One limit worth knowing: a routed buy from a third-party AdCP buyer — one with no account on this platform — reports no delivery, and so no pacing or goal progress either. Delivery is attributed by the buyer it was reported under together with the sources the buy was routed to, and a third-party buy carries no buyer identity that reaches reporting, so a total for it cannot be proven to belong to one buy rather than two. We would rather show nothing than a number that might be another buyer’s. Buys your ad server manages are unaffected. Delivery is also attributed conservatively: a row whose reported buyer does not match the buy’s is not shown on it, and a buy whose delivery was reported under more than one buyer shows none at all rather than a total belonging to nobody in particular.
• Nothing to change on your side: every field is new, and no existing field is renamed, removed, changed in type, or made optional. Read adServerDelivery when you want the new ad-server totals.
• You can now see the buyer’s goal on every buy on your storefront, and whether delivery is hitting it. GET /api/v2/storefront/media-buys and the per-buy timeline (/media-buys/{mediaBuyId}/timeline) carry a goal block: what the buyer asked for, what your own terms committed to, what has actually been achieved, and a verdict of on_track, behind or beat — the same judgement the buyer sees, computed by the same code over the delivery your sources reported. When the evidence does not support a verdict, verdictWithheld says why rather than guessing, and a withheld verdict is never a bad one. You see the goal only from what the buyer told you: the commitment recorded against the buy at booking, and the optimization_goals on the AdCP request the buyer sent you. A buy whose goal was never disclosed to you carries goal: null, as does a buy whose packages, or whose forwarded sources, were asked for different things — the verdict is judged against the whole buy’s delivery, so there is no single target to state and none is invented. For a buy your ad server manages, optimizedBy says who is acting on the goal — ad_server when its own optimizer works towards it, seller when nothing automatic does and your ad operations own it. seller is the row to watch: it means the goal is yours to hit. Nothing to change on your side; every field is new.
• Pages that make many requests at once load faster: the Terms of Service check now runs once for a burst of requests from your account instead of once per request. Accepting the Terms of Service still takes effect immediately.

​

5.817.0 — September 30, 2026 at 5:57 AM UTC

• Signed-in web app requests no longer look up your contract on every call before doing their work, so pages that make many requests at once load faster. Terms-of-service checks work exactly as before.

​

5.816.1 — September 30, 2026 at 5:26 AM UTC

• Organization admins can set up payouts and accept Terms from Plan & Billing in chat. Opening Plan & Billing from the organization, in Apostra, Claude, or ChatGPT, now saves the organization’s payout entity. Every Seller Account that has no payout entity of its own is paid to it. Admins of a single Seller Account inside an organization still cannot change where its payouts go.

​

5.816.0 — September 30, 2026 at 4:59 AM UTC

• Campaign delivery grouped by channel now also reads the channels a product’s formats declare. When a seller leaves a product’s own channels empty but declares AdCP applies_to_channels on its formats, those rows show the channel instead of null. A format type on its own, such as video or audio, is still not treated as a channel. Nothing to change on your side.
• Organization admins can manage payouts for their Seller Accounts again. In Plan & Billing on the web, the Payouts tab at the organization now saves and shows payout entities for the organization and for each of its Seller Accounts. Payout control stays with organization admins: an admin of a single Seller Account inside an organization still cannot change where its payouts go.

​

5.815.0 — September 30, 2026 at 4:35 AM UTC

• Sellers can add a rate card as a typed Library document, preview parsed rows before they change live pricing facts, and cite the committed document row in quoted prices.
• Advertiser exclusion lists now reach sales agents that support exclusion-list targeting. Apostra continues to filter and block excluded inventory on the buyer’s side.
• Your account’s logo now appears as soon as the page opens, using the logo already saved for your storefront or advertiser, instead of showing initials while it’s fetched from your brand’s website.

​

5.814.1 — September 30, 2026 at 3:21 AM UTC

• Clarifies the Frequency Caps guide with a limitation that already existed: targetingOverlay.frequency_cap isn’t enforced the same way on every publisher for shapes outside a simple per-day count. Meta silently accepts an out-of-shape cap (for example, a whole-flight cap) without applying it, instead of rejecting the request the way TikTok and Snap do; Snap also requires per: "individuals" and only honors a cap for a subset of optimization goals. Check the ad platform compatibility guides for the exact shape each platform’s native cap supports before relying on this field as a guaranteed cap. No API behavior changed — this only corrects what the guide says about existing behavior.

​

5.812.0 — September 30, 2026 at 12:02 AM UTC

• Your agent phone line now replies to texts. The agent reads each one as a brief, composes against your catalogue, and texts back one short summary of what it drafted — nothing bought, approved, or changed, and no account data in the reply; whoever texted still signs in to act on it. Each text is answered once, on its own: the agent has no memory of earlier texts or replies, so a follow-up should restate what it needs. STOP opts a number out until it texts START, and the agent never sees a message from an opted-out number. Replies are on for Seller Accounts enrolled in agent phone lines; a line whose account is not enrolled keeps its texts queued unanswered until Apostra enrolls it.
• Advertisers on Meta, Pinterest, Reddit, and Snap no longer show Failed on the Sellers page. Each now shows the step it needs: Connect account, Reconnect, Map account, or Active once mapped. Two earlier releases said this was fixed, but it wasn’t; this release completes the fix.
• Rebuild the buyer discounts widget — where a seller sets rate-card discounts for buyer brands and buying operators — on the Apostra design system, and change how you reach the add and delete steps.
• “Add discount” now sits in the widget’s header. Choosing it opens a dedicated “New discount” screen instead of expanding a form under the list, so the list and the form are never on screen at once, and an “All discounts” control takes you back. Removing a discount asks for confirmation on its own screen in the same way, rather than in a dialog floating over the widget. Editing an existing discount is unchanged — it still opens in place, in the row.
• Every rule on the add form carries over. A duplicate brand-or-operator domain still sends you to the existing row’s editor instead of letting you post a create that would fail, a percentage outside 0–100 still holds Save closed with a quiet hint, the coverage preview still tells you what a domain will and will not cover before you commit it, and a refused save still shows the reason and keeps your draft to retry.
• Choosing between a brand and an operator discount is now a real pair of radio buttons rather than a tile that shaded when picked. The domain search is the design system’s search field, so its icon is sized to the field and it offers a clear button once you have typed. The header no longer repeats the total discount count and the per-section headings no longer repeat it either — the All / Brand / Operator tabs carry it. Each row’s percentage sits one step down the type scale, so a row reads as a row rather than competing with the widget’s own title.
• The widget card, tabs, form controls, chips, and alerts now match the rest of the converted in-chat fleet, which means they also inherit its focus rings, error styling, and keyboard behaviour. Loading and load-failure states render inside the card instead of flush on the chat background.
• Seller Setup now groups your go-live work by what you can do about it: Needs setup for the steps waiting on you, Waiting for the ones waiting on someone else, and Done for what is settled. Once your storefront is live those read as Needs attention, Waiting and Running.
• Every step appears in exactly one place. Inventory sources and publisher domains used to show up twice — once as a checklist row and again as their own section — and now each appears once, with its full detail inside the step it belongs to. A finished step keeps its detail and its action, so you can still add a second source or edit a policy without hunting for it.
• Confirming your settlement currency is now two labelled fields: the primary currency you are paid in, and an optional list of currencies buyers may pay with. Once confirmed, the step reports them on separate lines — “Primary: USD”, “Additional: EUR” — rather than one comma-separated list.

​

5.811.0 — September 29, 2026 at 11:02 PM UTC

• Apostra now requests a wholesale catalog only from agents that declare wholesale in their buying modes, as AdCP specifies: an agent that declares its modes without wholesale, or declares none at all, is not asked for one. If your agent serves a wholesale catalog, make sure its capabilities list wholesale. Source diagnostics stop reporting those calls as failures, and the unhealthy status the earlier rejected calls left on your source clears on the next check. Live buyer briefs still reach your agent, and nothing about them changes. One exception: if your inventory source is configured in Apostra as selling wholesale, we keep requesting the catalog and the calls keep failing — tell us and we will correct the source’s configuration to match what your agent declares.
• Accepting an invitation no longer shows “You do not have access to this customer” right after you join. The invitation page now waits while your new access becomes active (usually under a minute), then opens the account. If access still is not active after about a minute, the page says so and offers Try again, which reopens the account without needing a new invitation.
• Connected Library sources now explain safe sync failures on the source card, while the worker reports one diagnostic event per failed source pass.
• Demand Exchange responses now include revision-pinned Library passage citations for grounded response sentences.
• Your storefront dashboard now loads its analytics at the same time as the rest of the page instead of after it, so the dashboard fills in sooner when you open or reload your storefront.
• Require typed browser-handoff details when a V3 connection authorization is requested.

​

5.810.0 — September 29, 2026 at 9:13 PM UTC

• Proposal results now name official platform sellers such as Spotify, Meta, and TikTok by the platform’s own name. Previously these sellers could appear under the name of the company operating the connection (for example “Scope3”), so you couldn’t tell whose products you were looking at.
• Murph answers seller questions again, both in the app and in Slack. Some of those questions had been failing with “Murph could not complete the publisher authorization lookup”. Murph now checks the publisher authorization docs only when you actually ask about publisher authorization or adagents.json, and every such answer is still based on that page. Nothing to change on your side. If a question failed earlier, ask it again.
• Exclude products whose stored website, app, or CTV property identifiers match an advertiser exclusion list.
• Embedded sales agent 1.48.0: send ESA application logs to Sentry Logs, gAM probe reports NO_NETWORKS_TO_ACCESS as a connection failure.

​

5.809.2 — September 29, 2026 at 8:39 PM UTC

• Library source previews now include supported files in nested folders and Google Docs, Slides, and Drawings. They explain excluded files by type and only say when a count is limited when there are more files to check.
• log_event now accepts every action_source an event source can be registered with: offline, chat and email join website, app, phone_call, in_store, system_generated and other. If you registered an offline-sales, chat or email event source, you can now send its events without changing anything else.
• Widget header buttons now sit flush with the widget’s right edge on surfaces that do not show a collapse control. Widgets previously held that corner open for the collapse chevron everywhere, so on a surface that shows no chevron the button looked like it floated inboard of the edge, out of line with the content below it.

​

5.809.0 — September 29, 2026 at 7:23 PM UTC

• Tidied the Murph navigation rail. Setup status glyphs (the rings beside each checklist row) are now drawn at the same size and weight as the icons beside them, and a part-finished step’s progress arc sits on its ring instead of floating outside it. Hovering a row in the go-live checklist now highlights the same width as every other row, rather than pressing the fill flush against the label. The workspace tabs across the top of the rail have their spacing back — they had lost it to a vertical rule between each tab — and they now scroll sideways when they do not fit, so the last tab is reachable instead of clipped. Rows are wider: the rail’s side padding was uneven (wider on the left than the right) because it reserved room for a scrollbar that most browsers draw as an overlay and never occupy; the gutters are even again and tighter, giving each row more room for its label. The collapse control has moved out of the rail header and now sits beside Settings in the footer on both the buyer and seller rails.
• The web app now keeps its code in your browser between visits, so reloading a page no longer re-checks each file with the server before it starts loading your data.
• Campaign delivery grouped by seller or sales agent now names the seller when a sponsoring seller reads a self-serve client’s delivery, or when an app registration is scoped to one account. Before, those rows came back unattributed. Lifetime campaign delivery reads in those same scopes are now sized against the right account, so an oversized request is refused up front instead of running. Nothing to change on your side.
• Connected Google Drive, Microsoft 365, and Confluence Library sources now synchronize into Library materials and show a reconnect state when provider access is revoked.
• You can upload supported files from the Library again. Nothing to change on your side.
• Buyer agents can now group campaign delivery by media channel. Pass channel in dimensions on a V3 get_delivery call with report: "campaign_delivery", and each row’s channel lists the AdCP channels (such as ctv, olv, or display) declared by the product behind that package, so a seller that sells several channels is split by what each package bought. A product that declares several channels reports them as one list, so no delivery is counted twice; rows whose product declares no channels, or whose package has no product, return null, and the summary says how many. Channel comes from the product’s current record, so a seller changing a product’s channels re-files that product’s past delivery. It does not affect targeting or billing, it is separate from your own channel_group, and the REST /reporting/metrics endpoint does not have it. Available now; nothing to change on your side.
• Each media buy in Get reporting metrics (GET /api/v2/buyer/reporting/metrics) now says whether its money is moving on schedule, separately from whether it is hitting its goal. goalProgress.pace compares spend with how much of the flight has run, not with the budget alone: a buy three days into a thirty-day flight that has spent a tenth of its budget is on pace, and a buy on its last day that has spent the same tenth is nine tenths undelivered. It returns the share of the flight elapsed, the share the reported spend covers, expected and actual spend, spend per day against budget per day, and a verdict of on_pace (within 10% of even pace), behind or ahead. Both sides of that comparison always cover the same stretch of flight: narrow days and expected spend narrows with it, so a week of spend is never measured against a month of expectation. When the evidence is thin, verdict is null and verdictWithheld names the reason: no budget, no flight dates, the flight has not started, the window covers none of the flight, the window covers under 5% of the flight, or no reported spend. Campaign-level goalProgress carries no pace, and the V3 get_delivery tool does not return it. Rate goals are now judged on what they divide by rather than on their own count. A rate needs at least 1,000 impressions before it gets a verdict, so a low click rate over millions of impressions now reads behind where it was withheld, and a rate over fewer than 1,000 impressions is withheld even when its count is large. viewable_rate goals are now recognised, and read metric_not_reported instead of metric_unsupported until sellers’ viewable and measurable impression counts reach reporting. views is content views and is never used to estimate viewability. Nothing to change on your side: pace and actual.denominatorUnits are new fields, and no existing field is renamed or removed.
• The customer Slack app now appears as Apostra. You can use /apostra in Slack, and the existing /murph command continues to work.
• Show sellers which Library documents are still needed to run their storefront agent, sell guaranteed inventory, or promote a catalogue.
• Source Diagnostics now shows when products from your source were excluded from anonymous buyer discovery requests because their own properties matched an exclusion list. It reports only your affected product IDs, names, and matching domains.

​

5.808.0 — September 29, 2026 at 4:37 PM UTC

• Status alerts now stretch to fill the panel they appear in, so a short message and a long one line up on the same left and right edges instead of shrinking to fit their text.
• Agent text lines now protect you from runaway sending. Each line sends at most 10 texts a minute and queues the rest; it texts only ordinary North American (+1) numbers, never premium-rate numbers or short codes; and it stops sending for the rest of the UTC day once that day’s texts reach the line’s daily spend limit. A text to a destination the line cannot reach is refused immediately with 400, so nothing is queued.
• The unsupported filters.geo_countries and filters.excluded_content_categories fields now return a clear correction before any storefront is contacted. Existing requests using standard, negotiated, or vendor-specific AdCP filters continue to work without changes.

​

5.807.0 — September 29, 2026 at 3:27 PM UTC

• Media-buy submission now waits until the seller has accepted the exact creative revision before sending a library reference. If creative sync is still processing, the buy remains unsubmitted and can be retried after the seller finishes.

​

5.806.0 — September 29, 2026 at 3:03 PM UTC

• Storefronts in the pilot can now add another storefront on the platform as a linked storefront source, as long as that storefront has an active seller account relationship that consents to it. The new source starts pending: it can’t receive briefs or bookings yet, and activation with pass-through terms comes in a later release. If you’re not in the pilot, there’s nothing to change on your side.
• Create one with the existing Source create API or MCP tool.
• You can disable a linked storefront source at any time, including after pilot access is turned off.
• Source reads return a new optional linkedStorefrontTarget field. It describes the partner storefront and why the source isn’t active yet. linkedStorefront is unchanged and still returns null, so existing calls behave the same.
• Archived linked storefront sources keep their history but no longer appear in public source reads.

​

5.805.0 — September 29, 2026 at 2:45 PM UTC

• Approved creatives that needed a retry now reach the sales agent. Since 28 September, a retried creative sync on a media buy could stall without contacting the sales agent until its delivery deadline passed. Retries now go through as normal, and the media buy’s session timeline records each sync once.
• When you generate creative variants in chat, the gallery keeps completed image previews even when the session details are too large to return in full. Nothing to change on your side.

​

5.804.1 — September 29, 2026 at 2:01 PM UTC

• Murph now honours a buyer’s requested multi-storefront discovery wait, including long waits and explicit wait seconds, when it continues the same product query.

​

5.803.1 — September 29, 2026 at 1:40 PM UTC

• Allow a new buyer discovery to replace an unfinished discovery when no runtime owns it.
• Advertisers on Meta, Pinterest, Reddit, and Snap that still showed Failed on the Sellers page now show the step they need: Connect account, Reconnect, Map account, or Active once mapped. The earlier fix did not reach every one of these platforms.

​

5.802.0 — September 29, 2026 at 12:45 PM UTC

• You can now call every Apostra V3 tool over plain HTTP, with no MCP client required. Each V3 operation that exists as an MCP tool is also a fixed route, POST /api/v3/tools/<operation>, described by a public OpenAPI 3.1 document at https://api.interchange.io/api/v3/openapi-3.1.yaml. The REST routes and the MCP tools are generated from one operation registry, so they accept the same inputs and return the same results. Authentication is the same as for V3 MCP: an API key or OAuth.
• Every write request needs an Idempotency-Key header, so retries are safe:
• Retry a valid request with the same key and the same body, and you get the original result back. Results replay for 7 days after the write settles.
• Reuse a key with a changed body and the route returns 409 Conflict.
• If the write is still running, or its outcome is uncertain, the route returns 202 Accepted with Retry-After. Keep polling with the same key. A new key starts a new write.
• Nothing changes for existing V3 MCP connections or v2 REST integrations. TypeScript and Python SDKs are coming separately and are not part of this release.
• The suggested prompts on Murph’s opening screen load faster, because the account checks behind them now run at the same time instead of one after another.
• When you connect a Library source, returning from provider sign-in now continues setup automatically when possible. If the browser cannot open the sign-in tab or finish the handoff, the Library shows a clear way to continue or check again.
• Discovery now shows when an advertiser’s exclusion list removed seller products, including the total, a count for each seller, and bounded product and matching-domain details. Empty results caused by an exclusion list explain what was removed instead of appearing as no matching inventory.
• The web app now reuses the browser’s saved cross-origin permission checks, so pages you revisit within two hours skip an extra round trip before each API request.
• Agents on the V3 tools can now read what a seller committed to for your goal on each booked media buy. get and search for a media buy, and a campaign read with its media buys, return the same goalCommitment the V2 buyer reads already carry: the commitment kind, the goal you asked, the target the seller’s terms answer, and one answer per line. get lists up to 50 line answers and search and the campaign read up to 20 per buy, and each says when it cuts. Buys booked before commitments were recorded are unchanged.

​

5.801.2 — September 29, 2026 at 11:46 AM UTC

• Continue buyer discovery requests by their execution handle while preserving the original search arguments.
• Opening a link to another account you belong to now loads that account directly. The web app no longer loads your previous account first and then switches, so these links open about two server round trips sooner.

​

5.801.1 — September 29, 2026 at 11:16 AM UTC

• Approved no-spend source tests can now complete while Storefront intake remains paused. The Storefront stays paused, and ordinary buyer discovery remains closed.

​

5.800.0 — September 29, 2026 at 10:47 AM UTC

• Keep products from sellers that already answered when a get_products wait budget expires during page assembly.
• An update_media_buy sent straight to Meta with a stale revision now fails with CONFLICT and details.mutation_outcome: not_dispatched instead of SERVICE_UNAVAILABLE, and nothing in the request is applied on Meta. Read the media buy again with get_media_buys and resubmit with its current revision; updates held for seller approval still fail with SERVICE_UNAVAILABLE.
• Murph now preserves a later product read or unrelated answer when an earlier product discovery is still incomplete. Discovery and attachment safeguards continue to prevent unconfirmed results from being presented as complete or attached.
• Show product-discovery results as they arrive when a product search is still running.

​

5.799.7 — September 29, 2026 at 10:26 AM UTC

• The campaign creative upload task no longer shows the generic “An internal error occurred” banner when a save or readback step fails after the creative was actually saved — it now shows a specific message about what to check, with a support reference number when one is available.

​

5.799.6 — September 29, 2026 at 9:54 AM UTC

• Embedded sales agent 1.47.0: honor or reject every package optimization goal, optimize GAM CPM line items toward CPC, CPCV and viewable-rate goals, seller-managed elsewhere, prove GAM read permissions per tenant up front, accept Talpa FreeWheel CPM readback, optimize live buys’ goals and target-less goals.

​

5.799.3 — September 29, 2026 at 6:28 AM UTC

• request_proposals now enforces its no-country refusal for every buyer. Set targetingOverlay.geo_countries on the campaign, then retry with the new campaign revision. This requirement was announced for 12 October 2026 and has been enforced since 29 September 2026.

​

5.799.2 — September 29, 2026 at 6:17 AM UTC

• Enrolled buyers who request five image directions now receive all five when they generate a saved creative draft. Other creative generation requests are unchanged, and no action is needed.

​

5.799.0 — September 29, 2026 at 5:28 AM UTC

• Buyers enrolled in Creative Engines can compare generated variants in chat, explicitly refine one direction, and save a selected output to their Creative Library.

​

5.798.0 — September 29, 2026 at 4:47 AM UTC

• Video and audio creatives now report play progress through VAST tracking events.
• Sellers can find Library documents faster with one control row, clear document statuses, editable categories, and bulk category updates.
• Storefront admins can save publisher domains from the Property Roster again. Click Save domains after entering domains; no setup or API changes are required.

​

5.797.0 — September 29, 2026 at 4:28 AM UTC

• The web app makes fewer round trips when you come back to a page you loaded in the last two hours, because your browser now remembers the API’s cross-origin permission check instead of repeating it before every request.
• Platforms you connect with your own account, such as Meta, Pinterest, Reddit, and Snap, no longer show your advertisers as Failed on the Sellers page. These platforms bill your connected account directly, so connecting the account is your billing agreement. Each advertiser now shows the step it actually needs: Connect account, Reconnect, Map account, or Active once it is mapped.
• The credit-application endpoints (/api/v2/buyer/credit-applications/v2) are retired: every call now returns 410 Gone with a GONE error code and Deprecation and Sunset headers, and the endpoints are removed after 27 November 2026. Apostra does not grant buyer credit lines: sellers decide credit on their own terms, and buying from sellers on consolidated billing needs only your billing details. If your integration calls these endpoints, remove those calls before that date. Existing applications remain on record.
• GET /auth/me now returns customerAccess, which says how the session reached the account it describes: its own account, an account the user belongs to, or Apostra staff or support access. Use it to tell a membership switch from staff access, since the account appears in the returned account list either way.

​

5.796.2 — September 29, 2026 at 2:41 AM UTC

• The chat composer and the bar above it now use the Apostra design system, so the place you type matches the rest of the conversation around it. Two fixes come with it: the + button always opens its menu instead of sometimes jumping straight to the file picker, and people in a shared room are each shown in their own colour again. Everything the composer does is unchanged — attachments, slash commands, mentions, queueing a message while an answer streams, and stopping a reply all behave exactly as before.
• Media buys that never reach a seller because dispatch retries are exhausted now surface a clear “Failed” status and reason instead of staying stuck in Draft indefinitely with no explanation.

​

5.796.1 — September 29, 2026 at 1:27 AM UTC

• Progressive product discovery no longer loses progress when saving it briefly stalls. Seller results that arrive during a slow save are kept and appear on your next poll or discovery.revision event, instead of staying stale until discovery finished. When several sellers answer at almost the same moment, one discovery.revision event now carries all of their groups, so revision numbers can skip.

​

5.796.0 — September 29, 2026 at 12:07 AM UTC

• Creative Engines image drafts can request 1 to 8 distinct variants with request.variant_count. Preview requests first check capacity for the planned set, then reserve each direction before dispatch; concurrent use can return fewer directions than requested.
• V3 adds targetingOverlay as the campaign targeting field. targeting is deprecated with behavior unchanged. Its removal is a separately announced change (AI-10440) with at least 14 days’ notice.

​

5.795.0 — September 28, 2026 at 10:41 PM UTC

• Creative image sessions now save supported aspect ratios as canonical dimensions and return terminal generation failures without polling indefinitely.

​

5.794.0 — September 28, 2026 at 10:16 PM UTC

• TypeScript write methods now require a caller-supplied idempotencyKey; Python write methods require idempotency_key. The SDK sends this value as the V3 Idempotency-Key header, never creates or replaces it, and treats an HTTP 202 as an in-flight result rather than a completed write. Update existing write calls to retain and reuse the same key when recovery is appropriate.

​

5.792.0 — September 28, 2026 at 9:23 PM UTC

• Fixed a bug where a buyer’s previously selected account could incorrectly carry over into a fresh sign-in on their Claude connector, instead of returning to their usual account.

​

5.791.0 — September 28, 2026 at 9:04 PM UTC

• The account switcher now shows a standalone account under its own organization header, with the account listed beneath it — the same way multi-account organizations already appear. Previously a standalone account rendered as a flat, always-open list with no organization context, so switching into it never showed which organization you were in.

​

5.790.0 — September 28, 2026 at 8:19 PM UTC

• Seller operators can now find retained standalone media-buy Sessions in their default Session search, without selecting a source first.

​

5.789.0 — September 28, 2026 at 7:07 PM UTC

• Sellers with an active Demo Storefront can review its deterministic synthetic campaigns through the existing V3 delivery query. Responses identify the fixture and are unsuitable for commercial decisions; expired or revoked demos do not return synthetic data. Public REST remains held behind the AI-10305 launch gate. AI-10126 retains Demo Storefront attachment and lifecycle completion, including its daily canary.

​

5.788.1 — September 28, 2026 at 6:48 PM UTC

• get_media_buy_delivery now reports what your sources actually reported. Delivery totals are summed from each source’s own media-buy row instead of the response-wide aggregated_totals, which AdCP has deprecated: a source that omitted that field used to contribute nothing to your totals, and a source whose aggregate covered more buys than the one you asked about used to contribute too much. A source that returns delivery for several buys but not the one asked about is now treated as a failed read instead of silently attributing another buy’s figures. And the response now tells you which of your packages delivered — every source’s per-package figures are relayed under your own package ids, where the response previously always returned an empty list. Every package line carries its spend, pricing model, rate and currency, so package spend stays readable even when the buy’s combined total is withheld because sources disagree on currency. Other package fields are passed on when they are valid AdCP; a field AdCP does not accept is left off and named in errors as PACKAGE_FIELDS_OMITTED. A package that cannot be described completely, for example because its source gave no currency or no price, is left out of by_package and named in errors as PACKAGE_DELIVERY_INCOMPLETE with the reason, instead of being reported with guessed values. get_media_buys now takes a media buy’s currency and total_budget together: when the source’s live answer is missing either one, both come from the stored buy record, so a budget is never labelled with a currency from a different snapshot.

​

5.788.0 — September 28, 2026 at 6:38 PM UTC

• When Meta cannot confirm whether a media-buy update, pause, or cancel was applied, and cannot undo it, the request now fails with a clear “outcome unknown” error instead of a generic provider error. The error is SERVICE_UNAVAILABLE with recovery: terminal, details.reason: "adapter_update_outcome_unknown", details.mutation_outcome: "unknown", and details.retry_safe: false. Do not resend that change as-is: check the media buy’s current state first, then submit any further change as a new request.
• Apostra no longer automatically re-sends a media-buy update, pause or cancel after an attempt whose outcome it could not confirm. Each new pause or cancel you start is sent as its own request. Updates that wait for seller approval, Amazon changes, media-buy creation, and requests sent straight to a storefront’s MCP endpoint are unchanged. Nothing to change on your side.

​

5.786.0 — September 28, 2026 at 4:57 PM UTC

• Archive and restore seller Library documents through the API while preserving their source history and keeping archived documents out of new composition.
• The storefront workspace loads its inventory sources and Teach health checks at the same time as the storefront itself instead of afterwards, so the dashboard and left menu fill in sooner.

​

5.785.0 — September 28, 2026 at 4:28 PM UTC

• Add an operator-run historical media-buy Session import.

​

5.784.0 — September 28, 2026 at 3:59 PM UTC

• Media buys now stay failed when an inventory source reports a terminal booking failure, instead of being shown as not submitted and retried automatically. Temporary network and service failures remain retryable.

​

5.782.0 — September 28, 2026 at 3:23 PM UTC

• Buyers using an AI assistant connected to Interchange can switch accounts again after their session lands on their organization’s top-level account. Previously, switching to one of the organization’s buyer accounts from there was refused.
• You no longer need a card on file or an Apostra credit line to buy from sellers on consolidated billing. Apostra takes no credit risk on the seller’s media, so the only requirement for those buys is your organization’s billing details: a payer name, street address, and country, so Apostra can invoice you. Add them in Plan & Billing → Payment & invoices. If you already have a card or an Apostra credit line on file, you can keep buying while you add them. Until they are complete, a buy from a consolidated-billing seller is refused with the new billing_details blocker, buyer readiness lists the new BILLING_DETAILS value and reports commercial.billingDetailsComplete: false, and the buyer setup checklist shows an Add billing details step. Buyer readiness no longer reports PAYMENT_AUTHORITY or the payment_authority blocker; both stay in the schema so older clients still parse. If your integration reads buyer readiness, treat any blocker value it does not recognize as blocking. Sellers that bill you directly are unaffected.
• Storefront reporting that finishes processing before an upload returns now keeps the buyer’s delivery summary up to date.
• Delivery now tells you whether a campaign is achieving its goal, not just how the budget is pacing. Every media buy block and campaign block in buyer reporting, plus the campaign report in get_delivery, carries a goalProgress field. It holds the goal you asked for, the target you set and the cost the seller committed to, the achieved cost per unit or rate computed from the same delivery the block reports, and a verdict of on_track, behind, or beat. The verdict is withheld, with the reason, whenever the evidence does not support one: no goal or target was set, the metric is not one delivery can score yet (event goals other than leads, return on ad spend, and metrics such as reach wait for event-scoped counts), the seller has not reported that metric yet, or there are not enough observations yet. Each read also says the number is the seller’s own count, how fresh it is, and whether the seller has signalled that a later report will supersede it. A buy booked at 3.00 per click that delivered 500 clicks for 2,000 in spend shows an actual of 4.00 per click and a behind verdict; the same buy on day one, with only two clicks logged, shows the actual cost per click while the verdict stays withheld because two observations are not enough.
• Plan & Billing no longer shows an Apostra credit limit or an “Apply for credit” option. Apostra does not grant buyer credit lines: sellers decide credit on their own terms, and buying from sellers on consolidated billing needs only your billing details. Your funded balance, amounts owed, invoices, and payment methods are unchanged.
• When you stage a V3 media buy, save_media_buy now accepts the complete AdCP package targeting overlay (language, device, daypart, and demographic targeting), not the partial set it accepted before. Package targeting on those dimensions must now stay within your campaign’s own targeting; a package that falls outside it is rejected with a CONFLICT error naming both the campaign’s and the package’s values. Deprecated. Numeric codes replace names. Removal will be announced in release notes at least 14 days ahead; planned for 2 November 2026 (AI 10440). Codes must be in the Nielsen DMA dictionary.

​

5.780.0 — September 28, 2026 at 1:37 PM UTC

• Creative Engines now guides eligible buyers through the short path from a saved image draft to a usable generated image URL, with provider connections reserved for BYOK and voice work.
• Show media-buy updates and creative syncs in seller Session timelines.
• The Merchandise section of the seller navigation now follows the order you work in: Library first, then Inventory components and Signals, with Sessions last. The same rows are there and they open the same places; only their order has changed.

​

5.779.0 — September 28, 2026 at 12:49 PM UTC

• Organization administrators can now open Plan & Billing → Accounts to add child Buyer or Seller Accounts, review their status, usage, team access, and organization terms, preview archive blockers, archive an account, and restore it later. Archive preserves account history and is refused while an account has unfinished campaigns or executable or unsettled media buys.
• In a V3 organization session, search and get can read child accounts and members, including inherited Terms of Service and contract history. save_account can change only an existing account’s name or company label; it cannot provision accounts, change members, archive, restore, or hard delete. Existing calls keep working, so no action is required.
• Return adapter-local media-buy refusals as correctable request errors instead of retried upstream outages.
• You can now save image Creative Session drafts when your agent uses common image format shapes. Invalid requests identify request.format_kind and show the canonical format fields to provide.

​

5.778.0 — September 28, 2026 at 12:20 PM UTC

• Cancelling a storefront buy while the seller is approving it now cancels it reliably. Previously, if the seller’s approval landed at the same moment, the cancellation could fail with “already approved” and leave the approval in place, even though nothing had been sent to the seller yet.
• Dimension names and values now show as plain text in list filters and label pickers. Before, the Library’s category and topic filters, and the label filters and label editor on the advertiser and campaign lists, could show internal markup around each name, for example <untrusted_tool_output> Category </untrusted_tool_output>. Your dimensions and labels were not changed, and there is nothing to change on your side.
• In a Creative Session, you can now promote one approved generated output into an advertiser-owned Creative Asset in the Library. Each promotion keeps an immutable revision and an approval receipt. It also records the Creative Engine, the provider, and whether the output was generated on your own provider account or the Scope3-funded preview. That record comes from the generation call that produced the output, so outputs generated before this release can still be promoted but carry no provider record. Reuse rights follow the provider’s terms, and Interchange does not verify them. Check those terms before you use the asset outside Interchange. Promotion does not finalise a Creative or export the output.
• To retry a promotion, send the same idempotency key to get the same receipt. If the session revision, output digest, or advertiser changes, use a new key.

​

5.777.0 — September 28, 2026 at 11:48 AM UTC

• Fixed campaign launch so a seller’s pending confirmation cannot replace the returned revision or make the campaign appear to return to draft before a buyer can pause or cancel it.
• Canceled media buys now report a completed operational status when the seller has confirmed the cancellation. Statuses that need attention include a reason.
• In Sessions, you can open a linked brief or media-buy timeline from its chat event. The action appears when the event includes that item’s reference and respects your existing access permissions.
• sync_accounts on a storefront Interchange hosts or manages now rejects a request that sets payment_terms with PAYMENT_TERMS_NOT_SUPPORTED, instead of creating the account on the seller’s own terms without saying so. Omit payment_terms to accept the seller’s default terms. Storefronts that route accounts to the seller’s own sales agent still forward payment_terms to that agent unchanged.
• The web app no longer retries a request the server has refused (for example, a page you don’t have access to). The page shows that result right away instead of after several seconds of repeated attempts.
• Catalog V3 results now validate stable identity, lifecycle, and health fields while preserving provider-owned feed details.
• Seller V3 save results now validate stable media-kit and inventory-source fields while keeping provider metadata extensible.

​

5.776.1 — September 28, 2026 at 11:02 AM UTC

• Treat an empty media-buy Session advertiser ID list as no advertiser filter.

​

5.776.0 — September 28, 2026 at 10:49 AM UTC

• Scope3-funded preview image drafts now start with three distinct composition directions, while customer-key image engines keep one direction unless a request supplies its own axis. Enrolled Buyer Accounts can make up to 50 image requests per UTC day.
• Meta products no longer require a bid price except for the one product where Meta itself requires a value goal instead. create_media_buys and add_discovery_products previously rejected every Meta product without a positive bidPrice, even though Meta’s own delivery options let advertisers omit a bid cap in favor of automatic, highest-volume delivery for every objective except website value optimization. Buyers can now add and execute Awareness, Traffic, Engagement, Leads, App Promotion, and plain Conversions products without supplying a bid; Meta delivers them at its default automatic bid strategy, matching what Ads Manager already allows. Website value optimization (Maximize Website Conversion Value) is unchanged and still requires a ROAS floor or maximize-value goal instead of a bid.
• Build scheduled jobs and backend integrations against 53 account-aware Apostra operations through fixed v3 HTTPS routes or a generated OpenAPI 3.1 client. Authenticate with an existing API key or M2M application; existing MCP and v2 integrations keep working without changes.
• Embedded sales agent 1.46.1: classify FreeWheel profile source metadata.

​

5.775.0 — September 28, 2026 at 10:20 AM UTC

• Show recorded storefront media-buy exchanges in seller Session timelines.
• Add the seller Sessions workspace, retained-session filters, and session document handoffs. The Sessions view no longer includes a private-notes composer; existing notes remain read-only timeline events.

​

5.774.0 — September 28, 2026 at 10:10 AM UTC

• You can now select countries in the advertiser setup form, and the country menu closes when you click elsewhere. This changes only the form interaction; advertiser country matching and API behavior are unchanged. Nothing to change on your side.
• Sellers whose country or channel coverage is not yet declared can remain available for selection, with that coverage marked unconfirmed. An official adapter’s registered channel limits still apply. A Critical Supply approval still selects a seller by default only in its approved markets and channels. When a seller responds to product discovery with an error and no products, the response now reports a seller failure if no cached catalog is available, instead of treating the error as an empty catalog.
• Make Session searches require an advertiser to match both advertiser filters when callers provide a singular advertiser ID and an advertiser ID list.

​

5.773.0 — September 28, 2026 at 9:15 AM UTC

• Approved test inventory on a paused Storefront now appears in that source’s preview, test plan, and confirmed no-spend test. It remains hidden from buyers and disappears from tests when its approval is revoked or expires. No action is needed.
• The assistant appears as Apostra, with Apostra branding and links, when the product-brand cutover is enabled. Existing Murph links and integrations continue to work without customer action.

​

5.772.0 — September 28, 2026 at 8:34 AM UTC

• Meta campaign-level budget buys now launch instead of being rolled back after creation.

​

5.771.0 — September 28, 2026 at 8:18 AM UTC

• V3 media buys and the campaign defaults attached to proposals now respect geography set on the campaign through the v2 API as well as V3. Before, a V3 media buy could ignore v2-set campaign geography.

​

5.770.0 — September 28, 2026 at 7:28 AM UTC

• Meta campaign-level budgets now work when products carry a bid price.
• Every media buy now records what the seller committed to for your goal when it was booked. goalCommitment on the media buy carries the commitment kind (guaranteed, best_effort, report_only), the goal you asked, the cost the seller’s terms commit or aim at, whether every product meets your asked cost, one answer per product, and the proposal version it came from when you accepted a proposal. Buys created without a proposal get a commitment from their own pricing and delivery terms. Buys booked before this stay without one.

​

5.769.0 — September 28, 2026 at 7:01 AM UTC

• Publish the V3 webhook signing, retry, secret-rotation and deduplication contract so developers can prepare a receiver before endpoint registration becomes available.

​

5.768.1 — September 28, 2026 at 5:54 AM UTC

• Seller billing labels now say Consolidated billing and Direct billing instead of “Interchange-cleared” and “Seller-cleared”, matching the billing documentation. Under consolidated billing you send your invoice to Apostra, which bills the buyer and pays you once the buyer’s payment arrives; you keep the buyer’s credit risk, as with direct billing. Nothing changes in how billing works.
• Meta media buys that use a campaign-level budget now launch with the campaign’s bid strategy.

​

5.768.0 — September 28, 2026 at 5:22 AM UTC

• a campaign-level budget buy on Meta can now include several products from the same Meta storefront and channel group; Meta distributes the one campaign budget across their ad sets, and per-product budgets stay refused.

​

5.767.0 — September 28, 2026 at 4:48 AM UTC

• Eligible Creative Engines preview buyers can generate images and video with Gemini, OpenAI, fal.ai/FLUX, or Veo paid by Scope3. The preview is limited to 25 generation requests per account and 500 globally each UTC day, with Veo also limited to 3 requests per account and 50 globally each UTC day. Voice providers and customer-key connections remain unchanged.

​

5.766.2 — September 28, 2026 at 4:38 AM UTC

• A media buy whose targeting doesn’t overlap its campaign’s targeting now returns a conflict error naming both values, instead of silently targeting everywhere. A buy can only narrow its campaign’s targeting. For V3 campaigns, the guardrail currently covers campaign geography; it will extend to every campaign overlay field when V3 campaigns move to CampaignTargetingOverlay. V2 language and device constraints continue to be applied at launch.
• Meta Sales Campaign and Maximize Website Conversion Value media buys now default to Facebook and Instagram Feed, Stories, and Reels placements, instead of silently narrowing to Feed only when a buyer’s brief doesn’t name placements explicitly.

​

5.766.1 — September 28, 2026 at 4:11 AM UTC

• Meta media buys that use a campaign-level budget now launch correctly.
• Storefront navigation now loads in its final shape instead of adding or moving workspace tabs after the page first appears.

​

5.766.0 — September 28, 2026 at 3:35 AM UTC

• Speed up repeat Page opens by reusing unchanged widget shells, correctly identify the built-in host during widget data loading, and measure when Library first becomes usable.

​

5.765.0 — September 28, 2026 at 3:10 AM UTC

• Creative Engines generation results now return each completed image’s URL, MIME type, dimensions, and preview. Saved drafts include the next generation call, and pending work includes an exact poll call.
• Creating a media buy that hit a transient seller error during a platform deployment could permanently stop retrying, even though the same request would normally succeed on the next attempt. Retries interrupted by our own worker restarting are no longer counted against the attempt limit, so a deploy landing mid-retry no longer causes a media buy creation to fail for good.
• When a Meta campaign brief mentions an audience by name in free text instead of the structured audience field, Meta now resolves it against your live custom-audience list and applies it, or asks you to clarify if the name is ambiguous, unresolved, or conflicting. Previously the audience mention was silently dropped with no indication it had been ignored.
• V3 campaigns that target only a region such as "US-CA", a Nielsen DMA, or a postal area now reach the sellers that cover that country when you call request_proposals; before, such a campaign went to every seller with no country filter. Starting 12 October 2026, request_proposals will also refuse a campaign whose targeting names no country, before any seller is contacted. Set at least one country with save_campaign targeting.geo (for example "US") to keep proposal rounds running.

​

5.764.0 — September 28, 2026 at 2:49 AM UTC

• New Meta media buys can now spend from your campaign’s saved budget total instead of fixed per-package amounts, with Meta distributing spend across packages automatically.
• Set budgetAllocation.mode to seller_optimized on save_media_buy (or create_media_buys on v2) when you create a Meta media buy from explicit product selections. Meta then allocates your campaign’s saved budget total and currency across the buy’s packages — the Advantage+ campaign budget behavior you’d see in Ads Manager. Per-product budgets aren’t accepted with seller_optimized; Meta distributes the campaign’s saved total. The total is snapshotted onto the media buy when it’s created, so a later change to the campaign’s budget doesn’t affect a buy that already exists. Use mode: "fixed" with a positive budget on every selected package, or omit the field to keep today’s behavior, where a package without a budget is funded from the campaign’s remaining budget. No enrollment is needed.
• This only applies to a new Meta media buy built from explicit product selections on a single Meta storefront, and to one such buy per campaign per batch. It isn’t available for proposal-based buys, carts that mix in other storefronts, storefronts that require seller approval, campaigns without a saved budget total, or existing media buys — you can’t add it after the fact. Buys that omit budgetAllocation are unaffected.
• Meta audience targeting (targetingOverlay.audience_include / audience_exclude) no longer rejects a Custom Audience that was shared into your ad account from a data partner such as LiveRamp — a common agency workflow that previously failed every time. A genuinely invalid or non-deliverable audience reference now returns a clear, non-retryable error naming the problem, instead of a generic “Upstream request failed” that looked like a temporary outage and got retried pointlessly.

​

5.763.1 — September 28, 2026 at 1:58 AM UTC

• Our billing documentation now describes consolidated billing accurately. When a seller uses consolidated billing (billing party agent), the seller sends its invoice for a buy to Apostra, Apostra puts it on the buyer’s consolidated media bill and collects, and pays the seller once the buyer’s payment arrives. Apostra acts as a billing agent: it does not extend credit for the seller’s media, does not pay a seller before the buyer pays, and is not liable if a buyer does not pay. Sellers keep the buyer’s credit risk, exactly as with direct billing. Nothing changes in how billing works today, and there is nothing to do on your side.

​

5.762.0 — September 28, 2026 at 1:13 AM UTC

• add_discovery_products now warns when a submitted selection collapses into an existing one instead of failing silently. Give each repeat of the same product a distinct selectionId (e.g. several Meta ad sets on the same product with different budgets or audiences) to keep it as its own line item. Submitting repeats without a selectionId in a single call still merges them into one package for backward compatibility, but the response now names the collapsed product in warnings instead of dropping the other submissions silently.

​

5.761.0 — September 28, 2026 at 12:23 AM UTC

• Session timelines now show recorded RFP briefs and proposal terms in readable text. Sellers can filter Session activity by agent or person, advertiser, and buyer account without matching text in a brief or conversation.

​

5.760.0 — September 27, 2026 at 11:27 PM UTC

• When your certified Agent is ready to serve other organizations, Agent details now points to the next Partner action. The private-offer and payment process is unchanged.

​

5.759.0 — September 27, 2026 at 11:00 PM UTC

• Session search now names the future media-buy history source and adds Agent or Human classification plus exact advertiser and buyer-account filter fields. The new source returns no history and the new filters remain unavailable until their source adapters support them.

​

5.758.0 — September 27, 2026 at 10:24 PM UTC

• Measurement sources can now name their measurement vendor the way sellers and optimization goals identify it. Add vendor (the domain that hosts the vendor’s brand.json, such as placer.ai) and vendorMetrics (the vendor’s metric ids, each mapped to one of the source’s outcome types) when you create or update a measurement source. Both fields are optional and existing sources are unchanged. This is the first step toward letting a campaign goal be counted by a vendor such as Placer.

​

5.757.0 — September 27, 2026 at 10:03 PM UTC

• Agents using the Set Up a Campaign skill (version 1.5.0) now ask how you will know a campaign worked before saving a goal. They then propose a one-line goal statement for you to confirm: the goal, the target, who counts the result, and the commitment you want from sellers. Once proposals come back, they compare sellers on those terms: who guarantees a price, who will only aim for it, and who only reports. The goal-seeking campaigns guide now also explains what changes when you choose not to set a goal.
• When you sign in, an old Scope3 Seller membership no longer overrides your Apostra Buyer account or verified Storefront. Nothing to change on your side.

​

5.756.8 — September 27, 2026 at 9:41 PM UTC

• Long account names now truncate in the customer selector instead of overlapping the role badge and menu chevron.

​

5.756.7 — September 27, 2026 at 9:21 PM UTC

• Make the Agent Overview easier to scan by consolidating diagnostics into one details row and shortening the certification action and source-attention list.
• Fixed adding and executing a Meta Sales campaign optimized for purchase value with a ROAS floor: a buyer who declared the ROAS floor goal at the campaign level (update_campaign/create_campaign’s performanceConfig.optimizationGoals) rather than on the individual product was still rejected — both at add_discovery_products and again at execute_campaign — with “provide optimization_goals … instead of bid_price”, because those checks only recognized a goal declared on the product itself. They now also recognize a satisfying goal declared at the campaign level, matching how the goal is actually dispatched to the seller.

​

5.756.4 — September 27, 2026 at 4:09 PM UTC

• Storefront cancellations now keep media-buy commitments in place until the seller confirms a terminal outcome, exposing unconfirmed cancellations as ending rather than releasing budget early.
• create_media_buys and save_media_buy now support adding the same product more than once in one call — for example several ad sets on the same product with different budgets or audiences. Give each repeat a distinct selectionId (v2 selections[]) or products[].selectionId (v3) to keep it as its own media-buy line item. Previously, repeating a product with no selectionId silently collapsed every repeat into a single package, keeping only the last submitted budget with no error or warning. Submitting repeats without a selectionId still merges them into one package for backward compatibility, but the response now names the collapsed product in warnings instead of dropping the other submissions silently.

​

5.756.1 — September 27, 2026 at 2:19 PM UTC

• create_campaign now scopes the product discovery it runs automatically to the storefronts you pinned with storefrontIds. Previously that inline discovery ignored the pin and could surface products from unrelated sellers; calling discover_products directly afterward already worked correctly and is unaffected.

​

5.756.0 — September 27, 2026 at 2:05 PM UTC

• When you request proposals for a campaign with an inclusion property list, the response now shows which requested properties sellers covered and why any properties are missing. Sellers that do not support property-list filtering are identified, so you can choose a supporting seller or revise the constraint.

​

5.755.0 — September 27, 2026 at 1:35 PM UTC

• Buyers can declare viewability, IVT, completion-rate, brand-safety, and attention-score standards per media-buy package, with readback and a clear launch blocker when seller support is not declared.

​

5.754.0 — September 27, 2026 at 12:46 PM UTC

• In V3 save_campaign, you can set frequencyCap with level: "mediaBuy" while a campaign is a draft. The AdCP 3.2 cap applies to each eligible seller media buy and is shared across that buy’s participating packages. Proposal discovery returns only sellers and products that support the cap. A seller proposal must confirm the exact cap to be a usable quote, and launch checks seller and product support again before dispatch.
• save_media_buy also accepts an independent AdCP package targetingOverlay.frequency_cap. Completed synchronous and asynchronous creates must confirm a MediaBuy cap before V3 reports it as effective. Meta and Pinterest reject capped packages with multiple offerings before provider mutation, because separate ad sets or ad groups cannot share one package counter.
• Each seller media buy has its own counter. A cross-seller Campaign cap and live cap changes are not available. A bound proposal keeps its quoted cap; changing it requires removing the bound MediaBuy and requesting a new proposal. Existing calls and campaigns are unchanged.

​

5.753.2 — September 27, 2026 at 12:35 PM UTC

• Simplify the Agent Overview so its next step and key status facts are easier to scan, while keeping production, certification, and reporting evidence in details when needed.

​

5.753.0 — September 27, 2026 at 11:16 AM UTC

• The Agent test page now tells governed administrators when the claimed owner must run a test, while keeping certification-check status separate from test results.
• An optimization_goals / optimizationGoals request with the wrong field casing (for example eventSources where event_sources is expected) now fails with a clear message naming the correct field names, instead of a generic validation error. Tool descriptions for add_discovery_products, update_campaign, and update_media_buy also now state each field’s expected casing explicitly.
• Long account names now truncate in the customer selector instead of overlapping the role badge and menu chevron.

​

5.752.0 — September 27, 2026 at 10:05 AM UTC

• Library document filters now search and page across the complete filtered result.
• Canonical storefront reloads now preload the landing module and report the complete landing timeline, matching account-switch navigation.

​

5.751.0 — September 27, 2026 at 9:45 AM UTC

• Campaign filters now search the full campaign collection and page against the filtered total.

​

5.750.2 — September 27, 2026 at 8:29 AM UTC

• Keep failed capability-probe backoff bookkeeping from invalidating current source configuration attestations.

​

5.750.1 — September 27, 2026 at 7:34 AM UTC

• Complete-key seller account operations now use current organisation, advertiser, and actor authority without a credential-scoped fallback. Public mapping guidance now documents country scope, deferred reauthorisation, and staged cutover safety.

​

5.750.0 — September 27, 2026 at 7:24 AM UTC

• Buyer activity, activity log, setup, Creative Engines, and Library now page long lists and show errors at the top.
• Eligible sellers can select recorded RFP exchanges in Sessions to read admitted history and open an exact linked Proposal Pass. Existing seller access checks still apply, and this does not enable RFP edits or private notes.
• Make Agent test setup status clear, including safe next steps when a test has not started, and keep test evidence distinct from certification.
• If Apostra has enabled agent phone lines for your Seller Account and assigned a text number, you can send text messages through the API. A 202 response means the message was queued, not delivered; retry the same message with the same request ID to avoid a duplicate.
• Switching between Storefront and Buyer accounts now opens the account you selected instead of returning to the previous one.
• Agent owners can request certification review without selecting an Inventory Source. The Agent test view now keeps the next action clear while a confirmation is pending.
• Discovery and proposal requests now show a safe outcome for every seller and the property domains represented in returned products. Sellers with no inventory for a request are shown as no-inventory results rather than failures.
• Account switches and signed-in page loads now check independent access settings together, reducing the time spent waiting for account details before the page can appear.
• Buyers can save campaign target and suppress audience lists and a catalog reference through V3. Campaign readiness now explains that these fields cannot be delivered to sellers yet, so campaigns using them cannot launch.
• You can now invite a specific contact to claim self-service access to a managed Advertiser. The Advertiser roster tracks email delivery, recipient claim, and your admission decision as separate states so you can see exactly what happened before acting.
• Submitted seller media-buy creates now settle through background task polling when a webhook is unavailable. Seller rejections are visible and terminal. If the seller does not return terminal evidence before the recovery deadline, the buy moves to a visible reconciliation state while its budget remains committed; a seller response or operator follow-up resolves it.
• Complete AccountKey seller-account feeds now export and import explicit dedicated and shared-default binding modes without changing native-account ownership.

​

5.749.0 — September 26, 2026 at 10:37 PM UTC

• Buyers can cancel a campaign and all of its media buys in one call. Cancellation is asynchronous and remains visible until every seller confirms it.

​

5.748.0 — September 26, 2026 at 9:22 PM UTC

• Buyers can bind an advertiser catalog to a campaign and read it back. Catalog-bound campaigns remain blocked from launch until seller catalog sync is available.

​

5.746.3 — September 26, 2026 at 8:07 PM UTC

• Two buyers on the same storefront can now each have a media buy with the same id routed to the same source. Before, the second buyer’s media buy could fail to be recorded because the first buyer already held that id there.

​

5.746.2 — September 26, 2026 at 7:21 PM UTC

• Start with Apostra V3 documentation. Choose Manage ads for work in the application or a connected assistant, or Build software for the developer installation guide. Codex and Claude Code use the apostra-developer plugin; regular Claude and Cowork use the hosted MCP connector.
• Existing V2 integrations continue to work. No migration or credential changes are required.
• Seller accounts now require verified Seller setup before they can sign in or use product APIs. An old internal account classification or empty storefront no longer grants product access. Existing MCP credentials retain only account status and account-switching tools so operators can leave a blocked account.

​

5.746.1 — September 26, 2026 at 6:55 PM UTC

• Live Seller storefronts now start loading their dashboard from the account’s existing liveness check instead of waiting for the detailed setup checklist to finish loading.

​

5.746.0 — September 26, 2026 at 6:39 PM UTC

• Storefront navigation now appears once with the correct workspaces instead of adding tabs while the page loads.
• Sessions now lets you open the exact Proposal Pass for a linked RFP request or response. Representation links remain read-only records, and access still follows the existing seller permissions.

​

5.745.0 — September 26, 2026 at 6:18 PM UTC

• Account Admins can submit a separate no-spend Source for certification fixture review after attesting the current observed endpoint. The submission is tenant-bound, replay-safe, and requires current isolation evidence. A reviewed sandbox Source is registered and parked for the existing bounded certification runner; neither submission nor review certifies the Agent, starts a run, or authorizes spend.
• When you save a draft Creative, the response now includes the revision required to update it. Nothing to change in existing calls.

​

5.744.2 — September 26, 2026 at 6:02 PM UTC

• Storefront pages now reuse the existing liveness check for the navigation alert instead of running a second full readiness check while the page loads.
• Anyone with read access to an advertiser can now find, attach, and deliver that advertiser’s Library assets. The original uploader remains recorded for audit.

​

5.743.0 — September 26, 2026 at 4:37 PM UTC

• In MCP Session search, sellers can now select the Storefront RFP source, find retained RFP interactions by exact recorded buyer or advertiser labels, and read their structured history. These labels are discovery metadata and do not grant account access.

​

5.742.3 — September 26, 2026 at 3:52 PM UTC

• Seller account approvals now belong to the verified buyer organisation, so authorised colleagues share one account and approval while each action retains its own audit identity.

​

5.742.1 — September 26, 2026 at 2:21 PM UTC

• Seller storefront homes now reuse one readiness result when choosing the initial Setup or Dashboard view, avoiding a duplicate load during page startup. Nothing changes on your side.
• Seller dashboards now reuse storefront data that is already loaded, reducing the delay before dashboard content appears. No action is required.

​

5.742.0 — September 26, 2026 at 2:07 PM UTC

• When you switch between Storefront and Buyer accounts in Interchange, the account you selected now stays active instead of switching back. No action is needed.

​

5.741.0 — September 26, 2026 at 1:29 PM UTC

• Partner Program organizations with an issued private offer can now review and accept its exact terms in Plan & Billing. When the accepted payment choice supports CARD, they can continue from a compatible MCP app to secure card setup. Card details are entered only on the hosted payment page. Payment standing, ownership, registration, certification, and operating authority remain separate requirements.

​

5.740.1 — September 26, 2026 at 1:15 PM UTC

• Plan & Billing now reports the IUs your organization used instead of an internal provider cost. Accounts without IU usage see an IU-specific empty state. Nothing to change on your side.

​

5.740.0 — September 26, 2026 at 1:08 PM UTC

• Media buys now clearly show when their only creative is rejected before delivery.
• Campaigns, media buys, and connections pages now page long lists and show errors at the top.
• Media-buy errors from managed ad-server inventory now explain which targeting field or product setting needs attention instead of returning a generic invalid-request message. Update the named setting and resubmit the media buy; provider, authentication, and transport details remain hidden.

​

5.739.0 — September 26, 2026 at 12:33 PM UTC

• Buyer agents can create, update, archive, check, find, and read property lists through the V3 MCP surface. A campaign can apply one include list at a time through save_campaign.propertyListId, or clear that targeting with null.
• Eligible organizations without a selected IU plan now see the current activity schedule in Plan & Billing instead of a retired preview. Accepted plans keep the schedule they agreed to. Nothing to change on your side.
• Plan & Billing now uses Apostra consistently across billing screens, next steps, help links, and commercial offer PDFs. Existing activity and action codes remain unchanged. Nothing to change on your side.

​

5.738.0 — September 26, 2026 at 11:25 AM UTC

• Opening an advertiser from the Advertisers page works again in the web app.
• Meta can now deliver one selected image creative to each selected package when a buy has multiple package assignments.
• The Advertisers page now pages its list and shows any error at the top.

​

5.737.0 — September 26, 2026 at 10:41 AM UTC

• Meta ad accounts that contain campaign-budget (Advantage campaign budget) or daily-budget campaigns now read and sync. Before this fix, one such campaign made the whole account’s media-buy read fail, which stopped status updates and directed-campaign syncs for every buy on the account. A bidding policy recorded once for the whole media buy is reported once in ext.scope3_meta_bidding instead of as each package’s bid_price. A provider-authored campaign-budget bid cap without that recorded policy has no package bid_price, so it is not misrepresented as package-owned. Each campaign now reports what Meta actually holds. A lifetime campaign budget is reported as the total, and its packages carry no package budget. A daily campaign budget has no lifetime total, so the total is 0 and the daily amount is in ext.scope3_meta_budget; daily per-ad-set spend limits under a daily campaign budget are not reported. For a campaign that mixes lifetime and daily ad sets, the total counts only the lifetime ad sets, and each daily ad set carries no budget and states its daily amount in its ext.scope3_meta_budget. The update-budget action is no longer offered for campaign-budget, daily-budget, or mixed campaigns, because a per-package budget change cannot be applied to them. Per-package bid_price and optimization_goals changes on a campaign-budget buy are refused with a clear error, and nothing changes on Meta. Buys whose ad sets each hold a positive lifetime budget read exactly as before. Three shapes that already read are corrected: a campaign-budget campaign whose ad sets report a lifetime budget of 0 now reports the campaign budget as its total instead of 0, and a directed campaign mirroring it moves from 0 to that budget; an ad set that reports a lifetime budget of 0 alongside a daily budget now reads as a daily budget; and a campaign-budget campaign with no ad sets yet reports its campaign budget and no longer offers update-budget, which always failed for it. Some campaigns still cannot be read truthfully and still fail the whole account read: a campaign reporting both a campaign budget and ad-set budgets, or both a lifetime and a daily campaign budget, and campaigns with unsupported optimization or bidding settings. Nothing to change on your side.
• V3 MCP integrations can now read billing readiness, current Terms and the next setup action in text-only chat. Read get with kind: "billing". When nextAction.canCompleteInChat is true, obtain the person’s authorization for the returned Terms version, use the existing save_billing Terms operation and read again to verify the result. Accepting Terms requires direct organization-admin authority. Parent-container sessions can read readiness but keep their existing write restriction.
• Existing save_billing request, confirm, status and Terms behavior is unchanged. Use the new billing read’s paymentAuthority.verified for the current payment method and capture or submission for setup history. The billing read cannot start secure card setup: paymentAuthority.secureHandoff.available is false. A versioned one-time handoff with fresh cardholder confirmation is still needed. See the V3 billing flow.

​

5.736.0 — September 26, 2026 at 10:16 AM UTC

• Make synthetic demo reporting deterministic, internally consistent, and clearly labelled as unsuitable for commercial decisions.
• Make Property Roster publisher management admin-only and show non-admin members a read-only roster. Show a clear admin-required state in Plan & Billing instead of a generic load failure.

​

5.735.1 — September 26, 2026 at 9:01 AM UTC

• Approved creatives now reach third-party sales agents when the storefront and source use different identifiers for the same format. Previously affected deliveries retry automatically, and any remaining failure appears in the seller media-buy view with a clear owner and next action.

​

5.734.0 — September 26, 2026 at 4:15 AM UTC

• You can now upload WAV and MP3 files, up to 50 MB each, to the Creative Library for any advertiser in your buyer account, from Upload under More in the Library or by asking the assistant to upload the file. There’s nothing to turn on. Each file is checked to confirm it’s a valid WAV or MP3; once it passes, the upload confirmation shows it and it appears in the Library’s Assets tab. Uploading saves the file but doesn’t create or deliver a Creative; to build an audio Creative from an uploaded file, ask the assistant, since the Library’s Add creative flow doesn’t place audio files. Image and MP4 uploads work as before.

​

5.733.1 — September 26, 2026 at 3:38 AM UTC

• The Library page’s Upload now accepts WAV and MP3 wherever audio upload is on.

​

5.733.0 — September 26, 2026 at 2:57 AM UTC

• Simplify the default Source overview to show a connection outcome and one supported next action, with connection evidence and technical diagnostics available on request. Provider-authorized Sources now prefill their saved endpoint separately from replacement credentials and only allow publisher endpoint edits that the pinned provider contract permits.

​

5.732.2 — September 26, 2026 at 1:42 AM UTC

• A seller’s own category dimension is never taken over by the Library’s system category.

​

5.732.1 — September 26, 2026 at 1:29 AM UTC

• Uploaded MP4 creatives now get their delivery renditions and poster frame produced automatically after inspection, so the Creative Library card, upload receipt, and preview show the poster without any further action.

​

5.732.0 — September 26, 2026 at 1:11 AM UTC

• An All countries advertiser’s country scope no longer blocks matching with an eligible media partner. The Media Partners page labels the advertiser scope as All countries and keeps each media partner’s own markets visible. Nothing to change on your side.
• After an upload finishes, the message the Task sends on your behalf is one plain sentence with a link to the Creative Library; the raw receipt stays inside the Task under its untrusted-receipt disclosure.

​

5.731.0 — September 25, 2026 at 11:58 PM UTC

• In staging, you can now upload WAV and MP3 files, up to 50 MB each, to the Creative Library for any advertiser in your buyer account, either from Add creative in the Library or by asking the assistant to upload a creative. There’s nothing to turn on, and staging accounts that were previously told audio wasn’t enabled can upload now. Each file is checked to confirm it’s a valid WAV or MP3; once it passes, the upload confirmation shows it and it appears in the Library’s Assets tab. To build an audio Creative from an uploaded file, ask the assistant; the Library’s own creator doesn’t place audio files yet. Uploading saves the file but doesn’t create or deliver a Creative, and image and MP4 uploads work as before. Production rollout follows the validated staging check.
• If you can edit campaigns, select New campaign on the Campaigns Page to create an untitled draft and open it straight away. On a Page that isn’t scoped to an advertiser, you choose the advertiser first. On the campaign, edit its name, budget (in the advertiser’s currency), and flight dates directly; tracked campaigns stay read-only. In chat, ask for a campaign and the agent creates the draft and opens it. For MCP integrations, save_campaign now creates a draft without flight dates or a budget. Calls that already send them behave as before, and the REST create endpoint still requires both.
• If your storefront has the Library, you can now filter your Library documents by Category, Topic, Audience, and Vertical in the Library Page, and an Uncategorized chip finds documents that have no Category. These four are filled in and kept current each day from each document’s existing category and relevance details, so there is nothing to set up; they don’t count toward your limit of 20 dimensions, and if you already created a dimension with one of those names, yours is left unchanged. You can also create your own dimensions for Material with save_dimension, label documents with save_material, and filter by up to 20 dimensions at once (as chips in the Library Page, or with filter.labels when your agent searches Material); labels organize your Library and don’t change inventory selection.

​

5.730.2 — September 25, 2026 at 9:04 PM UTC

• Product emails now arrive from Apostra with Apostra branding. Sustainability emails use the Scope3 by Apostra identity.
• Storefront discovery and merchandising simulations now continue when an early policy check claims a restriction that the seller’s active policy does not contain. Explicit policy prohibitions still stop the brief, and sellers can distinguish an unsupported check from a genuine policy decline in the demand inbox.

​

5.730.1 — September 25, 2026 at 8:48 PM UTC

• Storefront media buys with declared creative formats now reach inventory sources without forwarding the buyer’s reporting webhook. Failed bookings retain their status, reason, payload, budget, and currency for follow-up.

​

5.730.0 — September 25, 2026 at 8:31 PM UTC

• Storefront home now starts loading earlier for buyers and sellers, while keeping account checks in place. Seller setup status also loads sooner, and new timings show where any remaining wait occurs.

​

5.729.0 — September 25, 2026 at 8:08 PM UTC

• Creative delivery now keeps seller feedback with the current submission. A local delivery failure or later Creative revision no longer shows an earlier seller rejection as current.
• Meta feed image creatives now accept JPEG and PNG assets reported with their standard MIME types or file extensions. Unsupported image formats remain blocked. Nothing changes in how you create or attach a creative.
• We’ve turned off the automatic event source syncing to seller ad accounts (for example Snap or Meta pixel registration) that we introduced recently. The sellerProvisioning field no longer appears on event source reads, and buys no longer try to register your event sources on seller accounts automatically. We found structural problems with that first approach and are rebuilding it properly; your registered event sources themselves are unaffected.
• Media-buy reads now leave package and total budgets unset when a provider allocates from a shared campaign budget, rather than presenting stored line-item budgets as provider budgets. Nothing to change on your side.

​

5.727.1 — September 25, 2026 at 6:36 PM UTC

• Clarify whether a Source connection check is current, stale, or needs setup, and show one next action with its owner.

​

5.727.0 — September 25, 2026 at 6:26 PM UTC

• Storefronts now reuse the authenticated session response when loading the current account, removing a redundant startup request while preserving account and Terms of Service checks.

​

5.726.3 — September 25, 2026 at 6:11 PM UTC

• Seller dashboards now fetch recent RFP counts and rows at the same time, reducing the wait without changing the results shown.

​

5.726.0 — September 25, 2026 at 5:13 PM UTC

• MCP sign-in now keeps the browser confirmation page open until you continue to the local client. If the client is not listening, you can retry the callback from that page for up to 10 minutes without signing in again.
• Storefront account switches now reuse the account data returned by the switch itself, avoiding a duplicate loading request before the destination account appears.

​

5.725.1 — September 25, 2026 at 4:34 PM UTC

• Explain when Source Diagnostics requires a directly signed-in organisation admin to create an owned Sales Agent instead of offering an action that cannot succeed.
• Preserve each proposed product’s sales agent and inventory source when a buyer saves a media buy from a text-only MCP client.

​

5.725.0 — September 25, 2026 at 4:04 PM UTC

• Embedded sales agent 1.46.0: certify FreeWheel booking per tenant with a no-spend canary, fail closed for unsupported FreeWheel targeting.

​

5.724.4 — September 25, 2026 at 3:25 PM UTC

• FreeWheel source setup now shows commercial booking readiness separately from read access, with the exact schedule timezone correction when a booking check fails.

​

5.724.2 — September 25, 2026 at 2:44 PM UTC

• Opening a storefront home now keeps one loading state while the account route resolves, including entry through the root URL. Nothing changes on your side.

​

5.724.0 — September 25, 2026 at 2:13 PM UTC

• Agent connection setup now opens after one bounded contract-history request and loads older published versions only when requested.

​

5.723.1 — September 25, 2026 at 1:26 PM UTC

• Clarification: the Meta AdCP 3.2 age-update capability announced in v5.716.0 is a substrate-only change today. No save_media_buy request path currently reaches this code because the three public AdCP 3.2 gates (STOREFRONT_ADCP_SUPPORTED_VERSIONS, STABLE_ADCP_WIRE_VERSION, SUPPORTED_ADCP_RELEASES) remain dark. Sellers running Meta will observe the described targeting_overlay.demographics.age update behavior once those gates activate in a later release; today’s requests still land on the AdCP 3.1 contract and reject demographics on update as before. The analogous Snap and Pinterest slices (#16614, #16676) shipped as type: internal for exactly this reason; this note aligns the record.
• Media-buy create, update, and cancellation responses now identify inventory-source setup errors as terminal seller configuration problems instead of temporary outages. Buyers should ask the seller to correct the source configuration; retrying the same request will not help.

​

5.723.0 — September 25, 2026 at 1:01 PM UTC

• Seller storefronts now open in one stable state, with Chats collapsed until you open it. Nothing to change on your side.

​

5.721.0 — September 25, 2026 at 11:40 AM UTC

• Restore Activity as an always-visible buyer and seller left-rail destination.

​

5.718.0 — September 25, 2026 at 9:29 AM UTC

• Source account refreshes now handle valid task response wrappers and preserve safe diagnostics when an upstream account listing fails.
• Embedded sales agent 1.45.4: classify deterministic FreeWheel client errors, defer FreeWheel booking until creatives verify, reconcile FreeWheel inventory before trafficking, resolve FreeWheel schedule timezones.
• Every quoted proposal now says what the seller committed to for your goal. Each allocation carries a goal answer read off the seller’s terms (its pricing option, the product’s delivery type and measurement terms, and any optimisation goal it declared), with the cost the seller’s terms commit or aim at and a commitment kind: guaranteed when a fixed price on the outcome comes with guaranteed delivery or a makegood policy, best_effort when the seller named a target or priced the outcome without a guarantee, and report_only when nothing in the terms is tied to your goal. The proposal-level commitment is the weakest kind across allocations and says whether every answer meets your asked cost. Older proposals are read the same way from their stored terms.

​

5.717.5 — September 25, 2026 at 8:51 AM UTC

• Conductor pull-request watch recovery now uses a repository-scoped GitHub webhook ledger index, preventing broad retained-ledger scans from delaying the repair lane.

​

5.717.4 — September 25, 2026 at 8:36 AM UTC

• Permanent creative approval callback failures now produce one immediate alert per destination and status, followed by a cooldown. Every failed callback remains recorded and available for support to inspect and replay.

​

5.717.3 — September 25, 2026 at 8:05 AM UTC

• add_discovery_products now accepts Meta’s “Sales — Maximize Website Conversion Value” product without a placeholder bidPrice, as long as you declare a ROAS floor (target: { kind: "per_ad_spend", strength: "floor" }) or a target: { kind: "maximize_value" } optimization goal — this product never accepts a bid, since Meta only runs it as automatic delivery driven by that goal. Previously you had to add the product with a throwaway bid and then null it out via update_campaign before executing. The same check runs again at execution time, so removing the goal after adding the product is caught with a clear error instead of failing deep inside Meta’s own bidding rules.
• Forward explicit insertion-order and placement timezone contracts when provisioning or rotating a managed FreeWheel sales agent connection.
• The Library’s Documents list is easier to scan: the All documents / Recent rail and the pages-or-slides filter are gone, counts read as plain document counts, a document without a preview shows that in its thumbnail, and the table view drops the repeated type-and-date line under each name.

​

5.717.1 — September 25, 2026 at 6:43 AM UTC

• Creative approval callbacks that receive a permanent HTTP rejection now stop retrying automatically. The failed callback remains recorded for support to inspect and repair without flooding the buyer endpoint or creating repeated alerts.

​

5.717.0 — September 25, 2026 at 6:02 AM UTC

• Sessions can keep the selected RFP turn as removable private context for the existing Murph composer while you review that exchange.
• Video uploads now show an inspected poster frame in the Creative Library, upload receipt, and preview when it is ready. For a video Creative, the image in the thumbnail slot is used wherever the Creative shows a still; otherwise it uses the inspected poster frame. The upload receipt shows the poster once it is ready. Sellers receive the poster only where their destination has a thumbnail slot.

​

5.716.0 — September 25, 2026 at 5:29 AM UTC

• Meta media-buy updates on AdCP 3.2 now accept targeting_overlay.demographics.age, closing the last gap in the AI-5309 demographics slice for Meta. Before this change, a buyer who created a Meta media buy with a specific age range on 3.2 could not adjust that age range through update_media_buy — the request returned 400 does not yet support targeting_overlay.demographics. Age changes on 3.1 continue to be rejected as before, matching the create-side gate. min_spend_target, canonical bidding, and canonical budget_allocation on 3.2 update remain deliberately blocked (see update-media-buy.ts:880-893) until they can be delivered with atomic-rollback semantics.

​

5.715.2 — September 25, 2026 at 3:43 AM UTC

• Improved storefront availability during temporary routing delays: affected storefronts now stay safely unavailable until routing is confirmed, then refresh automatically.

​

5.715.1 — September 25, 2026 at 3:27 AM UTC

• Sessions now shows its RFP ledger inside the Sessions page, keeping RFPs and conversation records separate without a second page heading.
• Optimization goals with a cost_per or per_ad_spend target now accept an optional strength field (target, cap, or floor). Some sellers only support a subset of strengths for a given target — Meta, for example, requires strength: "cap" for cost_per and strength: "floor" for per_ad_spend, and previously rejected every such goal outright because there was no way to say which one you meant. Set strength explicitly when targeting a seller with this constraint; omitting it keeps today’s behavior unchanged.
• Sessions now opens native RFP exchanges in a persistent browser while keeping authorised Murph conversations separate.

​

5.715.0 — September 25, 2026 at 3:10 AM UTC

• You can now attach creatives from the campaign itself: on the Campaigns Page, open a campaign and select Attach creatives in its Creatives section, tick creatives from the advertiser’s Creative Library, and select Save creatives. Unticking a creative detaches it when you save. Attached creatives run on every current and future media buy in the campaign whose products accept their format, and they’re listed under Attached, separate from Placed on media buys. Drafts, reference material, uploads with no linked file, and creatives without a canonical format can’t be selected, and each row says why. A creative live on an active or paused media buy can’t be detached until that buy ends, and the picker manages up to 200 creatives per campaign. It’s available now to anyone who can edit the campaign; buyers who can only view see no change, and tracked campaigns stay read-only.
• Creative review retries now reuse existing submissions without failing when the same creative content is submitted again.
• Meta product descriptions returned by discovery could state an open-ended age range (for example, “18 and older”) that disagreed with the exact age range actually applied to the campaign. Descriptions now always include the resolved age range, so buyers reading product details see the same age targeting that gets sent to Meta.

​

5.714.4 — September 25, 2026 at 2:43 AM UTC

• request_proposals now reports age targeting that was already resolved from your brief text alongside its existing demographicOverlay capability line, so a product with brief-driven age no longer reads as if age targeting failed. demographicOverlay/ageTargeting are unchanged and still describe only the separate AdCP 3.2 structured-overlay path, which remains unavailable while the platform negotiates AdCP 3.1.

​

5.714.3 — September 25, 2026 at 2:20 AM UTC

• create_media_buy no longer permanently blocks retries after a seller rejects a request that never reached the ad server (for example, an unsupported bidding combination). A corrected resubmission on the same media buy now gets a fresh attempt instead of an idempotency conflict. Rejections where the seller may have partially processed the request still block retries, so no duplicate ad-server write can be created.

​

5.714.1 — September 25, 2026 at 1:31 AM UTC

• Storefront task webhook callbacks now recover after transient delivery failures without reusing a delivery identity when the event timestamp changes.

​

5.714.0 — September 25, 2026 at 1:02 AM UTC

• Inventory source pages now lead with the saved connection, authentication state, and next action. Technical test evidence stays under Technical details, and connecting a Partner referral keeps the selected Source open in the same browser tab.
• Inventory source validation and sandbox guidance now explains the account, authorization, and provider test setup that still apply. Selecting or omitting a Source no longer implies that a blocked connection becomes runnable or that every provider account is no-spend.
• Valid API and MCP requests queued behind another authorization lookup now receive a fresh bounded lookup window, reducing temporary authentication failures during request bursts. Authentication rules and permissions are unchanged, and no action is required.
• Source Diagnostics now opens faster for storefronts with multiple inventory sources. If one source is unavailable, the page still shows evidence from the others. No action is needed.

​

5.713.0 — September 25, 2026 at 12:19 AM UTC

• Accept completed synchronous adapter delivery payloads that omit the transport-managed task status.
• Every published agreement page now lists its earlier versions at the bottom, each linking to its permanent page, so you can open the exact text of any version you or a counterparty accepted. Opening an older version shows only the versions published before it. The list comes from the agreement registry, so a newly published version appears automatically. For agents and integrations, GET /agreements/{document}/versions returns the same list, newest first.

​

5.712.0 — September 24, 2026 at 11:44 PM UTC

• On the Advertisers and Campaigns Pages, a Dimensions filter in the filter row narrows the list to the labels you pick, such as Market › US or Launch › Q4, and each card shows its current labels as read-only chips. To change one campaign’s labels, open the campaign and use Labels in its detail view (shown when your account can manage dimensions); to label advertisers, create a dimension, or label many campaigns or advertisers at once, ask in chat, then reopen the Page to see the change. Nothing changes for reporting, targeting, or seller Pages.
• Sellers now see a campaign’s goals when the buyer requests proposals. The brief each seller receives carries the campaign’s ranked optimisation goals with their targets (for example “clicks, target cost 3.00 or less per click, counted by the seller’s delivery metrics”), so a seller can price against the goal instead of guessing it from prose. Event goals disclose the event type and never the buyer’s event source id or tracker configuration, and the campaign budget stays withheld.
• When you read a media buy with creatives, each creative now includes its saved click-through URL. Nothing to change on your side.

​

5.711.2 — September 24, 2026 at 11:25 PM UTC

• Media Partners now keeps selected and default-on partners in Active while advertiser setup is provisioning, deferred, failed, or waiting for action. Available is reserved for partners you can add or have excluded. You don’t need to take any action.

​

5.711.1 — September 24, 2026 at 10:55 PM UTC

• Fixed an edge case in seller event-source provisioning: renaming an event source (or changing its event types) after it was already provisioned onto a seller account now correctly re-registers it with the seller instead of potentially reusing a stale response.

​

5.711.0 — September 24, 2026 at 10:40 PM UTC

• Meta campaign connections can now finish multi-page campaign syncs even when Meta rewrites its pagination URL. Nothing changes on your side.

​

5.710.1 — September 24, 2026 at 10:23 PM UTC

• Apostra connection authorization links now remain on the Apostra domain. Existing Interchange links are unchanged, and no reconnection is required.

​

5.709.3 — September 24, 2026 at 9:33 PM UTC

• Buyer agents now receive safe diagnostic details when a connected provider campaign sync fails, so they can identify the next corrective action instead of stopping at a generic error.

​

5.709.2 — September 24, 2026 at 8:56 PM UTC

• Apostra signup, confirmation emails, and FAQs now say that we will get in touch to enable access, without describing Apostra as a private alpha or asking people to join a waitlist.

​

5.709.1 — September 24, 2026 at 8:36 PM UTC

• Publish the buy-side Apostra commercial offer in the Organization IU Rate Card guide. Connecting accounts, creating campaigns, and placing buys are free with 0% of media. Optional Intelligence is in beta; the existing Enhanced Reporting catalog default is 4 IUs per connected account per billing period and current plan templates waive it, while other buy-side Intelligence plan pricing is coming soon. Enterprise services are scoped and priced through a separate agreement. Ordinary product support through Murph remains included.
• The internal model defines what must be true before a buyer intelligence activity can be priced, keeps bulk IU economics separate from feature access, and treats each Enterprise engagement as a scoped combination of managed service, integrations, cooperative agent development, dedicated support, governance, and intelligence.
• The pricing source also separates partner-funded gateway economics from the buyer offer, records the current one-year Global Market Maker negotiating anchor, and explains how seller-response density can grow IU revenue without introducing a percentage-of-media fee.
• Enabled Creative Engines and organisation advertiser grants are less likely to be interrupted by a slow feature-flag response. Nothing to change on your side.

​

5.709.0 — September 24, 2026 at 8:01 PM UTC

• get_delivery now supports additive live_campaign_delivery reads for one exact campaign from its connected provider. Pass campaignId and a date range. The existing stored campaign_delivery rows, totals, filters, dimensions, and pagination contract remains unchanged.
• The Apostra developer package uses this live read for its read-only Meta campaign review. When Apostra or Meta authorization is missing, the agent gives the person a secure browser handoff instead of asking for credentials.
• Meta campaign pagination now strips provider-echoed authorization parameters from trusted continuation URLs and follows them with the current connection credential. This restores campaign synchronization without forwarding a token from response data.
• When a provider referral has no suitable Agent Source yet, you can create one from that provider’s published connection options without leaving the referral. Enter a full HTTPS endpoint only when the connection options allow a publisher-owned endpoint. Your endpoint and credential reference stay with your Source; they do not change another publisher’s connection or the Agent’s shared identity. Provider acceptance, validation, activation, and certification remain separate steps.

​

5.708.2 — September 24, 2026 at 7:41 PM UTC

• Valid API and MCP calls using the same API key now handle request bursts with fewer temporary authentication failures. Authentication rules and permissions are unchanged, and there is nothing to change on your side.

​

5.708.1 — September 24, 2026 at 7:10 PM UTC

• When you test a brief from a specific inventory source, the preview now reports that source’s catalogue error instead of saying the storefront has no inventory. Healthy sources with no matching products still return an empty preview, and buyer discovery is unchanged. Nothing to change on your side.

​

5.708.0 — September 24, 2026 at 6:33 PM UTC

• Restore Campaign image thumbnails, make rehosted Media Partner logos visible across API instances without blocking page loads, and use the current product brand in portable widget hosts. Keep account-switch recovery on the selected account when provider refresh fails.
• Embedded sales agent 1.45.3: verify FreeWheel currency after booking.

​

5.707.1 — September 24, 2026 at 5:39 PM UTC

• Account-scoped media buys now keep the buyer’s authentication when syncing creatives during creation and updates, so the sync can reach the seller.

​

5.707.0 — September 24, 2026 at 5:27 PM UTC

• Event sources now register automatically on every seller account that supports it, not just the ones that happened to find them on their own, like Meta sometimes did. When a campaign referencing your event source buys on a seller account such as Snap or Meta, Interchange registers the source there, and every later buy sends the seller’s own id instead of yours, so that seller can attribute conversions back to your campaign. Nothing to change on your side — this starts on your next buy against that seller, and it can add up to a few seconds of latency to that buy while it registers (capped at five seconds); it never blocks the buy outright. If the seller can’t confirm an id in time — a failed registration or a timeout — that buy proceeds without that one optimization goal rather than sending an id the seller was never given, and it’s retried automatically on your next buy. A seller that doesn’t support this at all is rechecked at most every 30 days instead of on every buy. Check the sellerProvisioning array on GET /advertisers/:advertiserId/event-sources for the status per seller: provisioned, needs_install (some sellers require a one-time manual step in their own dashboard before they issue an id), unsupported (nothing to configure — that seller’s native tracking still applies; rechecked every 30 days), or failed (fix the named error and it retries on your next buy).

​

5.706.0 — September 24, 2026 at 4:58 PM UTC

• Campaigns now gives every buyer the enriched list with advertiser-wide active campaign count, daily budget, and today’s spend.
• Update media buy — typed Storefront targeting preflight. A targeting_overlay your seller doesn’t support (for example a geo_postal_areas country outside the seller’s declared coverage) now fails early with a clear Sales agent does not support the requested targeting: … error, before the seller-side dispatch, instead of failing later inside the adapter with an adapter-shaped message. No change to any accepted overlay.

​

5.705.0 — September 24, 2026 at 4:34 PM UTC

• Keep buyer and seller left-rail destinations as stable navigation after a chat starts.

​

5.701.0 — September 24, 2026 at 2:10 PM UTC

• You can now commit product-local creative formats in modular avails feeds without a matching publisher catalog entry. Omit publisher_domain for a product-local format and provide a stable format_option_id when possible; existing requests without one receive a deterministic id. Publisher-scoped formats still require an exact catalog match.
• If you choose Developer when signing up with a password, email verification now returns you to the signup you started. No action is needed.
• Sellers using third-party catalog sources will keep supported zero-reserve CPM auction products in catalog validation. No action is needed; invalid price data remains excluded.

​

5.699.0 — September 24, 2026 at 12:28 PM UTC

• Account Admins can now open Attest current endpoint from an eligible Agent’s Overview when an observed production revision still needs endpoint confirmation. Certification setup errors now distinguish a missing revision endpoint, a missing protected fixture, an unavailable fixture, and an unsafe fixture source. Attesting an endpoint does not register a fixture, start certification, or authorize spend.
• Managed ad-server-backed storefronts now keep creative format selections aligned with their media-buy packages, so valid buys reach the connected ad server instead of being cancelled before submission.

​

5.698.0 — September 24, 2026 at 12:05 PM UTC

• Source Health now distinguishes an Apostra initial-response timeout from an error returned by your third-party sales agent. It assigns the timeout to Apostra, keeps later completed responses healthy, and still assigns genuine Source errors to your operator.

​

5.697.1 — September 24, 2026 at 11:04 AM UTC

• Creative Library searches now return exact creative results reliably when render links are available.
• Campaigns and Creative Library pages opened in a new chat now stay above the chat input and starter prompts. You do not need to change anything.
• Demand Inbox now shows saved and uploaded RFPs when you open it from the seller navigation or an existing bookmark. Nothing to change on your side.

​

5.697.0 — September 24, 2026 at 10:31 AM UTC

• Fixed a bug where launching a Meta “Sales — Maximize number of conversions” (or Traffic) media buy could fail with a SERVICE_UNAVAILABLE error and roll back the campaign, even though the ad account was fully eligible. Meta returns an additional geo-targeting detail on these campaign types that our targeting verification didn’t yet recognize; it’s now accepted, and the campaign launches normally.
• The advertiser roster no longer overlaps the chat input or starter prompts when the list fills the available screen height.

​

5.696.1 — September 24, 2026 at 9:56 AM UTC

• Buyer agents can now express country, ISO 3166-2 region, metro, and postal targeting on a V3 media-buy overlay, including exclusions. Country and region names resolve to canonical codes before dispatch. Campaign geographic intent is used as the default for proposal discovery and media buys unless a buy supplies its own overlay.

​

5.695.0 — September 24, 2026 at 7:47 AM UTC

• Product Marketing links now open the Library, where sellers can continue to manage material and review selling points without moving or re-uploading data.

​

5.694.1 — September 24, 2026 at 7:12 AM UTC

• Sellers with a configured custom modular source can now ask Murph to open a read-only preview for that source, then plan and run a confirmed no-spend test campaign using its products. The test leaves source, storefront, and Listing activation unchanged. Nothing to change on your side.

​

5.692.1 — September 24, 2026 at 5:08 AM UTC

• Re-running product discovery on a campaign now always uses the campaign’s current brief, even when the request reuses an existing discovery ID. Previously, editing a campaign’s brief (for example to add geographic targeting after a launch error) had no effect on a subsequent discovery run against that same discovery ID — sellers kept receiving the original, pre-edit brief.
• Reading a V3 campaign with no creatives attached now says plainly that creatives are optional before launch and only needed once delivery starts, instead of showing an unexplained “0 creative(s)” count. Buyer agents were misreading that bare count as a launch blocker and telling buyers to attach a creative before a campaign could go live, even though nothing on the platform required one.

​

5.692.0 — September 24, 2026 at 3:39 AM UTC

• Use dimensions to label and filter Creatives and reusable Creative Library assets. Existing Library tags are available through the built-in tags dimension, and the Library can filter by labels without exposing another advertiser’s data.

​

5.691.0 — September 24, 2026 at 2:55 AM UTC

• Organization administrators can now review and change access for an approved self-serve advertiser relationship from the Advertisers page. They can choose Viewer (read), Editor (read and write), or Administrator (admin, read, and write) after comparing currently reviewed, currently effective, and proposed access. These changes do not grant billing, payment, or Campaign execution authority.

​

5.690.0 — September 24, 2026 at 2:25 AM UTC

• Buyer advertisers can now sync first-party CRM audiences through the V3 MCP surface using save_audience. This enables audience-based social targeting (Meta, TikTok, and similar channels) that requires a first-party seed list from the advertiser’s CRM. Without this surface, the targeting layer had no way to receive that seed list through the agent.
• Each call accepts one or more audience items. For each audience, the agent can add members by raw email (normalized and SHA-256 hashed at the API boundary before forwarding), pre-hashed email, or pre-hashed phone; remove members by external ID; or delete the audience entirely. Deletion and removal are permanent for that sync; re-adding members requires a subsequent sync call.
• After submission, use get(kind: audience, advertiserId: <id>) to check match status and member counts as processing completes.
• This capability ships ungated (gate: none): it operates on the caller’s own advertiser data, is governed by existing GDPR/consent fields on each audience item, and does not alter any shared platform state. No additional rollout cohort or kill switch is needed beyond the existing buyer account access control.
• Target persona: This tool is built for the S2S/MCP-integrated buyer — the scrappy-builder or power-buyer persona who programmatically manages CRM-audience-based social campaigns (Meta, TikTok, and similar channels) via an automated pipeline. Enterprise and agency buyers who prefer a business-effect framing: this capability enables CRM-based social targeting without a separate data-onboarding service. Sellers are not implicated: save_audience operates on the buyer’s own advertiser data, has no effect on storefronts, ranking, or seller presentation, and is invisible to any seller account.
• Monetization: This capability is part of the standard buyer MCP surface with no separate billing line.
• Acceptance criteria: (1) A buyer calling save_audience with a valid audience item receives a stable operationId; (2) A subsequent get(kind: audience, advertiserId: <id>) returns the bounded total and audience rows with their processing status and member counts within the V2 sync SLA. These criteria are covered by the v3-audience-surface acceptance test suite.
• Adoption measurement: save_audience call volume and syncAudiences dispatch count are captured in the existing audience-sync V2 metrics pipeline — no new instrumentation is required. Review cadence: weekly for the first 30 days post-launch to confirm adoption and surface any match-rate anomalies.

​

5.689.0 — September 24, 2026 at 1:23 AM UTC

• Buyer readiness now counts only sellers with active sales agents, aligning the ready count with the active-agent eligibility used for proposal requests.
• Remove the Pages & slides tab. Pages and slides now open inside each document, and sellers can filter the Documents list to show material that has them.

​

5.688.0 — September 24, 2026 at 12:48 AM UTC

• The Apostra Platform Terms of Service v4.1 are now the current terms. If you’re an organization admin on v3.0, you’ll see a prompt to review and accept v4.1 when you next open Apostra. You can choose Review later until October 23, 2026; after that, account activity pauses until an admin accepts. Until you accept, your current contract and rates stay in place. Once you accept, your standard contract takes no percentage of media. Negotiated contracts are never prompted. The documents v4.1 incorporates are published with it: Facilitated Agreement Terms 1.2, which govern your existing Relationship Agreements once you accept, Marketplace Policies 1.1, and Payment Operations Schedule 1.1. See what’s different from v3.0: https://api.apostra.com/agreements/changes/terms-of-service/v3-0_v4-1

​

5.686.2 — September 23, 2026 at 11:37 PM UTC

• Interactive pages now keep their height in sync when content loads after the host connection, and long advertiser directories use the available page space. Campaigns, notifications, and other widgets remain fully visible with nothing to change on your side.

​

5.686.0 — September 23, 2026 at 11:07 PM UTC

• You can now create, update, archive, and restore event sources — the pixels and server feeds your campaigns measure conversions through — with the new save_event_source tool, and read them with search/get alongside your other campaign objects. Existing sources and sync calls are unaffected: nothing to change on your side.
• event_source is distinct from measurement_source (your MMM feeds, brand-lift studies, and other outcome-record sources): use event_source to register how conversions reach us, measurement_source for how you measure their effect afterward.
• Each event source can now also report the ISO 4217 currencies it accepts for ROAS reporting. It can report where its events originate too — a flat category like website, app, or in-store, or, when that’s too coarse, a structured surface such as a specific owned channel or feed. And it carries a new AdCP health grade, from insufficient to excellent, alongside the ingestion status you already had.
• Syncing event sources with event_sources omitted is now a discovery-only call: it returns every registered source unmodified, so you can check what’s configured before you write.
• Distribution pricing is now available on request. Existing sellers can accept a Distribution upgrade with no monthly fee for its first 60 days, and the accepted offer controls the IU rate. Listing waives brief responses, Enhanced Reporting, and qualifying media buys. Storefront agent plans waive Enhanced Reporting and charge 1 IU for each completed brief response and qualifying media buy.

​

5.684.0 — September 23, 2026 at 10:22 PM UTC

• Review extracted selling points and inventory disagreements from each document in the Library.

​

5.683.2 — September 23, 2026 at 9:55 PM UTC

• Sales-agent validation can now confirm its sandbox advertiser activation when the storefront is not yet eligible for live transactions. Normal advertiser activation and storefront eligibility are unchanged, with nothing to change on your side.

​

5.683.1 — September 23, 2026 at 9:16 PM UTC

• The campaigns list in chat no longer gets cut off at the bottom.
• It was reporting its height to the chat host only in a timing window that rarely happened, so the host often left the panel at its startup height and clipped everything below the filters — including the campaigns themselves and the panel’s own rounded bottom edge. The list now reports its height reliably, and a long list scrolls inside the panel instead of running past its edge.
• Archived campaigns are no longer mixed into the list by default. Pick “Archived” in the status filter to see them.
• For buyers on the V3 campaigns experience, the list also now uses the same visual system as the rest of the product — the same cards, status labels, filters, and empty states.
• The Creatives page now opens for seller-operated advertisers in the Advertisers workspace. Nothing to change on your side.

​

5.683.0 — September 23, 2026 at 8:17 PM UTC

• To replace a saved Interchange connector name in Claude, ask an organization owner to remove it and re-add the same api.apostra.com MCP endpoint with the name Apostra. New connections through api.apostra.com use Apostra’s purple apostrophe icon and publish Apostra as the server identity automatically.

​

5.682.5 — September 23, 2026 at 8:00 PM UTC

• Buyer account switches now keep the account menu covered until the selected account is ready. Nothing needs to change on your side.

​

5.682.4 — September 23, 2026 at 7:36 PM UTC

• This changeset records the launch guidance and exchange-ledger change as evidence, not a customer capability.

​

5.682.3 — September 23, 2026 at 7:16 PM UTC

• The Demand inbox now keeps every saved brief visible when one row’s details cannot load. The affected row explains the gap and can be retried while the other rows remain current. Nothing to change on your side.

​

5.682.2 — September 23, 2026 at 6:33 PM UTC

• Fixed a bug where a buyer’s creative-approval webhook could get permanently stuck after a single delivery failure and never retry successfully. A background query that only needed to read the request’s retry count was also touching its updated_at timestamp, which the delivery system relies on to recognize a retry as the same notification; that side effect made every subsequent retry look like a conflicting delivery, so the buyer’s push notification for that creative’s approval or rejection was never delivered.

​

5.682.1 — September 23, 2026 at 5:52 PM UTC

• Connections pages now show provider cards without waiting for brand-registry lookups.

​

5.682.0 — September 23, 2026 at 5:27 PM UTC

• Cancelling or deleting a media buy whose seller acceptance is still pending now succeeds and releases its budget; the seller-side cancel completes once the seller resolves the buy.
• Seller Rate Card plans now carry their own activity prices. Listing plans waive all IU-rated seller activity, while Merchandising plans charge only for work completed by the Storefront agent.
• Listing-only storefronts no longer show Demand or specialist merchandising navigation, while storefronts with merchandising selected keep those destinations during setup.

​

5.680.0 — September 23, 2026 at 4:32 PM UTC

• Sign in with Google or Microsoft now opens the provider’s account picker when you have not typed an email first, so you can choose which account to sign in with. Previously the provider signed you straight in with whatever account your browser already had a session for, which made the provider buttons look like they only worked after typing your email. Typing your email before clicking a provider still takes you straight to that account.
• Signing in now completes when your browser opens the identity provider in a new window instead of the current tab. Arc does this, and it left sign-in dead on “Authentication failed — Sign-in verification has expired. Please start again.” even on a first attempt. The state a sign-in carries from start to finish — the verification secret, the email you typed, and the MCP client session — is now readable by the window that receives the provider’s callback, so you end up signed in, on the page you were heading to, with the wrong-account check still applied. Sign-ins started in separate windows stay independent of each other, and unfinished sign-in state is discarded after thirty minutes.

​

5.679.0 — September 23, 2026 at 4:09 PM UTC

• Demand now stays in the storefront navigation, while the chat add menu focuses on files and other content you can add.

​

5.678.1 — September 23, 2026 at 2:39 PM UTC

• The advertiser picker in Murph’s left rail reads better on a long roster. Its menu no longer runs the height of the window: the list scrolls inside a fixed height, with the search field pinned above it and ”+ Add advertiser” pinned below, and a row part-way through a scroll is no longer sliced flush against either of them. The menu is a little wider than the button that opens it, a sandbox advertiser’s label now sits beside its ID rather than on its name, and with no advertiser chosen the button reads “All advertisers” instead of the account name.
• Private plans now keep the renewal terms shown in the plan and accepted offer instead of losing automatic renewal because they are not publicly listed.
• Staging a v3 media buy package for Meta, Snap, or TikTok with no geographic targeting now returns a non-blocking warning immediately, instead of only failing at launch after budget, creative, and flight work is already done.

​

5.678.0 — September 23, 2026 at 2:12 PM UTC

• V3 campaign launch failures now show the real classified reason (and, where the platform’s message is safe to display, the specific text) instead of a bare “execution failed” — a debug-mode error wrapper was silently dropping that information before it reached the buyer.
• Connections and other media-partner pages no longer wait for third-party logo rehosting before showing content.
• Sellers can now re-admit a rejected buyer account intake. A new POST /api/v2/storefront/account-mappings/reviews/:intakeId/readmit endpoint transitions a rejected intake back to pending_review so the seller can review it again - useful when a rejection was made by mistake.
• V3 tool responses now surface more detail by default. save_signal success text includes the signal ID and source ID so follow-up calls can reference the exact record without a separate search. save_media_buy create responses include the seller, flight dates, and budget; update responses include the resulting flight; and update errors include the attempted flight dates. Error messages from save_advertiser, save_connection, and save_wholesale_product now include the relevant entity ID and operation context, making it easier to diagnose what was attempted when a write fails. Signal discovery now runs with debug mode enabled so diagnostic detail is available when discovery fails.

​

5.677.1 — September 23, 2026 at 1:12 PM UTC

• Fixed the API access page showing a generic “internal error” when a parent account admin was not enrolled in a sub-account’s WorkOS organization. The error is now correctly classified as an access issue (HTTP 403 with a clear message) rather than an opaque internal server error.
• Cancelling or deleting a media buy that is still waiting for seller approval now withdraws the seller’s approval request, so the seller can no longer approve it and it can never go live afterwards. Previously the cancel failed and left the request approvable, so a buyer who cancelled a buy could still see it booked with the seller’s ad server once the seller approved it. The buy reads canceled only once the request is withdrawn; if the seller approved it moments before your cancel arrived, the cancel is refused and you can retry it once the buy reaches the seller’s ad server. Nothing to change on your side. Sellers: a buy the buyer cancelled drops out of your approvals queue and shows as revoked.
• Cleaned up the wording buyers’ agents see when Meta or TikTok has no real price guidance to offer. It now reads “no price guidance available for this cpm product” instead of the awkward “cpm AUD (no price guidance available)“.

​

5.676.2 — September 23, 2026 at 12:13 PM UTC

• Updated the documentation site’s content to the Apostra brand: company/product references, API and asset URLs (interchange.io → apostra.com), and the “Use Apostra”/“Build with Apostra” guide filenames now match the rest of the docs.

​

5.676.1 — September 23, 2026 at 11:45 AM UTC

• Launching a v3 campaign with a Meta media buy that has no geographic targeting now shows the specific reason (“Meta requires explicit geographic targeting…”) instead of a generic “The ad platform rejected the request as invalid.” message.

​

5.676.0 — September 23, 2026 at 11:08 AM UTC

• Buyers on MANAGED storefronts can now declare operator or advertiser billing on a sync_accounts entry, not only agent. POST /api/v2/buyer/storefront-accounts/sync and the sync_buyer_storefront_accounts tool accept a billing_entity payload on any entry — legal name, tax/VAT/registration ids, postal address, billing contacts, and (optionally) bank details — and operator/advertiser entries now require one.
• A storefront only accepts the billing modes it has declared support for; requesting one it doesn’t returns HTTP 400 BILLING_NOT_SUPPORTED naming the supported modes. billing_entity.bank is write-only: you can send it to provide payment coordinates, but it is never echoed back in a sync_accounts or list_accounts response. billing: 'agent' behavior, and entries that omit billing_entity for agent billing, are unchanged.
• Sellers see no new protocol or UI surface. A buyer’s billing_entity flows through the same account-grant record sellers already read for agent billing.
• Monetization: no billable surface, no packaging change.
• Rollout - gate: none, atomic launch. The new billing modes and billing_entity field are additive; a buyer that never sends them sees no behavior change. Release check: after deploy, an operator/advertiser entry with a complete billing_entity against a storefront that supports it returns action: created/updated, one against a storefront that doesn’t returns BILLING_NOT_SUPPORTED, and no response body carries billing_entity.bank.
• Meta’s get_media_buy_delivery adapter method now accepts host-attested protocolOptions.servedAdcpVersion and forwards it into the underlying task, matching the signature of Meta’s other four AdCP methods. No customer-visible behavior changes today — the delivery-read task has no 3.2 branches to gate yet — but this closes the last Meta signature-parity gap so a subsequent per-behavior slice can add 3.2 read-path branches without touching the adapter boundary.
• Meta and TikTok product discovery and proposal responses no longer show a $0 or invented CPM floor price. Neither platform gives us a real price signal at discovery time, so a floor we authored ourselves was never more than a guess - and for any non-USD account it was already showing as zero. We now leave floor price and price guidance out of the response entirely when we don’t have a real number to back it, rather than showing a number that could be mistaken for platform guidance.
• Snap wholesale get_products now stamps per-product ext.scope3_execution_readiness (ready_for_execution / setup_required / input_required / selection_required / inventory_unavailable) when the buyer’s Snap ad account is connected, matching Meta’s and TikTok’s existing wholesale behaviour. Buyers on Snap wholesale can now see at discovery time whether a product will succeed at create_media_buy or requires setup.

​

5.675.1 — September 23, 2026 at 10:33 AM UTC

• Library cards and rows now show file-type thumbnails and preview state, while buyer Creative images use their approved source image when available.

​

5.675.0 — September 23, 2026 at 10:21 AM UTC

• Open Buyer Account Mapping directly from the Buyers workspace. Murph now uses the public guide when explaining where buyer mappings are managed.
• Fixed a bug where budget and other field updates sent to AdsWizz/Mediamark (and any ESA seller that responds synchronously) were confirmed by the seller but not applied locally - leaving the media buy showing its old values indefinitely. Updates now correctly apply after seller confirmation.
• The TypeScript starter can generate types from the live tool schemas. Run npm run types:generate to write one input type per tool into src/generated/tools.ts, so incompatible type or enum changes and newly required fields can become compile errors instead of rejected calls.

​

5.674.0 — September 23, 2026 at 9:27 AM UTC

• The Media Partners page now groups partners into Active, Needs connection, and Available, and opens with Ready for buying selected. Choose All to include partners that are not yet open for buying; partners that need a platform connection remain visible.

​

5.673.0 — September 23, 2026 at 8:43 AM UTC

• First-party emails now use the Apostra name, legal identity, and visual design from the scheduled launch time. Buyer invitations have shorter setup copy.
• Buyer waitlist submissions now receive a confirmation email after the form is accepted. The message confirms that the request is under review without implying that an account or access already exists.

​

5.671.0 — September 23, 2026 at 7:17 AM UTC

• Show sellers recorded reasons for an RFP response, including a safe link to the relevant source diagnostics when pricing configuration is incomplete.

​

5.670.0 — September 23, 2026 at 5:53 AM UTC

• Seller Library documents and Creative Library items now open in a previewer while the browse list stays in place.

​

5.667.0 — September 23, 2026 at 4:04 AM UTC

• Restrict Apostra’s developer skill to canonical first-party contract sources, scan its exact source tree for trust-boundary drift before publication, and bind the pre-publication policy result to the exact source digest, including extensionless text and executable assets, without treating an unbound public provider result as release qualification.
• Give an Account Admin an owner task for attesting the endpoint of an exact current observed Sales revision. Fixture setup now reports a safe reason when it has no eligible option. Attestation records endpoint provenance only: it does not register a fixture, certify an Agent, start a test, or enable spend.

​

5.665.0 — September 23, 2026 at 3:08 AM UTC

• Uploading to the Library after an earlier session no longer fails with “Could not start the private upload”.
• Responses now show only sent or imported proposals. Uploaded Library files stay in Documents until you save one as a response from its detail view by linking it to a brief.
• In V3 get_delivery, group campaign delivery by a Buyer Account label with dimensions: ["labels.<key>"]. Reports use current campaign and advertiser labels, so relabeling reorganizes historical delivery; no setup change is required.

​

5.664.0 — September 23, 2026 at 2:10 AM UTC

• Buy mobile web display, CTV, and other coherent inventory combinations in one campaign by defining channel groups with save_campaign. Assign every selected product or proposal to a channelGroupId; Interchange creates separate media buys for each group, seller, and settlement currency, and reports delivery by the same group. Presets cover display, online video (OLV), mobile web display, mobile web OLV, and CTV, or you can define a custom group with AdCP channel, property type, device type, and format values.
• Channel groups preserve the buyer’s declared inventory intent, but Interchange does not yet filter discovery, validate selected products against a group, or translate the group into package targeting. Clients must verify seller product evidence before assigning a group. See Channel groups for examples and reporting queries.
• Library now identifies a private upload that did not finish as incomplete and lets you retry the original file, instead of leaving the document at Inspection pending.
• Launching a v3 campaign with a Meta media buy staged without geographic targeting now returns a clear reason (“Meta requires explicit geographic targeting…”) instead of an opaque, unclassified failure with no diagnostic detail.
• When transaction validation finds an active inventory source that is not linked to a registered Agent, Interchange now opens Source diagnostics for that exact source. You can create or attach the Agent there, then retry validation.

​

5.663.0 — September 23, 2026 at 1:46 AM UTC

• Exact document reads return fenced code blocks and inline code again. The search tokenizer strips them so ranking works on prose; reads shared that projection, so request examples were removed from the surface agents use to learn call shapes.
• When you open the Advertisers page, advertiser cards now load campaign counts without downloading every campaign or waiting for every brand logo. A logo that is still loading uses the existing monogram fallback. There is nothing to change on your side.
• Switching accounts now stays inside the application instead of loading the whole page again. The account menu and page content wait for the new account together, which removes the brief flash of the previous account. Wide Advertisers tables also fit the available page width.
• The Sellers page now starts loading seller data immediately even when its optional configuration service is slow. The Connections page also loads its initial data with fewer requests.
• When OAuth authorisation for a sales-agent source fails, the credentials page now shows the specific safe error instead of a generic failure. Interchange also waits until it has observed the Agent before offering implementation registration. Nothing changes on the agent server.
• The Library now opens as a list grouped by category, and the grid view stays one click away.
• build-with-apostra 1.0.3 corrects the instructions so agents take request and response shapes from the tool schemas before writing calls or parsers. It also separates authentication and account readiness from operation authority. This prevents local fixtures from confirming an assumed shape that the server can reject.
• Use the full public Git URL when adding the Apostra developer marketplace in Codex, Claude Code, or another compatible coding agent. Existing installations do not need to change.

​

5.662.0 — September 22, 2026 at 10:54 PM UTC

• The advertiser picker in Murph’s left rail now edits any advertiser directly from its row: hover a row and a pencil opens that advertiser’s settings without changing which advertiser you are working in. From the keyboard, the up and down arrows choose an advertiser and the right arrow edits it. The roster no longer repeats itself as a second list of nav rows under the picker, each row labels its identifier as ID: … rather than showing a bare string, and the picker’s search field drops its magnifying-glass icon. On a storefront, the setup checklist count in the rail header reads 4 of 14 with a chevron instead of underlined text, so it looks like the link into the checklist that it already was.
• Murph now keeps chat available while you use Sellers and Creative Engines, and Creative Engines loads and scrolls correctly. Nothing to change on your side.

​

5.661.1 — September 22, 2026 at 10:31 PM UTC

• The Library now explains what each tab is for and what to do next, and its rail item no longer shows the materials-teaching count.

​

5.660.1 — September 22, 2026 at 8:32 PM UTC

• Advertisers with a confirmed no-country-qualifier brand scope can now manage sellers after selecting at least one channel. Legacy advertisers can classify an unknown country scope once, and the form now explains exactly which setup is required for seller availability.

​

5.660.0 — September 22, 2026 at 8:24 PM UTC

• The released Apostra Platform Terms of Service v4.1 are available at their permanent versioned URL. Existing product terms and acceptance requirements are unchanged.

​

5.659.0 — September 22, 2026 at 8:12 PM UTC

• When you attach a canonical Creative in the Creative Library, Interchange now checks its declared media details against the campaign’s product options. It shows whether the Creative fits, needs named adaptations, or lacks the facts needed to confirm a fit; if no option fits, attachment stops and identifies the closest option and the mismatch. Attachments with insufficient facts proceed unconfirmed. Existing attachments and legacy seller-specific formats do not change. An attachment records the required adaptations but does not create them. The Creative is forwarded as-is for seller review.
• The Add button in the Library is no longer covered by the widget’s collapse control. Header actions in Listing, Murph escalations, Release notes, buyer Catalog list and detail, Run-rate, and Marketing email operations also remain clear of it.

​

5.657.0 — September 22, 2026 at 7:23 PM UTC

• Event (measurement) sources now report managedBy (buyer or seller) and sellerId on every read — via GET /api/v2/buyer/advertisers/:advertiserId/event-sources, sync_event_sources, and the measurement_source noun (search, get, and save_measurement_source in the v3 agent surface). Buyer-created sources report managedBy: "buyer" with sellerId: null. These fields are read-only for now; a later release will populate sellerId once a source is provisioned on a seller account.

​

5.656.1 — September 22, 2026 at 6:11 PM UTC

• Media buy reads now show newly attached and removed creatives immediately instead of returning a stale creative list for up to five minutes.

​

5.656.0 — September 22, 2026 at 5:53 PM UTC

• The agent that sells for your storefront is now called the storefront agent in the docs glossary and concept guide. It was previously documented as the Merchandising Agent; the glossary keeps that name as a pointer so older links and screenshots still make sense. Nothing changes in how the agent works or in your account.

​

5.655.2 — September 22, 2026 at 5:08 PM UTC

• Sales-adapter dispatch now forwards the host-attested AdCP 3.2 negotiation to the underlying adapter tool call. Previously, adapterCallOptions() in the storefront SDK platform adapter propagated candidatePropertyCoverageVersion but silently dropped servedAdcpVersion, so Meta’s 3.2 code branches (and any other adapter’s 3.2 wiring) never executed for storefronts that route through a sales adapter. Direct-dispatch storefronts were already correct; this change closes the sales-adapter parity gap.
• Tidied two pages that sit on their own outside the app shell. The page you land on from a “connect this adapter” link now keeps one frame the whole way through — asking for a key, waiting for the provider, and explaining a dead end all look like the same page rather than three different ones — and its buttons take the standard size. The page for accepting an invitation to an organization uses the standard loading state on its Accept button.
• TikTok wholesale get_products now stamps per-product ext.scope3_execution_readiness (ready_for_execution / setup_required / input_required / selection_required / inventory_unavailable) when the buyer’s TikTok ad account is connected, matching Meta’s existing wholesale behaviour. Buyers on TikTok wholesale can now see at discovery time whether a product will succeed at create_media_buy or requires setup.

​

5.655.1 — September 22, 2026 at 4:42 PM UTC

• The Apostra company page now uses the brand’s uppercase display treatment for its “Better advertising” headline and gives the supporting headings the same visual weight as the copy beneath them.

​

5.655.0 — September 22, 2026 at 4:28 PM UTC

• Tidied the standalone pages that sit outside the app shell. The hosted “add a payment method” page and the media-company confirmation form now use the shared panel, so their headings, spacing, and buttons match every other page. The referral page is now two tabs — make a referral, then see what became of the ones you have made — instead of one long column, and an empty list says so properly rather than trailing a grey sentence. The referral form’s fields now show what to type in them, the company-confirmation form no longer shows an empty country box, and the note about what an AMC account includes now sits with the option it describes.

​

5.654.0 — September 22, 2026 at 4:06 PM UTC

• Account administrators can inspect commercial identity, correct operator domains, look up public branding and follow Seller domain reviews from a text-only v3 MCP client. Identity reads expose saved-brand provenance and verification status in text; identity writes return audit receipts.
• Use identityContract: "confirmed-v1" on operator identity saves and existing advertiser brand corrections. Before replacing an operator identity or advertiser brand, request preview: true. Review the change with the person requesting it, then repeat without preview and with its confirmation token. An unconfirmed replacement in this contract returns an error and saves nothing. Earlier save payloads retain their existing behaviour. Advertiser creation can require public branding with publicBrand: true and a stable idempotency key. See Identity and brands for the calls and verification steps.
• Domain text and public branding do not grant access or prove ownership. Editing or publishing brand.json and completing Buyer AAO OAuth proof are outside this text-only flow; the guide explains the supported human follow-up.

​

5.653.1 — September 22, 2026 at 3:32 PM UTC

• Embedded sales agent 1.45.2: bound update media buy idempotency replay.

​

5.653.0 — September 22, 2026 at 3:23 PM UTC

• Allow a directly authenticated organization account admin to attest a current observed Sales revision’s existing source endpoint without changing the revision or its deployment history.

​

5.652.3 — September 22, 2026 at 3:02 PM UTC

• Codex and Claude Code installation now uses the published Apostra package. The developer guide verifies account access with a read-only call and keeps interactive sign-in separate from a deployed application’s runtime identity.
• Budget changes made while a media buy is waiting for seller approval now update the pending request. If the request cannot be updated, the buyer’s original budget is kept.

​

5.652.2 — September 22, 2026 at 2:35 PM UTC

• Media-buy updates now use a new idempotency key for each submitted change, so a previous failed response cannot be replayed over a later retry with the same budget.

​

5.652.1 — September 22, 2026 at 2:04 PM UTC

• Seller analytics compares buyers side by side again, and a screen reader can reach every part of it
• Buyer signals and recent runs are tables once more — one row per buyer or run, every comparable figure in its own column — so two buyers can be read against each other without scanning down two cards. When the table is wider than the widget, its scroll area is now reachable from the keyboard and announced by name, so the off-screen columns are not stranded.
• Each widget title is a heading, so heading navigation lands on it, and a policy’s own headings sit underneath in order. Metric names read as written names rather than machine keys: the latency tile says “Average processing latency” instead of “Average Processing Latency Ms”.

​

5.652.0 — September 22, 2026 at 1:24 PM UTC

• Murph’s left navigation is rebuilt on the Apostra design system. Sections that showed a collapse chevron now actually collapse — previously several of them drew the chevron but ignored the click. The setup checklist drops its per-section progress fractions, keeping the single “N of M steps” summary at the top, and its rows now read at the same size as the rest of the rail.

​

5.651.3 — September 22, 2026 at 1:01 PM UTC

• Creative Library now explains how to save a draft with a canonical format or a seller product format, and shows when Creative Engines is unavailable.
• save_campaign responses now include flight dates, budget, phase, and seller IDs in the text content so the full campaign state is visible without a separate read. When a campaign launch fails, each per-buy error now includes the exact ESA request payload that was sent, making it easier to confirm what targeting, pricing, and format options were passed. save_media_buy staging calls now also pass debug mode through so diagnostic detail is available when media buy staging fails.
• The standalone pages behind the account menu and the organization settings — your account, account settings, notification preferences, connected apps, user API keys, member management, advertisers, activity, reporting, connections, billing sections and partner fleet — are rebuilt on the Apostra design system. Same pages, same actions, same data; what changes is the typography, spacing and controls, which now match the rest of the product instead of carrying the older look.
• A filter that sits above a list no longer repeats its own name as a label — the chosen value already says what it filters.
• More of the product now uses the new design system: the API keys page, the account page, member management, advertisers, connected apps, notification preferences, organization settings, buyer agents, campaign creative assets, and the “page not found” / “access denied” / error screens. Nothing about how any of them work has changed — the same information, the same actions, the same permissions. A newly created API key is still shown once and never again.

​

5.651.2 — September 22, 2026 at 12:22 PM UTC

• Media buys sent to legacy-format sellers no longer fail when a creative is pinned to a specific format option. After the storefront translates the package’s format options into the seller’s legacy formats, the pinned creative had nothing to match against and the request was rejected with “cannot select a valid creative wire shape … did not provide one unambiguous legacy format reference”. The pin is now matched exactly against the legacy format it was created from, and a creative that narrows to a single legacy format is trafficked under it. A pin that names a format the product does not offer still fails, with a message that says so.

​

5.650.2 — September 22, 2026 at 9:57 AM UTC

• Credential alerts now name the connected platform, explain what has stopped, and link directly to Settings > Connections to reconnect it.

​

5.650.1 — September 22, 2026 at 9:35 AM UTC

• Fresh Demo Storefront chats reach the Teach entry without waiting for unrelated setup navigation.

​

5.650.0 — September 22, 2026 at 9:18 AM UTC

• Buyers can now open the campaign Creative Library composer and assemble a creative from their uploaded assets even when Creative Engines is not enabled. Pick assets, fill format slots, and save the assembly draft without connecting or calling an engine. Generation remains available only to Buyer Accounts with Creative Engines enabled; when it is unavailable, the composer labels those controls and links to setup guidance.

​

5.649.0 — September 22, 2026 at 8:36 AM UTC

• Buyers can now use Nielsen DMA codes or familiar DMA names when saving campaign and media-buy targeting. If a name could mean more than one DMA, the response lists the matching codes to choose from.

​

5.648.0 — September 22, 2026 at 7:09 AM UTC

• Organize advertisers and campaigns with buyer-owned dimensions and labels. Create governed or open dimensions, use the built-in tags dimension, and find labeled or unlabeled records through the V3 MCP tools. Buyer Accounts can have up to 20 dimensions, each dimension up to 200 values, and each advertiser or campaign up to 50 labels. Existing advertisers and campaigns start unlabeled. Nothing to change on your side.

​

5.647.0 — September 22, 2026 at 6:28 AM UTC

• An advertiser can now hold more than one catalog, and your agent can read and write each one directly on the V3 agent surface. A catalog is the AdCP Catalog object: a product feed or other typed list your advertiser sells from. Find them with search(kind: "catalog"), read one with get(kind: "catalog", id, advertiserId: "12345"), and add include: ["items"] to page through its items up to 50 at a time, filtered by id, GTIN, tag, category, keyword contains query, or status: "approved". Create, replace, or archive a catalog with one save_catalog call; it requires an idempotency key, so a retried request returns the original result or recorded failure for 24 hours instead of applying twice. Each catalog reports a health of healthy, syncing, or stale with a plain-language reason. Nothing to change on your side: an advertiser’s existing default catalog keeps working as before.

​

5.646.0 — September 22, 2026 at 5:40 AM UTC

• When you assemble a creative in the Library, products now update automatically while sellers respond and are easier to search and compare. Product rows show the declared format requirements and explain when an asset does not fit, so you can upload another file or review all available products before you save.

​

5.645.0 — September 22, 2026 at 5:15 AM UTC

• Buyers can now turn an uploaded file into a creative by naming its format before choosing a product.

​

5.644.3 — September 22, 2026 at 3:36 AM UTC

• get { kind: "advertiser" } now returns preferredTimezone alongside reportingTimezoneLocked, matching save_advertiser and search. Previously, a buyer reading an advertiser via get could see that its reporting timezone was locked but not what it was locked to.

​

5.644.2 — September 22, 2026 at 2:09 AM UTC

• Fixes AI-9720: buyers can recover from cancelled or stale media-buy updates without a stranded pending change blocking their next update.

​

5.644.1 — September 22, 2026 at 12:15 AM UTC

• save_campaign’s launch step now shows the actual reason a media buy failed to launch when that reason is safe, locally-generated text from a first-party ad-platform adapter (e.g. Meta requiring a Pixel/Dataset for a Sales campaign) - previously the chat response collapsed every failure to a bare execution failed (CODE, recovery) with no further detail, even when the underlying cause was already known and actionable. A genuine remote sales agent’s own error text is unaffected and continues to stay out of the rendered response, unchanged from today’s behavior.
• Let a verified domain user claim an archived Seller account, become an admin, and restore its existing Storefront. This works for every archived Storefront, including accounts that already have an administrator, while keeping ambiguous domains and public email providers out of the recovery path.

​

5.644.0 — September 21, 2026 at 11:42 PM UTC

• Upload copy now says file, not creative, and clarifies Library file types, audio availability, campaign counts, and Catalogs so buyers can find and use their creative files.
• Pending invitations in the account menu now open the organization you were invited to, even when you are working in a different organization. Sign-up links for invitations that are no longer available now explain the problem before account creation instead of asking you to join an unnamed organization.

​

5.643.0 — September 21, 2026 at 10:37 PM UTC

• Seller signup now describes storefront setup more clearly and labels the setup action directly. No action is needed for existing accounts.

​

5.642.3 — September 21, 2026 at 10:22 PM UTC

• Account choices use the available row width during sign-up when fewer than three options are available.
• Adapter errors on create_media_buy, update_media_buy, sync_creatives, and delivery reads (get_media_buy_delivery, get_media_buys) now return a classified error message and code instead of the ad platform’s raw response text. This closes an inconsistent gap where Google, LinkedIn, Reddit, Criteo, CitrusAd, Flashtalking, OpenAI Ads, UniversalAds, and Pinterest passed their provider’s unfiltered error text straight through on every operation, and where sync_creatives could leak raw upstream diagnostics in a creative’s errors[] entry regardless of platform. code/reason remain the same stable, machine-actionable classification every integration already keys on; the platform’s own explanation (when it designed that text for external display, as Meta does) is now surfaced consistently instead of only in a couple of hardcoded scenarios.

​

5.642.1 — September 21, 2026 at 8:43 PM UTC

• Campaigns Pages pass plain advertiser names to their widgets, and browser links open the advertiser’s workspace.

​

5.642.0 — September 21, 2026 at 8:16 PM UTC

• On the buyer agents list, the link to the documentation moves into the page header beside Add agent, so it stays reachable when the list is empty or when you are signed in through a session that cannot manage agents — the states where it was previously hidden. Each agent row is now a card, and its status carries a colour that matches what the state means for that agent’s work.

​

5.640.3 — September 21, 2026 at 7:04 PM UTC

• The buyer agent list and agent detail pages are rebuilt on the Apostra design system. Same routes, same actions, same data — what changes is the presentation and some of the wording.
• Each tab’s sections no longer draw a panel inside the page’s own panel, so a section reads as a band of the page rather than a nested card. A credential is one row that names itself and carries its own Rotate and Revoke actions. On Activity, “Platform state changes” and “Administration activity” say in plain language what separates them: what the platform recorded on its own, versus what someone on your team did and who they were. A limitation under “Current limitations” now reads as a warning when there is something to act on, and as an empty state when the connection simply has not reported anything yet.

​

5.640.0 — September 21, 2026 at 5:47 PM UTC

• Branding & distribution now opens Listing even when the browser had cached an older setup route. Publisher domains entered in the Property Roster are saved directly; invalid entries stay unsaved, and a failed save keeps your draft so you can try again.

​

5.638.0 — September 21, 2026 at 4:40 PM UTC

• Selecting the required-step count in the setup rail now opens the full Seller Setup checklist. The rail labels the final validation separately, so its result no longer looks like the full checklist.

​

5.637.0 — September 21, 2026 at 3:51 PM UTC

• The Creative Library now leads with Add creative. Pick an image or video file; when the upload finishes, the Library opens the creative composer (campaign Library) or the inline creator (advertiser Library) with that file in the first slot, and you complete the creative with a name, click-through URL, and format. Campaigns that declare Audio :30 also accept audio. Upload (add a file only) and New creative (start from a file already in the Library) are under More. Nothing to change on your side.
• Media buys sent to sellers that still speak legacy creative formats no longer fail when the seller lists more than one legacy format for the same display size, for example display_html with 300x250 dimensions next to display_300x250_html. The creative is now matched on its own declared dimensions and, when two legacy formats impose the same constraints, trafficked under the seller’s fixed-size format. Previously the request was rejected with “cannot select a valid creative wire shape … the seller advertised 2 legacy refs”.
• Text across the product is easier to read. Interface copy, labels, and table data now set in Public Sans, a typeface drawn for screen text at small sizes, while headings keep the GT Planar brand face. Small text reads clearer without anything moving or changing size, and labels separate more cleanly from the content around them.
• In-chat widgets also load less: each one carries about 29 KB less font data than before.

​

5.636.0 — September 21, 2026 at 3:05 PM UTC

• save_media_buy on the v3 buyer surface now accepts products[].pixelId, so Meta Sales campaigns can supply the required Pixel/Dataset ID for conversion tracking. Previously the field had no way to reach v3, so launching a Meta Sales (or a Traffic campaign optimizing toward a pixel-based conversion goal) failed with a bare INVALID_REQUEST naming no cause. This brings the field over from the existing v2 create_media_buys surface unchanged - same name, same “no auto-select” behavior.
• Storefront transaction readiness now stays current while product catalogues are syncing.
• Find the right advertiser faster by searching the workspace selector by name or advertiser ID. Advertiser IDs now appear alongside names, making similar or duplicate names easy to distinguish.

​

5.635.0 — September 21, 2026 at 2:47 PM UTC

• After uploading a creative asset, see its preview, name, media type, size, and saved Library tags, then open that exact advertiser-scoped Library asset.

​

5.632.0 — September 21, 2026 at 12:54 PM UTC

• Widget navigation now keeps text readable while buttons change state. Nothing changes on your side.
• Interactive buyer Pages now accept Claude’s external-host authorization when Claude forwards the same signed Page capability in both request metadata and the reserved app argument. Conflicting capabilities and first-party proxy requests remain rejected.
• Canonical image requests now reach the configured creative generator with their validated dimensions. Existing valid legacy format selectors continue to work; malformed or ambiguous selectors are rejected before generation.

​

5.630.0 — September 21, 2026 at 11:32 AM UTC

• Select or drop up to 25 creative files into the upload Task and follow them in one progress list. The Task uploads three files at a time, and a failed file retries on its own without touching the ones that finished. Enter Library tags once for the whole batch, or change a queued file’s tags before its upload starts. Per-file size limits are unchanged, and a batch adds files to the Library; it does not create Creatives. Nothing to change on your side.

​

5.628.1 — September 21, 2026 at 10:45 AM UTC

• Murph can now follow an exact Skill ID without searching for it first.
• Library and Product Marketing uploads now accept a valid short-lived private upload reservation when the seller’s browser clock is slightly behind the server. Server reservation failures remain distinct from an unsafe upload capability, and overlong capabilities still fail closed.

​

5.628.0 — September 21, 2026 at 10:14 AM UTC

• Interactive buyer Pages (Creative Library, Advertisers, Campaigns) now load in Claude and other MCP-app hosts that run the widget on a separate MCP session from the chat. Opening a Page returned “authorization could not be verified” on its first read in those hosts because the Page’s signed capability was bound to the session that launched it; it is now verified against its own signed session when it arrives through the external-host transport, with every other check unchanged.
• Embedded sales agent 1.45.1: create bookable FreeWheel placements.

​

5.625.0 — September 21, 2026 at 8:41 AM UTC

• Creating a Meta media buy with postal/zip-code targeting for most countries (United States, United Kingdom, Canada, Germany, Switzerland, Austria, France, Australia, Brazil, India) now succeeds instead of failing after the ad set was already created on Meta.
• Buyer agents can open the Creative composer from the Creative Library’s new campaign-scoped composer lens, including a browser hand-off for hosts without an embedded widget surface.

​

5.623.1 — September 21, 2026 at 6:57 AM UTC

• Fixed request_proposals returning a bare, unexplained SELLER_ERROR for a built-in storefront adapter (e.g. Meta) rejecting a request as invalid — for example, a brief that names an unsupported placement exclusion like “Threads” or “Audience Network”. The adapter’s specific, actionable error code and message now reach the response instead of being discarded.

​

5.623.0 — September 21, 2026 at 6:03 AM UTC

• Third-party sales-agent observations now remain current when two refreshes reach the same connection at once. This keeps implementation changes and freshness records available for certification. Nothing needs to change on your side.
• Murph can now read an exact versioned Skill before continuing a workflow.

​

5.621.0 — September 21, 2026 at 3:08 AM UTC

• Buyers can now open a slot-based Creative composer from a campaign’s Creative Library. Save drafts to an existing Creative Session, preview slot changes as you work, and use host chat to request copy or other changes.

​

5.620.0 — September 21, 2026 at 2:43 AM UTC

• Meta discover_products and create_media_buy now honor a buyer’s request to target Facebook/Instagram Stories and/or Reels alongside Feed. Previously, any brief or targeting_overlay.placement_selection naming Stories or Reels silently collapsed to Feed only. A mixed request — Feed together with Stories and/or Reels — is now honored in full. targeting_overlay.placement_selection is also now read and honored at create_media_buy time (previously rejected outright as an unsupported targeting dimension) and can override the discovery-time snapshot, including an explicit mode: "default" to revert to Advantage+ Placements.
• Requesting only Stories and/or Reels with no Feed in the mix remains unavailable on every account today: discovery now returns no products for that specific request rather than one it can’t actually deliver.
• Brief-text placement parsing also now fails closed on an explicit exclusion (e.g. “excluding Feeds, only Stories and Reels”) instead of matching the excluded surface’s keyword and selecting it anyway.

​

5.618.0 — September 21, 2026 at 12:16 AM UTC

• Organization administrators can approve, suspend, reactivate, or revoke one advertiser’s self-serve admission from the Advertisers page. These actions do not change capabilities, invitations, billing or payment authority, organization membership, or campaign execution.

​

5.617.0 — September 20, 2026 at 11:07 PM UTC

• The Library now identifies Responses as durable saved materials and shows each saved version’s date and current brief. Opening Responses does not regenerate an answer from the documents visible in your Library. Nothing to change on your side.

​

5.616.1 — September 20, 2026 at 10:29 PM UTC

• You can now see and manage a brief’s linked response from either the Demand Inbox or the Library. Choose an eligible saved response or import a historical brief without losing the current pairing record. Add files in the Library before linking them from the Demand Inbox. Nothing to change on your side.

​

5.615.0 — September 20, 2026 at 9:12 PM UTC

• MP4 upload preparation now finishes within the upload Task’s request window. Storage or signing timeouts and confirmed database aborts return a retryable error without signed upload details; an unconfirmed database outcome says not to retry. JPEG, PNG, WAV, and MP3 uploads are unchanged.
• Opening the Campaigns Page from a host that cannot show interactive pages, such as Claude Code or a plain MCP client, now returns an “Open in the browser” link that opens the same Campaigns Page in the Interchange chat for that advertiser, focused on the launched campaign when there was one. The link is also available as openInBrowserUrl in the structured result. Following a Campaigns Page link in the browser now opens the Page once, with the list filters the link carries, instead of minting a second launch that was discarded on arrival.

​

5.613.0 — September 20, 2026 at 7:39 PM UTC

• In the Library Page, sellers can assign a document category and filter documents by category alongside file type, search, and grouping. Existing documents remain Uncategorized until a seller chooses a category. Rate-card and policy documents can remain source Materials, but their canonical facts remain governed by Rate Cards and AI Business Rules. Categorising a document does not make its units reusable.

​

5.612.2 — September 20, 2026 at 7:04 PM UTC

• Existing storefronts with audited pre-split sales-agent sources can continue transacting without repeating onboarding approval.

​

5.612.0 — September 20, 2026 at 6:24 PM UTC

• Library now explains reuse per page, slide, or sheet, shows why each unavailable control is disabled, and enables eligible units as soon as inspection finishes. Keep buyer-specific content off and current prices in Rate Card.

​

5.611.0 — September 20, 2026 at 6:07 PM UTC

• Buyers can now see connected catalog feeds in the advertiser Creative Library, including item counts, sync health, and links to manage a feed.
• An empty Material Library links to a fictional publisher onboarding pack with a short, goal-based starter checklist. The guide distinguishes included examples from missing proof material and keeps pricing and policy in their owning flows. Opening or downloading the pack never adds account data, and completing the checklist proves neither seller readiness nor production completeness.

​

5.608.0 — September 20, 2026 at 4:09 PM UTC

• You can open the Create Agent task from the Agents page. Your existing administrator permissions still apply.
• Keep navigation to another account workspace from returning you to a Murph conversation that is no longer available.

​

5.604.0 — September 20, 2026 at 2:11 PM UTC

• Set which campaigns a Library creative runs on from either side of the relationship: save_creative now accepts campaignIds, the full set of campaigns for an advertiser creative, and save_campaign accepts creativeIds, the full set of creatives on a campaign. An explicit list replaces membership, so a missing id detaches; omitting the field leaves membership unchanged. Attaching checks the campaign’s sellers and fails, naming them, when none accepts the creative’s format. Both fields set the same membership the Creative Library picker sets, and a member creative is delivered on every media buy of the campaign whose products accept its format.

​

5.601.2 — September 20, 2026 at 11:38 AM UTC

• Show both Enterprise seller choices during signup while keeping them outside the selectable public Rate Card plans.

​

5.601.0 — September 20, 2026 at 10:28 AM UTC

• Murph now states that you are interacting with an AI agent on your first interaction. Once delivered, the notice applies across supported channels. This does not change what Murph can access or do.
• Every Apostra sign-up path now stays in the Apostra interface, including organization invitations, buyer qualification, partner registration, and Storefront plan setup. Nothing changes for existing accounts.
• Murph in Slack now clears its working status after posting a completed response. Nothing to change on your side.

​

5.600.0 — September 20, 2026 at 9:36 AM UTC

• Correct the historical identity used to restore readiness for one existing third-party sales source. New sources still need the normal validation.
• Your enrolled advertiser viewers can now list Campaign summaries for the advertiser assigned to them. Their access is read-only and does not extend to another advertiser.

​

5.599.2 — September 20, 2026 at 9:24 AM UTC

• Live seller workspaces now open analytics even when setup status is temporarily unavailable. Nothing to change on your side.

​

5.598.1 — September 20, 2026 at 8:29 AM UTC

• Apostra-branded sign-in pages now show the full Apostra wordmark with dark lettering.

​

5.597.0 — September 20, 2026 at 2:38 AM UTC

• Opening a creative in the Creative Library now offers “Attach to a campaign”. The picker lists the advertiser’s campaigns with their status, flight and budget, and says for each one how many of its sellers accept this creative’s format and which sellers do not and why. Campaigns whose flight has ended, and campaigns where no seller accepts the format, are shown with the reason instead of an Attach button. Attaching adds the creative to the campaign so its sellers review it; campaigns it already belongs to are marked Attached.
• An existing third-party sales source that was serving before readiness enforcement no longer remains blocked because its historical transaction evidence was missed. New sources still need the normal validation.

​

5.596.0 — September 20, 2026 at 1:00 AM UTC

• Saving coaching in a practice proposal now reruns the same buyer brief and opens the revised response beside the original.
• When a seller-managed relationship needs missing advertiser information, Sellers now pauses the advertiser view with one setup action instead of repeating it on every seller card. Direct ad platforms do not trigger this blocker. Nothing changes for API integrations.

​

5.593.1 — September 19, 2026 at 9:18 PM UTC

• Campaign Creative links now open the advertiser Creative Library with the campaign already selected, while keeping Creative requirements, upload, create, attach, and preview actions together.
• Seller workspaces now open directly into setup or analytics without briefly showing the Merchandising Agent introduction. Nothing to change on your side.

​

5.593.0 — September 19, 2026 at 8:30 PM UTC

• Buyer access requests now use Apostra’s responsive sign-up experience when the new product brand is enabled. The journey keeps its existing qualification and routing behaviour while making conditional questions, validation, progress and outcomes easier to follow on desktop and mobile.
• Buyer access requests now distinguish direct Apostra use, a buyer’s own AI agent, and a preferred AI chat. Buyers can select Claude, ChatGPT, Copilot, or name another chat, or say that they are still undecided. Pilot countries and channels appear in the intended priority order, Social requests can proceed regardless of country, and New Zealand is no longer treated as a pilot market. Buyers who select Social or a pilot country receive the same fit confirmation at any timing. The nurture message now explains that supply is still being onboarded in the selected markets.
• Managed MP4 upload is now generally available and no longer depends on a separate account rollout switch. It remains subject to authenticated advertiser access and managed-video service availability. Managed audio remains an alpha behind its existing account rollout gate and independently dark production infrastructure.

​

5.592.0 — September 19, 2026 at 7:53 PM UTC

• Buyers can associate a completed advertiser Creative with an authorised campaign through save_creative before seller package assignment or provider delivery exists. The saved Creative read now reports durable campaign membership separately from delivery state.

​

5.589.0 — September 19, 2026 at 3:36 PM UTC

• Agent Page can now forward a protected technical certification evaluation request to Murph. A queued request is not a completed evaluation, certification, or client authorization.

​

5.588.0 — September 19, 2026 at 3:24 PM UTC

• During an active Demo Storefront evaluation, Product Marketing now names the selected file and distinguishes upload, processing, ready-to-review and failure states. Each state gives the seller one clear next action, while ordinary Product Marketing and the existing private upload flow remain unchanged.
• Opening the Creative Library from a host that cannot show interactive pages, such as Claude Code or a plain MCP client, now returns an “Open in the browser” link that opens the same Library in the Interchange chat for that advertiser. The link is also in the structured result as openInBrowserUrl.

​

5.587.0 — September 19, 2026 at 2:58 PM UTC

• Stop sending sellerPractice and sellerPracticeAction in Murph chat requests. Seller Practice is no longer available, and requests containing either field now return a validation error instead of opening an ordinary chat. Other seller chat requests work as before.

​

5.586.2 — September 19, 2026 at 2:32 PM UTC

• During an active Demo Storefront evaluation, Product Marketing now starts with a clearly labelled file upload and explains the path from adding seller material to reviewing offers and testing a buyer brief. Webpage import and synthetic practice remain available as secondary choices. Ordinary seller Product Marketing and upload handling do not change.

​

5.585.1 — September 19, 2026 at 1:33 PM UTC

• Practice proposal reruns now apply the latest saved coaching note while keeping the buyer brief, products, prices, sources, and claims unchanged.

​

5.584.1 — September 19, 2026 at 12:49 PM UTC

• The fixed synthetic practice proposal now uses only the seeded Demo catalogue and its matching synthetic teaching material. Ordinary media-kit uploads and Library examples stay out.

​

5.584.0 — September 19, 2026 at 12:12 PM UTC

• Opening a creative in the Creative Library now shows where it stands with each seller. A Seller approval table lists every seller the creative was sent to with Approved, Reviewing, Changes requested, Rejected or Sync failed, the date, and the seller’s note when it rejected the creative or asked for changes, and the header sums it up as “Approved n of m” plus how many need attention. A collapsed Destination row shows the click URL, the URL as delivered, and which UTM additions came from the advertiser, campaign or creative. A creative not yet sent to any seller says so.

​

5.583.2 — September 19, 2026 at 12:07 PM UTC

• Slack actions that need your approval now say “Approval needed” while they wait, instead of reporting that the call failed. The action, approval decision, and final result do not change.

​

5.583.1 — September 19, 2026 at 11:35 AM UTC

• Library previews now distinguish pending, failed, unsupported, unavailable, and ready files, and older PDF or PowerPoint uploads can be retried from the open document without reloading the Library.

​

5.582.1 — September 19, 2026 at 10:00 AM UTC

• Inventory-source diagnostics now retain recorded health timestamps so an older error is not presented as a new provider check or current transaction outcome.
• Time-bounded Seller beta profiles now include the complete feature package they name. Enrolled sellers no longer need a second set of matching entitlement grants, and the profile’s expiry still returns the account to its safe fallback.

​

5.582.0 — September 19, 2026 at 9:40 AM UTC

• The Creative Library page is easier to scan. Creatives and Assets are tabs with counts, one row holds search and the Shelf, Format, Source and Role filters (Media for assets), and each card shows its state alongside role, campaign and reuse badges. Opening a creative or asset shows a detail with About, Used in, Where it lives and a collapsed technical record, and “New creative” opens the composer directly. The same layout fits the narrower width chat hosts give a widget.

​

5.581.3 — September 19, 2026 at 9:26 AM UTC

• Buyer briefs now open as compact cards with the complete plan, targeting, measurement, governance, provenance, and exact request available in one disclosure. Existing brief records remain readable, and sellers do not need to change how they work.

​

5.581.2 — September 19, 2026 at 9:08 AM UTC

• V3 archive is now visibility-only: campaigns and media buys keep their lifecycle phase, and restoring a canceled campaign keeps it canceled. Campaign archive refuses while executable media buys remain, and legacy archived media buys are readable.
• Buyer account reads now keep a linked seller account visible when its connection is disabled or archived, so it can be reconnected. Partner-scoped reads now include direct seller-account links.

​

5.581.1 — September 19, 2026 at 8:37 AM UTC

• In Advertisers, clients admitted for self-service now show their advertiser access state instead of a missing sponsorship warning. These rows remain read-only; access readiness does not grant Campaign or payment authority. Nothing to change on your side.

​

5.580.2 — September 19, 2026 at 6:29 AM UTC

• Sellers in the Product Marketing beta can complete a teaching rehearsal from their training material to a held-out buyer brief, a coached follow-up proposal, and its comparison.

​

5.580.1 — September 19, 2026 at 5:54 AM UTC

• Record a completed, cleaned own-supply transaction as the matching technical-certification assertion only after the platform verifies its immutable fixture and implementation binding.

​

5.580.0 — September 19, 2026 at 1:37 AM UTC

• Show the confirmed sample booking, synthetic source, and delivered impressions in Demo Storefront Media buys.

​

5.579.3 — September 19, 2026 at 12:08 AM UTC

• Product searches that exceed the quick wait now show the products already returned and can continue the same search without starting a replacement. Nothing needs to change on your side.
• Active Demo Storefronts now show a synthetic, non-commercial Plan & billing state without changing ordinary billing setup.

​

5.579.2 — September 18, 2026 at 11:18 PM UTC

• Synthetic inventory sources in an active Demo Storefront now show all nine required setup steps as ready. Source Diagnostics identifies them as local synthetic recipes and no longer asks you to run vendor connection checks that do not apply. Ordinary inventory sources keep their existing live-source checks.
• Fixed an issue where buyer-agent principal routes were inaccessible for organizations whose WorkOS binding exists but whose internal organization record has not been populated. The registry key for buyer-agent principals is now derived from the customer ID directly, which is always present, rather than from the optional organization FK.

​

5.579.1 — September 18, 2026 at 10:06 PM UTC

• When you open Listing in an active Demo Storefront, its readiness now agrees with Seller Setup: Identity and What you do are the two required details. Marketplace publication and Public distribution remain available as optional choices. Nothing changes for ordinary Storefronts, and there is nothing to change on your side.
• Pages on app.apostra.com now show the Apostra name and favicon in browser tabs. Apostra’s staging app and creative-preview domains use the orange Apostra symbol to stay visually distinct. Other domains are unchanged, and no action is required.

​

5.579.0 — September 18, 2026 at 9:17 PM UTC

• Media Companies can now create a sandbox advertiser from Advertisers or Campaigns and switch into it immediately. Accounts enrolled for live campaign management can explicitly choose Live; other accounts see Sandbox only.

​

5.578.2 — September 18, 2026 at 8:58 PM UTC

• Selecting a Demo Storefront inventory source now replaces the previous source Page and opens the source named in the setup checklist.
• Demo Storefront now shows its versioned sample buyer brief and booked outcome in Demand while the demo lease is active.

​

5.577.1 — September 18, 2026 at 7:56 PM UTC

• Readable scanned faxes now reach your storefront agent when lower scan quality makes text recognition less certain. Nothing to change on your side.

​

5.577.0 — September 18, 2026 at 7:36 PM UTC

• Demo Storefronts now create and restore a synthetic inventory source during explicit creation and reset, so Inventory and Signals can be explored without connecting a live ad server.

​

5.576.0 — September 18, 2026 at 7:22 PM UTC

• Click-URL parameters now have one home. The utmConfig you set on an advertiser or campaign and the tracking.macroAdditions you set through V3 are the same parameters, resolved advertiser → campaign → creative with the nearest value winning, and applied once when a creative is synced to a seller. A key already in your click-through URL is never overwritten. New advertisers start with no parameters; advertisers created earlier keep the six utm_* entries Scope3 used to add for them, and you can edit or clear those like any other entry. {PACKAGE_ID} is accepted alongside the canonical AdCP macros. Parameter keys start with a letter or digit and use URL query-key characters (max 100), the same rule for utmConfig and macroAdditions.

​

5.575.0 — September 18, 2026 at 6:55 PM UTC

• Embedded sales agent 1.45.0: add synthetic mock inventory selectors, add synthetic mock signal catalog, negotiate FreeWheel booking actions as XML, preserve published format option ids, update AnyIO past known vulnerabilities.

​

5.574.1 — September 18, 2026 at 6:33 PM UTC

• Keyboard focus on a clickable row in an in-chat widget now draws its focus outline inside the row, so the outline is no longer sheared off at the left and right edges when the list scrolls. Advertiser rows on the All advertisers widget also sit flush against each other instead of being separated by a gap.

​

5.574.0 — September 18, 2026 at 6:05 PM UTC

• Buyers on MANAGED storefronts can now request production account linkages, not only sandbox ones. POST /api/v2/buyer/storefront-accounts/sync and the sync_buyer_storefront_accounts tool accept entries without sandbox: true, and the request lands in the seller’s approval queue as a pending account. Once the seller accepts it and maps the account to a source, creative sync on that storefront stops failing with MANAGED_ACCOUNT_LINKAGE_REQUIRED.
• A production entry must use your confirmed buyer operator domain as operator. Any other domain returns HTTP 403 ACCESS_DENIED (details.reason: "operator_identity_mismatch"); an account without a confirmed identity gets the existing BUYER_SETUP_REQUIRED response. Sandbox entries are unchanged and still accept any operator. billing remains agent.
• Sellers see no protocol or UI change. Production requests arrive through the same pending-review queue and decision endpoints as any inbound sync_accounts.
• Monetization: no billable surface, no packaging change.
• Rollout - gate: none, atomic launch. The operator check is the only new refusal and it fails closed. Kill switch is apps/api/src/routes/v2/buyer-accounts.routes.ts (unmount) or re-adding the sandbox literal in apps/api/src/schemas/v2/buyer-accounts.schema.ts. Release check: after deploy, a production dry_run: true request from a buyer with a confirmed identity returns action: created, and one naming another operator returns 403; adoption watch is the count of non-sandbox storefront-accounts/sync requests per customer via the standard v2 REST metric labels.

​

5.573.0 — September 18, 2026 at 5:36 PM UTC

• Demo Storefront approval queues now start with one synthetic media-buy request and one synthetic creative review. Reset restores both pending items, while expiration or deletion removes their synthetic approval data.

​

5.571.0 — September 18, 2026 at 4:15 PM UTC

• In save_campaign, set brief or flight to null to clear the saved value. Omit either field to leave it unchanged. Campaign pauses now use the same audited path as the API.

​

5.570.0 — September 18, 2026 at 3:46 PM UTC

• Claimed agent owners can request a protected certification evaluation for the current implementation when an approved fixture and immutable evaluation template already exist. The request does not run a provider test or create certification evidence.
• Show a claimed agent owner when protected certification preparation cannot continue, rather than scheduling the same permanent failure again.

​

5.568.1 — September 18, 2026 at 2:46 PM UTC

• Platform administrators can now choose Listing, Listing + Distribution, Merchandising, or Merchandising + Distribution capabilities when creating a Demo Storefront. New and existing demos default to the full Merchandising + Distribution experience without changing the organization’s paid plan. Setup progress also counts only required work, while recommended setup remains visible.

​

5.568.0 — September 18, 2026 at 2:07 PM UTC

• Buyer agents can now create, inspect, update, and archive advertiser event sources through V3. Each save returns installation guidance and keeps registration separate from proof that conversion events are flowing.
• Buyer agents can also define generic click-URL macro additions on advertisers, campaigns, and creatives. Campaign values override advertiser defaults, creative values override both, and null suppresses an inherited parameter without changing the authored click URL.
• Murph’s guided Storefront rehearsal now explains the purpose, current step, next action, and expected result across Teach, Confirm, Test, Inspect, and Coach. It uses the same seller workflow and actions as self-guided practice. Media-kit upload is discoverable, teaching still requires explicit candidate confirmation, and coaching still records immediately on the immutable turn.

​

5.567.0 — September 18, 2026 at 12:26 PM UTC

• Advertiser guidance now explains how measurement evidence stays in advertiser scope across sellers and distinguishes Apostra’s standard 0% media-fee model from percentage-based terms in existing agreements.
• Reject a media buy when its composed product points to a creative-format option that the source product has since removed, renamed, or changed. The storefront now asks the buyer to refresh the product before approval or forwarding instead of sending a request the source will reject.

​

5.565.0 — September 18, 2026 at 11:06 AM UTC

• For organizations enrolled in IU plan selection, seller choices now appear under Listing and Merchandising. Choose Get in touch for help with a plan or a private offer, even when public plans are available. A billing administrator can send the request and, when tracking is available, follow it in Your requests. Stalled help requests now recover instead of leaving plan actions disabled. During signup, finish creating your account, then send the request from Plan & Billing. Your plan, prices and access stay the same until you separately accept an offer.

​

5.563.0 — September 18, 2026 at 9:23 AM UTC

• Embedded sales agent 1.44.0: add FreeWheel inventory-package targeting and ad-product defaults, support FreeWheel direct ad-unit selection, harden FreeWheel booking state reconciliation, keep AdsWizz package delivery stable across renames, persist and book FreeWheel insertion orders, respect FreeWheel insertion-order booking state, traffic AdsWizz audio impression trackers, validate FreeWheel VAST renditions after create.

​

5.562.0 — September 18, 2026 at 8:47 AM UTC

• The Merchandising Agent interview now stays open when you enter the seller workspace, so Seller Analytics no longer replaces the buyer-practice entry.

​

5.561.0 — September 18, 2026 at 8:04 AM UTC

• Installable messaging apps are now available as an early-access customer feature: your team can talk to Murph from Slack, Microsoft Teams, Discord, or WhatsApp. On a seller’s Listing page, Distribution lists each as a destination with two ways in; seller administrators manage the same apps from Settings → Messaging apps. Use the Interchange app is the shared, one-click option with nothing to configure. Slack installs from the tab once Interchange’s Slack app is publicly available; shared Microsoft Teams and Discord apps are not available yet. Use your own app connects a Microsoft Teams, Discord, or WhatsApp app you created with the provider. The tab says what each provider needs, lists the apps already connected with their install locations and linked people, and opens the secure setup pane (Settings → Messaging apps) where you manage credentials, approved install locations, and the links between provider identities and Interchange members. WhatsApp replies only when a linked member messages the registered business number inside Meta’s user-initiated service window; it never starts a conversation or sends template notifications.
• Branded apps are early access for enrolled accounts. Enrollment controls who can set up and administer them; it does not stop an app that is already active. To stop new conversations, suspend a location or retire the branded app. Nothing changes for storefront ranking, readiness, or buying workflows, and there is no new plan, entitlement, or usage charge. Conversations from Microsoft Teams, Discord, and WhatsApp never count toward usage or billing; they are recorded for telemetry only.
• Team members who already use Murph need no setup of their own. Once an administrator has connected an app and a member’s Teams, Discord, or WhatsApp identity is linked to their active Interchange membership, that member can ask Murph the same questions from an approved Teams or Discord chat, or by replying on WhatsApp. Members never handle provider credentials or installations.

​

5.560.5 — September 18, 2026 at 6:57 AM UTC

• Creative reads now report a successful sync only when every current seller link succeeded. Failed links include the seller’s rejection reason when available, so buyers can see that a creative was not delivered and why. Nothing to change on your side.

​

5.560.3 — September 18, 2026 at 5:59 AM UTC

• Enterprise offers now reject unsupported campaign management, custom inventory onboarding and co-marketing commitments before they become commercial terms. No action is required for offers that do not include those commitments.

​

5.559.0 — September 18, 2026 at 4:29 AM UTC

• Files from your existing creatives can appear in the Creative Library Files panel as reusable assets after your team runs the backfill.
• Publisher practice now saves the proposal and its private practice plan together. If the practice conversation changes while a proposal is being created or extended, no partial proposal is retained and the seller can retry from the current conversation.

​

5.558.0 — September 18, 2026 at 3:34 AM UTC

• Sales Agent providers can complete the confirmed no-spend media-buy step before certification or Storefront publication setup is complete. The exception is limited to the temporary certification source; live transactions remain gated.
• Buyers enrolled in the Creative Engines alpha can find a versioned guide that helps their agent create and refine campaign creatives without losing the output they selected or approved. The guide covers secure connection, advertiser mapping, the funding that applies to the request, named-parent refinement, exact-output approval and recovery after an interrupted request.
• Using the guide requires its two Creative Session tools, a supported engine capability and connection, any locked reference required by the selected engine, funding and an authorised quote before generation can be dispatched. It does not choose funding or prices, approve a creative for a seller, or launch a campaign.

​

5.557.1 — September 18, 2026 at 2:55 AM UTC

• Buyer agents now see that Creative search requires exactly one advertiser or campaign owner before calling the tool. Successful searches repeat the effective scope and filters in text and structured output, including the three promoted filter meanings: omitted for all visible results, true for the reusable shelf, and false for non-promoted results.

​

5.557.0 — September 18, 2026 at 2:49 AM UTC

• Completed Creative uploads now leave a durable conversation receipt in Claude, ChatGPT, and Interchange with the available saved metadata and verified video facts. Advertiser uploads include their reusable Library asset ID. A legacy provider upload without one includes its digest only as byte identity for the receipt, not as a value that can be saved, adopted, or attached later. The receipt does not create or attach a Creative, sync data, contact a provider, or deliver media, and the upload Task stays open for retry if the host cannot record it. Existing assets need no changes.
• No changes are required for existing V3 save_creative callers: omitting mode preserves complete-save behavior.
• You can now save a partial advertiser-scoped Creative with mode: "draft", then replace its entire submitted authored and slot state by sending the Creative’s current stateRevision as expectedRevision. Use mode: "complete" on the same Creative once every required media, authored, and repeat-group slot validates. Creative reads expose state and the authoritative whole-state stateRevision, while the existing opaque preview revision remains compatible and revision-bound previews continue to use the Interchange render frame. These advertiser-scoped draft and completion saves do not attach the Creative to a campaign or contact a provider.

​

5.556.4 — September 18, 2026 at 2:19 AM UTC

• Opening reviewer access now recovers automatically when an earlier login setup attempt left cleanup unfinished.

​

5.556.1 — September 18, 2026 at 1:22 AM UTC

• When you choose another Murph conversation while an earlier one is still loading, Murph now keeps the conversation you chose last.

​

5.555.0 — September 17, 2026 at 11:41 PM UTC

• When released, buyers already enrolled in the Creative Engines alpha will be able to save a campaign creative brief, generate variants, refine a named variant with feedback, and finalise the exact output they approve through V3 MCP.
• To use these actions, save a brief with save_creative_session, then explicitly request generation with generate_variants. Saving does not start generation. A saved engine connection and the existing account access are required. If a generation request is uncertain, recovery checks the original request without silently starting a replacement. Provider account and funding requirements still apply; finalising creative does not approve it for a seller or launch a campaign.

​

5.554.1 — September 17, 2026 at 11:16 PM UTC

• Fixed TikTok video creatives failing to sync to campaigns. Uploaded videos were being rejected every time due to a response-parsing bug in how we read TikTok’s upload confirmation; video creatives now sync and attach correctly.

​

5.554.0 — September 17, 2026 at 11:10 PM UTC

• The Creative Library’s Files and compose panel now loads the product picker in the Interchange web app. Previously the panel showed “Products unavailable” there, so you could not choose a product or its canonical formats; in Claude and ChatGPT the picker already worked.

​

5.553.3 — September 17, 2026 at 10:32 PM UTC

• Seller admins can open newly provisioned directory reviewer logins without a Secret Manager error.

​

5.553.0 — September 17, 2026 at 9:15 PM UTC

• When an MCP host cannot show the creative upload task, its fallback now opens the selected advertiser’s Creative Library and starts the existing upload task. You do not need to select or create a campaign first.
• Additional account creation now appears only when your organization’s accepted package includes an unused account slot. Otherwise, the account selector does not show a creation or upgrade control, and API requests fail without creating a partial account. Existing accounts are unchanged. Buyer accounts now ask for the Operator domain. Seller accounts ask for the Company domain and distinguish it from the public listing domain.

​

5.552.0 — September 17, 2026 at 8:59 PM UTC

• Buyer agents can pause an active media buy or resume a paused one through save_media_buy. Media-buy reads can also return the authoritative selected-product details and a fresh live AdCP status when requested.
• get_media_buy now includes proposalId in pendingChange when the queued change is waiting on seller approval through the async approval flow. Use this ID with DELETE /api/v2/buyer/update-proposals/{proposalId} to cancel the pending proposal and unblock a subsequent update.

​

5.550.0 — September 17, 2026 at 8:08 PM UTC

• Design-system widgets now render in the same brand typeface as the rest of the app. Headings sit slightly lighter than before, because that typeface ships Regular and Medium only and no longer synthesises a heavier weight.
• Creative Library now shows collections as a navigable tree with nested paths. Dragging a creative onto a collection adds it, with Undo available.

​

5.549.1 — September 17, 2026 at 7:46 PM UTC

• Seller admins can now open reviewer login credentials from eligible child accounts.

​

5.549.0 — September 17, 2026 at 7:20 PM UTC

• Selected sellers can choose Try as a buyer in the Merchandising Agent interview to practise a buyer conversation. Coach a completed reply, write and test a private lesson, then review it before applying it to your Playbook. Practice uses your normal allowances; it books no media and does not open advertiser admission. Existing conversations need no changes.

​

5.547.0 — September 17, 2026 at 6:07 PM UTC

• The Creative Library now has an advertiser-scoped Assets view for browsing reusable image, video, and audio files. Image and video assets can be selected for Creative assembly; audio remains browse-only for now.
• When a published Rate Card is available for your Free Seller Account, Interchange prompts you to review it from any app page after the Terms of Service step. An organization administrator opens the existing plan review and explicitly confirms the exact offer before accepting. Other members see an Ask your admin message. You can decide later or continue without a paid plan, and return through Plan & Billing at any time.
• Plan & Billing now shows only the public IU plans that cover every active Buyer, Seller, and Partner product in your billing organization. Seller choices also follow the Storefront operating mode. Existing accepted plans stay in effect, so there is nothing to change unless your organization chooses a new plan.

​

5.546.0 — September 17, 2026 at 5:23 PM UTC

• Product discovery now polls a successful provisional result without sending internal routing fields that the buyer API rejects.

​

5.544.0 — September 17, 2026 at 4:08 PM UTC

• Report progress while a chat turn runs. A caller that sends a progress token now receives notifications/progress updates as the turn works, written in the language the conversation is already being answered in, so a long analysis is no longer indistinguishable from a hung request. The first update goes out before the turn starts: preparing a caller’s status language never delays it by more than a second, and cancelling the request releases that wait immediately. Callers that send no progress token keep the existing synchronous behaviour.
• The Teach opening now explains how your materials prepare your agent and how to test it safely with a practice brief. It presents Teach as the one clear way to begin.
• Allow existing active reviewer grants to open the reusable directory reviewer login.
• Practice proposals now create a new attempt from the same brief when you select Run again, then show the new response beside the previous one. Products, prices, uploads, and saved feedback are unchanged.
• Creative sync now reaches sellers that publish legacy creative formats when a creative is pinned to one of the product’s format options. The selected option is sent back as the exact seller format it came from, so buyers no longer need to retry the media buy without syncing creatives first.

​

5.543.0 — September 17, 2026 at 2:37 PM UTC

• Sellers can upload a private file from Product Marketing in Murph without the file being rejected after selection. Existing file permissions and the general Murph attachment flow are unchanged; sellers do not need to take action.

​

5.542.0 — September 17, 2026 at 1:10 PM UTC

• Product searches that take 30 seconds now preserve their in-progress results and continue the same search instead of stopping before products can be returned. Nothing needs to change on your side.
• Buyer Pages now load reliably in external MCP Apps hosts and provide a clear recovery message when Page authorisation cannot be verified.
• Media buys now reach sellers that publish their creative formats in the legacy form, instead of failing with “the selected seller product did not provide one unambiguous legacy format reference”. When you pin a creative to a format option a seller’s product advertises, that pin now routes to the exact seller format it was built from. Nothing about how you select a format changes, and the affected buys can simply be retried.
• Sellers can open and reuse reviewer test credentials for their public listings.
• Buyers can organise advertiser creative collections into nested groups, see each collection’s parent and distinct subtree member count, and archive a collection after its active children are archived.
• Partner organizations with an issued private offer can review its terms in Plan & Billing and continue to secure payment setup when required.
• FreeWheel sellers can now build products from direct Ad Units, Ad Unit Packages, or both. Product creation follows each source’s inventory selection rules, so networks without packages can create valid drafts without a separate seller setting. Existing products are unchanged.

​

5.541.0 — September 17, 2026 at 11:36 AM UTC

• Enrolled buyers can now upload WAV and MP3 files up to 50 MB through the V3 creative upload Task. After inspection, the file is saved to the advertiser’s creative library and can be found with search(kind: "creative_asset").
• These audio assets are not yet available to save_creative, and uploading does not create or deliver a Creative. Existing image, MP4, and connected-provider audio workflows continue unchanged. Buyers who are not enrolled see no change.

​

5.539.1 — September 17, 2026 at 10:32 AM UTC

• If Creative Engines is enabled for your Buyer Account, open Creative Engines under Discover in Murph, or ask Murph to find a registered provider and open its setup on the Page. Start the secure connection from the Page. The form names the provider and, for OpenAI connections using your own key, links to the OpenAI API key dashboard. Creative Engines remains an alpha; this change does not make generation available.

​

5.539.0 — September 17, 2026 at 10:17 AM UTC

• Prepare remote MCP directory reviews from Listing. Request read-only reviewer access and reopen the same email and password for OpenAI, Anthropic, Microsoft, and other directories until you revoke it or it expires.

​

5.538.0 — September 17, 2026 at 9:58 AM UTC

• To cancel a campaign through /mcp/v3, first cancel or settle every executable or unsettled media buy. Then call save_campaign with desiredPhase: "canceled" and the campaign’s current revision.
• Campaign cancellation is terminal and does not cancel media buys for you. If any executable or unsettled media buys remain, save_campaign names them and leaves the campaign unchanged. Archive is a separate visibility action; this cancellation request does not archive the campaign.
• When you open Library in Murph, your documents and pages or slides now load correctly. An empty Library shows its first-run guide, and a failed read shows the full retry action. Nothing to change on your side.

​

5.537.0 — September 17, 2026 at 9:19 AM UTC

• Demo Storefront sellers can now use Teach to review and correct extracted candidates before opening a frozen synthetic evaluation in Proposal Pass. The evaluation keeps its sources and limits visible, including a synthetic rate card for planning only, not a live or buyer-quotable price. Custom fulfilment stays a named human or Connect follow-up; it is not treated as available automatically.

​

5.536.1 — September 17, 2026 at 8:39 AM UTC

• Embedded sales agent 1.43.4: declare AdsWizz hosted audio durations, quarantine partial AdsWizz creates, read the AdsWizz agency currency from the ad server, respect AdsWizz delivery in budget updates.

​

5.536.0 — September 17, 2026 at 8:32 AM UTC

• Ask Murph to show your creatives and open a portable Creative Library for one advertiser. The Page clearly separates all visible Creatives from the promoted reuse shelf, keeps active filters and incomplete results visible, and opens revision-bound previews without exposing another advertiser’s records. Existing search(kind: "creative") calls continue to return plain objects.

​

5.535.0 — September 17, 2026 at 7:38 AM UTC

• Sales Agent providers can run a zero-spend creative check that records a separate result for the exact implementation revision after cleanup completes.

​

5.533.0 — September 17, 2026 at 5:35 AM UTC

• Sales Agent providers can explicitly confirm each no-spend sandbox transaction step in a run-scoped technical certification check before any client setup.
• RFP proposal-file rendering continues after the request that queued it ends.

​

5.531.0 — September 17, 2026 at 2:05 AM UTC

• Sales Agent providers can start a no-spend brief-only technical certification check with a dedicated, run-scoped fixture before connecting an Inventory Source.

​

5.530.0 — September 17, 2026 at 1:10 AM UTC

• When you open an active Demo Storefront inventory source in Murph, its Display and CTV readiness now loads without an Enterprise Merchandising plan. Creating or changing custom modular inventory sources still requires Enterprise access. Nothing to change on your side.

​

5.529.0 — September 16, 2026 at 11:31 PM UTC

• Seller Material decks now produce slide previews, OCR, and semantic document inspection in production. The renderer runs inside the private worker boundary and does not receive seller or cloud credentials.
• A media-buy change that every publisher rejects for a reason that cannot be fixed by sending it again — an invalid request, or an outright refusal — now stops immediately and reports why, instead of being re-sent every two minutes for six hours and then going quiet.
• Nothing about a valid change is different, and a change rejected for a reason that might clear on its own — a publisher’s system being briefly unavailable, or an access grant that has not landed yet — is still retried for the usual six hours. Publishers see the same “forwarding failed” signal they already receive, once, rather than repeatedly.
• Cancellations are deliberately unaffected: a cancellation that fails to reach the publisher stays retryable, because a live campaign must never be recorded as stopped while it is still delivering.

​

5.528.0 — September 16, 2026 at 10:09 PM UTC

• Expose direct parameter types beside reusable MCP schema references so Anthropic’s directory scanner can validate the live tool catalog. Remove the non-actionable Claude plugin-package checkpoint from the storefront distribution flow and lead publishers directly to connector submission.
• Behind the existing default-off organization-settings-in-place flag, corrected the server-side authority foundation for the organisation-posture endpoint and added the B1 epoch proof surface:
• The flag is now evaluated for every caller before any posture is returned, including excluded principals. An excluded principal whose parent org is enrolled receives 200 ineligible rather than 403.
• Standalone posture is restricted to valid PARENT or STANDALONE customers with no parent; unknown or malformed topology is ineligible after the flag check.
• The OrganizationPostureService production entry point wires all dependencies (Prisma, Agentic DB, PostHog, delegation reader) inside the service module; the route only builds context and calls one method.
• BillingAccountService.getInheritedBillingStub uses a neutral locked Core FOR SHARE substrate: topology is read with FOR SHARE, and while those locks are held a single Agentic REPEATABLE READ snapshot evaluates sponsorship, membership, and delegation. Concurrent reparenting cannot produce a stale parent identity and the billing result is fully assembled before Core releases. Billing has no feature-flag gate and no epoch computation.
• Shared Zod runtime contract (OrganizationPostureKindSchema, OrganizationPostureResponseSchema, OrganizationAuthorityProjectionSchema) exported from @scope3/agentic-contracts/organization-settings.
• Non-impersonated platform SUPER_ADMIN principals authenticated to a CHILD account receive direct_parent_admin without a parent membership read.
• B1 addition: GET /api/v2/accounts/organization-posture now includes required authorityCustomerId (integer — the authenticated account whose authority was resolved) and authorityEpoch (opaque 16-hex-char string) fields in every 200 response. The epoch encodes all verified authority-bearing inputs (principal identity, credential, customer topology, parent membership, child projection, and delegation) and rotates whenever any of these change. The /auth/me response optionally includes the same authorityCustomerId+authorityEpoch pair for enrolled accounts. Both endpoints derive the epoch from the same authority-proof resolver so the values are guaranteed to match for the same canonical authority state. A UI hook (useOrganizationPosture) is shipped in this slice but has no consumers; it is wired to the posture surface exclusively and carries no lifecycle dispatch, route decisions, redirects, or rollout logic.
• Creative Library and Catalog feeds now follow your interface language in German, Spanish, French, Italian, Japanese, Korean, Dutch, Brazilian Portuguese, and Simplified Chinese. Names and content from your account remain unchanged. No action is required.

​

5.525.0 — September 16, 2026 at 8:42 PM UTC

• An approved media buy now has its flight start re-checked at the moment it is sent to the seller, instead of only when it was first submitted. A start that has since passed is sent as “start now” rather than as a stale timestamp the seller would reject.
• A media buy whose flight has already ended is no longer sent at all. Previously it was retried against the seller every two minutes for six hours, rejected every time, and then went quiet — leaving the buy approved but never placed, with nothing to explain why. It now stops immediately and reports flight_window_elapsed, so buyers and publishers both see a stated reason and can submit a replacement buy with a current flight window.
• Buys with a valid flight window are unaffected.

​

5.524.0 — September 16, 2026 at 8:17 PM UTC

• The Creative Library composer now lets you choose an eligible product by seller and product name before selecting its creative format. Incomplete seller results remain visible and selectable, with clear options to continue or retry the browse, and saves and previews retain the selected format exactly; there is nothing to change on your side.
• Executing a staged media-buy batch no longer repeats an already-completed campaign link, preventing an otherwise valid batch from failing during concurrent activity.
• Buyer Accounts enrolled in the Creative Engines preview can now browse registered engines and manage provider connections, account selection, and advertiser mappings. Declared support and observed account access are shown separately. Provider prices and generation are not available in this preview.

​

5.523.0 — September 16, 2026 at 7:29 PM UTC

• Fixed searchable dropdowns being cut off inside dialogs. In the Create account dialog, the option list for a field like additional payment currencies or support channel was clipped at the edge of the dialog’s scrolling area, so options below the cut were invisible and unreachable. The list now opens over the dialog, scrolls with a trackpad, flips above the field when there is no room below, and closes on Escape without also closing the dialog.
• Buyer agents can now browse an advertiser’s visible wholesale products across eligible Sellers with search(kind: "wholesale_product") before a campaign exists. Pass filter.advertiserId; bounded results include the exact product and Seller IDs needed for creative_format, and incomplete Seller reads or withheld unsafe identities are reported instead of appearing as an empty catalogue. Seller product search is unchanged.

​

5.522.0 — September 16, 2026 at 7:01 PM UTC

• The notification bell now shows a dot when you have something unread, instead of a number. The exact count lives in the panel the bell opens, so the bar just tells you there is something waiting. The help, notifications, switch-account and menu icons beside it are quieter too — they carry no background until you hover them, so the top bar reads as one row of icons rather than a row of filled buttons.

​

5.521.0 — September 16, 2026 at 6:35 PM UTC

• In /mcp/v3, buyers can now set a media buy’s flight and budget when save_media_buy stages products or accepts a proposal. A total budget applies to a single-product buy; use per-product budgets for a multi-product buy. Flight dates use ISO 8601 datetimes; use a future start time or asap to start immediately. Calls that omit these new inputs continue to work unchanged.

​

5.520.2 — September 16, 2026 at 6:10 PM UTC

• Inventory-source and other seller workspaces now open at their content height in chat instead of taking over the conversation window when their content is short. Tall workspaces remain capped and scrollable, and the surrounding conversation stays accessible.

​

5.520.0 — September 16, 2026 at 5:18 PM UTC

• Creatives that name only a format kind now attach to products that declare the same format more than once. Some catalogues list one size under two option ids; that counted as two competing options and the product dropped the creative. Identical declarations are now treated as the one format they describe. Creatives pinned to a specific option are unaffected, and no creative is sent to a seller with an option id we had to guess at. The message shown when a creative genuinely cannot attach now counts the options on the product it failed against, rather than every option on the buy.
• Campaign goals are now opt-in. You can clear a goal without recreating the campaign.

​

5.519.0 — September 16, 2026 at 4:51 PM UTC

• Brand logos no longer run to the edge of the tile they sit on. A logo is now centred in the avatar’s content slot, so the brand colour behind it reads around the mark and a list of advertisers lines up row to row whatever shape each logo is — a square icon, a wide wordmark, and a logo that carries its own background all render the same size.
• The colour behind a logo is now chosen by looking at the artwork itself rather than by trusting what the brand kit says about it, which is often missing. A white knockout mark gets a dark backing and a dark mark gets a light one, so a logo can no longer disappear into its own tile. An advertiser with no logo and no brand kit falls back to its initials.
• The advertiser-list response no longer carries logoFill. It said whether a logo should fill its tile, and nothing fills a tile any more.
• Fix two agent-facing text issues in the v3 buyer surface.
• Currency lock: the skill now explicitly states that an advertiser’s primaryCurrency is freely updatable, while a media buy’s settlement currency is a separate value locked at creation and cannot be changed. The currency mismatch error message in save_media_buy has been updated to reflect this correctly.
• Draft wording: agent-facing prose in save_media_buy and the buyer skill now uses “draft” instead of “staged/staging” to match the product vocabulary. Status enum values, field names, and wire identifiers are unchanged.
• V2 Buyer connectors now publish a smaller tool catalogue so supported AI clients can load it. Existing API inputs and validation do not change, and buyers do not need to take action.

​

5.518.0 — September 16, 2026 at 4:32 PM UTC

• Optimization goals (performanceConfig) are now hints you can attach to any campaign — they no longer transfer composition ownership to the platform optimizer. Composition is now controlled by autonomy.inventorySelection.
• Before: setting optimization goals made a campaign performance, which blocked manual seller picks and create_media_buys calls from staging.
• After: autonomy.inventorySelection owns composition:
• manual (default) — you pick sellers and products directly
• propose — the platform drafts a selection for your approval
• automatic — the platform optimizer owns product selection; manual staging is rejected
• Campaigns with goals but without inventorySelection: "automatic" can now stage manual media buys. To use the platform optimizer, set autonomy.inventorySelection: "automatic" alongside your goals.
• Existing performance campaigns are automatically migrated: any campaign with optimization goals and no explicit inventorySelection receives inventorySelection: "automatic", preserving their current behaviour.
• The mode field on campaign reads continues to return performance when goals are present, discovery otherwise — v2 consumers see no change on reads.
• Creative Library now confirms that the upload task opened before showing success, and shows a clear error when the task cannot open.
• OpenAI package downloads no longer leave a stale preparation message after the browser starts the download.
• Fix async task poll never firing for third-party seller sources (e.g. PubX) when the seller responds in the final 2 seconds of the discovery budget.
• The SDK call was being aborted by an internal deadline signal 2 seconds before the outer timeout, cutting the connection before the response arrived. Interchange never received the async task ID, so no poll row was created and tasks_get was never called. This change gives sellers the full discovery budget to respond, and adds a background flush to recover the task handle if the flush-to-DB races with the deadline.
• Seller identity labels in the v3 buyer surface now use storefrontId instead of sellerId, making it clear the id refers to a publisher storefront rather than an internal account. Searches that reference a seller by name now also match on platform id and publisher domain. When a storefront’s display name disagrees with its publisher domain (for example, a name of “Daily Mail Digital” paired with a domain of “wonderstruck.org”), the domain is shown instead — catching data mismatches at read time without requiring a data correction.
• The legacy connection.customerId remains available for one compatibility release and is now deprecated. Buyer integrations should move to sellerId or storefrontId; we will remove connection.customerId in a follow-up release after the transition period.

​

5.517.0 — September 16, 2026 at 3:46 PM UTC

• When one inventory-source health change also updates Storefront liveness, you now receive one source-health email instead of a second Storefront update for the same change. The Storefront state change remains in your in-app notification history. Nothing to change on your side.
• Buyers receive an incomplete, pollable product-discovery result when a background publication misses the request deadline, instead of an error that requires starting over.
• The V3 buyer agent now requires explicit user confirmation before staging a media buy, even after a proposal round completes. Previously the agent could proceed to save_media_buy based on a prior direction or conversational momentum without waiting for an active “yes”. After this fix, the agent stops after presenting products or proposals, confirms the exact commitment with the user, and calls save_media_buy only after receiving explicit approval in the current exchange. The agent also treats any failure or error in the buy flow as a fresh decision point — a “try again” re-proposes and confirms rather than silently re-authorizing the prior action.
• Buyer agents can search for and open Sellers whose activation is deferred without receiving a conflict response. No action is needed.
• Parent organizations can now see each child account’s attributed customer IU usage for the current billing period in Plan & Billing. Accounts with no rated activity show 0 IUs; unavailable or unratified usage remains blank.

​

5.516.0 — September 16, 2026 at 3:06 PM UTC

• OpenAI package downloads now start from a direct click after preparation, so browsers no longer block them as pop-ups.

​

5.515.2 — September 16, 2026 at 2:22 PM UTC

• Connections can open the advertiser setup flow from the buyer workspace.

​

5.515.0 — September 16, 2026 at 1:41 PM UTC

• Creative Library uploads can now include searchable tags. After an upload finishes, the agent receives the saved asset’s name, tags, file details, and verified video facts so it can accurately confirm the result and continue building a Creative. Existing uploads need no changes.

​

5.514.1 — September 16, 2026 at 1:04 PM UTC

• Plan & Billing now opens inside Account settings, keeps its selected tab in the URL, and sends older billing links to the same in-frame destination.

​

5.514.0 — September 16, 2026 at 12:38 PM UTC

• Interview actions now stay unavailable until their matching workflow is ready, instead of starting a general chat.

​

5.513.0 — September 16, 2026 at 11:59 AM UTC

• Fixed two bugs that could leave a creative attached to a Meta media buy without ever reaching Meta, or reaching it with no explanation of why it failed:
• A creative attached to a media buy before launch was never recorded against its package, so buyers and their agents saw 0 creatives linked even though the creative was correctly associated internally.
• When a background retry to re-sync a creative to Meta failed, the failure reason was sometimes left blank instead of explaining what went wrong, making it impossible to tell why delivery hadn’t started.
• Standalone accounts no longer show a duplicate organization settings entry, and Buyers without another account or account action no longer see a redundant selector.

​

5.511.4 — September 16, 2026 at 11:22 AM UTC

• OpenAI package downloads now revalidate the current approved listing before generating the archive.

​

5.511.3 — September 16, 2026 at 10:39 AM UTC

• Let buyers assemble uploaded Library assets with save_creative by passing the exact creativeFormatId returned by Creative format search or read.
• You can now upload supported seller material from the Product Marketing Teach page. The page sends the file to private storage and starts processing it; pasted text and existing material are unchanged.

​

5.511.1 — September 16, 2026 at 9:57 AM UTC

• Package budget updates now return success only after the seller confirms the change. If every seller proves that a rejected update left no upstream mutation, the existing live budget remains in place and the rejected proposal no longer appears as pending approval. Asynchronous and otherwise uncertain outcomes stay pending for reconciliation.
• The Campaigns page now loads self-serve advertiser campaigns correctly. Nothing changes for existing campaign filters.

​

5.510.0 — September 16, 2026 at 9:02 AM UTC

• Proposal passes now show buyers—and the sellers reviewing them—when a request depends on unsupported attribution or human-fulfilled custom work, so neither side mistakes a limitation for an automated promise.
• Make the current Proposal Pass response the visual focus, show sellers a direct before-and-after comparison after coaching without hiding preserved commercial limits, and keep format previews refreshing reliably while proposal files render.

​

5.509.1 — September 16, 2026 at 7:17 AM UTC

• Fixed a bug where a creative could stay stuck in a failed/pending-approval state on a Meta media buy after activation, because the background job that re-syncs assigned creatives to the seller wasn’t resolving the format details some Meta placements require. Retrying creative delivery after a media buy goes live now carries the same format information as the initial sync.

​

5.508.0 — September 16, 2026 at 4:57 AM UTC

• Fixed an issue where MCP apps opened in Ask Murph could open without the original request details. Nothing to change on your side.

​

5.507.3 — September 16, 2026 at 3:24 AM UTC

• The Plan & Billing Accounts tab now shows intelligence usage by account. Account-level fees and billing delegation controls remain unavailable, and no action is required.

​

5.507.2 — September 16, 2026 at 3:03 AM UTC

• Open API calls from the Agents workspace’s left navigation on both the buyer and seller sides. It opens the existing Activity widget in the main screen, with chat still available. The shortcut has moved out of Inventory and the general buyer navigation. API keys remain in Settings.
• The seller Agents collection now opens from a standard left-navigation row instead of appearing as a management widget inside the sidebar. Agent creation and selection stay in the main screen.
• Selecting an Agent groups its sections beneath its name. API calls stays separate and account-wide; selecting an Agent does not filter calls or API keys. On narrow screens, use All agents to return to the collection instead of an Agent dropdown.
• Existing access rules and Calls-beta eligibility are unchanged. Accounts outside the beta retain the Changes fallback. Sellers using the older navigation, or a failed-checklist fallback, keep their existing Activity shortcut. No credential or integration changes are needed.

​

5.507.1 — September 16, 2026 at 2:28 AM UTC

• Plan & Billing → Accounts no longer shows an empty Period fees column. Organization-level billing and account usage are unchanged; no action is needed.

​

5.507.0 — September 16, 2026 at 2:06 AM UTC

• Creative reads now identify the durable Library asset used to assemble each manifest asset. This keeps the reusable asset and Creative-specific manifest identities distinct while making their provenance navigable.

​

5.505.1 — September 16, 2026 at 12:58 AM UTC

• For buyers, REST responses continue to provide a numeric file_size. Verified video sizes include file_size_status: "verified"; when verification is unavailable, file_size is 0 and the status is absent instead of reporting the length of the URL. No buyer action is required.
• For sellers, sales-agent integrations now receive video size, container, and codec through video-specific properties. The existing generic file_size and format aliases remain during the compatibility transition, so current custom integrations continue to work. Unknown sizes are omitted from delivery and size checks under both field names, while older video records keep their available file-type details. No storefront setup change is required.
• Show a clear loading indicator while an OpenAI submission package finishes processing.

​

5.504.0 — September 15, 2026 at 10:29 PM UTC

• The per-buyer auto-approve Page has been retired. New clients should use the storefront-wide media-buy approval setting in AI Business Rules.
• The deprecated V2 REST and MCP operations keep their existing behaviour while clients migrate. Existing V2 buyer overrides therefore continue to apply during this window.

​

5.503.3 — September 15, 2026 at 10:18 PM UTC

• The Creative Library now accepts the exact Product ID returned by marketplace discovery and checks promoted MP4 container, codec, duration, and dimensions before save. New durable uploads also retain their original filename. After one advertiser-level save, buyers can preview the saved revision and find the Creative once under All creatives. No integration change is required, and no campaign or provider is contacted.

​

5.503.2 — September 15, 2026 at 10:09 PM UTC

• Source tests no longer blame your agent for a discovery that returned nothing conclusive.
• When you test an inventory source, we run a buyer discovery against it and then select products from the result. If that discovery came back empty, the test told you your source returned no products and suggested your inventory did not match the brief — even when the discovery had not finished, or when it reported no reason at all.
• A source test now says plainly when it is inconclusive. If the discovery had not finished, it says so and names which agents were still outstanding. If the discovery came back with no products, no error, and no explanation, it says it cannot tell a source with no matching inventory apart from a discovery that returned before the source answered. Either way it asks you to re-run rather than drawing a conclusion.
• It does not swing to the opposite claim either: an unfinished discovery is reported as inconclusive, not as our fault, because an agent that did not answer in time may have been slow itself. Where discovery genuinely finished and the source reported products, a skip reason, or an error, the test attributes it exactly as before.
• Every run also records whether discovery had completed when its products were read, so a past result can be re-examined instead of assumed.
• This changes what a source test reports, not how discovery runs or how long it waits.

​

5.502.1 — September 15, 2026 at 9:01 PM UTC

• When a selected creative format has one compatible asset slot, your agent can now save an advertiser-owned image or video without supplying a slot name. Formats with multiple compatible slots or repeatable groups still require an explicit slot, and any other required assets are unchanged. Nothing to change on your side.

​

5.500.0 — September 15, 2026 at 6:48 PM UTC

• The creative uploader now points to the correct Close action when it records an asset but cannot dismiss the upload card.

​

5.498.0 — September 15, 2026 at 6:09 PM UTC

• The menus in the top navigation bar — account, help, workspace picker, notifications, and the organization switcher — now use the new design system, so they match the look of the rest of the product. Opening Ask Murph from the navigation bar no longer reloads the whole app.

​

5.497.2 — September 15, 2026 at 4:12 PM UTC

• The Advertisers and Campaigns pages load again in the web app. Both pages could open to “Couldn’t load advertisers” (or an empty campaign list) with a Retry button that never recovered, because the page discarded its own read authorization while starting up.

​

5.497.0 — September 15, 2026 at 2:58 PM UTC

• Buyers can now select Show preview for a saved Creative in the Library. V3 get clients can request the same short-lived, revision-bound preview with include: ["preview"]. Direct image, video, and audio sources are renderable; active tag documents return an honest reason rather than exposing nested provider resources or trackers. V3 Creative reads no longer forward the legacy provider preview URL or tracker fields; use the capability-gated preview instead.

​

5.495.3 — September 15, 2026 at 2:27 PM UTC

• First-time users who return to signup after signing in with an existing password can now continue account setup. If the recovery session has expired or is not eligible, signup shows an error instead of leaving them on the same step. No action is needed unless you encountered this issue; sign in again to retry.
• FreeWheel sellers can now set the execution currency in Inventory Sources without re-entering or replacing source credentials. Existing sources without one must add the currency FreeWheel uses for insertion orders, and it must be one the storefront settles.

​

5.494.0 — September 15, 2026 at 12:06 PM UTC

• Storefront operators with an approved, expiring lifecycle-test exception can commit the exact test availability row while their Storefront is paused. The row stays out of buyer catalogs and does not count as publisher authorization or activation evidence.

​

5.492.0 — September 15, 2026 at 11:16 AM UTC

• Buyers can now assemble advertiser-owned image or MP4 assets into a canonical creative format directly from the Creative Library, then save and verify the result without attaching it to a campaign.

​

5.491.0 — September 15, 2026 at 10:33 AM UTC

• In creative approvals, live previews now stay closed until you choose Show preview and appear in their placement format. Expired or superseded previews do not load; refresh the queue for a current preview. External creative links continue to open separately.

​

5.489.0 — September 15, 2026 at 7:51 AM UTC

• Buyer agents can now read the exact creative format and slot requirements for visible products before a campaign exists. Use V3 search and get with kind creative_format, then pass the returned formatOptionRef unchanged when saving the creative. The read makes no provider call or setup request. Seller-owned product declarations are available without a provider connection; direct-adapter products keep their existing active-connection visibility rules.

​

5.488.1 — September 15, 2026 at 7:00 AM UTC

• Buyer Library MP4 Creatives can now reach a compatible selected Meta destination when they are attached to a campaign. Interchange rechecks the current buyer, advertiser, account authorization, Library source, format, and revocation state before Meta delivery, without another upload or a private storage URL.

​

5.486.2 — September 15, 2026 at 5:42 AM UTC

• HTML5 ZIP uploads in the V2 buyer flow now accept one enclosing creative folder and report missing or ambiguous banner dimensions explicitly instead of calling a readable archive corrupt. Hidden export metadata no longer creates extra creatives in the campaign upload UI. Mac metadata is removed from delivered HTML5 ZIPs while creative files and relative paths are preserved. V2 Murph can retrieve saved attachments on a later turn before inspecting them. HTML5 adoption through the V3 connector remains unavailable.

​

5.486.0 — September 15, 2026 at 4:34 AM UTC

• An empty sales Library now explains which documents to add and opens the existing private file chooser from the drop area. Loading, failed reads, filtered results and narrower empty views keep their existing messages.

​

5.485.0 — September 15, 2026 at 3:47 AM UTC

• AI Business Rules now keeps a support correlation ID visible when a policy save fails without a usable server response.
• Buyers enrolled in the Creative Engines preview can list creative sessions for a campaign and open them through V3 search and get. Each session includes its persisted revision, plan, variants and evaluation, subject to current campaign and advertiser access. Session reads do not start generation. V3 session writes and generate_variants are not available in the preview.
• Separately, existing V2 creative-session fixes take effect when this release is deployed. They preserve explicit image dimensions and an AudioStack duration, refuse a selected credential when it is unavailable rather than falling back to another key, and return the saved result when a finalized session is retried with the same selected variant, name and message. A batch whose direction labels resolve to the same provider key is rejected before generation. The Creative guide explains retry behaviour and direction-label requirements.

​

5.484.0 — September 15, 2026 at 3:10 AM UTC

• Library documents you upload now get faithful page and slide previews: PDF pages and PowerPoint slides render as they look, and each page’s inspection state comes from that render rather than a text-only scan. If a page cannot be rendered fully, the Library says so instead of presenting it as ready. Nothing to change on your side; documents already in your Library keep their current previews until they are reprocessed.

​

5.482.1 — September 15, 2026 at 1:40 AM UTC

• Campaigns opened with an existing relationship or status filter now load the matching list. Invalid filter values and extra filter fields remain rejected.

​

5.482.0 — September 15, 2026 at 12:49 AM UTC

• Advertiser Creative Library can switch the same loaded results between Grid and List while keeping filters and detail context, and can manage advertiser-owned collections. Refreshes and collection results stay scoped to the current advertiser.
• If your seller account uses a third-party sales agent, Source Diagnostics now shows Storefront availability, Agent certification, and Source health separately. It gives you the next action for the status that needs attention. This release only clarifies existing status; it does not change whether your storefront can transact.

​

5.481.1 — September 14, 2026 at 11:26 PM UTC

• The Advertisers Page now loads its advertiser list reliably in MCP v3 hosts. Nothing to change on your side.

​

5.481.0 — September 14, 2026 at 11:00 PM UTC

• Browse Library documents and decks with source-grounded previews, file types, and relevance labels. Search and grouping use the canonical, seller-scoped Material read projection while keeping source mentions, catalog links, suggestions, and seller confirmations distinct.

​

5.480.0 — September 14, 2026 at 10:34 PM UTC

• Promote finalized image and video uploads into durable advertiser asset records, expose them through V3 search/get, and let save_creative assemble reusable assetId inputs.
• Seller decision details now leave buyer advertiser and buying-operator identity unknown when a captured brief request omits them, instead of presenting compose-run fallback data as buyer-declared identity.
• Start storefront brief tests from Storefront Briefs. Test Runs no longer appears in navigation or starts new runs; historical links still open during the rollback window, and Fix this run remains available for failed or stalled records.
• Provisioned Demo Storefront accounts can open their Demo Storefront page from the setup rail without modular source access.

​

5.478.0 — September 14, 2026 at 9:25 PM UTC

• Advertiser-owned creative collections can now be read and changed through the existing creative collection tools. Changes require the current collection revision, support name or description and saved-creative member changes, and do not attach a campaign or add executable behavior.
• Creative collection search now accepts an explicit advertiser scope, and save_creative_collection can create an advertiser-owned non-executable collection without attaching it to a campaign or changing membership.
• When a seller investigates a media-buy mutation that did not go out, Source Diagnostics and Murph now show the intended mutation, any capability check that did run, and whether Interchange stopped before sending the mutation. The view identifies Interchange as the owner of that local stop and directs the seller to the recorded evidence while Interchange resolves the local setup failure and retries through the normal operation path; it does not ask the seller to change their Agent or Source configuration.
• Opening a seller from the connections widget now shows a tabbed detail in place — Connections & advertisers and Controls — instead of a side drawer. It lays out your media partners, the accounts each connection authorizes, and the advertisers mapped to them, with icon statuses (hover for detail) and inline actions; the advertiser search now filters whichever tab you’re on. Section and tab labels are clearer too: Media Partners, Connections, and Controls.

​

5.477.3 — September 14, 2026 at 8:51 PM UTC

• New signups no longer inherit a retired Seller account or its billing family from an email-domain match. Child accounts and archived Seller accounts now require an explicit invitation or support-led recovery. Sign-in fallback also ignores historical permissions on inactive accounts. No action is needed for active standalone accounts.

​

5.476.0 — September 14, 2026 at 7:20 PM UTC

• Inventory Sources now distinguishes a healthy ad-server connection from whether that source can accept a new buy. If execution currency blocks buying, the page names the blocker and keeps seller-owned actions separate from work Scope3 must complete instead of saying that nothing needs attention.
• Show seller-facing Core reporting capability, exact Source attribution and health, and retained obligation/revision evidence without treating one Source as Agent-wide health.

​

5.475.0 — September 14, 2026 at 6:19 PM UTC

• Library Material search and lookup now show source file type separately from business format tags, and keep topics, audiences, product relationships, suggestions, and seller-confirmed applicability distinct.
• Material get can now include repeats to show separate readable units with the same complete rendered preview in one rendering configuration. Each unit keeps its own source, rendition, and place in the document. Results are bounded and may be incomplete. This comparison does not mean the Material has the same meaning or is an approved template, and seeing a result does not make it available for model use or reuse.
• Library Material searches can return indexed evidence matches from current readable source units, with source and inspection identities but no source text.

​

5.474.2 — September 14, 2026 at 5:55 PM UTC

• Run transaction validation from Required to go live now opens the exact Agent and inventory source that needs proof. If Interchange cannot identify one active Agent connection for the inventory source, it explains whether to connect the source or reconcile its connections instead of reopening Seller Setup.

​

5.474.0 — September 14, 2026 at 5:19 PM UTC

• v3 get_delivery seller delivery responses now include two new fields: period (the resolved reporting window — start and end dates) and totals (an additive rollup of impression and click metrics across all matched rows). Non-monetary metrics such as impressions and clicks are available in totals; monetary metrics are unavailable because seller delivery data does not carry currency. No changes to existing calls are required — the new fields appear alongside the existing response without breaking current usage.

​

5.469.1 — September 14, 2026 at 2:26 PM UTC

• Murph chat no longer blocks new messages when it crosses the 24-hour token threshold. Gemini-backed chats also avoid repeating expanded tool instructions between steps, reducing token use. The runaway-use safety backstop is unchanged.

​

5.469.0 — September 14, 2026 at 2:05 PM UTC

• Seller RFP responses and proposal files now begin processing when they are queued instead of waiting for the next periodic worker check.

​

5.468.0 — September 14, 2026 at 1:06 PM UTC

• Inventory Components now keeps the publisher-property coverage option you choose when it prepares a product for review. Coverage for all publisher properties and for tagged properties is sent exactly as your source provides it.

​

5.467.0 — September 14, 2026 at 12:36 PM UTC

• Inventory Components now asks you to choose the publisher-property coverage for a draft product. A single source-provided option is selected automatically; when several are available, choose the one that covers the product before review. The product check no longer adds a contradictory advisory when the ad server already reports missing coverage as a blocking issue.
• Connections now waits for its owner-authorised Page session before loading or changing seller connections, and lets the user retry a failed launch.

​

5.466.0 — September 14, 2026 at 11:34 AM UTC

• Buyers can now assemble finalized image and video uploads into an advertiser Creative before a campaign exists. Campaign-scoped saves still create and attach in one operation.

​

5.465.0 — September 14, 2026 at 11:13 AM UTC

• Inventory Components now loads each product’s complete editable definition before you save. Review and update canonical formats and their parameters, placements and inventory, targeting, video placement types, channels, and every pricing option, while source-managed fields remain visibly read-only. The editor validates complete and repaired products and safely patches only your changes, preserving every untouched field. Blank or null optional JSON and unsupported delivery-type clears are rejected rather than silently retained. Legacy FreeWheel products can still receive non-inventory edits; inventory changes clearly require a current Ad Unit Package.
• Your Listing page is now four steps you complete in order: Identity, What you do, Listed on Interchange marketplace, and Public distribution, where you add the paid Distribution package and point your own domain at Interchange. Once that step is live, the Distribution tabs below let you add app destinations, starting with the ChatGPT app, and each tab lists the steps it still needs. Your existing listing, domain, and ChatGPT app setup carry over, so there is nothing to redo.

​

5.464.4 — September 14, 2026 at 10:30 AM UTC

• AI Business Rules now keeps a failed policy draft and shows the save reason, recommended action, and support correlation ID.

​

5.464.3 — September 14, 2026 at 10:09 AM UTC

• In Configure connection, you can load a published contract as a new higher-version draft. The published version remains unchanged; retry if its canonical definition cannot be read.
• Creatives pinned to a format from an earlier product discovery now stay attached when rediscovery returns the same requirements under a new synthetic format ID. Interchange uses the current format automatically when the media buy runs; nothing changes on your side.

​

5.464.0 — September 14, 2026 at 8:50 AM UTC

• FreeWheel product drafts in Inventory Components now require an Ad Unit Package and keep it alongside the selected site or site group. Empty package lists and package-loading failures are shown separately so an incomplete draft cannot advance to review. Product creation for other ad servers is unchanged.
• Buyers can now add an agent to a room they own.
• Buyer administrators now see clearer agent setup, access, lifecycle, and error guidance.

​

5.463.1 — September 14, 2026 at 7:30 AM UTC

• The Inventory Selector now separates FreeWheel targeting from delivery binding. Sellers can choose where a product runs using sites, sections, site groups, series, or video groups, then independently choose the ad-unit packages that provide its delivery slots.

​

5.463.0 — September 14, 2026 at 6:14 AM UTC

• Sellers can now create a Sales Agent in the standard Agent workspace, attach it to a new inventory Source without leaving that workspace, test its get_products path directly without spending, and follow an end-to-end guide for validation, diagnostics, certification, and distribution. Source creation and attachment now complete as one operation, so an interrupted response can be recovered by refreshing the Agent instead of submitting the connection form again.
• When you try to change the agents in a room you do not own, the error now says you do not own the room instead of reporting that the room was not found.

​

5.462.0 — September 14, 2026 at 5:33 AM UTC

• Use upload_creative_asset in Buyer V2 or V3 to upload a JPEG, PNG, or MP4 without sending the file through chat. Uploading alone does not create or attach a Creative. To use the asset in a campaign, call V3 save_creative, bind the returned asset reference to each required canonical format slot — including a thumbnail for video — and select a destination before provider delivery can begin.

​

5.461.0 — September 14, 2026 at 4:33 AM UTC

• Snap Pixel-optimized media buys (Web Conversions and other pixel-based products) now get a clear, actionable error when the selected Snap Pixel doesn’t yet have enough tracked conversion events, instead of an opaque “ad platform rejected the request” error. When Interchange can confirm this up front, it refuses the buy before creating anything on Snap, so the buyer sees the real reason (and can wait for more events to accumulate, or choose a different product/optimization goal) rather than a rolled-back campaign with no explanation.

​

5.460.0 — September 14, 2026 at 3:05 AM UTC

• Enrolled buyers can use V3 search and get to discover registered Creative Engines, then use save_connection to authorize an engine, select a provider account and map it to an advertiser. Existing seller connection calls and their default results remain unchanged. This preview covers registered engines only. It does not include the Creative Engines Page, V3 generation-session tools, pricing or settlement, provider qualification, or arbitrary external MCP services.
• In the existing V2 creative workflow, AudioStack voiceovers now render through Audioform at the script’s natural spoken length without background music. API-key connections expose one credential-scoped provider account for advertiser mapping before generation. When an image-generation request starts with brand context but no prior creative assets, it is treated as a new draft: Interchange preserves the initial brief and creates the requested variants.

​

5.459.2 — September 14, 2026 at 2:47 AM UTC

• Fixed sync_creatives (REST and MCP api_call) failing with account_grant_inactive for direct/official-adapter storefronts (Meta, TikTok, Snap, and similar). These storefronts authorize buyer accounts through the adapter’s own credential, not through the storefront relationship/grant model, and the buyer-facing sync path was checking the wrong one.

​

5.458.4 — September 13, 2026 at 11:19 PM UTC

• Sellers enrolled in the Product Marketing corpus can open their material Page from Teach my agent without starting a chat. Sellers outside the rollout keep the guided conversation.

​

5.458.3 — September 13, 2026 at 10:17 PM UTC

• OpenAI submission packages now download successfully while the Listing page refreshes their status.

​

5.458.2 — September 13, 2026 at 9:54 PM UTC

• Fixed two issues that could block getting a creative live with a sales agent. list_creatives, list_campaign_creative_manifests, and sync_creatives now find every creative attached to a campaign — some attachments were previously invisible to these calls, which blocked retrying a sync after fixing a rejected creative. Separately, a click-through URL now must be provided in the URL field; providing it as plain text is rejected with a clear error instead of being silently dropped every time the creative syncs.

​

5.458.1 — September 13, 2026 at 9:38 PM UTC

• Hands-on buyer teams using REST API, MCP, or S2S proposal-request integrations now keep each response bound to the exact campaign revision and brief that created it. A reused provider proposal ID cannot be attributed to a different request. No action is needed and existing integration contracts are unchanged. Seller indirect audience is not applicable: this changes no seller-facing surface or contract.

​

5.455.1 — September 13, 2026 at 6:06 PM UTC

• Fixed a sign-in loop that returned users to the login page immediately after successful authentication.

​

5.455.0 — September 13, 2026 at 5:43 PM UTC

• Make the Demo Environment Notice open reliably and keep the attached-source count grammatically correct after live source changes.

​

5.453.0 — September 13, 2026 at 4:28 PM UTC

• Browser authentication now requires WorkOS session tokens to target the configured application.

​

5.452.0 — September 13, 2026 at 3:23 PM UTC

• Agents now opens and stays inside the standard seller workspace, preserving workspace navigation, chats, settings, and the composer while an Agent is selected. Partner-entitled organizations also receive the same Agent collection and creation launch access as enrolled organizations.

​

5.451.0 — September 13, 2026 at 2:37 PM UTC

• Show creative upload byte and inspection progress, keep Claude informed as inspection advances, and show a completed state when a host retains the widget.

​

5.449.0 — September 13, 2026 at 1:20 PM UTC

• Choose an Interchange plugin package for the job you need to do. Buyers get separate packages for account setup, campaign management, creative management, and reporting. Agent developers get a sales-agent testing package. Agentic Media Companies get packages for listing, merchandising, distribution, campaign management, and self-serve buying.
• Storefront operators can now see the Anthropic and Claude distribution path alongside OpenAI. OpenAI reviewer access lasts 90 days after the reviewer confirms receipt, and downloading the same submission bundle more than once no longer creates a conflict.
• Installing a package does not change pricing, storefront listings, or account access. Existing Interchange plans and OAuth permissions still decide which tools and accounts each person can use.

​

5.447.1 — September 13, 2026 at 12:29 PM UTC

• When your AI assistant sends you to Interchange to upload a creative, the campaign page now accepts private MP4 uploads up to 2 GB instead of rejecting files larger than 50 MB. After inspection, the page keeps a visible upload receipt. MP4 uploads still only store and inspect the file; creating or attaching a campaign creative remains a separate step.

​

5.447.0 — September 13, 2026 at 12:08 PM UTC

• People using Interchange through chat or the UI do not need to configure anything new. Buyers and sellers may be shown an approved public agreement as reference material, but this does not accept terms, reveal private agreements, or decide which agreement governs an account.
• MCP builders can discover approved public agreement revisions through the existing docs search source, then read an exact revision or section and continue a long read without starting over. API developers can read the same immutable public text or download the complete document through the focused /api/v3/documents resources.
• Monetization: none. These read-only resources do not change packaging, billing, or feature access.
• Measurement: monitor successful, not-found, and unavailable reads for the two public-document HTTP operations and exact-revision MCP reads. HTTP and MCP acceptance checks must return the same approved revision and content hash.

​

5.445.0 — September 13, 2026 at 11:18 AM UTC

• Hosted buyer-agent operators can now give a deployed runtime a short-lived, read-only Interchange identity instead of storing a long-lived credential in the runtime. The deployment orchestrator provisions an installation binding, mints a token with a 15-minute default lifetime, and refreshes it before expiry; normal buyer credentials, human sessions, and the runtime token itself cannot call those endpoints or gain administration authority.
• This is opt-in for hosted runtimes only. Existing buyer automations and seller workflows do not change, and sellers have no new UI, ranking, inventory, or authorization effect. There is no pricing, entitlement, billable-surface, or Interchange Unit impact. The hosted-runtime handoff guide documents the orchestrator-only flow and its fail-closed binding prerequisite.
• Configured means an orchestrator has provisioned an active runtime-token binding for an installation; using means it has successfully minted or refreshed a runtime token. Track successful provisioning, mint, refresh, and runtime-token authentication events, alongside rejected mint/refresh requests and lifecycle-invalidated token attempts, before expanding hosted creation.
• Storefront connections now use AdCP 3.1 by default. Requests pinned to stable AdCP 3.2 use the compatible 3.1 contract, while prerelease 3.2 requests return a clear unsupported-version error. Clients already using an advertised Storefront version do not need to make any changes.

​

5.444.0 — September 13, 2026 at 10:36 AM UTC

• On /mcp/v3, documentation search now prioritizes public guidance for the active Buyer, Seller, or Organisation account and explains each result’s relevance. MCP builders can pass docsScope: "public_research" to search across all public documentation; this changes discovery only and never grants access to private content or customer objects. Existing clients need no action, and the change does not affect how buyers see sellers.

​

5.442.7 — September 13, 2026 at 8:17 AM UTC

• update_campaign now always protects against two concurrent updates to the same campaign silently overwriting each other. Previously, this concurrency check only ran when the caller supplied expectedRevision; now the campaign’s own revision is always used as the check, even when the caller doesn’t. If a concurrent update wins the race, you now get a 409 CONFLICT telling you to re-read and retry, instead of silently reverting the other request’s already-applied change.

​

5.442.4 — September 13, 2026 at 6:52 AM UTC

• Murph escalation triage now probes only public, credential-free URLs, validates every redirect, and pins validated DNS destinations before connecting.

​

5.442.0 — September 13, 2026 at 5:15 AM UTC

• Printable discovery-card downloads now allow a cold browser start up to 15 seconds before timing out.
• Amazon campaign end dates now stay on the selected UTC calendar day when media buys are updated. Nothing to change on your side.
• Murph chat recents remain responsive when an older conversation needs its title repaired and its account details are unavailable.
• Show a current first-party Discovery submission package as ready for the OpenAI portal without requiring a second custom app hostname.
• New Listing + Distribution offers include unlimited self-serve advertiser invitations and management instead of a ten-advertiser allowance. Existing accepted and negotiated offers continue to use the self-serve advertiser capacity stated in their terms.

​

5.441.3 — September 13, 2026 at 4:28 AM UTC

• Sellers with a configured third-party Agent source can now view bounded physical transport attempts alongside logical Calls in Murph. Source-attributed and shared-Agent evidence remain separately labeled, and an evidence-read outage does not hide the existing Calls view.
• Buyer-side behaviour is unchanged. This adds no billable surface, packaging, unit economics, or product differentiation. It introduces no new adoption event because it is an additive view within an existing diagnostic journey; the existing authenticated request-audit record for GET /api/v2/murph/agent-debug-calls, together with the returned bounded transport-attempt counts, provides the usage and acceptance signal.
• Storefront Agent Page access now follows a stable application-owned account profile, preserving the existing experience independently of analytics targeting changes.

​

5.441.2 — September 13, 2026 at 3:48 AM UTC

• Verify the active platform route before atomically transferring first-party Distribution hosting, so a public listing cutover can complete without requiring the replacement route to be live first.

​

5.440.0 — September 13, 2026 at 2:32 AM UTC

• After completing buyer qualification for the pre-launch program, the success screen now makes clear that your details are still under review and that the solutions team will follow up.

​

5.439.0 — September 13, 2026 at 2:13 AM UTC

• Keep non-interactive creative upload deeplinks on the requested advertiser and campaign while the buyer workspace initializes its chat scope.
• In v3 MCP, you can now use save_advertiser to create, update, and archive test-only sandbox advertisers before claiming your buyer operator identity. Nothing changes unless you want to test in sandbox; live advertisers and all other readiness requirements still apply.

​

5.438.0 — September 13, 2026 at 1:36 AM UTC

• Organization administrators can register an Agent’s current observed implementation as an immutable production revision without interrupting active Inventory Sources.

​

5.437.0 — September 13, 2026 at 12:55 AM UTC

• Buyer integrators now have one architecture guide that distinguishes an interactive MCP client or application from a registered buyer agent, while covering external-agent administration, optional creative pipelines, the portable asset-and-creative handoff, hosted-orchestration limits, approval boundaries, launch confirmation, and reporting ownership.
• MCP v3 now lists both Buyer and Seller tools for people who can operate in both account kinds, while each call remains authorized against the selected account.
• Sponsoring sellers can now edit a client’s self-serve campaigns directly from the shared rail — no need to route changes back through the client. Every edit made this way is labeled “Edited by [seller organization] (operator)” so both the client and the seller always know who made the change.
• Persona pass.
• Seller: can make the same campaign changes available to its client from the sponsored Campaigns Page. No separate setup is needed.
• Sponsored self-serve buyer: sees each sponsoring-seller edit in campaign history as an operator action, including the seller organization. The buyer can continue editing the same fields itself and needs no action.
• Packaging and monetization.
• No pricing, entitlement, or metering change: this extends the existing seller campaign-management workflow for an already sponsored self-serve account.
• Availability and exposure.
• This ships without a new flag because the request is already parameter-gated: only an active sponsorship, the seller’s existing campaign-management capability, a self-serve child advertiser, and the seller-owned Storefront prove access. It does not expand to External, Delegated, advertiser-scoped, or child-bound principals. The current ruling is the expansion boundary; a future product decision may limit it to oversight-only fields. Immediately suspend the sponsorship or the seller’s campaign-management eligibility to remove access.
• Measurement.
• Acceptance: a sponsored seller can edit an eligible client campaign and both the client history and seller activity list show the operator line; every ineligible principal is denied.
• Adoption: first successful save_campaign or save_advertiser audit record with parameters.operator.role = operator per sponsoring seller.
• Usage: successful operator-attributed campaign edits per sponsored buyer account, monitored alongside denied scope proofs and write failures.

​

5.436.0 — September 12, 2026 at 11:38 PM UTC

• Seller administrators can now complete Distribution and ChatGPT setup in the Branding & distribution Page, while technical operators can run the same guarded steps with an MCP agent. Both paths edit one shared storefront profile and clearly separate it from ChatGPT-only category, hostname, verification, reviewer access, and submission-package settings. Leave both icon overrides empty to use resolved brand identity automatically, or upload both the directory and composer PNGs; new one-sided manual uploads are rejected. Existing one-sided icon setups continue working during migration, so existing apps need no action. Printable PDF cards remain a Page-only download so their bytes never enter an agent conversation.

​

5.435.0 — September 12, 2026 at 11:16 PM UTC

• In Interchange’s buyer console, the Agents page now shows a buyer agent’s name, lifecycle state, credential count, and advertiser-access summary in one place, and lets an administrator rename it, or suspend, resume, and retire it directly. Suspending or retiring still requires retyping the agent’s exact name and retiring is permanent — none of this changes advertiser access or billing; access is still granted separately on the Access tab.

​

5.434.0 — September 12, 2026 at 10:40 PM UTC

• Directly authenticated buyer-organization administrators can now create an external buyer agent, rename it, set its exact advertiser access, and suspend, resume, or retire it from their agent workflow. Hosted buyer-agent creation is not available here, and existing agent connections do not change. Start with the buyer-agent credentials guide. This does not change what buyers see about sellers, seller storefront presentation, or seller setup.

​

5.431.0 — September 12, 2026 at 8:10 PM UTC

• Allow V3 connections to switch accounts before Terms acceptance so they can reach the account that needs setup and inspect its next action.
• Return an authenticated Interchange upload deeplink when an MCP client cannot render the creative upload Task, preserving advertiser and campaign context.

​

5.430.0 — September 12, 2026 at 7:40 PM UTC

• The Listing page now separates the current listing status from its publish destinations. A printable card appears only after a revision is live, and a failed publish names the attempted destination while keeping the confirmed status visible.
• ChatGPT setup now leads with one next action, with detailed configuration under App details. Temporary reviewer-status failures can be retried, while a missing entitlement points to Plan & Billing.
• No action is required. Buyer-facing discovery results are unchanged.
• When you ask Murph to find advertising options, it now follows the same search while sellers respond and keeps earlier options as more arrive. It tells you whether a search finished with no matches or is still waiting, and checks that your selections belong to that search before saving them. You can correct a request rejected before the search starts and continue in the same conversation. No setup is required.
• For buyers using REST, MCP, or server-to-server integrations outside Murph, continue using your client’s polling policy and the existing execution ID, campaign revision, idempotency key, and result cursors. This update adds no required request fields or integration setup; direct clients still control their own waiting and retries.
• Sales Agent validation from the Agent Page and Source Diagnostics now keeps one deterministic run in flight per action and returns its run-specific zero-model-token receipt.

​

5.428.0 — September 12, 2026 at 6:28 PM UTC

• Scrappy builder and power-buyer teams can now inspect a registered buyer agent in the Interchange API, including its identity, lifecycle, active credential facts, exact advertiser grants, and notification configuration. It gives the people building and testing an automation one place to check what Interchange recognizes without treating a credential or organization membership as permission to buy.
• Existing integrations require no change. Access remains limited to directly authenticated organization administrators and an agent reading only its own record; advertiser access remains an explicit grant. Enterprise, agency, and chat buyer workflows do not change. Sellers’ storefronts, inventory, ranking, and seller-facing experience do not change. This is included with the existing buyer API: it adds no entitlement, price, billing, or Interchange Unit use.
• The capability is alpha and structurally admin-gated, with no deployment flag. It is an atomic release: expansion is limited to eligible directly authenticated organization administrators after direct-human authorization, cross-organization isolation, zero-authority behavior, and grant-readback validation pass. Any unexpected authorization, cross-organization result, or authority without an explicit grant pauses the release and triggers rollback of this buyer-agent read surface; existing authentication and buying workflows remain available.
• We will measure first buyer-agent inspection per organization as adoption; repeat buyer-agent readback as usage; and buyer-agent read failures, grant-readback failures, and rejected non-direct-human, cross-organization, or over-broad search requests as guardrails. At 30/60/90 days, review adoption, repeat use, error/rejection rates, and whether documentation clarifies the common safe setup question; none of these signals weakens the authorization boundary.
• Add revision-fenced advertiser access editing to buyer-agent management.
• Buyer-agent administrators grant each connected agent read or read-write access to exact advertisers from the agent’s Access tab; the editor keeps unsaved changes until Save or Discard and reloads on a revision conflict.
• Sellers are not affected: this changes only a buyer organization’s own agent-to-advertiser grants and nothing a buyer sees about a seller.
• Monetization: no new billable surface. Advertiser access control is part of the buyer-agent management included with the buyer plan; it makes hosted and external agents safe to connect, which is the precondition for agent-driven spend on the platform.
• Creative submissions to direct provider storefronts now use the authenticated provider account through manual review instead of incorrectly requiring a managed storefront account grant.
• Fixed an Interchange-side response handoff delay that could incorrectly mark configured seller storefronts unhealthy during account-scoped product discovery. No seller action is needed; submitted-task recovery and retries retain the original account context.

​

5.427.0 — September 12, 2026 at 5:05 PM UTC

• No action is needed. Reporting polls for configured Agent sources now leave safer, more complete diagnostic evidence for support investigations, and reporting continues even when that evidence cannot be recorded.

​

5.426.0 — September 12, 2026 at 4:24 PM UTC

• Buyer access links from Scope3 now open the Interchange signup flow directly, preserve campaign attribution through sign-in, and collect the same required qualification details on every waitlist path.

​

5.425.0 — September 12, 2026 at 3:56 PM UTC

• Buyers can now configure per-campaign autonomy settings on save_campaign that persist across sessions. Two independent dimensions — inventorySelection and rebriefing — each accept one of three modes: manual (buyer acts), propose (agent drafts, buyer approves), or automatic (agent acts without per-action confirmation). The preference survives session restarts; omitting a dimension on update leaves it unchanged.
• Sellers are not affected: autonomy is buyer-configured campaign behavior with no seller-visible effect on storefront, ranking, or presentation.
• Plan & Billing no longer shows an empty Orders & quotes card before that functionality is available. Pending IU offers remain under Plan & pricing, and accepted plans remain in IU plan history. No action is required.
• V3 buyers can inspect a selected product’s declared demographic-overlay support and age ranges while reading proposals. When capability details do not fit in one result, a signed cursor returns the next page from the same completed request or saved proposal and identifies when the result is complete.
• This is discovery and readback only. It does not activate public AdCP 3.2 execution or send demographic selections to sellers: application seller transport remains on AdCP 3.1, so save_media_buy rejects demographic overlays before seller dispatch. Existing seller request shapes do not change.
• There is no plan, entitlement, pricing, or usage-charge change in this slice. Existing save_media_buy calls without demographic age-range selections are unchanged.
• Sellers: No action is required. Buyers can read existing declared capability facts, but Scope3 does not send a new demographic targeting request to an existing seller connection.

​

5.424.0 — September 12, 2026 at 2:50 PM UTC

• Your campaigns can now carry structured targeting intent. Pass a targeting object to save_campaign on the V3 MCP surface (/mcp/v3) and the campaign stores it — geography (countries and DMAs), language, device type (CTV, mobile, desktop), daypart, and demographic dimensions. Targeting is returned in the campaign workspace so any subsequent read sees what was set.
• For teams managing multiple campaigns at scale, targeting intent travels with the campaign object in a single workspace read — no separate lookup needed. For programmatic integrations, each dimension is an array of requirement entries with a stable requirementId, a strength of required or preferred, and the values to include or exclude; update targeting by calling save_campaign again with the revised object. For buyers working through Murph or a chat surface, targeting set via the tool appears in the campaign workspace immediately.
• The targeting parameter is optional — existing calls and campaigns are unaffected. Sellers: this is buyer-side only and does not affect storefront ranking, readiness, or presentation. Delivery enforcement is tracked separately and is not yet active.
• This ships ungated: targeting is purely additive. Every buyer account can use it from day one; callers that omit the field see today’s behavior unchanged. No billing change — targeting is campaign metadata, not a separately metered surface.
• Murph now routes unqualified questions about what teammates were chatting about to conversation search and shows safe evidence from the title, participant, or message that matched, including older message matches outside the recent transcript preview. This lets Murph answer from the result instead of trying Slack or incorrectly reporting that only recent messages were searched.
• Buyer agents can now configure campaign optimization goals through save_campaign on the V3 buyer surface. Supply optimizationGoals as a ranked array — the primary goal is at index 0, with up to 10 goals total.
• Two goal kinds are supported. An event goal targets conversion events delivered by configured event sources, with optional cost_per, ROAS, or maximize_value targets and attribution windows. A metric goal targets a seller-tracked delivery metric (clicks, views, completed_views, viewed_seconds, attention_seconds, attention_score, engagements, follows, saves, profile_visits, reach), with optional cost_per or threshold_rate targets.
• Campaigns that do not include optimizationGoals are unaffected — seller execution for those campaigns is unchanged. Sellers receive the ranked goal list during campaign execution and apply it within their delivery capabilities. This is a buyer-configured field; seller-side delivery behavior is governed by each seller’s own optimization support.

​

5.423.1 — September 12, 2026 at 12:43 PM UTC

• Creative uploads opened in Claude can now send selected files directly to private storage, and failed browser transfers are reported to operators without including creative content, filenames, or signed upload details.

​

5.423.0 — September 12, 2026 at 11:17 AM UTC

• Clarify neutral no-match, stalled, and genuine run failures in seller run details, with safe recovery guidance and recorded buyer identity. Buyer identity remains available only to the authorized seller of the recorded storefront; this introduces no buyer-facing lookup or inferred account mapping.
• Browser SSO sign-ins now complete reliably. Existing sign-in methods are unchanged.
• Asking an AI agent to “show me all sellers” no longer triggers both a seller search and the Connections page at the same time. The agent now routes seller and connection discovery exclusively through open_connections_page. No changes required for programmatic callers — search(kind: seller) and search(kind: connection) remain valid on the V3 wire contract.
• The save_campaign tool now correctly labels flight dates as datetimes and rejects a start in the past, preventing the midnight-UTC same-day start bug and grounding date arithmetic.
• get_products (and discover-products) no longer stalls a cold-start caller with an opaque advertiser-context error. If your account has exactly one active advertiser we now use it silently, so a request with no ext.interchange.advertiser_id, X-Advertiser-ID, or advertiser-scoped credential just works. If your account has several (or none), the error now names each candidate as adv_<id> so your agent can pick the right one on the next call. Explicit sources still win — no change is required if you already pass an advertiser id.
• If your seller account is outside a request’s market or channel, you will no longer receive a brief for that request. No action is needed from sellers, and buyers have no new workflow or action to take.
• The Merchandising Agent interview now separates facts awaiting confirmation and gaps that block a practice brief from optional delivery setup needed only before live activation. Practice proposals also distinguish source-backed facts, assumptions, and manual confirmation instead of inventing commercial or delivery details.
• Product Marketing now summarizes confirmed selling points, pending reviews, processing material, and recorded gaps before you inspect each source.

​

5.422.0 — September 12, 2026 at 10:17 AM UTC

• Buyer delivery reports now show flight-to-date totals when sales agents send daily delivery using an end-exclusive reporting window. Daily buy and package counters are retained in the delivery ledger and accumulated across the flight; no action is required from buyers or sellers.
• Through the V3 MCP, seller agents can now find and inspect seller-owned account relationships with external buyers, admit or decline seller-controlled pending requests through save_seller, and open the existing relationship-scoped Media Buys and Delivery page. Decisions use the request’s current version, so stale writes cannot overwrite a newer decision. Existing relationships and buyer-side admission behavior are unchanged; no action is required unless you want your seller agent to use this workflow.
• Campaign reads now include a readiness field with a status (ready or not_ready) and specific reasons (no_budget, no_staged_buys, flight_not_started, flight_ended, advertiser_missing) so agents can give buyers actionable next steps instead of showing a misleading active phase when the campaign cannot actually deliver.
• Campaign delete no longer holds the budget lock while issuing upstream cancel requests to the seller ad server.
• The lock is now committed before each seller cancel call and re-acquired for the final check and archive write. This removes a latency spike that could block concurrent campaign edits for the full duration of a seller-cancel round trip.
• Ask Murph keeps your latest sent message and its response visible while the response or an in-chat widget loads more content. Scrolling up to review earlier messages still pauses automatic following until you return to the bottom.
• Snap media buys targeting Australia exclusively now automatically include only 18+ audiences to satisfy Snap’s Australian minimum-age regulation. If you explicitly request 13-17 targeting on an AU-only buy, the buy is rejected with a clear error before it reaches Snap.
• Snap media buys no longer fail creation with a generic “The ad platform rejected the request as invalid” error caused by Snap rejecting our targeting-expansion shape as internally contradictory. The adapter now sends the standard “no expansion” signal instead of the regulated-sector-only shape it was previously using by default.

​

5.419.0 — September 12, 2026 at 1:08 AM UTC

• Murph now makes one tool-capable recovery attempt with an independent model when its primary model cannot complete a response. Account lookups and actions keep the same authorization and confirmation checks, with nothing to change on your side.
• Creative observation no longer reports the analytics beacon Cloudflare adds to pages on the Interchange render origin as a domain the creative called or as a tracking pixel. Only that injected script and its beacon post, issued from the render origin’s own frame, are left out. Requests the creative makes from its own page, including to the same hosts, are still recorded; a creative that embeds Cloudflare Web Analytics inside the render frame itself is the one case the observer cannot tell apart.
• Seller Agent navigation controls now have accessible labels for assistive technology.
• Show preview on the Approvals page in the Interchange web app now loads the creative’s live preview. The web app’s widget host refused every frame, including the render origin, so the preview panel fell back to “Nothing to preview for this format”. The host now allows the frames a widget declares, and nothing else.

​

5.418.0 — September 11, 2026 at 11:22 PM UTC

• Organization administrators can now grant a buyer agent access to specific advertisers as read-only or read-write through the buyer-agent principals REST API. Changes take effect on the agent’s next advertiser operation and notification-delivery attempt.
• Buyer agents without configured grants cannot access advertisers. Registering an agent, issuing credentials, or organization membership does not grant advertiser access. This buyer-side control does not change sellers’ storefronts, inventory, ranking, or buyer-visible seller information.
• Campaign creative creation and updates now map uploaded files to declarative repeatable format slots, including carousel cardinality validation and correction controls.
• Proposal PDF downloads render correctly in common PDF viewers.

​

5.417.0 — September 11, 2026 at 9:59 PM UTC

• On the shared /mcp/v3 connector, select a buyer-owned advertiser to upload a local JPEG, PNG, or, for enrolled buyers, MP4 to private storage. Each upload is bound to the buyer, authenticated principal, and advertiser; it neither selects a destination nor confirms provider delivery. Finalized JPEG/PNG sources can be adopted through save_creative. MP4 remains upload-only on V3 pending explicit human approval of its adoption contract. The V2 provider-bound Legacy adoption path remains a separate handoff and is never a fallback.
• Activity’s Calls API now returns an mcpHost hint for newly recorded MCP calls when it recognizes a host, such as ChatGPT or Claude; accounts with the Calls view enabled see the same label there. The caller supplies this diagnostic hint, so it is not identity or authorization evidence; it is null for older calls, non-MCP calls, and unrecognized hosts. Nothing to change on your side: use the Calls API, or Activity’s Calls view where it is available, when you need to inspect the hint.
• Proposal composition now keeps a dedicated verification window after corrective model passes, preventing valid corrected proposals from falling back because generation consumed the verifier’s entire time budget.

​

5.416.2 — September 11, 2026 at 8:25 PM UTC

• Keep seller setup tasks and collapsed widget expand controls available before a chat begins.

​

5.416.1 — September 11, 2026 at 7:46 PM UTC

• Branding & distribution now opens Plan & Billing reliably and lets every eligible Public storefront request and revoke its own ChatGPT reviewer sandbox. No action is needed.

​

5.416.0 — September 11, 2026 at 6:29 PM UTC

• Preview structurally valid modular inventory rows before catalog proof is complete, while keeping unresolved rows unavailable to buyers until their publisher, property, and format declarations are verified. Seller agents can also update an existing modular source module’s non-secret configuration through the typed inventory-source save flow.
• The buyer and storefront API specs grew: shapes reused across the document are written out at each usage site, and Zod 4.5 reuses more aggressively than before, so the buyer spec restates its 78 distinct regex patterns thousands of times. The two largest offenders — the AdCP product’s placements and format_options — are now published once each, as AdcpProductPlacements and AdcpProductFormatOptions, and referenced from the product schemas rather than repeated inside them. That recovers about 73,000 lines. No existing schema component was removed or renamed, and nothing about what the endpoints accept changed.
• Three GET /activity/calls query parameters — includeDiagnostics, includeProtocol, and includeInternal — now publish as boolean rather than as a string enum of "true"/"false", which is what they always were on the wire. Regenerate your client to pick up the corrected type.
• Integer lower bounds now render as exclusiveMinimum where they previously rendered as an inclusive minimum one value higher. The accepted values are identical; only the spelling in the spec differs. Request validation also got substantially faster, most noticeably when rejecting a malformed request.
• Campaign resume now skips media buys that were paused directly by the buyer.
• Previously, resuming a paused campaign would reactivate all paused media buys, including ones the buyer had explicitly paused. Resuming a campaign now only reactivates buys that were paused as part of the campaign pause. A buy the buyer paused individually stays paused after a campaign resume.
• A new pausedBy field on the media buy surface shows whether a buy was paused by the buyer directly (buyer) or by a campaign pause action (campaign).
• When a seller sends an updated offer across negotiation rounds, each version is now stored separately and linked to the one it replaced. You can retrieve any round’s proposal and trace how the seller’s offer evolved — earlier versions are no longer silently overwritten. Nothing to change on your side; proposal history is tracked automatically.
• Snap media buys submitted with start_time: "asap" (the default meaning “start immediately”) now correctly submit an ISO timestamp to Snap instead of the literal string, so they no longer fail with a generic error on creation or update.
• Snap media buys using automatic bidding — the default for nearly every Snap product — now create successfully instead of failing with a bid-price error. Nothing to change on your side.
• Invitations now keep the intended account email design when resent, use a saved Dutch language preference when available, and render transactional email chrome from centrally configured branding. An invitation opened with a different authenticated email now explains the mismatch and alerts compliance while keeping access locked to the invited address.
• Embedded sales agent 1.43.2: resolve FreeWheel creative nodes from Placement readback.
• Restored the Merchandising Agent interview as the eligible seller’s bare-chat value layer alongside the current seller setup navigation. Sellers first encounter it on initial login and can return whenever the chat canvas is empty to teach the agent how their business sells or test it with a real buyer brief; sellers without product-composition capability retain the neutral home experience.
• get_delivery({ report: "campaign_delivery" }) on /mcp/v3 now accepts range: { lifetime: true } for the campaign’s full delivery history and echoes the resolved window as period; every response carries totals over all matched rows (money is unavailable when rows span currencies); and two new dimensions, seller and sales_agent, group delivery by the storefront and AdCP sales agent a buy ran with.

​

5.415.0 — September 11, 2026 at 12:37 PM UTC

• Buyers and sellers can now select All in Murph’s recent chats list to search and reopen past conversations for the account, advertiser, or storefront they are viewing. Earlier conversations are included; results never leave the selected scope, and nothing needs to change on your side.
• For enterprise brand buyers, this keeps previous work visible within the advertiser their media organization is reviewing. Agency buyers can return to a prior account or advertiser conversation without hunting through recent chats. Hands-on buyers can quickly pick up an earlier task, and newer Murph users will simply see All as another way to find a chat they already had. For sellers, this changes only their own storefront conversation history; it does not change what buyers see about a seller or storefront.
• Monetization: none — this ships with existing Murph access and adds no plan, entitlement, packaging, or billable-surface change.
• Clarified that campaign-level frequencyCaps is enforced through Scope3’s own cross-publisher exposure tracking and cannot be honored at request time by closed-platform integrations (TikTok, Meta, Snap, Pinterest, Reddit, Spotify, Amazon, Google, LinkedIn). To set a native per-publisher frequency cap on one of those platforms, use targetingOverlay.frequency_cap on the product instead.
• Selected sellers now activate every eligible advertiser through the canonical account connection, including storefronts without a legacy sales-agent record. New advertisers are picked up while the seller remains selected, blocked sellers create no new advertiser accounts, and failed activations show a support code for diagnosis. Nothing changes on your side.
• The Public Distribution upgrade action in Listing now opens Plan & Billing instead of showing an error.
• The v3 buyer skill now explicitly instructs agents to poll a running proposal execution by calling request_proposals again with the same campaignId, expectedCampaignRevision, and idempotencyKey, matching the tool’s own response text. The previous wording (“reuse the idempotency key to poll”) was vague about which tool to call.
• Murph buyers. In-progress seller results now continue on the same product query instead of restarting. When you select a returned product, Murph carries that selection into the campaign without rerunning discovery. There is nothing to change on your side.
• Direct V2 API and MCP integrations. Reuse the original execution ID when checking progress. To attach a selection, set productQueryId to that execution ID and include the returned storefront-qualified product or proposal IDs, as applicable. Legacy executions without saved accepted proposals still require a fresh product query and buyer re-selection.
• Direct V3 integrations. Retry in-progress proposals within a bounded polling policy using the same campaign ID, expected campaign revision, and idempotency key. No endpoint or schema change is required.
• Murph sellers. An inventory-source diagnostic that records its test run and source-health result now asks for confirmation before it starts. Read-only inventory-source checks remain confirmation-free, so only diagnostics that save a result add this approval step.
• You can now guarantee that specific reusable Library slides appear in a composed proposal. When you call save_rfp with create or append_turn, pass requiredLibraryUnitIds with the exact identity of each unit (materialId, unitId, renditionRevision). Only slides, pages, or sheets you have marked reusable, that carry no pricing, and that are currently available in your Library qualify; anything else is rejected with a validation error before composition starts. The buyer’s proposal then always carries those Library blocks unchanged, including when the composer falls back to the deterministic response, and the turn receipt records them as seller-required rather than model-selected. Leave the field out and proposals compose exactly as they do today. Details are on the Seller RFP lifecycle docs page (/v2/setup/v3/rfp-lifecycle).
• Launching a campaign from your agent now shows you exactly what would go live before anything does.
• What changes for you
• The launch preview lists the media buys. Asking to activate a campaign without confirming returns a preview that names each staged media buy that would go live, its budget and seller, and the combined budget across them, alongside the campaign budget and flight. Nothing is launched by that call.
• The confirmation step is explicit. The preview tells your agent the exact follow-up call — the same request with confirmLaunch: true and the previewed revision — so a launch always takes two intentional steps: see it, then confirm it.
• Budgets in different currencies are never added together. If the staged buys settle in more than one currency, the preview totals each currency separately instead of inventing a single number.
• Do you need to do anything?
• No. The confirmation field already existed; this release makes the preview complete. Agents that already confirm with confirmLaunch: true keep working unchanged.
• Sellers: not applicable.

​

5.414.0 — September 10, 2026 at 11:54 PM UTC

• In the Buyers tab, select an external buyer to see the media buys delivering on your inventory — impressions, seller-reported net spend, progress toward the seller-visible booked budget when available, and the latest reported delivery day. Nothing to configure. Buyers awaiting admission and buys without a delivery report remain clearly unavailable rather than showing zero.
• Clarify available IU offers, current plans, and the no-plan state.
• Keep the Available balance explanation visible inside its overview card.
• Open balance details directly at Standing & funding.
• Give Interchange and media invoice activity distinct section headings.
• Label unbound IU accounts as having no paid plan instead of pay-as-you-go.
• Explain the action or payment issue causing an account to need attention.
• Creative sync now succeeds for media buys placed through a connected ad-server account (Google, Meta, Snap, TikTok, Reddit, Spotify, Amazon, or AudioStack). Previously, creatives could silently fail to sync to these media buys after they were created. Nothing to change on your side.
• The Sellers page now tells you to add an advertiser’s markets and channels instead of saying sellers don’t match, and offers the setup step.
• Managed storefront creative syncs now reuse approved account links when creatives are saved again or explicitly resynced. Incomplete links are blocked before sync starts and return an actionable account or seller-mapping error.
• In a storefront’s Advertisers tab, Sellers now opens the advertiser’s sellers page instead of doing nothing.
• A media buy whose underlying source connection was removed or never fully configured no longer stays stuck indefinitely with a status that never updates — it now resolves to canceled after a bounded number of retries. Nothing to change on your side.
• Corrected composed-product prices so size-specific rate-card facts apply only to products that actually include those selected creative dimensions.
• Preserve organization-local browser history while moving between billing tabs.
• Use Available balance consistently across Plan & Billing.
• Show billed Intelligence Units on Overview instead of provider operating cost.

​

5.413.8 — September 10, 2026 at 11:09 PM UTC

• When Murph is waiting for a storefront during product discovery, it now continues the same search instead of treating a provisional empty response as final or starting over. Direct API responses are unchanged, and there is nothing to change on your side.

​

5.413.0 — September 10, 2026 at 11:57 AM UTC

• Enterprise buyer teams can govern their buyer agent’s organization-owned machine notification subscriptions through the buyer API. Teams building their own buyer-agent integration can create or replace, pause, reactivate, remove, and non-business-test an endpoint. Changes are fenced, endpoint credentials remain write-only, and only deliverable event types are offered. This does not change any seller-owned account or destination.
• See a clearly labeled fictional Storefront before creating an account. This display-only walkthrough uses preloaded sample data, runs no analytics, and saves nothing. Create an account to add your inventory or connect a production system.
• Campaign creative creation and updates now map uploaded files to declarative repeatable format slots, including carousel cardinality validation and correction controls.
• Updating a campaign’s country or region targeting (constraints.geo_countries / constraints.geo_regions) now correctly applies to media buys that are already live, instead of only affecting future product discovery. update_campaign reports the outcome per media buy (applied, unchanged, or rejected) so a targeting change a seller can’t accept on an already-live buy is never silently dropped. Sellers see this the same way they already see any other live targeting change: through the existing per-package targeting-overlay update.
• Separately: any update to a campaign — not only ones that change targeting — now returns 409 CONFLICT if it arrives while another update to that same campaign is still being applied, instead of racing it. This closes a gap where an unrelated concurrent change (for example, a rename) could silently undo a targeting change that had already taken effect. If you see this error, retry the request.
• Proposal PDF downloads render correctly in common PDF viewers.

​

5.411.0 — September 10, 2026 at 8:18 AM UTC

• Campaign creative format pickers now show only formats declared by that campaign and preserve the selected canonical option identity.

​

5.410.2 — September 10, 2026 at 7:31 AM UTC

• Listing + Distribution now unlocks automatically once an account has the package’s distribution entitlements. No action is needed.
• When a creative submitted to your storefront cannot be filed for review, the failure is now recorded with its reason instead of disappearing. The buyer’s sync result names the creative and carries a typed error, and the storefront operator sees the exact cause in logs and error tracking, so a creative that never reached your Approvals queue can be traced rather than guessed at.

​

5.410.1 — September 10, 2026 at 6:23 AM UTC

• update_media_buy errors are more actionable, with no change to which requests are accepted or rejected. An unsupported update field now tells you to remove that field and resubmit the rest of the request separately, instead of a generic “Upstream request failed”. A package creative that fails format-compatibility validation now names the exact creative and the reason it was rejected, instead of a generic “does not match its product’s canonical format options” sentence.

​

5.410.0 — September 10, 2026 at 5:53 AM UTC

• Fixed creative assignment to a Meta-backed media buy, which failed end-to-end after Meta rejected sync_creatives for requesting webhook completion tracking it doesn’t support, and then rejected the update_media_buy fallback too. Creative sync to a synchronous adapter-backed storefront (Meta, and any other first-party ad-platform connection) no longer requests webhook tracking meant for asynchronous external sales agents, so sync_creatives now completes directly.

​

5.409.0 — September 10, 2026 at 5:02 AM UTC

• Pass a finalized private JPEG or PNG upload as sourceAssetRef to save_creative to create a durable Creative; existing calls are unchanged. Interchange confirms that the upload belongs to the connected account and the Creative belongs to the advertiser, then saves a managed copy. For source provenance, the Creative stores only a one-way fingerprint, never the private source reference or a signed storage URL. The upload Task activity keeps the private reference available until the handoff completes. Retrying the same source and name returns the same Creative, and you can optionally associate it with a campaign. Raw REST creative creation and package or media-buy attachment remain separate.
• Storefront discovery now retains submitted third-party seller tasks and continues them through account-scoped catch-up polling when an interactive deadline ends.
• Agent-composed proposals now allow the model up to 90 seconds before falling back to the plain summary, so a slow answer no longer discards the endorsed shape or Library material you asked it to follow.

​

5.408.2 — September 10, 2026 at 4:02 AM UTC

• When a proposal required to follow an endorsed response hits a transient verifier model error and time remains, it now gets one more verification pass instead of falling back to the plain summary. Proposal receipts identify verifier outcomes and retain the cost of verification passes even when the proposal falls back.

​

5.408.1 — September 10, 2026 at 3:24 AM UTC

• A product you price on your ad-server source, or that carries a platform-derived floor, can now be pitched by the proposal composer, and its product page shows the same completeness verdict the composer uses. A bare non-fixed rate without a fixed or floor price is not quotable.
• Media buys created directly against a Meta, TikTok, Snap, or other platform-adapter storefront now record their routing correctly, so creative sync and other post-buy operations can find them instead of silently failing.

​

5.408.0 — September 10, 2026 at 1:52 AM UTC

• Products from Google Ad Manager now carry a channel inferred from an unambiguous canonical creative format when the source leaves channels blank. You can also set channels yourself when saving a product, and the proposal composer can pitch those products once a complete price is present.
• Correction: uploaded TikTok creatives are still affected. Release 5.404.0 reported this as fixed, and that was incorrect.
• Release 5.404.0 said uploaded TikTok image and video creatives now become ads, and gave TikTok’s media processing time as the reason they previously did not. Both statements were wrong. Uploaded creatives still reach your TikTok creative library and are still not attached to an ad.
• Nothing you uploaded has been lost. Those creatives are in your TikTok creative library and remain usable directly in TikTok Ads Manager in the meantime, and no action is needed from you. We are still working on the underlying cause and will report again only once it is confirmed working end to end.
• Buyer administrators with publication access can now open Branding & distribution from their designated account. No action is needed.
• Inventory Selector can now open the secure ad-server connection task when an ad server needs to be connected.
• Google and SSO signup now moves directly to company confirmation while company research runs in the background. Academic mailbox subdomains are normalized to their institution domain and treated as affiliation context, never evidence of a sell-side media business.
• When you endorse a response and a later brief fits it, the composed proposal now follows that endorsed shape instead of falling back to the plain summary.

​

5.407.1 — September 9, 2026 at 9:22 PM UTC

• When a media buy uses a seller creative library, retries now reference existing creative IDs instead of resending them as new creatives. Inline delivery for sellers without a creative library is unchanged, and buyers do not need to modify their creatives.

​

5.407.0 — September 9, 2026 at 8:19 PM UTC

• Murph can now accept WAV files that Slack or a browser labels with the common vendor MIME type, and a direct request in a Slack thread can use a file shared earlier in that thread.
• Campaigns, media buys, and advertisers on the v3 buyer surface now do what they say, and you can undo more without leaving your agent.
• What changes for you
• You can bring an archived campaign back. Restoring returns it as a draft, since its media buys were retired when it was archived. Stage inventory again before launching.
• You can fix or drop a draft media buy. Change its budget, bid, or pricing option, remove a line item, or archive an unwanted draft without touching the rest of the campaign. When the same product is staged twice, each line item now carries its own reference so you can point at exactly one. Anything the draft cannot absorb is refused with the field named, never silently ignored.
• Archiving an advertiser no longer hides its history. Its campaigns, media buys, and creatives stay readable (read-only until the advertiser is restored), and its name is free for a new advertiser. Restoring into a name that is now taken is refused with a clear conflict message.
• Archive several advertisers in one go. Ask once; your agent confirms the list once and reports each outcome. A long list that runs out of time tells you exactly which advertisers were not attempted, so you can retry just those.
• Offers do not silently expire while you decide. A product query left for over an hour is reopened when you stage from it, and an expired proposal says whether the seller’s validity or the 90-day window lapsed.
• Do you need to do anything?
• No. Everything in this release is additive or corrective; existing calls keep working.
• Sellers: not applicable. Nothing a seller sees about a buyer, a proposal, or a delivered buy changes.
• add_discovery_products now returns a distinguishable discovery_publication_orphaned error when the discovery snapshot never finalized, telling you to rerun get_products on the same discovery so the snapshot republishes — the session’s selected products and campaign attachment stay intact. Previously these attempts failed with discovery_pricing_superseded and the misleading advice to “retry against the current snapshot” — but no newer snapshot ever existed, so every retry was guaranteed to fail. The real transient race (a fresh publication is landing while your request runs) still surfaces as discovery_pricing_superseded and remains safe to retry. If your integration branches on error.details.reason, add a handler for the new discovery_publication_orphaned value.
• Invitation links now join you to the intended account when an organization has multiple accounts with the same name. No action is needed.
• Fixed a bug where campaign postal-code targeting for countries without a dedicated postal system (e.g. the Netherlands) could make list_campaigns fail to load for affected campaigns.
• For sellers enrolled in the limited Sales Library rollout, Murph chat now reliably saves material when you explicitly approve the supplied details, and proposal previews reliably use the response example you select. Buyers may see the proposal shaped by that selected example. No action is required.
• Agent-composed proposals can now follow your endorsed responses. Shaped by and Library blocks appear when a fitting endorsed pair or reusable Library material exists.
• If Source Diagnostics shows stale or conflicting health evidence for a sales-agent inventory source, you can refresh it with Murph or an MCP client. A fresh no-spend get_products check can supersede an older creative-sync failure, so your storefront’s readiness reflects the source’s latest observed catalog health. It does not change source configuration or create a media buy; review the timestamped receipt in Source Diagnostics. No refresh is needed when diagnostics does not request verification.
• This is an ungated (gate: none) atomic, read-only operational improvement for sellers with an already configured external sales-agent source: there is no staged audience expansion, billable surface, packaging change, or new entitlement. There is no runtime kill switch because it neither mutates source configuration nor spends; withdraw the tool in a follow-up release if it produces misleading evidence. For the first 30 days, review refresh invocation volume, successful durable receipts, and readiness-status changes. Success is replacing stale evidence with a current receipt without creating a media buy; investigate repeated failed or no-change refreshes in Source Diagnostics.
• Buyer reporting no longer fails an entire account’s metrics when a seller reported delivery spend in a currency it is not actually paid in. Those buys previously made /api/v2/buyer/reporting/metrics return SPEND_DENOMINATION_UNRESOLVED (and the timeseries view mislabelled their rows). The spend is now denominated by the currency the source settles in, when that is evidenced by money that actually moved — an FX lock or a booked spread-ledger leg: unchanged when it already matches the advertiser’s reporting currency, converted from the settlement currency when it does not. The deliveryFxConversion.source field gains a settlement value identifying spend denominated this way. Buys whose settlement currency cannot be established, and buys whose only settlement evidence is the product budget currency (a configuration value, not proof of what historical periods were paid in), still fail closed rather than guess.

​

5.406.0 — September 9, 2026 at 2:53 PM UTC

• Authenticated customer members can now search their own and shared Murph conversations by title, participant, or transcript text. V3 clients can also search and open a bounded conversation transcript; private teammate rooms and other accounts remain excluded, and service credentials without a member identity cannot read chat history.
• When a media buy or creative sync fails for a reason the buyer can fix, the error now carries a structured classification your agent or client can route on directly — no more regex on the human message.
• If your code doesn’t consume the new field, nothing changes. Existing error messages still render the same way, and the outer code on the error is unchanged.
• On a buy-flow failure the buyer can act on (creative dimensions don’t fit the packages, missing destination URL, budget below the source’s minimum, product no longer available, permission not granted yet, account not linked, etc.), the error now includes a buyer_reason sub-object with a stable code and a message safe to show to a buyer. It travels with a recovery classifier (correctable, transient, or terminal) so you can tell “fix and resubmit” apart from “wait and retry.”
• The same classification appears on each per-source entry when a fan-out mixed causes (one source rejected the creative, another was unavailable), and on each failed creative row on sync_creatives so a batch failure is per-creative traceable.
• The code follows the AdCP 3.2 error vocabulary; unknown codes are preserved end-to-end, so a newer source or a seller-defined extension flows through your client without upgrade.
• Read the current buyer_reason.code for programmatic routing and buyer_reason.message for the string you show a human.
• The Sellers page keeps loading when a connection is waiting for activation prerequisites. This does not change storefront readiness or how sellers are presented.
• ChatGPT app registrations that omit the deprecated upload fields now use the storefront logo from brand.json to generate directory and composer icons automatically, without requiring a separate rollout enrollment. Existing V2 upload callers keep working, and stored manual icons remain safe while their accounts migrate.
• A response you attached to a brief now shows as Paired on the Library page.
• Agent-composed proposals now complete the full model pass instead of falling back to the short summary, so Shaped by and Library blocks appear when an endorsed pair or reusable material fits.
• For sellers enrolled in the limited rollout, this restores reliable Murph chat support for saving shared material and using a selected response example while preparing a proposal. Buyers may see proposals shaped by the selected response example. No action is required.
• get_media_buy and get_campaign now include TikTok’s provider-confirmed targeting (country, age, gender, and audience) alongside what you requested, so you can verify what a TikTok media buy is actually targeting without checking TikTok Ads Manager directly. Previously this readback was never returned for TikTok buys.
• Seller Page search tools now keep their complete guidance on the wire instead of cutting off the final identity instructions.
• Published agreements now have permanent, hash-verified revision URLs. Current links continue to show the maintained version, while pinned links—including the Privacy Policy and Demo Environment Notice—remain tied to the exact published text for reliable citation and historical review. A corrected v2→v3 summary restores its originally approved “MSA equivalent” wording at a new revision URL while preserving the earlier published summary bytes.
• Account admins can now review people in a connected Slack support channel from Communications. Choose an account role to send an invitation, keep someone as a channel guest, identify an external company, or disconnect the channel. Joining a channel never grants Interchange account access; disconnecting it leaves existing account memberships unchanged.

​

5.405.0 — September 9, 2026 at 11:01 AM UTC

• The advertiser picker now opens on your only advertiser, or the one you used last, so you land in the right workspace without an extra click.
• Invited team members now land in their organization after verifying a new Interchange account instead of reopening an invitation after signup already granted access. Other post-signup destinations are unchanged, and there is nothing to change on your side.
• Invited team members can finish creating their Interchange account without a signup validation error. When the invitation already belongs to their resolved organization, signup no longer offers to create a duplicate organization. Nothing needs to change on your side.
• Fixed two related Meta storefront issues: resuming a paused campaign now activates its ad set and ad along with the campaign (instead of leaving delivery silently paused underneath a reportedly-active campaign), and syncing a creative to a package no longer requires the package to already be paused first.
• Prevent capability checks from reusing the tracking ID of a following seller mutation. Media-buy updates and account syncs with webhook callbacks now reach the seller instead of failing locally with a webhook-registration conflict.
• Nothing changes in the Interchange chat experience today. Teams using a buyer or seller MCP client can now continue a Murph conversation and read its display-safe history, while existing ask_murph integrations keep working. There is nothing to configure and no pricing or packaging change.
• For enterprise brands, this makes a Murph conversation easier to retain in their governed workflow. For large agencies, it gives teams a consistent way to resume the same conversation across their client tools. Builders can use the new chat and get_conversation operations, including standard progress and app-display support. For people using Interchange chat directly, the behavior stays the same and requires no action. Sellers receive the same client support; it does not change how buyers see their storefront or inventory.
• This does not yet add the Interchange agent picker, calls to installed buyer agents, or agent-initiated messages.
• Rollout is ungated because this is additive on Murph’s existing authenticated MCP endpoint and keeps its existing authentication, terms, and availability checks. Monitor successful and failed chat and get_conversation calls plus cursor/readback errors during the first seven days; only the later installed buyer-agent and picker slices expand the audience. Set MURPH_ENABLED=false to use the existing Murph kill switch if the profile needs to be withdrawn.

​

5.404.0 — September 9, 2026 at 8:40 AM UTC

• When you use an endorsed response example in a proposal, its “Shaped by” detail now stays visible. Murph also saves a complete Library dictation instead of replying without making the requested update. Nothing to change on your side.
• TikTok image and video creatives now become ads instead of stalling after upload.
• An uploaded creative reached TikTok’s creative library but was then reported as failed, so no ad was created and the media buy stayed in pending creatives. TikTok processes uploaded media asynchronously, and Interchange was reading back the result before that processing finished. It now waits for TikTok to confirm the media is usable before deciding whether a creative is live, and a creative that is briefly unavailable immediately after upload is no longer treated as missing.
• Recent chats in the rail are now named for what you asked, empty chats no longer linger, and the list shows your five most recent with an All view for the rest.

​

5.403.0 — September 9, 2026 at 5:48 AM UTC

• Snap media buys using a creative that wasn’t tied to a specific product at upload time — the common case for a general-purpose creative-library upload — now sync correctly instead of being rejected outright. We resolve the correct format automatically from the assigned product when it’s unambiguous. No action needed on your side.
• While a Scope3 administrator used view-as to view your account, they could have seen analytics from another account. This was limited to Scope3 administrator view-as sessions; other sellers could not access your analytics. Analytics now always belong to the account being viewed. There’s nothing for you to change—your own sign-in was never affected.
• The configured first-party distribution account can now open Branding & distribution from its account navigation even when that account is classified as a buyer. Other buyer accounts remain unable to open seller-only surfaces.
• Asking Murph about your Library now goes straight to your Library materials instead of first trying the advertiser creative library.
• Sellers who submit their storefront’s buyer agent to a public app directory now get a no-spend test advertiser inside that storefront and one read-only reviewer credential. Existing storefront configuration, customer advertisers, campaigns, billing, and delivery are unchanged; no action required.

​

5.402.0 — September 9, 2026 at 1:06 AM UTC

• Creative observation is now on for every seller, with no enrolment step. When a buyer submits a creative for your review, Interchange runs it once, headlessly, on its render origin and records what it actually did, and the Approvals row reads from that run instead of guessing from the source. Where thumbnail storage is configured, a picture of the frame appears beside it. Observation is evidence from one run at one time, never a safety verdict, and it never gates your decision.
• The example pack now includes Library files and two brief/response pairs so a new seller can rehearse the full proposal loop before uploading their own material.
• Opening a link for one of your other accounts now switches to that account before rendering, instead of showing the wrong navigation or an error.
• Since 2026-09-07 the Library, the demand inbox scoreboard, and proposal narratives are available to every seller, and the Playbook rules editor points to the Library, rate cards, and AI Business Rules. This release updates the documentation to match what you see: use Add material at the top of Materials to upload a file, and use Shaped by on your seller pass or preview to see the endorsed pair the response followed and why. Docs: /v2/storefront/library.
• Keep Murph-specific response rewrites out of internal TARS answers while preserving shared security and action-confirmation guardrails. Murph no longer replaces a terminology warning with unrelated inventory guidance.

​

5.401.0 — September 8, 2026 at 7:33 PM UTC

• When an admin sends an account invitation, they now receive a copy of the email so they can confirm what was sent and help resolve delivery issues.
• The Library and Demand pages now load in the Interchange web app; they previously failed to load outside chat hosts.
• For API integrators: no action is needed unless your integration called the Seller Dashboard demo evaluation through the web app’s internal endpoint with an API key. That path now requires a signed-in browser session. Use the Seller Dashboard read tools on the API instead; nothing else about your API access changes.
• Murph can now file an ask after you switch into another account you manage. Staff support and impersonated sessions remain excluded from customer-authored requests. If an MCP session authenticated with a user or personal API key was already open during the release, reconnect it once before filing; this includes switched sessions.
• Murph no longer fails at the start of a Gemini-backed conversation when the Seller V3 tool catalog contains recursive JSON values.
• Delivery reports whose response-wide currency contradicts the currency their packages declare no longer strand spend as unbooked. The reconcile sweep and the admin replay path now denominate a re-driven delivery the way the report processor already does — the currency every package agrees on takes precedence over the deprecated response-wide one — so spend that a mismatched currency kept out of the ledger books automatically on the next sweep.
• A report that sends an empty currency now falls through to the next level that declared one, rather than being read as a declaration of nothing; previously a report whose packages all sent "" booked no spend at all even when its response-wide currency was valid.
• Reject placeholder unknown brand and account identities before consulting cached product-discovery results, so stale cache entries cannot mask invalid seller-bound identity.
• When you select an Agent, its workspace now stays in your Murph conversation with your chat history and message composer available. Nothing to change on your side.
• On Seller settings, Resume intake now clears a seller-owned hold even if the readiness panel still needs attention. No extra action is needed to clear the hold; readiness, runtime, and administrator safeguards still control whether new transactions can proceed. This does not bypass buyer transaction eligibility safeguards.
• On Agent collection pages and Murph, active Inventory Sources with an explicit authorized binding now appear consistently. These visibility corrections do not change an Agent’s details, source ownership, or buyer transaction behavior.
• Media buy and campaign product reads now show the selling agent again for buys whose seller moved to typed storefront routing, and their product and publisher names resolve as before. No buyer action is required.
• When sellers open Advertisers, they can select an account they operate from a shared advertiser picker and use its buyer work rail. Protected System accounts remain read-only. External counterparties continue to appear in Buyers, while Merchandise, Operate, and Organization settings remain in Inventory (or the Settings footer); no action is required.
• search(kind: "media_buy") on /mcp/v3 now accepts filter.advertiserId without a campaignId, returning every current media buy for the advertiser across its campaigns in one paged read (limit up to 200, nextCursor for the next page). Each row carries its campaignId. The campaign-scoped read is unchanged.
• In-chat widgets now render as one consistent card in every state. Fixes extra padding around widget content, doubled card frames, a stray horizontal scrollbar, and clipped list rows, and caps the advertisers list so it scrolls within the widget instead of running the whole surface tall.

​

5.400.0 — September 8, 2026 at 3:13 PM UTC

• Sellers can now use the new Buyers tab, between Advertisers and Agents, to find existing external buyer relationships and their media buys, synced creatives, and account setup. No action is required: this reorganizes seller-only relationship work and does not change what counterparties see.
• Buyers can now author a social creative through save_creative without uploading a file; existing calls are unchanged. Pass a social block with headline, body, description, callToAction, and displayName, plus components for any slot a specific platform format declares (TikTok’s ad_text, for example; a format that needs a Facebook Page or Instagram-account identity exposes it as a slot the same way). You still set clickUrl and a formatKind such as image or video_hosted, because copy alone carries no format identity. The copy lands in the standard AdCP text and URL slots, the same place a file upload would put it. get with kind: "creative" now returns the full record: ownership scope, canonical format identity and media kind, stored asset metadata, the authored copy read back from those slots, validation and sync state, and campaign membership. An advertiser-scoped search with kind: "creative" accepts formatKind, assetType, role, source, and promoted filters and reports each row’s media kind and readiness; under campaign scope those filters are refused rather than ignored. Archiving frees the name for reuse and removes the creative from get and search; unarchiving is not available, and an isArchived: false request is refused rather than ignored.
• Attaching a creative to an existing package on a Meta-backed media buy through update_media_buy now fails with a clear, actionable error instead of a confusing “No update fields provided” rejection — Meta requires a separate sync_creatives call to actually deliver a creative, same as most other storefront adapters. sync_creatives also no longer silently returns an empty result for these media buys. If a creative attach to a Meta package fails, retry with sync_creatives as directed by the error message.
• Selected Agent details now keep Agent navigation and controls separate from seller workspace navigation.
• Reduce repeated capability checks and account-sync requests sent to active third-party sales agents, and reject placeholder unknown brand domains before they can be queued or sent to a seller. Internal discovery requests that identify an advertiser without repeating its brand now resolve the persisted brand instead of fabricating a fallback, so buyer discovery continues without repeating identity already stored for the advertiser. Account-change webhooks now return a retryable error when reconciliation cannot be durably queued.

​

5.399.0 — September 8, 2026 at 11:57 AM UTC

• The Approvals widget now shows what a creative actually did, not just what its source looks like. For sellers in the observation cohort, the “Does” line reads from the headless run Interchange made when the creative was submitted: the external domains it called, tracking pixels fired, redirects followed, popups and page navigations attempted, and media fetched, with when it was observed. While a run is still queued or running the row says so; when no run exists the line falls back to the source-derived summary and is marked “from source”. The row stage also shows the observed thumbnail of the creative before you open the live preview. Observation is evidence from one run, never a safety verdict, and it never gates your decision.
• Selecting an advertiser now opens that advertiser’s Campaigns workspace reliably for buyers and sellers, and the seller rail shows only that advertiser’s jobs.
• Fixed creative sync failures against Storefront-backed sales agents (e.g. Snap) so the reported reason reflects the actual per-creative problem — a rejected review status, an unconfirmed package assignment, or a specific validation error — instead of an uninformative “Sales agent reported creative sync failure” for every kind of refusal.
• Rewarded-video and other product-discovery polls now receive a fresh wait budget for each request, so buyers can continue a provisional search until its storefront results settle.

​

5.398.0 — September 8, 2026 at 8:44 AM UTC

• The Sellers screen matches marketplace browsing: the market and channel filters now sit in compact controls instead of stretching across the page, and the market filter is searchable so you can jump straight to a country instead of scrolling the full list.
• Embedded sales agent 1.43.1: fail closed on invalid JSON and architecture drift, fail closed on unexecutable FreeWheel products, reconcile archived GAM inventory, traffic FreeWheel content inventory selectors, verify FreeWheel placement inventory contract.
• Nothing to change on your side. In your Advertisers tab the rail now starts with a Needs you count and one row per advertiser lens (House, Partner-managed, Self-serve, plus System when present) with how many advertisers each holds; the roster overview opens in the canvas, including for live storefronts. Selecting an advertiser shows a picker at the top of the rail and only that advertiser’s jobs. Seller analytics stays under Operate → Dashboard.

​

5.396.1 — September 8, 2026 at 6:36 AM UTC

• Campaign constraints.age_min, age_max, gender, genders, and demographics now return a validation error instead of being silently accepted and dropped. These fields never affected targeting on any storefront — requests carrying them previously succeeded with no error and no effect. Describe age and gender targeting in your campaign brief instead.

​

5.396.0 — September 8, 2026 at 5:34 AM UTC

• If a media-buy request to a managed sales agent stops before the storefront starts sending it, it can be sent again. Once sending may have begun, the safeguard against duplicate media buys remains in place.

​

5.395.0 — September 8, 2026 at 5:01 AM UTC

• Creative review now includes live, interactive previews for every seller. In Approvals, select Show preview to run the buyer’s creative at placement size in an isolated browser sandbox. The preview cannot access Interchange, your chat host, or your session. Source inspection and Approve or Reject remain available when a preview cannot be rendered. No setup is required.

​

5.394.1 — September 8, 2026 at 4:02 AM UTC

• Shaped by now names the past example your agent followed, on your pass and previews only; buyers never see it.

​

5.394.0 — September 8, 2026 at 2:51 AM UTC

• You can now add a deck, one-sheet, or PDF directly from the Library page.

​

5.393.0 — September 8, 2026 at 2:09 AM UTC

• Nothing to change on your side. In your Advertisers tab, selecting a buyer’s advertiser now opens that buyer’s activity with you: the media buys they placed, the creatives they synced, and their account setup. This works the same in Murph, Claude, and ChatGPT. It never shows the buyer’s own campaigns. Delivery figures for those buys are not in this view yet; they remain in your Media buys and Reporting.

​

5.392.0 — September 8, 2026 at 1:32 AM UTC

• Buyer-agent developers can validate conversational MCP integrations against one portable contract. It defines chat and get_conversation, including MCP Tasks for longer turns and MCP Apps widget data in structuredContent. Nothing changes in the Interchange UI yet: no buyer-agent runtime serves this profile until the server and edge-route slices land.
• This contract does not alter what buyers see about sellers, so sellers have no action or notification for this release. It has no separate price or billable event; packaging and monetization remain unchanged.
• The contract is not exposed from a runtime, so no feature flag is needed in this slice. Expansion requires separately reviewed server and edge-route slices with their own release plan; reverting this package addition removes the contract before any runtime can expose it.
• Acceptance is an independently runnable schema suite covering valid chat, conversation pagination, MCP Tasks handles, MCP Apps metadata, and rejected invalid input. Adoption begins when a runtime records a successful chat call and a client reads a conversation with get_conversation; neither event exists in this slice.
• Creative reviews now carry an observation and a thumbnailUrl. For sellers in the observation cohort, Interchange runs each newly submitted creative version once, headlessly, on its render origin and records what the creative actually did: the registrable domains it contacted, pixel-shaped requests, redirects, popups, attempts to navigate the top window, and bytes transferred. The review row’s observation field carries that record with its status (queued, running, completed, timed_out, failed), and thumbnailUrl points at an authenticated PNG of the creative frame from that run, bounded to 600 px on its longest edge and served only to the storefront that owns the review. A resubmitted creative gets a fresh observation, and the previous version’s picture stops being served. Observation never gates review, live preview, or decisions; a row without one simply reads null.
• When you open Seller Dashboard as the owner of an active Demo Storefront, you can review a Synthetic evaluation data view for the current lease generation. It shows terminal evaluation RFP facts, including RFP and turn IDs, response state, the demo profile disclosure, and lease expiration. This rehearsal evidence is not buyer demand, commercial outcomes, bookings, revenue, attribution, learned posture, delivery, or live performance. Resetting the demo or allowing it to expire removes prior evaluation evidence. Your standard Seller Dashboard analytics remain live-only, and nothing changes on your side.
• Slack DM tenant defaults now resolve only when one active account has the exact normalized, approved email domain and the user holds a current authoritative seat on it. The same protection applies to buyer and seller accounts, requires no customer action, and ignores existing cached defaults in favor of bounded recomputation from current authority.
• The Demand inbox and Proposal pass no longer describe a practice, draft, or imported response as sent to a buyer.
• Marking a whole deck reusable could make every slide reusable, including priced slides. Now only individual slides, pages, or sheets can be marked reusable, and priced ones stay excluded.

​

5.390.1 — September 7, 2026 at 9:22 PM UTC

• Campaign creative uploads now show and count every creative found in a tag sheet before the sheet is submitted. Nothing changes about how the original tag sheet is uploaded or trafficked.

​

5.390.0 — September 7, 2026 at 8:14 PM UTC

• Teach your Merchandising Agent with the proposals you’d send again. Endorse a brief-and-response pair and the agent draws on those pairs when composing future proposals — you can trace which pairs shaped each response. Reuse slides across proposals and close open Library requests by uploading material or asking Murph.
• Agent developers who retrieve Set Up a Campaign through the buyer MCP skill catalog can now pin version 1.1.0 and run a repeatable no-spend sandbox advertiser check before relying on it. This makes automated skill checks reproducible, while the unversioned skill link keeps returning the latest instructions. Ordinary buyers do not need to change how they set up campaigns, and sellers are unaffected.

​

5.389.1 — September 7, 2026 at 6:38 PM UTC

• A media buy now records the currency its delivery is reported in, so anything reading that buy knows the denomination instead of having to assume one. The currency comes from the report itself — the currency every package agrees on, or the report’s top-level currency if the packages do not declare one. A report that names no currency anywhere leaves the field empty rather than guessing at one. Buys that were already delivering have their currency recovered from their packages.
• If your context agent prices packages for a media buy, its price block now uses that buy’s reported delivery currency where one is known, instead of falling back to your campaign’s rate-card currency.

​

5.389.0 — September 7, 2026 at 5:29 PM UTC

• Advertiser currency changes now update in place instead of rebuilding; clarification requests no longer appear as failures. Always pass primaryCurrency (an ISO 4217 code) at create time to avoid locking silently to USD: save_advertiser defaults to 'USD' when primaryCurrency is omitted, and that currency locks after the first campaign is created. Changing an unlocked advertiser’s currency is an ordinary update with advertiserId plus the new primaryCurrency. When name or brand is missing the tool returns a neutral needs_input result instead of an error. Sellers are not affected by these changes.
• The only customer-facing change is an optional buyer API guard; existing proposal requests are unchanged. Buyer agents can add expectedSellerId to request_proposals when automation must remain confined to one seller. The server rejects a fresh round if current buyer authority no longer resolves exclusively to that seller; the value can narrow access but never grant it. Sellers receive no new or changed requests from this precondition, so no seller action is needed.
• Enrolled sellers now open the canonical Material-backed Product marketing page from Teach and can open the exact Proposal Pass shaped by an accepted selling point.
• The Sellers page now loads Connections correctly when activation is deferred. Repeated failures are also flagged automatically for review. Buyers do not need to change anything, and seller storefront presentation is unchanged.
• Nothing to change on your side. Advertisers that Scope3 operates for compliance checks now appear as System in your Advertisers list and in the advertiser roster API. The seller UI does not offer actions for these rows; advertiser lifecycle, relationship, and campaign creation actions are unavailable.
• Sponsored buyers can now complete a sandbox media-buy test with their seller when advertiser-to-seller activation checks are enabled. No action is required: seller visibility and activation defaults for other buyers are unchanged.
• Enrolled organization administrators can open Organization in the rail to use Members, Billing & contract, and Accounts without leaving their current account. Each pane works on the parent organization. When the rollout flag is off, the existing gear and parent-account navigation are unchanged.

​

5.388.1 — September 7, 2026 at 2:48 PM UTC

• The Sellers page keeps loading when a connection is waiting for activation prerequisites. This does not change storefront readiness or how sellers are presented.
• Fixed: brief-mode product discovery (discover_products and request_proposals) was ignoring the countries filter whenever a brief didn’t also mention the country in prose, causing 0 products or an unhelpful “no usable candidate” result across Snap, Meta, TikTok, LinkedIn, Google, Pinterest, Reddit, Spotify, and UniversalAds. The countries filter now takes priority over any country implied by the brief text. request_proposals failures also now include the seller’s own explanation (e.g. a brief-mode clarification reason) instead of a generic message.

​

5.388.0 — September 7, 2026 at 1:50 PM UTC

• The advertiser status filter in a seller’s details is clearer. When every advertiser has the same status, the filter chips are hidden — there’s nothing to switch between — instead of showing a single chip that blanks the whole list when clicked. If a search or filter matches nothing, the list now says “No advertisers match your search or filters” rather than showing an empty area.
• Sellers you haven’t connected yet no longer look broken. A seller you’ve never connected now reads as a calm “Not connected” with a plain Connect action, instead of an amber “Action required” alert — and the “Action required” count reflects only connections that genuinely need attention (reconnect, account mapping, or billing).
• Published the Demo Environment Notice and linked it from Demo Storefront and developer documentation. Bring-your-own buyer agents now receive the same canonical notice URL with the visible and machine-readable warning on every demo/onboarding MCP tool result.

​

5.387.0 — September 7, 2026 at 12:28 PM UTC

• Browsing sellers is easier to scan: the channel and market filters now sit in compact controls instead of stretching across the page, and the market filter is searchable so you can jump straight to a country instead of scrolling the full list.
• Seller logos now render in the Sellers widget. When you browse or connect to sellers in an agent, each seller shows its brand logo instead of a placeholder with initials. Nothing to change on your side.
• Organization administrators now manage their organization’s members, invitations, billing, and accounts from an in-place Organization section opened from a child account.

​

5.386.0 — September 7, 2026 at 11:31 AM UTC

• Meta delivery reports now accurately show the reporting metrics available for each campaign goal. They no longer publish inconsistent qualified-lead totals when package and campaign evidence disagree: a reported zero remains zero, missing lead evidence stays unavailable, and qualified leads are not shown as generic leads or conversions. Existing buyer setup and optimization are unchanged, and buyers do not need to take action. Seller setup and workflows are unchanged; this buyer reporting update does not apply to sellers.

​

5.385.0 — September 7, 2026 at 10:06 AM UTC

• Sponsored self-serve advertisers now open their own Campaigns work from the seller Advertisers tab, while external and delegated advertiser relationships remain unavailable there. This update provides read access only; write actions from that Campaigns Page are not yet available.
• Buyer organizations can now manage software Agents as first-class resources alongside Advertisers. The redesigned Agents collection shows each agent’s purpose, connection state, advertiser access, and useful activity, while its detail experience organizes work into Overview, Access, Connections, Activity, and Settings.
• Named seller-account discovery replaces numeric ID entry. Connections distinguish Interchange, reporting resources, and machine subscriptions; activity keeps seller updates separate from exact human administration records. Technical identifiers, protocol versions, configuration generations, and proof state move to collapsed Advanced diagnostics.
• Settings retains one-time credential handling and exact-name confirmation for pause, retirement, credential rotation, revocation, and supported connection controls. The console continues to report No advertiser access until a separate authoritative grant exists; it never infers spend, payment, or Terms authority from identity, credentials, or connections.
• This workspace is for administrators and teams that already operate buyer automations. It serves power buyers and large-agency administrators; it does not change enterprise governance or the novice/chat buying experience. Existing integrations require no migration or customer action.
• There is no pricing, entitlement, packaging, or billable-unit impact. The workspace ships behind the existing direct organization-administrator authorization boundary rather than a separate feature flag, because its controls and visibility must share one authorization path. Expansion requires the documented cross-organization, revocation, zero-authority, and lifecycle checks; the kill switch is an atomic rollback of the workspace and named discovery route without changing existing authentication.
• Adoption is measured by buyer organizations reviewing an active Agent, usage by successful Add agent and administration flows, and guardrails by authorization refusals, control failures, post-revocation use, and any inferred authority. The owner reviews these signals at 30, 60, and 90 days using the plan in the commercialization brief.
• See Buyer-agent credentials.
• Enhanced Reporting now consumes its 4-IU account-period activity only after the exact connected account completes a successful reporting sync. Enabling an account without a reporting subscription no longer creates IU usage.
• Connections now disables unavailable Enhanced Reporting controls until the applicable IU Rate Card is active and accepted, rather than showing a predictable enablement error.
• Delivery reads no longer report a combined spend figure that no single currency covers. When one media buy is served by several sources, get_media_buy_delivery previously added up every source’s spend and labelled the total with whichever source happened to answer last — so $200 plus €300 came back as one number under one currency, and money a source reported without naming a currency was quietly counted under another source’s. It now withholds the figures it cannot state truthfully: the response omits currency, aggregated_totals, and the spend inside media_buy_deliveries[].totals, and says why in errors[] — MIXED_CURRENCY_DELIVERY when sources named different currencies, SPEND_DENOMINATION_UNRESOLVED when a source reported spend without naming one. Impressions, per-source status, and every other non-monetary metric still report as before, and a buy whose sources share one currency is unchanged. Read each source separately to see its amount in its own currency.
• Storefront connections no longer claim that advertiser provisioning is underway when setup has been safely deferred. Activation failures now also produce explicit operational evidence for faster diagnosis.

​

5.384.1 — September 7, 2026 at 4:56 AM UTC

• Organization administrators can again find Members, Billing & contract, and Accounts in the seller rail while the setup checklist is shown.

​

5.384.0 — September 7, 2026 at 4:14 AM UTC

• Organization administrators can open Members, Billing & contract, and Accounts from the rail without switching away from their current account. Nothing needs to change on your side.
• Seller impact: not applicable. This signed-in organization navigation change does not alter storefronts, inventory, seller presentation, or anything buyers see about sellers.
• Monetization: none. This changes where existing organization settings open; it does not change billing plans, packaging, prices, entitlements, or charges.
• Buyers now live under Advertisers: each buyer is an External advertiser row, and pending ones show as ‘awaiting you’.

​

5.383.1 — September 7, 2026 at 2:27 AM UTC

• Connecting a provider account (TikTok, Meta, and other OAuth-based storefronts) from a connection link now reaches the provider’s sign-in page. Clicking Continue no longer silently stalls in some browsers before the sign-in screen ever loads.

​

5.383.0 — September 7, 2026 at 2:00 AM UTC

• Sellers who have not connected an inventory source yet see the setup checklist again.
• Advertiser updates, tracking configuration changes, and archiving through the Buyer API now require the same current Buyer identity, plan, Terms, and account-hold checks as advertiser creation.
• Delivery spend now books in the currency your packages declare, not the one the report’s top-level field claims. Some sales agents send a delivery report whose overall currency contradicts every package inside it — those deliveries previously failed to book at all and sat unbooked while the mismatch was chased down. Where the packages agree with each other, that shared currency is now what we book and what we report, and the contradiction is flagged so the source can be corrected. Reports with genuinely mixed package currencies are unchanged, and a report that declares no currency anywhere is still never booked against a guessed one.
• The Advertisers tab now opens on your organization’s full roster instead of a chat prompt. It reflects your existing advertisers automatically — nothing to set up on your side.
• Each row is one of three kinds: House (you operate it), Self-serve (your client runs it, though you can still edit), or External (a buyer connected through their own agent). A Sandbox badge marks any test advertiser and stays hidden behind a toggle. Filter the roster by House, Self-serve, Partner-managed — the same External rows, filtered — or Needs you, which shows every row with an open setup case waiting on your response.
• House and Self-serve rows open Campaigns, Creatives, and Reporting. External rows open Account — the same setup-case drawer Buyer Account Mapping already shows (billing path, setup requests, inventory mappings), so it’s one place to review instead of two.
• This only changes what you see on your own Advertisers tab. Buyers see no change: the Account drawer is your existing Buyer Account Mapping case, reached from a new place but showing no new buyer-facing data.
• Enable Enhanced Reporting for an active connected provider account when you want up to one year of reporting history for that account. If you do nothing, your standard reporting, connections, campaigns, and charges do not change.
• For a governed media organization, the account-level control makes each reporting and billing decision explicit. For hands-on teams, it is available in Connections, the API, and MCP; an account earns 4 Interchange Units per billing period only after its existing reporting subscription successfully syncs after the control is enabled. Turning it off stops future enhanced reporting while preserving the history already collected.
• Seller impact: not applicable. Sellers cannot see or configure this buyer-side account control; their storefronts and ordinary connection and campaign workflows do not change.
• TikTok product discovery now reports which account setup (app, pixel, connected identity) each candidate product still needs before you can execute a campaign with it — not only for the one product a decision plan already picked, but for every product returned from a brief-driven search.

​

5.381.1 — September 6, 2026 at 11:33 PM UTC

• Seller setup navigation is cleaner and easier to scan, with aligned status details and a compact go-live summary.

​

5.381.0 — September 6, 2026 at 11:00 PM UTC

• During seller signup, choose Just list to list inventory with an agent operated by you, a partner, or another provider, or Create an AMC account to list inventory and train your AMC’s hosted Merchandising Agent. An AMC account always includes listing. Interchange uses that selection to show the setup workspaces and navigation that apply. Existing sellers do not need to act; use Account settings or ask Murph if you want to switch later. Switching does not change your plan or inventory sources and does not delete completed setup. The initial choice and canonical Storefront capabilities commit together, so onboarding cannot complete with stale workspace routing. This launch does not introduce new pricing, change a seller’s plan, or grant an entitlement; it configures which already-packaged seller product the account is setting up.
• Measurement: track media_company_intake_started and media_company_identity_confirmed, then measure current-mode adoption from the canonical Storefront projection. Before expanding the flag, complete at least one onboarding in each mode and one switch in each direction with zero authority divergence and no sustained increase in confirmation errors.

​

5.380.0 — September 6, 2026 at 9:46 PM UTC

• During account signup, you can now record the exact product, country, and channel you need when that option is not ready. The waitlist applies to that request, so you can continue setting up work that Scope3 supports. See the Buyer onboarding and Market readiness guides for the available paths.
• For buyers, the Buyer Setup response now names the identity, plan, Terms, account-standing, product-access, or payment step blocking an action. Existing integrations need no response-parsing change: platformReady keeps its prior wire behavior, and developers can adopt capabilities from the Buyer Setup operation when they are ready. This is an intentional authorization cutover: an existing account that lacks verified Organization identity, a selected plan, or current Terms is denied real operations and receives that specific blocker; deprecated LIVE_ELIGIBLE posture does not bypass those requirements. Payment remains required only for purchases on routes that clear through Interchange.
• For sellers, signup can record interest for the country and channel where you want to offer supply. This does not change how your storefront ranks, presents inventory, sets prices, or becomes ready to transact. No action is required for an existing storefront.

​

5.379.0 — September 6, 2026 at 8:26 PM UTC

• Approval notifications now open straight to the review waiting on you. The email for a pending creative review names the creative, the buyer, its format, and its size when the creative states one, plus a Review creative button that opens directly on that review. A pending media-buy approval works the same way, with a Review media buy button. The in-app feed entry and the Slack post’s Open in Interchange link open to the same review. Nothing to change on your side: delivery still follows your storefront’s approval routing rules, and notifications never include the creative itself or a preview link, since the live preview is created only when you open the review.
• V3 advertiser creation safely replays an uncertain response when callers reuse one idempotency key.

​

5.378.0 — September 6, 2026 at 6:03 PM UTC

• When a brief names an age range a Seller cannot target exactly, get_products and request_proposals now return a proposal instead of an error: products without age targeting, plus a limitations entry (age_targeting_unavailable) that states the requested range, the ranges the Seller can target, and any fixed-range inventory that was excluded. A brief that names disjoint ranges (for example 21-24 or 35-44) is asked to clarify rather than answered for one segment. Only when the Seller has no inventory without age targeting does the request still fail as before. Buyer integrations that read get_products programmatically should check limitations before treating a proposal as fully on-brief; agents that read the proposal text need no change. Sellers see the same limitation in the run record and can declare the age ranges their inventory targets (seller-authored age signals) so briefs that name them are answered exactly.

​

5.377.0 — September 6, 2026 at 5:03 PM UTC

• Sellers with more than one storefront can now open the proposal pass returned by a practice brief from their selected storefront. Practice briefs now use the same session-selected storefront context as the proposal-pass view.
• When you ask Murph to set up or manage your Seller Account in a private conversation, Murph now handles the request with dedicated seller actions. Murph remains restricted in shared conversations.
• You can now open the Advertisers page from your seller workspace to see every advertiser in your organization’s roster. Each row is labeled House, Partner-managed, or Self-serve. House is an advertiser you run directly, live or sandbox. Partner-managed rows are run by a connected partner — an AdCP counterparty or a delegated relationship. An advertiser you’ve set to self-serve mode shows as Self-serve. When someone else operates the advertiser, the row also shows the operator’s name.
• A row with an open setup step you need to act on shows “Awaiting your decision,” “Waiting on buyer,” or “Awaiting billing,” with a Review setup action that opens the same case in Seller Accounts.
• Your Playbook now opens with a first-run checklist of what your Merchandising Agent sells from: business rules and a rate card (required), plus a media kit, selling guidance, and past proposals or sales decks (recommended), each with a line on why it sharpens the agent’s pitch. Every buyer brief the agent has answered now reads in four blocks (what the buyer asked, what we responded, outcome, our read), and the Inventory components and Signals pages open by explaining how the agent uses them; nothing to change on your side.

​

5.376.0 — September 6, 2026 at 2:13 PM UTC

• Creative review now shows the ad itself. When you open a pending creative in Approvals, Show preview runs the buyer’s creative live at placement size: third-party display tags, hosted HTML, VAST video, DAAST audio, images, video, and audio all render, animate, and respond to hover and click the way they would on the page. Open full size shows the same preview in a new tab through your chat host.
• The preview runs on Interchange’s dedicated render origin (render.interchange.io), inside a browser sandbox that has no access to Interchange, your chat host, or your session. Click macros are rewritten to an interstitial that shows the destination instead of leaving the page; a tag’s own code can still open a new window, which stays sandboxed: it cannot script or read your page or read cookies and storage itself, though like any navigation it reaches that site with the cookies your browser already holds for it. Treat any window the preview opens as buyer-controlled. Each review row carries a signed preview link that expires after fifteen minutes and stops working the moment the buyer resubmits the creative or the review is decided.
• Seeing a creative run is not a safety verdict. The trust chip, the plain-language “Does” line, referenced domains, and the source itself stay beside the preview so you can judge what the tag does as well as how it looks.
• Buyers: nothing changes in how your creative is delivered. During review a seller may render your submitted creative in this preview, where its tags and trackers fire as they would on a page and its click macros resolve to an interstitial rather than a landing page. No action is needed.
• This capability is included in creative review at no additional charge: no package, entitlement, usage charge, or other billable surface is added.
• Adoption is measured through the fixed lifecycle events mcp_creative_preview.live_preview_open, .live_preview_full_size, and .live_preview_expired, alongside the existing .request, .returned_link, .external_open, and .expired_link events: preview-open rate per pending review, full-size rate per open, and the share of links that expire unused. These events carry no creative, URL, provider, or buyer identifiers.
• Creative review rows in Approvals now lead with the creative instead of the caveats. Each row opens to what the buyer sent: an image + copy creative shows its headline, body, and call to action as text; a hosted file shows its format, size, and host; a third-party tag shows who serves it and, in plain words, what it does (loads a script, fetches VAST from a domain, fires tracking pixels). One chip in the row header names the trust level, the tag source sits behind a “View tag source” disclosure, and Approve and Reject are in the same place on every row. Where an interactive preview is available, the button names the provider it will send the creative to, and its expiry is shown in your locale.
• Nothing about the safety boundary changed: buyer HTML, JavaScript, VAST, and media URLs are still never loaded or executed inside Interchange, and the provider preview still opens only through your chat host after you ask for it.
• Agent-supplied Listing storefronts now show their connected-agent account overview instead of unrelated Interchange merchandising analytics. Branding & distribution now presents a clear Public Distribution upgrade path before exposing paid hostname, self-serve advertiser, AdCP, and ChatGPT app controls.

• ​

  Enterprise brand buyers

• Connected-account campaign tracking now works without a separate enrollment, keeping campaign identity, governance, and live delivery evidence in the same Interchange workflow. Existing subscriptions need no changes, and provider capability and account-access checks still apply.

• ​

  Agency buyers

• After mapping and subscribing an eligible provider account, teams can inspect its mirrored campaigns, account presence, and live delivery across advertisers without waiting for feature enrollment. Tracking remains read-only and does not grant authority to change provider campaigns.

• ​

  Builders and power buyers

• Existing integrations continue to use the buyer API or subscribe_directed_campaigns in MCP. The former feature-enrollment error is gone; account mapping, credentials, provider capabilities, and advertiser access remain the operative checks.

• ​

  Buyers using chat

• No technical setup or action is required. Once an eligible connected account is mapped and subscribed, its campaign history and current delivery become available through the normal campaign experience.

• ​

  Sellers

• Listing + Distribution now makes a storefront easier for buyer agents to discover and transact with by publishing a stable /adcp/mcp action in its machine-readable Listing. Keeping the Seller CNAME verified gives buyers a branded, predictable route into the storefront’s governed campaign, contract, reporting, and billing workflow. Other Seller profiles remain private from this transaction endpoint.
• This release does not introduce a new charge or billable unit. Listing + Distribution remains the existing packaging boundary for the Seller endpoint, while connected-account campaign tracking remains a buyer capability.

​

5.375.0 — September 6, 2026 at 10:23 AM UTC

• Review & go live now preserves the standard not-found response when a campaign is outside the active buyer account, regardless of that account’s Campaigns Page availability.

​

5.374.2 — September 6, 2026 at 5:00 AM UTC

• Agency trading teams and in-house media teams enrolled in Campaigns V3 can move from an advertiser to its campaigns in Claude or ChatGPT, review campaign status, budgets, media buys, and creatives, and open Review & go live without losing their place. Hands-on buyers using compatible external hosts get the same workflow. No setup change is required.
• Monetization: none. This improves the existing buyer workflow and adds no charge.
• Rollout: campaigns-v3 remains the registered customer gate. Expand after Campaigns Page opens, campaign loads, and advertiser-to-campaign navigation remain stable. Disabling it returns buyers to the current Campaigns view; unavailable evaluation fails closed to that view.
• Measurement: monitor Campaigns Page load and retry rates, advertiser-to-campaign navigation, campaign drill-in and Review & go live opens, and use by enrolled customers.

​

5.374.1 — September 6, 2026 at 4:22 AM UTC

• Buyers using the MCP get_products tool or the Product Discovery API at POST /api/v2/buyer/products/query: when an initial response says results are still in progress and you continue the same discovery, the completed discovery results now remain available even during a temporary cache outage. You also see each refinement result only on the product or proposal from the seller that returned it. How you start a new discovery and its request fields are unchanged; continue with the same execution ID through the MCP tool or API endpoint, with no setup change required. When refining or applying a result, send back the exact ID you received. A bare product ID shared by two of a seller’s Inventory Sources is rejected as ambiguous, so use the returned qualified product ID. Proposals duplicated across those Sources are withheld until the seller returns distinct proposal IDs.
• Sellers: This fixes a display issue triggered when two Inventory Sources in one Storefront return the same proposal ID. Buyer-facing MCP and API discovery results now show only proposals that can be attributed to one Inventory Source, so distinct proposal IDs receive reliable buyer visibility once the Storefront finishes responding instead of risking the wrong proposal being displayed. Existing unique proposal IDs need no change; if you reuse an ID across Inventory Sources, update the proposal IDs returned by those Sources to keep every proposal eligible for display.

​

5.374.0 — September 6, 2026 at 2:34 AM UTC

• Child-account members can use GET /api/v2/billing/account/inherited-stub to show that billing is managed by their organization without exposing its billing document. The response contains only the organization name, organization scope, and managing customer pointer; full billing access and advertiser, API key, Agent, workload, and service-token restrictions are unchanged.
• For enterprise brand and agency buying teams that work from child accounts, an API integration can now explain that billing is managed centrally instead of requesting or inferring the parent billing document. Existing integrations do not change unless they call this new endpoint. Genuine seller child-account members can use the same shared read under the same membership and topology rules; it does not change Storefront billing workflows or what buyers see about a seller.
• This is an additive infrastructure read projection, not a new billable surface, plan, package, entitlement, or charge. It creates no billing write and exposes no contract, rate, standing, payment, account, member, or advertiser data.
• The endpoint ships without a feature flag because this server slice adds no UI entry point or discovery and remains behind existing authentication plus its strict direct-child membership checks. The later in-place rail UI is separately PostHog-gated. There is no endpoint-specific runtime kill switch; rollback is a server deployment revert. UI exposure expands only after the server soak has zero unexpected 5xx responses and the exact 200 and denied 401/403 contracts remain verified.
• Existing route-level request counts and latency by status and customer, plus durable REST activity records for GET /api/v2/billing/account/inherited-stub, measure successful, denied, and failed calls without a new event. For this slice, usage is a successful request by an eligible child account; acceptance is zero unexpected 5xx responses before UI rollout. UI adoption is not claimed or measurable from this server-only endpoint: the later flag-gated rail slice must define and use its actual instrumented exposure and usage signal.
• Show the next required setup action in the seller navigation header whenever setup remains incomplete.
• AI Business Rules now recheck storefront profile access under the same lock as profile changes, preventing a simultaneous profile removal from allowing a stale rule creation or activation to commit.
• Buyer agent principal-change notifications now retain one delivery identity across retries, preventing duplicate notifications after a delivery timeout. No action is required.
• Buyer agent principal package types now include the supported reporting ledger-change notification event.
• On the Branding & distribution Page, you now choose Interchange or Public for Distribution — there’s no separate “Hidden” option. A storefront that hasn’t published yet shows as “Not listed yet,” a state, not a third choice to pick.
• Choosing Public now walks you through what’s needed: a public listing domain card at the top of Distribution shows the CNAME to point at your own domain. Add it, and select Verify once your DNS has updated — once your domain verifies, select Public to go live (verifying confirms your domain is ready; it doesn’t switch Distribution for you). You’ll need a published Interchange listing before you can verify.
• Storefronts already publishing to Interchange are unaffected. No storefront besides Interchange’s own could choose Public before this change, so nothing to migrate. Interchange’s own first-party storefront keeps its platform-managed setup automatically — it never shows the domain card.
• Want to take your storefront off Interchange and the public web entirely? Select Unlist below the two-way choice and confirm — your storefront returns to “Not listed yet” until you publish again. Unlist is a separate action, not a third distribution choice, and it’s the same effect the old “Hidden” (private) value always had — that value still works for any tool that sends it directly.
• AI Business Rules now consistently names the seller Page for policy and approval decisions.

​

5.373.0 — September 5, 2026 at 9:22 PM UTC

• In the Advertisers tab, select the Partner-managed or Self-serve lens to see which buyer relationships require setup. The roster marks relationships as Needs setup — waiting on you, Waiting on buyer, or Awaiting billing; select Review setup to open the same setup case drawer available from Buyer Account Mapping. House rows carry no setup state. Nothing a buyer sees about you changes: the states are derived from setup cases already visible to the seller in the Buyers directory, and no buyer-facing response or page is altered.
• Buyer-organization administrators can now use the buyer REST API to see how a buyer agent is configured, whether its notification and reporting setup has been proved, and what still blocks readiness. Registration, an active credential, configuration proof, advertised capabilities, and business authority remain separate checks. Passing one check never grants advertiser, account, spending, payment, or Terms access. Existing integrations do not need to change, and the configuration UI remains withheld until this API contract is stable.
• Administrators can deactivate one notification subscriber or reporting destination, suspend a buyer agent, or permanently retire it. Each control requires the buyer agent’s exact display name and current state or version. The administration history records the authenticated person who made each change without storing endpoint details, proof material, or secrets.
• Seller-recorded changes appear in a separate principal.changed history and tell the buyer agent to refresh with get_principal. The buyer agent’s own successful sync_principal calls do not appear as incoming seller activity. Both histories return the latest 100 records and say when older records exist.
• Seller impact: sellers do not need to act, and buyers see no new seller ranking, inventory, packaging, or readiness information. Sellers continue to enforce the buyer agent’s configured lifecycle, while buyer agents can see when a seller records a proof or destination-status change. Monetization impact: none. This adds no billable surface, entitlement, price, Interchange Unit, spending, payment, or Terms authority.
• Availability is limited to directly authenticated organization administrators through the buyer REST API. That server-side authorization check is the release gate; rollback removes these administration routes together. Wider use requires the authorization, organization-isolation, destructive-control, notification-recovery, and authenticated-route checks to pass. Adoption is measured from successful administration audit records. Guardrails track rejected authorization, failed controls, notification-loss alerts, and any unexpected authority response without collecting endpoints, destinations, proof material, or secrets.
• See Buyer-agent credentials.
• Open Agents in Murph and select an Agent to manage its endpoint, certification, and inventory sources from the left rail. First-party Agents omit client onboarding controls; client-serving Agents show them when authorized. Open an exact inventory source for credentials, connection tests, and diagnostics. Existing connections need no setup changes.

​

5.372.0 — September 5, 2026 at 7:58 PM UTC

• Seller Accounts on Listing can review campaigns, media buys, creatives, approvals, delivery, activity, and reporting in Interchange while a connected sales agent handles selling. The current Campaigns experience and AI Business Rules become available when the account moves to Listing; no action is required to keep using the connected agent, and saving, enabling, or evaluating AI Business Rules is not IU-rated today. To add self-serve advertisers, public listing distribution with an optional CNAME, or customer-branded AdCP and ChatGPT app channels, choose Listing + Distribution in Plan & billing. This paid package does not change the visibility or ranking of the Interchange listing and does not enable Merchandising. Buyers do not see the seller’s account-profile label, and their existing Campaigns V3 exposure remains unchanged.
• Certified plan intent is pre-release and is not yet available to Seller Accounts. The seller-rfp-plan-intent flag remains disabled until the follow-up trigger-enforcement migration ships, so RFP responses retain the legacy contract. The pre-release capability adds no entitlement, package, or billing meter.
• There is no Seller Account action to take for this pre-release foundation.
• If your buyer agent or integration creates media buys from Buyer Proposal JSON, preserve each productId and pricingOptionId exactly as returned when calling create_media_buy. Buyer Proposal JSON keeps its published shape and field set, but these values now include their source so identical upstream IDs from different sources stay distinct.
• Integrations that already pass returned IDs through unchanged need no code changes. Existing defaults are unchanged. Integrations that map or replace IDs should instead preserve the returned values exactly.

​

5.371.0 — September 5, 2026 at 1:22 PM UTC

• Preview CSV, XLS, and XLSX tag sheets locally before upload with the new Inspect a Tag Sheet skill. The offline inspector shows the creative-row count and versioned mapping rules without uploading or printing tag content. When a readable tag-sheet shape uploaded through Murph repeatedly produces no creative rows across customers, Interchange sends one deduplicated, content-free signal for team review; nothing else is required from you.
• Route each seller setup checklist item and its next action to the incomplete task that needs attention.
• Sellers can use the left rail in their Seller Account to move between Inventory, Advertisers, and Agents. Setup progress stays in Inventory, and campaigns stay with each advertiser.
• Use open_proposal_pass({ rfpId, turnId }) in the v3 Seller Account MCP surface to open the Proposal Pass Page for an exact RFP turn. The launch returns only those IDs; the Page retrieves private proposal detail after it opens. Invalid pairs and records outside your account do not open, and the existing v2 storefront launch remains unchanged.

​

5.369.1 — September 5, 2026 at 7:55 AM UTC

• Creatives delivered after storefront review now preserve the downstream platform creative ID in the terminal buyer callback, so provider materialization appears in creative readback. Buyer-visible provenance is also correctly attributed to the seller storefront rather than its private inventory source.

​

5.369.0 — September 5, 2026 at 6:56 AM UTC

• Creatives on approved future-flight media buys now receive their package binding while the buy is pending start, so delivery no longer waits for the flight to become active.
• Source Diagnostics now explains recognized request-field failures in plain language, shows actionable fields and protocol guidance, and keeps the complete redacted upstream response in collapsed technical details.
• Creatives attached while a seller is reviewing a media buy are now delivered automatically after approval. Buyers no longer need to detach or resubmit them.

​

5.368.0 — September 5, 2026 at 3:32 AM UTC

• Inventory Sources is now available from the navigation in every seller account. Use it to connect an AdCP-compatible sales agent and open each Source’s settings, credentials, connection tests, and diagnostics. The agent may be operated by your company or by a provider; that choice does not require a different plan.
• No action is required for existing Sources.
• Commercial model: none. Connecting and managing an inventory Source remains included in the free Listing-only setup. Paid Merchandising controls still require a Merchandising plan and its entitlements; this navigation rollout does not change prices or grant paid access.
• Persona impact: seller operators get one consistent place to manage Sources. Enterprise brand, agency, power, and small-business buyers have no new action and see no change from this navigation release.
• Buyer-visible effect: none from the navigation rollout itself. Buyers continue to call the same storefront, and Source eligibility and returned products are unchanged until a seller configures or changes a Source.
• New seller workspaces now start with the tools included in the option selected during signup. Choose Listing only for the free publishing setup, or choose a Merchandising plan for richer product and inventory-management tools. There is no separate support request or hidden account switch after signup.
• Your workspace stays aligned when you upgrade, renew, downgrade, or join an approved beta. A setup change is applied only when every included capability is available, so a failed change cannot leave the account partly updated. The current setup is visible in the account switcher.
• Commercial model: Listing only is the free connection and publishing setup. Merchandising is the paid package for modular inventory and self-service publishing. The accepted Rate Card remains the authority for price and product rights; a feature profile only presents those rights and cannot grant or price anything by itself.
• Persona impact: seller operators choose the setup that matches how they sell. Enterprise brand and agency buyers may discover richer products after a seller chooses Merchandising. Power and small-business buyers use the same storefront interface and do not need to change their workflow.
• Buyer-visible effect: Listing-only does not change how buyers access a seller’s storefront. A seller that selects a Merchandising plan can publish the richer products enabled by those paid capabilities, which buyers may then discover through the existing storefront interface.

​

5.366.1 — September 5, 2026 at 1:37 AM UTC

• Managed sales-agent health now recovers after a successful status refresh instead of retaining a transient unreachable warning for seven days.

​

5.366.0 — September 5, 2026 at 12:59 AM UTC

• Source diagnostics can now launch deterministic validation for connected third-party sales agents instead of stopping before validation reaches the agent.
• Preserve package identity in newly generated click and impression tracking when a creative has exactly one package assignment.
• Seller home now starts eligible storefronts at Interview your Merchandising Agent. Choose Teach to add and confirm seller material, or Test to practice a buyer brief. Existing users do not need to change their setup, and each workflow keeps its existing access, review, and evidence requirements.
• FreeWheel media buys now create active placements with the selected inventory, retain the validated currency and connection settings through booking, and attach creatives immediately. No seller action is required.

​

5.365.0 — September 4, 2026 at 11:38 PM UTC

• External Agent setup now uses shorter, ownership-neutral guidance, and Source Diagnostics opens on a live Source by default while keeping inactive Sources available for deliberate review.

​

5.364.0 — September 4, 2026 at 10:33 PM UTC

• Buyer Storefront connection reads now include an opaque selection-edge revision, allowing read-only clients to verify repeated selection results while treating revision bumps as fencing changes rather than seller-choice changes.
• Campaign creative uploads now accept CM360 tag sheets in CSV, XLS, and XLSX formats, keep their placement tags ready for review, and let you search all managed campaigns by name when choosing where to use creative.
• Buyer-agent sandboxes that retain their first eligible provider account now remain active when registration expiry cleanup runs concurrently, including during a rolling deployment with an older API or worker. Cleanup still removes truly expired, unbound sandboxes and safely retries interrupted Core deactivation.
• Buyers now see regional market makers under “Selected & default-on” on the Sellers page, and regional market makers with no declared regions join automatically for advertisers targeting their approved markets.
• You can now filter the Sellers page by market and channel, so you can find, for example, every seller selling in the Netherlands or every seller offering CTV. The filters combine with search and the existing status filters. In the web app, share a link with market and channel in the URL to open the page with those filters already applied.

​

5.363.0 — September 4, 2026 at 7:31 PM UTC

• Restore seller billing links and make empty advertiser and collapsed-widget states recoverable in the seller rail.
• Find approvals and other pending seller work in one Approvals & operations rail destination, with approval routing still reachable from the combined inbox.
• Keep the Agents workspace inside Murph so sellers can browse and create Agents without losing their chats or composer.
• If you’re invited to administer a new Buyer Account, use the Welcome to Interchange email to join the organization and review any outstanding Terms of Service. If your organization already has a Seller Account, it remains available as a separate workspace; no changes are required to keep using it.

​

5.362.0 — September 4, 2026 at 4:42 PM UTC

• Plan & Billing now presents a Rate Card—the activities and prices included in a plan—with three Intelligence Unit activities for new v4 plans: Brief responses, Social account intelligence, and non-social Interchange media buys that record delivery. Scope3 initiates the transition by offering a v4 plan, and an admin for the organization must explicitly accept it. No customer is migrated automatically; existing v0-v3 plans and historical usage remain unchanged.
• Enterprise brand buyers: compare the three outcome-based rates with your governance and measurement plan before an admin accepts the offer.
• Large agencies and hold-co buyers: update pricing playbooks only for organizations that choose v4; current client plans need no action.
• Hands-on buyers: Plan & Billing shows the exact activity, unit, and rate before acceptance, so experiments can be costed against the same schedule the meter uses.
• SMB and chat buyers: nothing changes unless your organization is offered and accepts a new plan; Murph and Plan & Billing will present the new schedule.
• Sellers: a v4 plan rewards complete storefront responses and trustworthy channel attribution. Only sellers that explicitly accept v4 may incur one IU for a non-social Interchange media buy that records impressions or spend in a billing period; existing seller plans and earlier buys are unchanged.
• This release uses Social account intelligence as the customer-facing name for eligible social-account access. Usage is charged only after the matching customer outcome occurs. A non-social media buy costs one IU in a billing period only when Scope3 records positive impressions or spend for that buy in that period. If corrected delivery data returns both totals to zero before the invoice, the IU is removed. If the correction arrives after the invoice, Scope3 applies the credit or reversal to the original period; the customer does not need to take action.
• There is no separate feature flag: customer exposure is structurally gated by an offered and explicitly accepted v4 plan, and rollout coordinators will not create v4 offers until governance PR #12746 is approved. The immediate kill switch is to stop issuing v4 offers; accepted Rate Cards remain immutable and continue to follow their signed terms. Expand beyond the initial offers only after the first accepted v4 billing periods show zero unresolved attribution candidates, zero duplicate metering keys, and successful recovery sweeps for all three activities. Rollout coordinators will monitor accepted-v4 counts, per-activity metering events, recovery failures, unresolved attribution, and duplicate suppression in the launch tracker and project-iu-rollout channel.
• Murph now keeps uploaded creative tag sheets available while buyers choose a campaign in a later message, instead of asking them to upload the same sheet again.
• Creative review rows in Approvals now lead with the creative instead of the caveats. Each row opens to what the buyer sent: an image + copy creative shows its headline, body, and call to action as text; a hosted file shows its format, size, and host; a third-party tag shows who serves it and, in plain words, what it does (loads a script, fetches VAST from a domain, fires tracking pixels). One chip in the row header names the trust level, the tag source sits behind a “View tag source” disclosure, and Approve and Reject are in the same place on every row. Where an interactive preview is available, the button names the provider it will send the creative to, and its expiry is shown in your locale.
• Nothing about the safety boundary changed: buyer HTML, JavaScript, VAST, and media URLs are still never loaded or executed inside Interchange, and the provider preview still opens only through your chat host after you ask for it.
• You can now understand billing figures, update Business Rules from the top of the page, and diagnose ad-server sync failures without hunting across duplicate status panels. Approvals also adds a buyer filter and lists recently approved media buys with the newest decision first. Nothing needs to change on your side.
• The signup chooser appears only when Scope3 enrolls you. You can choose Advertiser, Advertiser Portfolio, Media Company, or Developer. An enrolled Media Company signup then follows the existing seller flow. Seller presentation remains unchanged when enrollment is not enabled.
• Your choice only determines your signup experience. It grants no authority or access and does not change billing, navigation, or capabilities. Nothing to change unless you are enrolled.

​

5.361.0 — September 4, 2026 at 1:24 PM UTC

• Keep the setup checklist visible after you connect an external sales agent, including while its product mappings and agent link are still being established.
• Fixes media buys that could get stuck in DRAFT status when a storefront (e.g. PubX) calls back with an acceptance before our system finishes writing the correlation record. The webhook handler now retries the lookup briefly to close that window, so buys transition to ACTIVE as expected.
• Modular inventory catalog refreshes now preserve a source-declared guaranteed or non-guaranteed delivery type. This keeps buyer cancellation behavior stable when a static-avails product is regenerated from its backing source.

​

5.360.0 — September 4, 2026 at 12:23 PM UTC

• Fixed TikTok Video Views (6-second and 15-second) media buys failing readback verification and being rolled back after creation. TikTok auto-populates the ad group’s conversion tracking event to match its optimization goal even when none was requested; the adapter now tolerates that provider-side normalization instead of treating it as a mismatch.
• Approved Media Company applicants can now review a research-backed setup draft in the Murph onboarding rail. The draft surfaces inferred operating role, candidate properties and domains, markets and channels, likely inventory sources, and selling-path guidance — helping you configure your Storefront before your team reviews it.
• Each field is labeled INFERRED, APPLICANT_CONFIRMED, or INDEPENDENTLY_VERIFIED so you know which suggestions to validate. Settlement currency is a suggestion only; set it in Plan & Billing. adagents.json is a draft for your review; you publish it yourself when ready.
• This has no buyer-facing behavior. It does not change pricing, packaging, billing, or paid-tier eligibility; it is an onboarding reliability and time-to-value improvement for enrolled sellers.
• Adoption is measured with media_company_setup_draft_viewed, emitted on a non-impersonated applicant read. For the asynchronous test cohort, the acceptance target is that every approved applicant with a completed projection can open the draft without assistance; after launch, track the share that reads it within seven days of approval and median time from approval to first read.
• Correct native adapter reporting mappings and declarations so cross-platform metrics preserve their standard meanings and supported conversion values are not dropped.

​

5.359.0 — September 4, 2026 at 10:47 AM UTC

• Keep the Inventory, Advertisers, and Agents workspace labels readable across the seller setup rail.
• Fixed create_media_buy on TikTok returning a generic, retryable “Upstream request failed” error for requests that were actually missing a required field (app ID, conversion event source, messaging-app destination, platform identity, or a Smart+ creative). These now surface as a correctable INVALID_REQUEST naming the missing field, so the buyer knows what to fix instead of retrying a request that will never succeed.
• Fixed TikTok Video Views (6-second and 15-second) media buys failing readback verification and being rolled back after creation. The ad group now requests the Video Views-specific promotion type TikTok requires, matching the fix already applied to TikTok Reach.
• Icons for your ChatGPT app now come from the logo in your brand.json — nothing to upload. If your storefront doesn’t have a logo there yet, add one; your directory (256×256) and composer (48×48) icons generate automatically the next time you publish.
• A FreeWheel inventory source that was withheld from buyers because its execution currency had never been confirmed with the ad server now clears itself. Interchange reads your FreeWheel network, restates the execution currency already configured on the source, and the source becomes buyable — within fifteen minutes, with nothing for you to do. It never chooses the currency for you: FreeWheel stamps the currency on each insertion order itself, so Interchange only ever restates the one you configured. Two states still need you, and the Ad-server execution currency row on the source names which: credentials that cannot read your network’s insertion orders, and a network whose existing orders book a different currency than the source declares. Google Ad Manager, SpringServe, and AdsWizz sources are unchanged.
• Product discovery now retains the exact inventory-source route for managed Storefront products, so buyers can stage own-inventory campaigns without a route-identity error.
• Creating a seller account is now more focused: company domain, billing currency, and support channel move to the guided setup steps after the account is created, where their purpose is clearer. Legal authorization is still required at account creation.
• Unenrolled accounts are unaffected and continue to see the current dialog.

​

5.358.0 — September 4, 2026 at 6:58 AM UTC

• Keep seller setup navigation legible and actionable by preventing workspace-tab overlap, naming incomplete inventory sources in the next step, and showing completed go-live steps without a strike-through.
• Keep seller workspace navigation in one rail, including live storefront and Agents-route follow-ups.

​

5.357.0 — September 4, 2026 at 4:18 AM UTC

• Sellers can request an interactive placement preview during Creative review for eligible third-party or unknown creative. No action is needed unless you choose to request or open a preview. This staged feature is included: it adds no package, entitlement, usage charge, or other billable surface.
• Buyers: requesting a preview sends your exact creative to an authorized preview provider only when a seller requests that preview so the seller can review it. Buyers have no additional action to take, and the provider does not receive your creative for static inspection, approval, or rejection alone.
• After the provider returns an expiring preview, sellers can choose to open it outside Interchange. Static source inspection remains inert, and sellers can approve or reject creative without requesting a preview.
• We will measure staged acceptance and adoption through the fixed lifecycle events mcp_creative_preview.request, .returned_link, .external_open, and .expired_link: request-to-returned-link completion rate, returned-link-to-open rate, and expired-link rate. These events contain no creative, URL, provider, or buyer identifiers.

​

5.356.2 — September 4, 2026 at 3:15 AM UTC

• The test-sales-agent validation skill’s advertiser-creation step now retries (up to 3 attempts) instead of failing outright on a rare, transient brand-lookup timeout, so self-validating your sales agent through this skill is less likely to fail for reasons unrelated to your own implementation. Published as test-sales-agent@1.5.1.

​

5.356.0 — September 4, 2026 at 1:23 AM UTC

• TikTok Traffic media buys now create successfully even when TikTok automatically extends delivery to its search results page — nothing to change on your side. TikTok’s platform doesn’t let advertisers opt out of this for some objectives, so your ad may serve there in addition to your selected placement.
• Media Companies no longer have to approve their own managed campaigns twice. Uploading Creative in an exact own-supply campaign satisfies the Storefront creative review; confirming Campaign launch and requesting a non-cancellation update satisfy the Storefront media-buy approval. Cancellation keeps its separate approval policy. Manual approval settings continue to apply to external and sponsored buyers, while source-native creative approval, readiness, financial, and safety checks remain unchanged.
• The new Buyer agents page shows which automations can call Interchange as your organization, and what proves it. It lists your organization’s own operator identity — with its principal ID and lifecycle state, but no credentials to manage — alongside every buyer agent you administer, each with its Interchange-issued principal ID, lifecycle state, and how many credentials are active. Identity is not authority: holding a principal or a credential grants no advertiser, account, spend, payment, or Terms access.
• From that page an organization administrator can issue a new identity-only credential, register an API key or OAuth client the organization already owns, rotate an API key, or revoke a credential. A secret is shown exactly once, in the response that creates or rotates it, and can’t be retrieved again afterward — not by the console, the API, or support.
• Rotating or revoking a credential asks you to retype the buyer agent’s name first. Revoking also states up front whether you’re removing the buyer agent’s last active credential — doing so suspends it until you add another — and revocation can’t be undone: the same credential can never be registered again.
• The page is backed by a new read, GET /api/v2/buyer-agent-principals. It returns your operator principal and your buyer agents, each credential’s type, active-or-retired state, timestamps, and the one identifier the rotate and revoke calls accept. It never returns a secret, and it carries no issuer URLs, organization IDs, domains, JWKS URLs, key IDs, or key fingerprints — those describe a credential, never the principal.
• Reads and changes both require you to be signed in directly as an administrator of the organization. Support, impersonated, simulated, and delegated sessions, API keys, and OAuth clients are all refused.
• See Buyer-agent credentials.
• Seller names, media-buy details, and creative formats now render in text content for AI agents using the v3 buyer surface.
• Agents on hosts that only pass tool text to the model (Claude web among them) were seeing sellers as bare numeric ids in proposal, media-buy, and request_proposals results, and get(kind: "media_buy") ignored include. Every buyer read now names the seller beside its id, get(kind: "media_buy") reports the campaign, seller, gross budget, and flight, and honours include: ["products"] (line items with their packages and human-readable format labels), ["creatives"], and ["deliverySummary"]. The single-buy REST read (GET /media-buys/:mediaBuyId) now carries campaignId. Nothing changes for callers that already read structuredContent; the same facts are simply mirrored into text.
• The Sellers page — where you choose which sellers to work with, set billing policy, and manage seller connections — is now available to every buyer account, in Claude, ChatGPT, and the Interchange web app. Seller connection management has moved there from the Settings → Connections pane, which still handles creative, data and measurement, and cloud-drive provider connections.
• Use one left-rail switch to move between Inventory, Advertisers, and Agents. Setup progress stays on Inventory, and each advertiser contains its campaigns.
• Setup checklist counts now show only the steps you still need to do; defaults and optional items no longer count as progress.

​

5.355.0 — September 3, 2026 at 5:31 PM UTC

• Buyers on the v3 agent surface can now open Advertisers, Campaigns, and a draft campaign’s Review & go live receipt from inside the conversation — nothing to set up. Ask your agent “show my advertisers” or “show my campaigns” and it opens the live, interactive Page in any host that renders MCP Apps — Murph, Claude, or ChatGPT — instead of reciting a list. Ask whether a draft campaign is ready to launch (for example, “is the spring launch ready to go live?”) and it opens Review & go live: the plan, the staged media buys and their budget split, why each buy is not live yet, and the readiness blockers still standing between the draft and launch. Reviewing never launches anything; going live remains the explicit, confirmed step it is today.
• Storefront readiness now reads the execution currency your ad server actually holds instead of inferring one from your storefront settings.
• Two things change for managed ad-server storefronts:
• A storefront that settles in more than one currency is no longer blocked because its ad server executes in a payment currency rather than the storefront default. Your ad server’s own default is what has to be enabled for new buys and settleable.
• A source whose ad server has no execution currency is now reported as blocked, with the reason, instead of appearing healthy in a currency copied from your saved connection settings. Previously a FreeWheel source could show a green execution currency and still fail a buy at booking time.
• Editing an ad-server connection also keeps the execution currency the ad server already uses, rather than resetting it to your storefront default.
• Nothing to change on your side. If a storefront was blocked on this, it clears on its own. If a source now reports blocked, the reason names the exact failed check — follow Ad-server execution currency is not ready in the source troubleshooting guide.
• TikTok Traffic media buys that previously failed to create due to a placement-setting mismatch now succeed in more cases — nothing to change on your side. TikTok’s platform doesn’t always honor the requested placement setting on the first attempt; when it still doesn’t, the buy fails safely instead of partially completing, the same as before.
• You can re-test an ad-server connection yourself again. Sync & diagnostics has a Test connection action that probes your ad server and shows what came back — pass or fail, with the ad server’s own message and what to do about it. Nothing is required of you: if a FreeWheel source was refusing buys because its currency had never been observed, re-testing it now is what clears that.
• Every probe is also recorded, including one that never reaches your ad server. “Last probed” says when anyone last checked, and says Never when nobody has — which used to look identical to a check that ran months ago.
• For sellers reading this over the API: a get on an inventory source now returns adServerProbe, so a read reports when the connection was last probed instead of letting stored state pass for a live test result. get also accepts an ad-server connection id where it previously took only the source id.
• In the Buyers directory’s account picker, you can now choose “Use Interchange default” to map a buyer relationship to your ad server’s shared default advertiser instead of mapping a dedicated account for that buyer. It’s offered when every active grant on the relationship settles through agent (Interchange-cleared) billing and the source’s configured default advertiser currently reads back healthy.
• Interchange keeps the mapping healthy on your behalf: if the source’s configured default advertiser later changes or stops reading back, the mapping is marked stale and execution pauses on it until it’s reconciled or you choose a dedicated account instead — it never keeps executing against a default that’s drifted. Relationships billed directly to the operator or advertiser still need a dedicated account mapping; this option isn’t offered for them.
• Buyer-facing surfaces are unaffected — buyers still see one account per relationship, with no visibility into which option you chose.

​

5.354.0 — September 3, 2026 at 2:26 PM UTC

• Plan & Billing now shows organization setup in the correct order: accept terms, select a plan when eligible, add billing details, then add a payment method. Completed steps stay marked complete if an earlier prerequisite reopens.
• Plan & Billing now separates pending IU offers from accepted plans. Pending offers appear in a dedicated IU offer card with their next action, while Your current plan and Your current terms only show accepted or effective information. Existing prices and agreements are unchanged.
• A new Connected apps page in your account menu shows every AI app you’ve authorized to access your Interchange account — such as Claude or ChatGPT — including when it was first connected and when it last refreshed. You can disconnect any of them from the same page.
• VAST tags registered through the API have never been able to reach a managed ad server without a declared version — now you can supply one and fix that. If that’s you, start setting vast_version on your VAST assets. If you don’t register VAST tags, there is nothing to do: hosted video and every other creative type are unchanged.
• Set vast_version on a VAST asset — 2.0, 3.0, 4.0, 4.1, 4.2, or 4.3 — when you create or update a creative:
• json { "url_asset": { "url": "https://ads.example.com/tag.xml", "url_type": "vast", "vast_version": "2.0" } }
• A VAST document is fetched at request time, not at registration, so we can’t detect its version automatically — you have to declare it. Until now a tag registered through the API carried no version at all, so it could never satisfy the check a managed ad-server destination makes before accepting a tag.
• Two sync outcomes are worth telling apart:
• destination_profile_rejected, reason missing:vastVersion — the tag declared no version. Update the creative with vast_version and sync it again to get it delivered.
• destination_profile_not_certified — the version is outside what we hold delivery evidence for on that destination. That boundary reflects what we have proven, not what the ad server refuses, so there is nothing to correct in your creative. Certifying that route is Scope3’s job: we have to establish delivery evidence on the destination before the version becomes eligible, and retrying the sync won’t change the result until that happens. There’s no self-serve status page for it today — ask Murph where the route stands, or raise it with your Scope3 contact.
• Declaring a version on a non-VAST URL asset is rejected as a contradiction rather than silently ignored.
• Existing enterprise and small-business customers do not need to take any action: accepted IU plans and billing amounts are unchanged.
• Billing administrators and builder/power buyers can now use Admin → Rate Cards (or the Rate Card API) to set the monthly subscription and included-IU allowance independently for a future offer. For example, a plan can charge a $1,000 monthly subscription with IU usage billed separately, or include 250 IUs with no monthly subscription. After a customer selects the plan, Plan & Billing shows the subscription, included allowance, and IU usage price as separate terms. For novice buyers, the existing plan-selection flow is unchanged; the clearer labels appear automatically and require no action.
• Organization administrators can now open Plan & Billing directly from organization settings without returning to the main account screen first.
• Child-only Seller Account administrators who follow a Plan & Billing link now see that billing is managed by the parent organization instead of being silently sent back to account home.
• Publisher authorization checks now agree with AAO when an authoritative manager file uses publisher_properties, repeats an agent URL for separate scopes, or mixes www and apex domains. When you connect or update a third-party sales agent, Interchange also rejects an adagents.json document as the agent endpoint and asks for the executable URL from authorized_agents[].url instead.
• Keep repeated unavailable Buyers actions visible and open Business Rules during storefront setup before approval capabilities are enabled.
• TikTok Reach media buys now pass readback verification and create successfully. Every TikTok Reach ad group was previously rejected after creation because it requested an optimization location TikTok doesn’t use for Reach campaigns; the ad group now requests the optimization location TikTok’s Reach objective actually expects.
• Wholesale pricing uploads now commit for every ad server’s own selector types. If you price FreeWheel site groups or site sections, SpringServe supply tags, or AdsWizz zones, a clean preview was followed by a commit failure naming an unsupported selector type — even for the selector ids our own pre-filled template gave you. Those feeds now commit, and your selector type is stored exactly as you sent it, so the pricing lands on the products keyed to it.
• Nothing about your file needs to change: upload the template as-is. A selector_type that matches none of your products still previews as an unmatched selector and prices nothing — that warning is the signal to check the id and type against the selector browser, and it no longer blocks the rest of the feed.
• When your storefront supports composed products, seller home now starts with “Interview your Merchandising Agent” and gives you two direct actions: teach it how your business sells or test it with a real buyer brief. Storefronts without composition capability keep the existing neutral home experience. This changes only the seller home entry point; it does not change what buyers see about your storefront.
• The explanation for an unavailable Fund your account action on Plan & Billing now remains fully visible instead of being cut off at the edge of the Standing & funding card. Nothing changes on your side.
• In the Seller Dashboard’s action row for a storefront that sells through its own sales agent: when merchandising is on your plan and a connected sales agent can supply products but hasn’t finished setup, you now see “Review source readiness,” which opens that source’s diagnostics, instead of “Connect an ad server.” When no connected source can supply products yet, you still see “Connect an ad server.” When merchandising isn’t on your plan, you still see “Upgrade to a merchandising plan.”
• “Listing-only account” now replaces “pass-through” on the plan screens and the Seller Dashboard badge — in renewal and non-renewal status lines, the free-plan confirmation step, and the badge label itself. The merchandising source prerequisite is stated in plain language everywhere it appears: a connected source that is ready to supply products your storefront can sell, such as an ad server.
• Buyer-facing surfaces are unaffected — every changed string is on the Seller Dashboard, the plan screens, or the seller glossary/onboarding docs.
• Source Diagnostics now reports only the discovery calls your diagnostics actually recorded. When a validation test ended without returning a usable result, the Product discovery row previously added a call of its own and showed “Calls 1 / Failed 1”, which read as a Source fault even when no such call had been recorded. The row now leaves the recorded counts untouched and says no test result was returned, so a test that gave you no answer is no longer indistinguishable from a Source that answered badly. Whether the Source was reached in that case is genuinely unknown until the diagnostics refresh, and the Page now says so instead of guessing. Run-specific request, response, and trace controls still appear only when the returned result includes their identifiers.
• Your seller rail stays in place when you open setup widgets, and newly created accounts open directly. Nothing to change on your side.
• For managed ad servers, connection responses now include the linked inventory-source name. Existing integrations continue to work without changes.

​

5.353.0 — September 3, 2026 at 7:17 AM UTC

• The Buyers account picker offers Use Interchange default for buyers you bill through Interchange, once it’s turned on for your storefront and your connected source has a healthy configured default account. One click settles that buyer through your existing default instead of creating or picking a dedicated native account — no setup required. The option only appears when it’s actually usable; it stays hidden for direct-billed buyers, a source without a configured default, or a storefront where the exit hasn’t been enabled yet.

​

5.352.0 — September 3, 2026 at 6:15 AM UTC

• Creative creation now commits its manifest, assets, metadata, and completion marker together. Failed saves leave no partial creative records, and a concurrent same-name request removes only its own prepared object batch before returning the existing creative; existing routes and V2 ordering remain unchanged.
• Buyers using their own connected Storefront can now reliably continue selecting products during campaign setup. You do not need to take any action. Sellers and their Storefront settings are unaffected.
• Scrappy builder / power buyer: On a configured Meta connection, you can use the MCP upload Task to add one private JPEG or PNG for the ad account you selected. If image upload is not shown, use a configured Meta connection; do not send the file through chat. Managed MP4 and audio uploads keep their existing account-access and service settings.
• Enterprise brand buyer: No action or governance change.
• Large agency / hold-co buyer: Existing team workflows do not change.
• SMB buyer (novice, chat): Nothing changes in chat.
• Seller check: This does not change seller ranking, inventory presentation, readiness, or setup.
• Fixed several issues on the storefront Listing page’s ChatGPT app and Distribution blocks:
• The generated-icon preview no longer shows a broken-image icon if it can’t load — it falls back to a plain tile instead.
• Directory and composer logo uploads now use an “Upload PNG” button instead of the browser’s native file picker, with the chosen file’s name shown next to it. Choosing the same file again (for example after replacing a logo and wanting to revert) now works correctly.
• The ChatGPT app’s category is now tucked behind a collapsed “Advanced — change category” section, since it’s already defaulted for you and most sellers never need to change it — but the current category always shows as a read-only row above, so you can see and confirm it before saving. If you change the category without saving, “Mark listing reviewed” is disabled until you save, so you’re never reviewing one category while approving another.
• Approving your ChatGPT app listing (“Mark listing reviewed”) now also covers the category shown at that time, the same way it already covers your listing name, subtitle, description, and URLs. If you approved your listing before this change and have since changed the category, you’ll be asked to review and approve it again — a one-time reset closing a gap where a category change alone didn’t require re-review.
• OpenAI Apps verification now appears only when Public web is selected, since that’s the only time there’s a public discovery URL for it to verify.
• Meta Feed Image, Feed Video, Stories, and Reels no longer advertise Call Now as a generic creative CTA. This change does not add a new Call Now option; use the existing Meta Calls product workflow when that product is available and configured.
• Seller impact: not applicable. This changes buyer capability discovery only; it does not change Storefront seller setup or delivery.
• Asking about a modular inventory source now returns its complete module list. Reading modular readiness returns tens of kilobytes of module contracts and per-stage field requirements, and an assistant that could only hold part of that answered from the part it had — reporting a source as having fewer modules than it does, and in one case describing an active trafficking module as absent. Modular source reads now state the module roster and the lifecycle stages it covers up front, so the list is complete regardless of how much of the detail behind it fits, and a partial read now says so instead of reading as a short one.
• Text fields (brand name, headline, etc.) now appear in the Upload tab when creating a creative for social platforms such as Snap, TikTok, Meta, Reddit, Pinterest, Spotify, and LinkedIn. Previously these fields were missing from the upload form, causing creatives to be rejected by the platform as invalid.
• Fixed a bug where creating a TikTok media buy for a non-conversion-tracking objective (e.g. Traffic) always failed with a false targeting mismatch, even though nothing was actually wrong with the campaign.
• TikTok Reach media buys now create successfully. Every TikTok Reach ad group was previously rejected by TikTok as invalid, because the ad group’s frequency settings were only sent when a frequency cap was explicitly requested. TikTok requires a frequency setting for Reach campaigns, so one is now always included — using your requested frequency cap when you set one, or a default sized to your flight dates otherwise.
• The Sellers page in Claude no longer shows a blank surface while it connects and retries automatically if the first connection stalls. Also registers record_widget_telemetry, an app-only, model-invisible observability tool with a closed fixed-code schema; it adds no customer capability, so this stays a fix.
• Technical buyer administrators can now issue a new identity-only credential for a buyer automation, instead of only registering one the organization already owns. Like a registered credential, it authenticates the automation only — no access to advertisers, accounts, spend, payments, Terms, or other business APIs.
• A directly authenticated organization administrator issues it through the buyer REST API, and can replace it later without changing the automation’s identity. Save the one-time client secret when it is returned — it cannot be shown again. If an issuance comes back needing reconciliation, retry the same request with the same idempotency key before trying anything else. There is nothing new for chat-only buyers or sellers to configure.
• The Seller Dashboard for accounts that sell through their own sales agent no longer shows a “Turn on merchandising” button that granted nothing when clicked. It now shows the one control that matches your account: sellers without a merchandising plan see “Upgrade to a merchandising plan” and go straight to Plan & Billing; sellers who already have a plan but no connected ad server see “Connect an ad server” instead. Sellers who already have both see no control here — merchandising is already on.
• Embedded sales agent 1.42.0. GAM-backed storefronts can now target every country GAM itself can target, including region-typed country targets, and a request naming a country the agent cannot map now fails closed instead of being silently narrowed. FreeWheel-backed storefronts are buyable again, and a media buy binds to the FreeWheel account the request names rather than a default.
• Corrected the update_storefront_capabilities documentation to match actual behavior: recording setupIntent (third_party_connect | sell_through_scope3) is purely descriptive and has never applied a capability preset or been rejected on ad-server-backed storefronts — capabilities (derived from merchandising entitlement and Source product readiness) is the only thing that changes what a storefront can do. Removed the dead, uncalled compatibility helper that previously implemented the (already inert) preset.
• Also documented an existing validation rule that already applies today, with the full rule and worked examples in Storefront onboarding → Approval-routing prerequisite. On an existing storefront that is not routed through an adapter, a save is rejected with a 400 (field-scoped to mediaBuyApproval or creativeApproval) when it results in that approval setting being manual and the matching capability (offersCampaignApproval or offersCreativeReview) being effectively true — unless that exact pair already held immediately before the save, or approvals of that kind already have somewhere to route: an active primary approval-routing policy for it, or, when none is saved, at least one active organization admin (the default). Routing is opt-out, so most sellers need no setup; configure an approval-routing policy only if approvals should go somewhere other than your organization admins. No behavior changed here — this makes a rule that was already enforced visible.
• Shareable buyer invite links have been retired. Opening a saved or shareable buyer invite link now shows a not-found (404) page and does not start signup. To access a seller, open the seller’s verified storefront or find the seller through Discovery. If you do not use saved or shared buyer links, no action is required.
• Sellers: replace any shared buyer-link directions with your verified storefront or Discovery page. Your existing buyer approval settings are unchanged.
• Enterprise and agency buyers: update saved links and team playbooks to use sellers’ verified storefronts or Discovery. There is no replacement invite-link workflow.
• SMB buyers: if a link no longer opens, search for the seller in Discovery or open the seller’s verified storefront. No technical setup is required.
• API and MCP builders: remove calls that create, list, delete, or resolve buyer links, and remove joinSlug from requests. Authenticated calls to retired APIs are not found (404); anonymous requests to the formerly public resolver are rejected by authentication without disclosing context. joinSlug is rejected as invalid input. Send users to the seller’s verified storefront or Discovery instead. There is no replacement targeted-invite API.
• Packaging and pricing are unchanged.
• Sellers can now declare the full AdCP MediaChannel vocabulary on their listing — including search, linear TV, radio, podcast, out-of-home, print, cinema, email, gaming, retail media, influencer, affiliate, product placement, and sponsored intelligence — instead of the previous six-channel set. Saving still accepts the legacy audio/video spellings for backward compatibility; video is now saved as olv and audio keeps its established spelling, so nothing already using either alias needs to change.

​

5.351.0 — September 2, 2026 at 10:35 PM UTC

• save_media_buy now stages auction-priced products and tells you plainly when a request cannot be applied.
• Auction products can be staged. Pass bidPrice (in the campaign currency) on any products[] entry whose pricing option is auction-based. Fixed-price products are unchanged; omit bidPrice for them.
• Budget changes on an existing draft no longer silently no-op. Calling save_media_buy with mediaBuyId and a budget now returns a NOT_IMPLEMENTED error explaining that the budget set at staging time is preserved, instead of returning success without applying the change.
• Same-day and past start times are rejected up front. On the update path, a flight.startAt that falls today (UTC) or earlier returns a VALIDATION_ERROR on flight.startAt with guidance to pass a later date-time or "asap". Media buys start on a future UTC day, so this replaces the previous behavior of accepting the timestamp and then either failing at the seller or quietly starting as soon as possible.
• Nothing changes for agents that only stage fixed-price products and never send a budget or past flight.startAt on update.
• If your agent calls get_proposals_diagnostic directly, you must switch to request_proposals with the same idempotencyKey to poll a running execution. Agents that do not call get_proposals_diagnostic only see the request_proposals error-message change described below.
• get_proposals_diagnostic has been removed from the v3 buyer MCP surface. The request_proposals tool already supports idempotent polling: calling it again with the same idempotencyKey returns the in-progress or completed result without starting a new execution. That pattern is now the only supported way to poll.
• Agents that currently call get_proposals_diagnostic will receive an unknown-tool error after this change and must migrate to the request_proposals polling pattern before then.
• Also in request_proposals: when a seller’s agent reports an error, the per-seller error.message now carries a short Scope3-written explanation (for example, “The seller returned PRODUCT_NOT_FOUND. Seller-supplied error text is withheld from this response.”) instead of the seller’s own free text, and the code is limited to standard AdCP codes with SELLER_ERROR as the fallback. Errors raised by Scope3 itself (for example a product snapshot that could not be saved, or no connected sales agent for the seller) keep their original code and message. If your agent displayed a seller’s raw message, expect the neutral text in its place.
• In Plan & Billing, you will now see your accepted, priced activity in IUs and a breakdown that matches your IU balance. Scope3’s provider costs are no longer shown as your IU activity, and no action is needed.

​

5.350.3 — September 2, 2026 at 7:31 PM UTC

• Buyers using your own inventory: We fixed an issue that could lose the selected product during activation. This selection fix applies only to own-inventory campaigns; third-party inventory selection is unchanged.
• Buyers with saved creative links: Supported seller destination URL slots now receive the saved clickthrough link instead of dropping it from the seller request.
• Sellers: This restores the buyer-provided destination in supported URL slots. It does not change how your inventory is listed or which buyer campaigns you can see.
• Existing saved campaigns and creatives use the corrected behavior on their next activation; they do not need to be recreated. No setup changes are required.

​

5.350.2 — September 2, 2026 at 3:30 PM UTC

• Own-supply product discovery now preserves a completed catalog when a seller responds during the first progressive window, so immediate continuation calls return the same selectable inventory instead of an empty result. Nothing needs to change on your side.

​

5.350.1 — September 2, 2026 at 12:22 PM UTC

• The Company tab’s setup checklist no longer shows a completed “Company identity” step once your company is admitted. The country picker in Branding & distribution groups popular countries first, and its “Add country” control no longer claims to be a search field. The printable-card button explains why it’s disabled whenever the current listing isn’t published, not just in one narrow case. The ChatGPT app icon uploads now state the exact size and file-size limit required, and can reuse your storefront’s own generated icon instead of a manual upload.
• Product discovery continuations now preserve the completed catalog from the original request instead of unexpectedly returning different or missing inventory.
• Product discovery now keeps supported_targeting stable across provisional and terminal catalog reads, so an undeclared targeting list cannot invalidate an own-supply product selection.

​

5.350.0 — September 2, 2026 at 10:47 AM UTC

• Preserve the host-neutral Company identity task destination and cover real iframe source-chooser actions in the setup-nav browser regression gate.
• The Company identity & eligibility setup row now displays its label in the seller rail.

​

5.349.0 — September 2, 2026 at 9:15 AM UTC

• Changing geo targeting on an existing Meta media buy through update_media_buy no longer fails. A package’s budget, pacing, and bid price on a Meta media buy now actually reach Meta when you change them — previously these appeared to succeed but were silently never applied on Meta’s side. If you changed a package’s budget, pacing, or bid price on a Meta media buy before this fix, resend that update to make sure it took effect. Changing an individual package’s flight dates isn’t supported on Meta; use the media buy’s overall start and end date instead.
• Products returned by get_products now include a supported_targeting field listing the targeting dimensions the product accepts as an overlay (e.g. "geo_countries", "language", "device_type"). Use this to avoid forwarding overlay dimensions a product cannot resolve — absence means the seller did not declare targeting support.

​

5.347.0 — September 2, 2026 at 6:30 AM UTC

• Sellers can now list VAST-delivered audio, seller-rendered stateful display, and coordinated multi-placement products, and buyers can select them without those formats being rejected or dropped. Sellers who want to offer them must add the matching audio_vast, seller_rendered_stateful_display, or coordinated_placements declaration to their products. Existing products, including DAAST and hosted-audio formats, are unchanged.
• VAST audio now stays intact from product discovery through selection, validation, pricing, and creative delivery. Collection-based targeting from AdCP 3.2 is also preserved in requests instead of being discarded. Buyers who only use existing formats do not need to take any action.
• Who this is for: Enterprise brand buyers gain access to additional seller inventory without a governance, partner-instruction, measurement, or billing change. Large agencies can compare and select the new formats across sellers without changing playbooks for existing formats. Scrappy builders can use the new format_kind values directly and can pass collection selections without them being dropped. SMB buyers using chat do not need to configure anything; the product adopts compatible seller capabilities automatically. Sellers that opt in should add the matching declarations and monitor catalog completeness and creative-readiness results for those products.
• Packaging and monetization: There is no entitlement, plan, price, billable-surface, unit-economics, commercial-package, or Interchange Unit change. These formats and collection fields are additive capabilities inside the existing buyer and seller surfaces.
• Availability and rollback: This ships as one ungated contract update because a partial flag would let discovery, selection, and validation disagree about the same format. Exposure is still opt-in at the protocol boundary: a seller must declare a new format, and a buyer must select it or send collection selection fields. Existing formats remain the default. Broader promotion of each new format requires at least one seller discovery and one successful buyer selection for that format, with no confirmed schema mismatch. The kill switch is an atomic code revert that removes the new SDK/schema version and derived format declarations together; 3.2-only requests then fail closed while existing hosted-audio, DAAST, display, and placement paths continue unchanged.
• Measurement: Track adcp_3_2_format_discovered as the first successful product response per seller and buyer customer containing each new format_kind; track adcp_3_2_format_selected for successful media-buy or creative submissions using those kinds; and track adcp_3_2_collection_selection_preserved when a request with collection selection reaches the downstream canonical request intact. During the first 30 days, establish unique-seller and unique-buyer baselines for each signal, require zero confirmed audio/video VAST misclassifications and zero dropped collection selections, and revert on a reproducible contract mismatch. Brian O’Kelley owns the 30-day review through AI-6639; low adoption creates a discoverability follow-up rather than weakening the contract checks.
• Technical buyer administrators can now connect an existing organization API key or WorkOS machine credential to a distinct buyer-agent identity, and turn off that identity from the same API. This helps hands-on teams keep an agent’s authentication separate from a person’s account without granting it access to advertisers, accounts, spending, payments, or Terms.
• Existing integrations do not change. To use this capability, a directly authenticated organization administrator registers a credential the organization already owns. There is nothing new for chat-only buyers or sellers to configure. Creating a new credential or swapping one credential for another is not included.
• Connecting a seller no longer dead-ends silently when an authorization link is opened more than once: the link pages now explain what happened (recently used or expired) and how long links stay valid (10 minutes). Bearer (access-token) submissions remain strictly single-use.
• Agent-visible text for seller and connection reads now includes discovered ad-account names and mapping states (not just a count), says explicitly when an advertiser transacts on account-level seller defaults, shows seller names instead of “Customer NNNN” placeholders, and prints names beside ids.
• We renamed the seller identity/story object buyers see in Marketplace — description, channels, accepted countries — from “media kit” / “Discovery Card” to Listing, and updated every agent-facing tool, error message, and doc to match. The v3 get seller include for it is now spelled listing — request it with include: ["listing"]. The deprecated discoveryCard spelling keeps working as an alias with no removal timeline: the response echoes back whichever spelling you sent, so an existing integration reading object.discoveryCard is not broken by the rename. All other agent- and buyer-facing tool descriptions, error messages, and documentation now consistently use listing / distribution / brand domain vocabulary in place of the retired media kit and Discovery Card names; “operator domain” is retired from seller-facing copy in favor of brand domain (it remains the name for a buying operator’s own domain on the buyer side, e.g. house discounts).
• This also fixes a real routing bug in the v3 open_page navigation tool, which had fallen out of sync with the rename above: page: "listing" had been opening the legacy Business Profile merchandising page instead of the current Listing page it’s named for. Fixed now, with three concrete behavior changes for any agent or integration calling open_page directly:
• page: "listing" now opens the Branding & distribution page (the current Listing) — it briefly opened the legacy Business Profile page instead; that misrouting is what this release corrects.
• page: "media_kit" (a deprecated spelling of listing) previously opened that same legacy Business Profile page. It no longer opens anything: the call now returns an explicit, self-describing error naming both successors, so any caller using this key must switch to page: "listing" (Branding & distribution) or page: "business_profile" (the legacy page, still fully reachable) — the ambiguity between the two meanings this one spelling had accumulated over time made silently picking either wrong for whoever meant the other.
• page: "discovery_card" (a deprecated spelling that always meant the current Listing page, never the legacy one) keeps working unchanged, now with an on-response note pointing callers at the canonical listing spelling.
• This ships as improvement, not feature, because the affected key (media_kit) is a deprecated alias on the v3 seller surface — a young, admin-gated integration path, not the primary customer-facing surface — and the new error is self-describing enough that an agent caller reads it and corrects its next call in the same turn, rather than needing new documentation or a workflow change. The repointing itself was ratified by the repo owner as a bug correction, not a new capability: nothing a seller or buyer does in the product changes.
• Sellers using the seller UI: no action needed. The UI does not call open_page with page: "media_kit", and your listing, distribution settings, and pages are otherwise untouched — only names changed, and every other deprecated spelling keeps working. Developers or agents calling open_page({page: "media_kit"}) directly should switch that one call to page: "listing" or page: "business_profile", per above.
• execute_campaign on Spotify, Snap, and TikTok adapter storefronts no longer fails with “ESA create dispatch returned an invalid structured response”. These adapters now return a media_buy_status of pending_creatives after a successful create (campaign paused, awaiting creative assignment), which is the correct lifecycle state and allows the host to record the submission.
• Fixed the storefront’s advertisedCountries and advertisedChannels to only reflect Sources whose product path currently routes through your own external sales agent. A Source that instead supplies Storefront-built (wholesale) products no longer contributes its raw upstream declaration to this coverage — that path’s evidence comes from its synced inventory instead. Storefronts with a mix of agent-supplied and Storefront-built Sources, or a Source pending a required mode selection, may see these fields narrow to the coverage their external agent actually advertises.
• The same fix now also applies to market membership and public market readiness: a Storefront-built (wholesale-only) Source can no longer make a storefront falsely appear tagged into a market, or make the public market readiness preview report supply that isn’t actually agent-supplied.
• Snap media buys with country, region, or postal targeting now create and update correctly. Two bugs were fixed: ad squad write requests were missing the targeting_v2=ENABLED query parameter that Snap requires to parse geo targeting, causing all geo-targeted creates to be silently rejected; and the postal-area validation guard did not recognise the {country, system: "us_zip"} shape that Interchange’s schema produces, causing US ZIP targeting to be rejected before reaching Snap.
• Spotify media buys with a package budget below Spotify’s $250 per-ad-set minimum now fail immediately with a correctable error message ("Spotify requires a minimum budget of $250 per ad set”) before any campaign is created, instead of silently inflating the budget to $250 with no signal to the buyer.
• If sign-in recognizes your verified email but account setup was interrupted, Interchange now returns you to signup with your details prefilled so you can finish. This works for buyer and seller accounts; no action is needed unless you encounter this interrupted state, and you do not need to reset your password.

​

5.346.1 — September 2, 2026 at 3:03 AM UTC

• Agent operators can now open and complete Configure connection from the Agent page, with a visible error instead of a silent click if the task cannot open.

​

5.346.0 — September 2, 2026 at 12:54 AM UTC

• Partner operators can now refer a publisher from an Agent’s Sources section. The client workspace opens on that exact Agent, preselects it in the invitation, and keeps the Agent’s pending referrals in view.

​

5.345.0 — September 1, 2026 at 10:35 PM UTC

• Open Plan & Billing help links on the current Interchange documentation site.
• Show “Not priced yet” instead of “NaN IUs” when an activity rate is unavailable.
• Seller account tiers now have clearer names throughout sign-up, plan copy, and documentation: a Listing-only account gets your listing on Interchange while your own sales agent handles selling, and a Merchandising account adds full merchandising functionality. The old “pass-through” plan wording is retired from sign-up, plan copy, and docs.
• New Media Company signups now land on a short company-confirmation page before they reach account setup. This is a limited early-access rollout — existing accounts aren’t affected and don’t need to do anything.
• Right after you create an account, we show the company name and domain we found from your sign-up email and ask you to confirm or correct them, along with the billing country of the contracting company (not your personal location). That country is the only input to your plan currency: there’s no currency picker, and a country we don’t support yet shows next steps instead of defaulting to USD. Confirming also records your acceptance of the Terms of Service and disclosure of the Privacy Policy.
• Confirming starts a short admission check, usually a few seconds. If it runs longer, you can close the page — refreshing or logging back in picks up the same check instead of starting over. Once approved, your first setup screen already shows “Company identity” as done on the setup checklist.
• Label the account-standing payment arrangement as “Billing method.”
• Media-buy status updates now complete reliably when multiple sellers respond at the same time. No action is required on your side.

​

5.344.0 — September 1, 2026 at 8:36 PM UTC

• Demo Storefront accounts now provision their synthetic inventory and setup checklist when created from the account switcher.
• Keep scoped Murph workspaces focused on their own canvas, bring newly opened workspace widgets into view, and preserve advertiser scope IDs in shareable URLs.
• Keep enrolled sellers on their setup checklist while it loads or retries, without showing another account’s cached rail.
• Your setup checklist rail and payout status page now reflect your actual account state. If a required payout or setup step is missing, you now see the action to take instead of a completed status. Sellers whose status was already accurate do not need to take any action; this seller-side correction does not change buyer-facing storefront capabilities.
• Prevent seller setup source actions from regressing into dead controls.
• The v3 save_advertiser and save_campaign tools now accept gvlVendorId on tracker inputs. Set this to your GAM TCF vendor ID to enable vendor-scoped consent macros in your ad tags. For sellers: trackers that carry a vendor-scoped macro will now include vendor-specific consent values in the outbound pixel — tags without a vendor ID are unchanged.

​

5.343.0 — September 1, 2026 at 6:00 PM UTC

• Asking Murph what you need to go live now opens your redesigned Buyer Setup page — the platform go-live checklist, your operator identity, and each seller or platform’s remaining connection, mapping, or billing step — instead of a long text summary. Murph gives a one-line lead-in and lets you act in the page, and no longer answers a buyer go-live question with seller-side readiness detail. The page is rebuilt on the Scope3 design system.
• Fixed a bug where forwarding a media buy to a third-party AGENT storefront source that returns a synchronous acceptance would report “No source accepted the media buy” to the buyer. The source accepted the buy successfully; our own inline handler threw because it looked up a buyer-side media buy record that only exists on the buyer’s tenant, not the storefront’s.
• External-agent storefronts now recognize publisher authorization for their connected sales agents.
• If your storefront sells only through connected external AdCP agents, each publisher’s adagents.json is checked against those agents’ published URLs. The publisher is authorized when the file grants property authority to at least one connected agent, so publishers no longer show a false “adagents.json does not list your sales agent” warning when they authorize the agent that serves their inventory. Existing affected publishers are queued for a new authorization check, and later agent URL or source-status changes trigger another check automatically. Storefronts with operator-run inventory continue to use https://interchange.io as their authorization identity. Nothing to change on your side.
• When you change a package’s targeting (geography, audience, or other overlay fields) with update_media_buy, the call now waits for your seller to confirm the change before reporting success. If the seller can’t confirm it, you get an error instead of a false success. Nothing to change on your side.
• Sellers holding a global market-maker authority now qualify for advertisers in every market, even when the seller’s storefront hasn’t enumerated regions. Previously an empty region list silently disqualified every advertiser with a misleading market-mismatch message.
• Sellers with only regional authorities, and sellers with no authority at all, keep their existing region-list behavior.
• Playbook version history no longer displays internal bookkeeping notes.
• The v3 agent surface’s deprecated compatibility singleton for the legacy Business Profile is now spelled listing on get/open_page, and save_seller accepts a grouped listing write field. media_kit/mediaKit keep working as deprecated aliases for the identical handler — no removal timeline is set. Sending both listing and the deprecated mediaKit alias with different values is rejected; identical values are accepted.

​

5.342.1 — September 1, 2026 at 1:51 PM UTC

• Sponsored sandbox buyers can now request proposals from their sponsoring storefront while it is still in sandbox readiness.
• Seller integrations can now match each material-candidate, RFP representation, and feedback response to its request more reliably. The service echoes the request, RFP, and turn identifiers you provide and includes generated representation or source-revision identifiers where applicable. When an existing representation is reused, clientRequestId identifies this call and originatingClientRequestId identifies the request behind the shared representation and its validation receipt. No request format or action is changing, and existing stored records continue to replay for older clients.
• Clarify directed campaign subscription instructions while keeping the V3 buyer tool surface within its context budget.

​

5.342.0 — September 1, 2026 at 12:50 PM UTC

• Creative reviewers can now request a placement-specific preview result when the seller’s completed package response identifies one exact format and placement. Interchange preserves and labels publisher-authoritative and representative seller results, including fidelity and expiry, while keeping raw provider URLs, HTML, submitted third-party tags, and remote VAST inert in the browser. Reviews without an exact authority context continue to show the submitted source only.
• Stage a creative on an advertiser before you have a campaign. save_creative now accepts an advertiserId in place of campaignId and creates an advertiser-level master. The same call previously failed with campaignId is required to create a creative, so creative work had to wait for a campaign to exist. The master won’t deliver until you assign it to a campaign, and it still needs both content (message, assets, or clickUrl) and a format — formatKind, unless an image, video, audio, HTML, or VAST asset implies it. Name and scope alone are rejected, and so is a brief with no format. Nothing changes for campaign-scoped creates.
• When save_creative persists fewer assets than you sent, it now tells you how many attached and sets assetAttachWarning on the response — a saved click-through URL can no longer make a dropped image look like success. Creating a creative on an advertiser also now confirms the advertiser belongs to your account before writing anything.
• The Listing page now leads with your storefront’s listing content once, replaces the visibility dropdown and separate Publish button with a single “Where can buyers find you?” control (Hidden / Interchange / Public web), and moves the dedicated-hostname setup behind an “Advanced” disclosure so it only shows up when you’re serving on your own domain. The ChatGPT app section is now a compact status row with a collapsed preview of what ChatGPT shows, instead of a full settings form.
• Nothing to change on your side — your current visibility, listing content, and ChatGPT app setup are unaffected. Only visit the page if you want to adjust who can find you or explore the streamlined layout.
• Buyers: Media buys now remain bound to the exact Storefront and inventory source selected in product discovery. No action is needed in the Interchange UI or Murph, or for API and MCP integrations that already store and return productId unchanged. An integration that modifies or rebuilds this opaque value must instead persist the value returned by discovery. If a previously stored value could select more than one inventory source, the request now stops instead of choosing one unpredictably; run discovery again and retry with the new productId. The field name and string type are unchanged.
• Sellers: No action is required. This does not change product setup or how a Storefront publishes inventory; it keeps the buyer’s selection tied to the product route returned through discovery.
• In the updated Buyers view, a relationship held only on billing readiness (no open request left to review) now has a “Resolve billing” action that opens the billing-readiness section directly, so you can assert readiness again without a dead end.
• You can also withdraw your own pending information request without deciding the whole case — the case stays open and returns to your queue, instead of your only option being to decline it.
• The setup-nav checklist rail now appears immediately when you open Murph — no more flash of the old navigation before the checklist loads. A skeleton placeholder appears in its place during the brief load window, and the checklist renders as soon as your storefront status arrives. Your last-loaded checklist state is also persisted locally so subsequent visits render the checklist instantly while a fresh update loads in the background.
• Embedded sales agent 1.41.0: replacing an ad-server connection no longer loses the destination advertiser it was mapped to, FreeWheel advertiser rosters are no longer cut off at a fixed ceiling, and FreeWheel execution currency now bootstraps correctly instead of blocking first use. The agent also now publishes an advertiser-account capability descriptor (starting with Google Ad Manager) that tells the platform exactly which account operations each ad server supports — groundwork for smoother buyer account setup — and runs on the AdCP Python SDK 8 beta.
• The seller Setup page that shows your identity, description, accepted channels, and countries to buyers is now called your listing instead of “media kit.” Sellers with a ChatGPT app still see it referred to as your “ChatGPT app listing,” which is a read-only projection of the same listing. This also fixes a stretched status chip on the Branding & distribution page, removes a duplicated identity display, and rewrites the brand domain explainer in plain language.
• The seller detail drawer now puts a Reconnect action at the top when a connection needs re-authorization, explains market/channel mismatches by naming the mismatched markets instead of a generic line, and adds search and status filters to the advertiser list.
• Buyers on the v3 MCP surface can now discover marketplace-listed sellers they have not yet connected to via search(kind:"seller", filter:{marketplace:true}). Channel filters accept multiple values with OR semantics: a seller qualifies if any listed channel matches. Existing search(kind:"seller") calls without marketplace:true are unchanged and continue to return only your connected sellers - no migration needed.
• To subscribe to a connected seller’s directed campaigns and mirror them into your reporting view, call save_directed_campaign_subscription. Subscription requires an existing seller connection. On partial failure, errors lists which subscriptions failed; successful subscriptions are not rolled back. Retry failed items individually.
• For sellers: marketplace-listed sellers become discoverable by all buyers using the new filter. Directed-campaign subscriptions only mirror campaigns the seller has explicitly listed; no undisclosed seller data is surfaced.

​

5.341.1 — September 1, 2026 at 8:01 AM UTC

• The Sellers page and other Murph-surface views no longer risk a render loop (React maximum-update-depth crash) when a navigation updates the page’s URL parameters.

​

5.341.0 — September 1, 2026 at 6:13 AM UTC

• Disconnecting Interchange from Claude, ChatGPT, or any AI assistant now ends your access immediately — before, your connection stayed live for up to 30 days after you disconnected. No changes needed; any AI assistant connected to Interchange picks this up automatically.
• The Sellers page widget now sizes correctly when opened directly on a seller’s detail drawer, instead of clipping the drawer to a short band.

​

5.340.0 — September 1, 2026 at 4:15 AM UTC

• MCP connections no longer drop when a host refreshes credentials from multiple components at once. A 90-second grace window lets concurrent legitimate clients (such as multiple Claude.ai components sharing one refresh token) receive the same successor pair instead of each one’s reuse triggering family revocation.
• MCP clients that received a grant for https://api.interchange.io/mcp can now call /mcp/v3.
• Clients (e.g. Codex/openai-mcp) that completed the OAuth flow against /mcp before discovering the versioned endpoint were rejected with resource_mismatch on every /mcp/v3 call. The server now accepts that specific grant at /mcp/v3 only — no other endpoint is covered by this change. Grants issued for any other resource (including /mcp/v2/admin, /mcp/v2/tars, /mcp/tars, /mcp/creative, or any other child of /mcp) still require an exact-resource match. New grants issued from a /mcp/v3 authorization flow continue to bind to the exact endpoint.

​

5.339.0 — September 1, 2026 at 3:11 AM UTC

• Fixed five issues in the seller setup checklist rail. Branding & distribution now opens your media kit instead of the property roster. Business rules opens in place instead of navigating away to an empty page. Buyers shows a clear “can’t open this right now” message instead of silently opening the sales agent surface when self-serve buyers isn’t enabled for your storefront. Plan & billing now renders with the same card styling as every other checklist item. And a Google Ad Manager sign-in problem no longer shows up as a warning on unrelated modular sources that have no GAM connection to fail.

​

5.338.1 — September 1, 2026 at 2:16 AM UTC

• Buyer Sellers now recovers on the next request after a temporary access-check failure, instead of remaining hidden for up to five minutes. Explicitly disabled access remains hidden, and customer and parent-account isolation are unchanged.

​

5.338.0 — August 31, 2026 at 11:27 PM UTC

• Fixed execute_campaign/create_media_buy and get_media_buys failing for Meta media buys because Meta’s raw timestamp format was passed straight through into confirmed_at/created_at/updated_at instead of being normalized to the required ISO 8601 format. These fields are now always correctly formatted.
• Fixed the seller rail’s “Set up” section sometimes collapsing itself a moment after loading, hiding rows (“Get ready to sell”, “Ad server”, “Sales agent”, “Branding & distribution”, and others) that had just appeared — its collapsed/expanded state could flip once the readiness read settled after the section had already rendered open. The section now defaults to collapsed while that read is still pending, so it either stays put or reveals itself once settled, and never opens a row only to close it out from under you. Explicitly expanding “Set up” while it loads is preserved even if the section would otherwise default to collapsed once loading finishes.
• Seller admins can now download a printable Discovery Card PDF from Branding & distribution after publishing a card. The PDF is generated from the current published revision for manual printing; fulfillment, provider submission, GCS delivery, webhooks, and durable print orders remain out of scope. This is seller-only tooling; buyers do not see a new download action.

​

5.337.0 — August 31, 2026 at 7:20 PM UTC

• When creating a wholesale product in the inventory-selector widget, you can now set delivery type (guaranteed or non-guaranteed) and a fixed CPM rate. On the product creation form, select “Guaranteed (fixed price)”, then enter a positive CPM amount and the 3-letter currency code that matches your storefront’s settlement currency. Guaranteed products are validated and submitted with the correct ad-server settings automatically - no manual configuration outside the widget. Existing products are unaffected. Buyer-facing inventory availability is unchanged: buyers see guaranteed products when they were previously configured correctly, now with less risk of misconfiguration on the seller side.
• For buyers: Third-party impression trackers configured on an advertiser or campaign (via PUT /api/v2/buyer/advertisers/:id/tracking-config) now attach automatically to outbound display and HTML creatives on the next creative sync or media buy. The media buy ID is stamped into each pixel request for per-buy attribution. No buyer action is required beyond configuring the tracker.
• If a creative’s format does not support tracker attachment (for example, a format that reserves all asset slots), the tracker is skipped for that creative and a NO_ATTACHMENT_PATH event is logged. The buy proceeds normally; only that creative’s measurement is affected.
• Trackers requiring IAB TCF vendor-scoped consent must include a gvl_vendor_id in the tracking configuration. If omitted, the IAB consent macro resolves to an empty string in the pixel URL, meaning the pixel fires without a consent signal. VAST (video) tracker support is coming in a separate update; existing click tracking is unaffected.
• For sellers: Buyers whose advertisers or campaigns have trackers configured will now include <img> pixel tags (injected before </body> in HTML display creatives) or pixel_tracker assets (in image and HTML5 ZIP creative payloads). No seller configuration change is required.
• This feature ships unconditionally to all accounts. It is backend delivery infrastructure tied to the existing tracking-config resource; no new customer UI surface is introduced and no flag is needed to control rollout. Adoption is tracked via NO_ATTACHMENT_PATH log events (skipped creatives) and per-buy pixel delivery rates. Third-party tracker delivery is included in the existing buyer platform tier with no separate charge.
• Audio creatives linked by URL now use the media’s probed file size when the origin reports one, instead of always falling back to the URL’s own length. Outbound audio creative delivery also now carries duration, container, codec, and bitrate detail, matching what video creatives already send; file size is not included in that outbound detail yet. This does not add support for any new audio destination; audio delivery through managed sources is still not available.

​

5.336.0 — August 31, 2026 at 4:59 PM UTC

• When a proposal request finishes, buyer agents using get_proposals_diagnostic can now show the returned product names, prices, and formats. Nothing to change on your side.

​

5.334.0 — August 31, 2026 at 2:13 PM UTC

• get(kind: "distribution") now reports a bounded, per-channel readiness summary — starting with your ChatGPT app: whether the listing is ready to submit, how many setup items remain, hostname and verification status, whether the submission bundle is current and approved, and one next-step line. Ask your agent “is my ChatGPT app ready?” without opening the Branding & distribution page. This reports platform-side readiness only — OpenAI’s own review and publish decision still happens on their portal.

​

5.333.0 — August 31, 2026 at 1:17 PM UTC

• Buyer creative details now show submitted display tags, VAST/DAAST source, tracking tags, and detected macro placeholders as inert text without executing ad code. Seller approval reviews show the same source evidence as a safety and trust signal. This source-inspection slice does not add rendered previews.
• Proposal requests now complete without getting stuck or asking for the same approval repeatedly. Product names, prices, and formats remain visible throughout the request. No changes are required on your side.
• Fixed execute_campaign/create_media_buy intermittently failing with “ESA create dispatch returned an invalid structured response” for Meta media buys, caused by an unrecognized Meta campaign status silently producing no lifecycle status at all. The buy is now correctly recognized and returned as completed with its real lifecycle status.
• When you ask Murph what a publisher needs for a GAM pilot, it now starts by retrieving the public GAM pilot guide and evaluating the particular publisher’s materials against it. The guide keeps audience and contextual signals in the core merchandising setup, checks that media-kit, pricing, and brief inputs can produce a strong response, and prefers real briefs plus the publisher’s responses over invented examples. Murph no longer carries these pilot requirements as client-specific prompt instructions.

​

5.332.0 — August 31, 2026 at 11:30 AM UTC

• Buyers and sellers can now connect Interchange from Microsoft Copilot Studio and Google Gemini Enterprise, in addition to Claude, ChatGPT, and Cursor. See Connect Interchange to Microsoft Copilot Studio and Connect Interchange to Gemini Enterprise for setup steps.

​

5.331.0 — August 31, 2026 at 10:30 AM UTC

• Before trafficking a third-party tracker, you can now use the read-only V3 beta test_creative_macros tool to inspect its vendor, AdCP, recipient, and synthetic final forms. Missing required mappings or values fail closed. Any supplied IAB GVL vendor ID shows Google Ad Manager consent syntax only; the tool cannot verify ownership, so the report remains not preview-ready. Verify the ID separately before production use. Existing creatives and delivery are unchanged: the tool does not fetch the URL, save a report as a platform record, render a creative, or attach a tracker. Standard request auditing retains only status and count metadata, not tracker URLs or binding values.

​

5.330.0 — August 31, 2026 at 9:09 AM UTC

• Your ChatGPT app listing now comes from your media kit. Name, subtitle, description, and your website, support, privacy, and terms links are managed once on the Branding & distribution page and project into the ChatGPT app automatically, trimmed only where OpenAI’s length limits are tighter. The ChatGPT app section itself now asks only for what’s unique to that channel: category and icons.
• Check your media kit before your next submission. If you’d previously entered a subtitle, description, or support, privacy, or terms URL directly in the ChatGPT app section, that value is not carried over automatically — add the equivalent fields on the Branding & distribution page. If your media kit is missing the subtitle or any of the three policy URLs, your next ChatGPT app submission will fail validation until you fill them in. If your media kit was already complete, there’s nothing to change.
• The dedicated hostname setting now sits next to Public hosting instead of living only under ChatGPT app setup, since it’s a storefront-level setting any future channel can reuse. The OpenAI verification steps were also reordered to match the sequence you complete them in.
• The ChatGPT app section adds a “Mark listing reviewed” step: review the projected name, subtitle, description, and links, then confirm them. Until you do, the submission bundle’s readiness checklist flags the listing as unapproved. Editing those fields again afterward clears the confirmation, so you’ll need to review and confirm once more. If your ChatGPT app previously had a subtitle, description, or policy URL that no longer matches your media kit, you’ll also see a prompt to update your media kit to match or confirm the current value is correct.
• Buyers see no difference: this changes where the listing content is managed, not what it says, as long as your media kit stays complete.
• Widgets now render inside ChatGPT: a compatibility adapter speaks ChatGPT’s native window.openai runtime alongside our existing MCP-Apps handshake, so a widget that used to time out and show “We couldn’t reach the chat host” in ChatGPT now loads and works normally. Tool results that share a widget with a companion action no longer disappear from ChatGPT’s tool list.
• Fixes AI-7637. A seller rail widget that opened while it was still loading — or while the chat had earlier scrollback — could land with most of its content below the fold, showing only empty space and a “Scroll to bottom” affordance. The view now follows the widget into place as its content settles, instead of leaving the scroll aligned to stale geometry.
• Fixed execute_campaign/create_media_buy incorrectly failing with “ESA create dispatch returned an invalid structured response” for media buys that are accepted but not yet fully active (e.g. still pending creative sync). The buy is now correctly recognized and returned as completed with its real lifecycle status.
• Claude Interchange connector widgets now load reliably. A configuration issue was causing widget content to fail with a domain mismatch error, showing “There was a problem displaying content from Interchange” in Claude. No action is needed.

​

5.329.0 — August 31, 2026 at 5:25 AM UTC

• In your Buyers directory, a new “Needs setup” count tells you at a glance how many buyers still need something from you — an account setup in progress, a pending review, or a billing hold. Click it to filter straight to them.
• Opening one of those buyers now shows everything left to resolve in one place: the request you sent the buyer (with the message, expiry, and a copy-link button), whether you’re ready to invoice them directly, and their account mapping — plus quick paths to map an existing account, start account setup, or decline. A buyer with only a pending review opens the same drawer as before.
• Nothing changes until your account is enrolled in the updated Buyers view; un-enrolled accounts keep the current page.
• Your Buyers directory now shows what’s happening with each buyer, not just what’s set up. Once a buyer is accepted and their accounts are mapped, their row leads with how many open proposals you have with them and what they’ve spent with you this month; buyers still mid-setup show nothing there yet.
• The totals above the table count open proposals and this month’s spend across every buyer on your storefront, whichever page you’re viewing, and the open-proposal count there always matches your demand inbox.
• Nothing changes until your account is enrolled in the updated Buyers view; until then, you keep the current page.
• Interchange Support can now run your Sales Agent validation when you have granted it Admin access. Support remains limited to the Agent and Source being tested and cannot use this workflow with Member access or after you revoke its membership. No action is required unless you want to grant, limit, or revoke that access.
• Server-to-server buyer integrations can now retry Google Ads audience syncs without automatically sending a duplicate write. Resend the identical sync_audiences request with the same idempotency_key within 24 hours; if the original request completed, the saved response is returned. Buyers using chat or the Interchange UI do not need to change their workflow, and integrations that do not retry continue as before.
• Server-to-server clients must inspect the ADCP error code and adcp_error.details.http_status before issuing another write; MCP transport success does not mean the tool call succeeded. AUDIENCE_IDEMPOTENCY_KEY_REUSE and AUDIENCE_IDEMPOTENCY_KEY_EXPIRED carry direct-adapter HTTP 409 when a key has different content or is outside the replay window. AUDIENCE_REQUEST_OUTCOME_UNCERTAIN can carry direct-adapter HTTP 503 on the original request or HTTP 409 on its retry; the earlier request may have reached Google, so reconcile that audience in Google Ads and do not automatically resubmit it. Use a new key only for a deliberately different write or after inspection shows another write is safe.
• Enterprise brands do not need to change audience strategy, governance, measurement, or partner instructions; route response handling to the team that owns server-to-server reliability. Large agencies and hold-co teams should add these outcomes to cross-account retry playbooks so operators do not blindly repeat an uncertain write. Hands-on power buyers who maintain server-to-server integrations should implement the status handling above; media operators using chat or the Interchange UI do not need to take action.
• This buyer-side change does not alter what buyers see about sellers, including how sellers rank, how inventory is presented, or Seller Account setup. Sellers have no action.
• If your integration reads Murph V2 insight responses, migrate taskSuccessRate to nonEscalationRate and resolvedWithoutEscalation to notEscalated. The older names remain available as deprecated compatibility aliases. These fields measure whether an interaction escalated; they do not prove task completion.
• When your agent calls the V2 REST API or /mcp/v3, it can optionally send an intent label with its run, workflow, skill, scenario, and step identifiers. Retrieve the skill first, then reuse those identifiers for its scenario steps. Interchange uses these identifiers to connect the retrieved skill version with observed API operations and server-backed completion evidence, so skill changes can be based on actual runs. Existing V2 REST and V3 MCP calls behave the same when this metadata is omitted. The metadata never changes authorization or certifies completion, and skill analysis does not store prompts, search text, retrieved instructions, or request payloads. Interchange correlates Seller Account workflows and Interchange-operated buyer workflows server-side. Only teams operating their own V2 REST or V3 MCP client need to add metadata; sellers and managed buyers have no setup change. This release does not change pricing, packaging, billing units, or plan availability.
• Learn how to correlate a skill run.
• Fixes AI-7637. The setup-nav checklist’s “Agents” row opened the Partner Program’s agent roster page, which doesn’t work for an ordinary storefront seller and always showed “Couldn’t load Agents.” It now opens the same sales-agent connectivity view the legacy rail already used. Also: a checklist row that can’t open its destination now shows a clear error instead of silently doing nothing.
• Fixed MCP connections (ChatGPT, Claude.ai, and other MCP hosts) disconnecting and asking you to reconnect well before their authorization was meant to expire. A connection no longer depends on the original sign-in browser session staying alive — signing out of Interchange elsewhere, or that browser session expiring, does not disconnect it. Connections now persist until your account loses access or is signed out everywhere for security reasons, instead of silently expiring.
• Updating a creative’s template_id via the API now correctly clears the stale auto-detected template and regenerates tracking URLs for the new template. Previously, template_id overrides were silently no-ops — the column updated but auto_detected_template in the response remained stale, leaving the creative with incorrect text slots and tracking.
• Fixed a persistent “There was a problem displaying content from Interchange” warning that appeared in Claude for all users connected via the Interchange or Interchange Staging connector. No action is needed — widgets now load correctly.
• Storefronts now use the AdCP SDK 14 compatibility layer while continuing to offer their existing AdCP 3.0 and 3.1 tools. Standard product, proposal, account, creative, and media-buy fields remain compatible.
• Buyers using chat or the standard fields do not need to change anything. Task completion and push notifications are more resilient to service interruptions, so an approval is less likely to remain visibly open after it was decided.
• Sellers do not need to reconfigure their Storefront. Integrations that read custom Storefront metadata should move from extensions.scope3.storefront to ext.scope3.storefront. Capability responses temporarily emit both paths for existing AdCP 3.0 and 3.1 buyers. Demo disclosures likewise move from top-level demo and demo_disclosure fields to ext.scope3.storefront.demo and ext.scope3.storefront.demo_disclosure.
• Push-enabled task completion and its encrypted webhook recovery record are now committed together. Once an approval settlement checkpoint exists, interrupted registry settlement resumes automatically. During an outbox-encryption-key rotation, operators can provide the previous key through ADCP_WEBHOOK_OUTBOX_ENCRYPTION_KEY_PREVIOUS until pending deliveries drain; ADCP_WEBHOOK_OUTBOX_FINGERPRINT_KEY must remain stable.
• During a mixed-version rollout, a legacy worker may have terminalized a push task without an atomic webhook checkpoint. Recovery now preserves that task’s settlement intent and any retained push configuration for operator remediation instead of silently acknowledging it or inventing a potentially duplicate notification.
• V3 campaign creative continues to use hosted or inline image assets; no buyer action is needed. This release does not add audio attachments or destination delivery.

​

5.328.0 — August 30, 2026 at 6:31 PM UTC

• If your storefront runs on a third-party (pass-through) sales agent, its account-setup handoff links are now validated and re-issued as Scope3 links instead of being forwarded from your upstream agent as-is — there’s nothing for you to configure. When your upstream agent’s sync_accounts response includes a setup handoff, Scope3 validates it and re-mints its own seller-scoped launch link, matching how a locally-managed storefront’s information requests already work.
• One thing you may newly see and need to act on: if your upstream agent returns an invalid setup handoff (a malformed or over-limit link or message), that account now shows up as a failed entry with an INVALID_UPSTREAM_SETUP code in your review queue, instead of being silently dropped or passed through. The fix for that is on your upstream agent’s side — the handoff it sent didn’t meet the validation bar.
• Buyers will see setup links for these storefronts arrive from Scope3 rather than your upstream agent, with no action needed on their end.
• Sellers can now record — and revoke — an explicit confirmation that a direct-billed buyer (operator or advertiser billing) is billable, separate from the decision to admit them. Going forward, accepting or linking one of these buyers no longer creates their account by itself: it stays pending approval until your finance system (CRM, ERP, a staff member, or an outside workflow) confirms they’re billable, at which point it activates immediately with no further action from you. Buyers you’d already activated keep their current status. Revoking that confirmation on an active buyer immediately blocks new direct-billed activity without touching buys already placed. Buyers billed through Interchange are unaffected. A new endpoint lets you recover a confirmation’s id for an account you already activated, in case you didn’t save it the first time.
• Eligible Seller Account administrators can opt into this relationship-gated alpha to record who may be billed for one exact advertiser relationship or an explicitly reviewed advertiser set. Existing billing, advertiser access, and proposal setup continue unchanged. Seller Accounts outside the alpha have nothing to do.
• A mandate marked ready is only a recorded prerequisite for a later workflow. It does not complete billing, authorize a proposal, Campaign, execution, or spend, or prove that a funded or invoice rail exists. This API cannot move money, charge a payment method, issue an invoice, fund media, pay a seller, or write a ledger entry. It has no structured credential fields. Recognizable card, bank-account, wallet, and provider-credential literals are rejected and must never be placed in its free-text reason fields; semantically unknowable bare identifiers are not treated as credentials. It never returns structured payment details or Organization payment methods.
• There is no new plan, price, billable unit, or automatic charge in this slice; it is a relationship-gated alpha only. Seller-direct invoicing and Interchange-cleared billing remain separate, and changing or revoking a mandate preserves its commercial and audit history.
• During the alpha, the Storefront/payments product owner will review these named signals at 30, 60, and 90 days: first mandate created per eligible Seller Account; readiness-state distribution and created-to-ready conversion; authorization or redaction failure rate; and zero downstream spend or payment-rail use attributable to this slice. Sources are immutable mandate and readiness events, audit records, authorization/redaction telemetry, and the absence of downstream rail claims. The product owner must approve success thresholds before the alpha audience or maturity widens.
• If a widget-launching tool (like Open Connections Page) didn’t render in ChatGPT, it now does. Nothing to change on your side.
• Fixes AI-7579. A cold navigation into the Campaigns workspace scoped to an advertiser with a purely numeric id (e.g. from the setup-nav rail’s per-advertiser row) could land unscoped — “Select an advertiser above.” — even though the advertiser genuinely existed. The URL’s advertiser id was being silently dropped during page load whenever it looked like a number; it’s now correctly preserved regardless of whether the id happens to be numeric or alphanumeric.
• Organization members can now open the Advertisers page to see which advertisers their organization owns or is allowed to work with, who operates each advertiser, and whether it is ready. Authorized admins can change eligible advertisers between managed and self-service operation, revoke eligible self-service access, or open Campaigns from a row. Reusable join links and invitation actions do not appear on this page; targeted invitations are planned separately. No setup or migration is required, and existing direct API and MCP calls continue to work.
• Sellers using this page see only buyer-facing advertiser relationships they already have permission to view. This change does not grant access to seller or buyer accounts, members, billing, or unrelated advertisers.
• Return a content-safe bootstrap stage when deterministic Sales Agent validation cannot start, while retaining the underlying failure as server-side telemetry.
• In Test & certify and Source diagnostics, you can now run the current 1.4 validation skill for a third-party Sales Agent from the Media Company account without a separate Buyer Account. Existing calls that select a Buyer Account continue using it. When a Source uses No auth, Murph moves on to diagnostics instead of reopening the credential form, and a zero-call window remains untested rather than failed. The validation keeps its internal MCP session on one API replica so it also completes in the deployed multi-replica environment.

​

5.327.0 — August 30, 2026 at 2:34 PM UTC

• Fixed the Campaigns workspace so clicking an advertiser in the setup rail lands you scoped to that advertiser, instead of the unscoped account view.
• The Branding & distribution page has a refreshed look, rebuilt on the Scope3 design system — clearer typography, status chips, and section cards, with better dark-mode contrast on loading and error states. Every control works exactly as before: nothing moved, no permissions changed, and no action is needed.
• Section headers in the setup rail now reveal a filter and, where relevant, an add button when you hover or focus them. Use the filter to narrow a section’s rows by name, or the add button to jump straight to adding an advertiser or inventory source — without opening a separate page.

​

5.326.0 — August 30, 2026 at 1:01 PM UTC

• In the V3 MCP creative tools, buyers can now attach hosted or inline image, video, audio, HTML, VAST XML, or text assets and a click-through destination when they create a campaign creative, then read that creative to see its ad-platform sync status and ID. Existing metadata-only calls are unchanged, and ZIP bundles still use the inspected HTML5 upload flow. No setup change is required.

​

5.325.0 — August 30, 2026 at 12:13 PM UTC

• V3 error messages now speak the V3 vocabulary and include the machine-readable code; internal routing details no longer appear in customer-facing errors.
• Murph and other connected assistants can now choose the current instructions that fit your account before they start a supported workflow. Buyers receive buying and campaign guidance; sellers with owned inventory can ask to test a Sales Agent in the advertiser sandbox. Existing integrations continue to work without changes, and there is nothing to configure.

​

5.324.0 — August 30, 2026 at 11:01 AM UTC

• Widgets now render in ChatGPT: tools that open a page advertise their widget template to the ChatGPT host.
• create_media_buy for Amazon Ads now rejects Sponsored Products Auto, both Sponsored Brands variants, both Sponsored Display variants, and all three Amazon DSP variants with a clear UNSUPPORTED_PRODUCT_CONTRACT error before any provider mutation. Amazon Sponsored Products Manual remains the only Amazon product family Interchange creates campaigns for; get_products and the published Amazon Ads compatibility page no longer list the other eight families as available or in testing.
• The Storefront and Discovery & distribution tabs in Settings are gone. Your brand domain, media kit, and distribution controls (visibility, publishing, and OpenAI Apps verification) now live together on the Branding & distribution page instead of split across three surfaces. An old link to either retired tab now opens Branding & distribution directly.
• The rest of what those tabs covered has its own home: approval modes for creative review and media-buy approval live in the Business rules widget, and pause/resume for your storefront’s transacting state lives in Settings → Danger zone (see below).
• Your ChatGPT app setup — listing, custom hostname, verification, and submission bundle — moved there too, grouped with the rest of distribution. Ask Murph to open the page and walk you through any step.
• Permissions are unchanged by the move: anyone on your account can view the Branding & distribution page, and every change on it — brand domain, media kit edits, distribution visibility and publishing, and the ChatGPT app setup above — still requires an account administrator, exactly as the retired tabs did. Non-administrators see the page read-only with the controls disabled.
• Pause/resume for your storefront’s transacting state moved to the Danger zone settings tab, next to Archive. Nothing else about how these controls work has changed.

​

5.323.0 — August 30, 2026 at 8:47 AM UTC

• Sales Agent owners can run brief-only validation when advertiser-specific Seller activation is enforced. The versioned workflow now turns the exact Seller on only for its temporary sandbox Advertiser through the public API, verifies the returned activation state, then restores the advertiser preference to Inherit before archival after a success, failure, or cancellation. Cleanup closes the run’s activation lifecycle so a delayed earlier write cannot re-enable the archived sandbox Advertiser. The Agent Page now negotiates the new workflow through a fresh resource identity; cached prior Pages remain read-compatible and cannot launch a mismatched validation version. No setup change is required.

​

5.322.0 — August 30, 2026 at 5:39 AM UTC

• Object searches (search with a kind, e.g. kind: "seller") no longer carry a docs-unavailability directive in their answer text when the documentation index is not loaded. That status is now reported only when documentation was actually requested — an explicit docs/specs source or a document lookup — and it is phrased as a status fact rather than an instruction to the model.
• Buyers: Available inventory no longer briefly disappears from product discovery when a seller’s catalog and connection updates arrive close together. No setup or workflow change is required.
• Sellers: When an inventory source stays unhealthy, its “Restore the connection” task remains open and updates with the latest instructions instead of disappearing or being duplicated. Continue working from that task. If Scope3 takes over the repair, your seller task closes before our internal repair begins.
• search and get on the v3 API now render seller, connection, and advertiser results directly into the response text, not just the structured payload. Hosts that only surface a tool’s text response (rather than its structured data) now see the same sellers, connections, and advertiser fields as hosts that read structured data.

​

5.321.0 — August 30, 2026 at 1:14 AM UTC

• Organization administrators enrolled in the limited beta can now invite another Organization to accept access to specific advertisers through the v2 API or Murph. Use this when an agency or partner needs to work with a fixed advertiser set while the advertiser owner stays in control.
• API-building teams get the same bounded contract through the REST grant endpoints plus the V3 advertiser_grant read noun and save_advertiser_grant lifecycle tool, so integrations can list, inspect, accept, reject, and revoke grants without account-level owner visibility.
• Each grant names the exact advertiser IDs and capabilities, and it must be accepted by an administrator in the invited Organization before access is active. There is no pricing or plan change in this beta; Scope3 must enroll both Organizations before the grant flow or delegated roster entries are available.
• Delegated access stays narrow. Scope3 rechecks the active accepted grant for the exact advertiser and capability each time it is used. The grantee sees only the named advertisers in its roster and does not receive owner account IDs, members, billing data, unrelated or future advertisers, or private configuration. Existing Campaign APIs remain account-scoped, and the advertiser owner keeps ownership and Campaign IDs.
• Measure the beta by first accepted active grant per enrolled Organization, active grants, delegated advertiser roster reads, lifecycle actions, denied cross-organization probes, and stale, expired, or revoked execution denials.
• Nothing changes for Organizations that are not enrolled in the beta, and existing access stays unchanged unless both Organizations’ administrators complete the grant flow. Seller persona check: seller workflows and Seller Account access are not affected. Manage organization advertiser grants.
• Fixed the Advertisers section in the setup rail so it always lists the same advertisers your Campaigns workspace shows. Some sellers were seeing no rows there even though Campaigns listed at least one advertiser.

​

5.320.0 — August 29, 2026 at 10:43 PM UTC

• A video you already uploaded to Interchange can now become a creative in one call, instead of hand-assembling one around the hosted URL. Call POST /api/v2/buyer/creatives/adopt-managed-video-source over REST, or run adopt_managed_video_source through buyer_api_call over MCP. Name a source that finished inspection and you get a creative manifest back, optionally attached to a campaign in the same call. Attaching also pushes the campaign’s live media buys to their sellers in the background; a success means the creative is attached, not that every seller has already accepted it.
• Nothing you have already built changes. Hand-built creatives around a hosted video URL keep working, and there is no migration to make.
• You name the source, never a URL. The hosted HTTPS URL on the creative is issued server-side, resolves the exact file that passed inspection, and stays valid while the source is retained and its delivery has not been revoked.
• Adoption is safe to call again. The same source under the same name returns the creative that already exists rather than a duplicate, created tells you which call made it, and a managed video source backs only one live creative even when two callers adopt it at once. An adopted creative reserves its advertiser-scoped name for its lifetime; attaching it to a campaign does not release that name. Give a new source an unused one — adoption refuses rather than reusing another creative. Refusals say what to do next; “Bring your own creative” in the buyer docs has the full set, including the retention, revocation, and deletion cases and exactly how a name is freed.
• Adoption produces a creative, not a delivery. Sync it to a media buy like any other creative: the destination’s format checks still run at sync, and adoption never produces a VAST tag. Audio sources are not supported yet. Adoption shares direct video upload’s alpha gate — if that is on for your account, this is too, with no separate opt-in.

​

5.319.0 — August 29, 2026 at 10:23 PM UTC

• The Advertisers section in the setup rail now lists each of your advertisers as its own row, the same way Inventory sources lists each source. Click an advertiser to open it directly in Campaigns, instead of landing on the unscoped workspace every time.

​

5.318.0 — August 29, 2026 at 7:23 PM UTC

• Sellers can now ask a buyer for information or an outside action — a credit application, a signed contract, a portal login — right from the account-setup review queue, instead of choosing only accept or reject. The buyer’s agent gets a message and a secure link back into the seller’s own process; the account stays pending until the seller confirms the material has arrived.
• Clicking an inventory source in the seller rail opens its source view again. Source clicks were failing with “This view didn’t load” because the app requested the source detail tools from an endpoint that doesn’t serve them; they now go through the MCP tool bridge that does.
• The V3 search tool’s filter.sandbox description now correctly states that false retrieves the live own-supply advertiser roster when amc-campaign-management is enabled, not true only. Agents reading only the published schema can now discover the supported live path.

​

5.317.0 — August 29, 2026 at 6:13 PM UTC

• Meta directed-campaign media buys that return active Advantage+ audience (targeting_automation.advantage_audience) now refresh correctly instead of failing as unsupported. The Meta adapter retains validated automation controls in provider readback evidence without projecting them to canonical targeting or granting write authorization; the shared directed-campaign response continues to omit raw provider controls.
• Sellers can now fix a missing or ambiguous account mapping without leaving the Buyers directory. Open “Map accounts” on the flagged relationship to pick from suggested matches or search the full account roster for that source — selecting one records the mapping immediately. Mapping accounts through the API or your existing process works as before. This is enabled per account; until yours is enrolled, the page you see today is unchanged.

​

5.316.1 — August 29, 2026 at 4:17 PM UTC

• Hosted product discovery that previously failed now works correctly, so affected products can be discovered normally. No buyer action is needed.

​

5.316.0 — August 29, 2026 at 1:26 PM UTC

• What changed
• Buyer REST now shows whether a selected Amazon Sponsored Ads profile has the marketplace and payment information needed for Amazon Sponsored Products Manual. Manual create is available only to explicitly enrolled internal test buyers through the customer flag. Turning access off blocks new creates but keeps readiness, existing receipts, reads, update/cancel, retained containment, cleanup, and internal test attestation available.
• Existing automatic Sponsored Products update and cancel requests are not governed by the Manual create flag. If Amazon may have accepted one of those mutations but bounded readback cannot confirm it, Buyer REST now retains and replays the terminal no-retry receipt for the same request key instead of sending another provider mutation.
• Audience guidance

• ​

  Hands-on buyer

• Surface: Buyer REST account readiness and manual create results.
• Trigger: You select an Amazon Sponsored Ads profile or submit a Manual create using one stored Amazon product family.
• Effect: Read marketplaceId and validPaymentMethod before create. A Manual selection carries its ASIN in targetingOverlay.product_codes and its per-request terms in targetingOverlay.keyword_targets. A partial or uncertain result says not to retry and provides the available campaign or account identity for reconciliation.
• Boundary: Only explicitly enrolled internal test buyers can create. Readiness does not grant catalog, ASIN, or broader Amazon eligibility.

• ​

  Agency or enterprise team

• Surface: Shared account-readiness fields, terminal receipts, and campaign cleanup status.
• Trigger: A create stops after Amazon may have created or changed a campaign.
• Effect: The result preserves the authorized account and any known campaign identity so the team can reconcile one provider resource without a blind retry.
• Boundary: This is not external availability. Pilot, eligible-buyer, and GA remain held until every customer cleanup record is acknowledged on time and Account Hygiene has an assigned owner.

• ​

  Small-business or chat user

• Surface: Your existing buying workflow.
• Trigger: Your organization has not been explicitly enrolled in the internal canary.
• Effect: Nothing changes; new Amazon Sponsored Products Manual creates remain unavailable.
• Boundary: Do not infer access from readiness fields or a future date.

• ​

  Seller or cleanup operator

• Surface: Full-buy cancel and get_campaign status for a known campaign.
• Trigger: A partial create or activation-uncertain result says cleanup is required.
• Effect: Cancel the whole media buy with its exact stored account and campaign. A confirmed cancel becomes CANCELED; provider-confirmed containment can remain PAUSED. A cancel-uncertain result is terminal and is not retried automatically.
• Boundary: If no campaign identity was returned, reconcile the authorized account through the seller/operator or support path instead of guessing.

• ​

  Prospect

• Surface: Sales and release communication.
• Trigger: You ask whether the feature is generally available or changes your Scope3 commercial terms.
• Effect: The answer is internal canary only, with no incremental Scope3 charge, plan, or entitlement.
• Boundary: No pilot, eligible-buyer, GA, all-market, or on-date availability promise is authorized.
• Terminal result guidance
• scope3_partial_creation: Amazon created the campaign but required setup or activation did not complete. failure_stage names the failed step, cleanup_required is true, and retry_safe is false. Do not retry the create. For a known campaign, request a full-buy cancel with mediaBuys: [{ mediaBuyId, action: "cancel" }] and no packageIds.
• scope3_create_uncertain: Amazon may have accepted the create, but no trusted campaign identity was returned. cleanup_required is true and retry_safe is false. Do not retry or invent a campaign identity; reconcile the exact authorized account through the seller/operator or support path.
• scope3_mutation_uncertain with operation: create_activation: the campaign identity is known, but its enabled state is not. cleanup_required is true and retry_safe is false. Do not retry the create; use the same full-buy cancel path. The exact account/campaign check still applies when create access is off.
• Every Amazon create request must resolve all packages to one authoritative stored Amazon base product family. Mixed Amazon families are rejected before any provider write.
• Named durable measurements and owners
• These are implemented database signals, not proposed analytics events:
• Eligible adoption — amazon_sp_manual_create_audit.outcome = 'SUCCEEDED': bokelley owns the widening decision. Conditional targets are 1, 3, and 5 distinct successful eligible buyers at 30, 60, and 90 days after a future eligible_start, which can be no earlier than September 22, 2026.
• Usage — amazon_sp_manual_create_audit.outcome = 'DISPATCHED' and its terminal outcomes: Supply Integrations (nbanerjee) owns internal-canary dispatch and terminal-result review from rollout_start.
• Duplicate safety — outcome = 'DUPLICATE_BLOCKED' plus the executable semantic-request provider-dispatch query: acceptance is zero requests with more than one actual provider dispatch.
• Terminalization safety — outcome = 'DISPATCHED' older than 15 minutes and the explicit terminal outcomes: acceptance is zero overdue unterminalized dispatches and 100% terminalization of partial or uncertain outcomes.
• Cleanup safety — amazon_sp_manual_cleanup_sla joined to amazon_sp_manual_cleanup_attestation_audit: Supply Integrations (nbanerjee) owns 100% acknowledgement of internal test cleanup within one Monday-Friday UTC business day.
• Any customer cleanup_required audit row blocks pilot, eligible-buyer, and GA widening until a later implementation durably links acknowledgement and the one-business-day SLA to that cleanup record. Bokelley owns that widening hold and owns filling the vacant buyer-account-hygiene route. Routine customer notifications also remain held.
• Existing customers have nothing to change while this limited beta remains dark by default. Named pilot organizations coordinate with Scope3 to receive the entitlement and capacity; Seller self-service must already be enabled for the selected Storefront before an organization can send an invitation.
• In this administrator- and API-facing first slice, organization administrators can use the organization advertiser roster API to create a managed advertiser or a single-use self-service invitation. Managed advertisers are created and administered by an organization administrator. A self-serve advertiser is a confined invited Buyer backed by the selected Seller Storefront and its sponsorship. The roster response reports which mode applies and the lifecycle state.
• Sellers do not operate the organization roster directly. Invitations remain confined to an organization-owned Seller Storefront and behind its existing self-service control. Revocation invalidates an unused invitation or ends the exact sponsorship and access relationship created from it, without exposing or changing unrelated Seller data and without deleting the advertiser, Campaigns, billing history, or lifecycle record. Reading the roster remains available without beta access. A simpler UI and signup path will follow in later work; this slice does not add either surface.
• Your storefront’s Discovery Card is now Branding & distribution, and it does more from the same page: save your operator domain, see exactly why it’s pending verification instead of an unexplained “verify” prompt, and manage Discovery visibility, publishing, and your OpenAI Apps verification token — all without leaving the page. What buyers see doesn’t change until you publish. After you publish, buyers and their agents see the updated Discovery Card — your refreshed identity, description, and channels — wherever storefront discovery surfaces render it. Nothing to change on your side: the same controls in Account Settings still work today.
• Discovery & distribution Settings now clears a previous challenge or bundle error after a successful retry. Switching accounts or leaving Settings during an in-progress action no longer allows that action to refresh another account’s status.
• Meta Video Feed, Stories, and Reels now appear as Testing and are withheld from standard buyer sync and assignment. These formats previously appeared available, but their creative path could not reliably complete a Meta ad. Buyers using currently available Meta formats need no action. The video-only ThruPlay product is now also withheld from standard buyer discovery because all its creative formats are Testing.
• The current Testing path requires a JPEG or PNG thumbnail that matches the video’s aspect ratio and is at least 1080 pixels wide. The thumbnail may use a scope3-asset:// reference; the video must use a hosted HTTPS URL. Automatic thumbnail selection is not available through standard buyer workflows.
• For tested assignments, ext.manual_action_count: 0 appears only after Interchange confirms the paused ad and its creative, account, campaign, and package in Meta. If Meta rejects the ad, the package remains in assigned_to, the response omits ext, and assignment_errors contains a sanitized Meta review reason. Thumbnail lookup and upload failures return fixed guidance without including raw Meta error messages, codes, or trace IDs.
• Assignment now also refuses a creative whose format cannot serve on the placements its target package explicitly targets, such as a Reels creative on a feed-only package. Meta would accept that ad and then never serve it as a Reel. A package that leaves placement automatic is exempt only where the format can serve on the platforms that package runs on; automatic placement on a platform the format declares no placement for, such as an Audience Network-only package, is still refused.
• Promoted Offerings no longer appears in the Meta creative format catalog. No Meta product offered it as a selectable creative format, so it could be discovered but never attached to a buy. Per-offering packages on create_media_buy are unchanged.
• Seller workflows and per-offering package creation are unchanged.
• Storefront connections that cannot activate yet now show as deferred instead of appearing failed or retrying indefinitely. Buyers do not need to take any new action for this fix: the status now more accurately reflects that the connection is waiting for the platform to finish activation safely.
• Turning a seller’s data-sharing permission off now asks for confirmation, and the dialog states exactly what happens: disabling audiences-and-catalogs or conversion events turns off every advertiser’s existing registrations of that data class under the seller, and re-enabling the permission does not restore them — each advertiser must re-register. Previously only enabling required confirmation, so the destructive direction was one accidental click.
• Ad-server and sales-agent account rosters larger than 1,000 accounts now mirror into your storefront. Previously a roster that size was read, then thrown away in full, so the source mirrored zero accounts on every attempt and no advertiser could be mapped to a buyer relationship through it. Scope3 now follows pagination to the source’s terminal page without imposing an account-count ceiling. Each bounded page is durably staged outside the visible mirror, then the complete snapshot is published atomically without holding the full roster in worker memory.
• An attempt that still stops short now says whose limit stopped it, so a Scope3 time budget is never reported as your ad server’s fault: ROSTER_DRAIN_TIMED_OUT is ours and INCOMPLETE_LISTING is the source’s. Scheduled refreshes get a longer reading budget than one you trigger by hand. That budget is propagated to the ESA HTTP client, so the first FreeWheel page can finish its complete upstream cache refresh instead of hitting the generic 15-second GET timeout.
• Buyer account creation now honors the existing access decision at submission time, including when signup began from a stale page or an alternate first-administrator path. Named organization invitations continue to apply only to their admitted organization, while Seller Account signup remains unchanged.
• The signup account-type step now keeps its helper text and continue button aligned with the account options shown, so Buyer-only claim flows no longer point users to Storefront setup.
• Your outgoing RFP responses now follow the buyer-requested supported language automatically. English and Dutch responses use localized proposal copy, prices, allocations, and concrete next steps; Dutch platform narrative is deterministic, while authorized source excerpts remain verbatim. Other valid locales fall back truthfully to English. No setup changes are required.
• OpenAI submission packages now carry a complete post-submission workflow. App publishers can record the exact reviewed snapshot, keep the reviewer setup stable during review, respond to a rejection without hand-editing generated files, publish an approved version explicitly, and verify and monitor the first 24 hours of an Interchange or white-label launch.
• No action is required for existing accounts: current defaults, registrations, and Discovery visibility are unchanged. V3 get_status responses are now locale-sensitive for every account: when an MCP client supplies a supported locale, account and status labels are localized while each setup blocker and action retains its specific guidance. Clients using the default locale continue to receive English guidance.
• Buyer administrators who opt in can open ChatGPT app Settings and download one ZIP with every portal field, prompt, locale review, release note, screenshot, and video requirement mapped in one place. Builders can use the same checklist for a first ChatGPT app, while enterprise teams can use it for reviewer-account and evidence sign-off. Before submitting, resolve any reported logo blockers and complete the remaining manual review items.
• Seller administrators who opt in can use Discovery & distribution Settings to inspect hostname verification, publish an OpenAI challenge token, and check the token served at the public challenge URL. A custom CNAME that is pending or failed continues to block public publication: update DNS to the target shown in Settings and return there after verification becomes active. Platform-managed hosting requires no CNAME action. The versioned publication skill remains available in Murph or another compatible agent, and none of these actions changes buyer discovery or adds marketplace exposure.
• For sellers working in Murph chat, a misplaced inventory-source scope is now repaired before a V3 search runs when that object supports source scoping.
• For V3 tool users, Agent search now distinguishes organization software from sellers. Managed-source signal writes name their complete replacement fields. Business Rules policy errors direct non-admins to an account administrator.
• Buyer admins can now set each advertiser’s Seller preference to Inherit, On, or Off. Inherit follows account selection and automatic market/channel matching; On and Off affect only that advertiser. Seller eligibility and account-wide Always include or Always exclude settings remain authoritative. Seller authorizations and account-wide billing and data-sharing settings are unchanged. No action is required unless you want to change an advertiser’s preference.
• In chat, a request such as “turn Meta on for Acme” now changes only Acme’s Seller preference. Use the all-advertisers Sellers view when you intend to change the whole buyer account.
• SMB/novice buyer: not a direct target for this buyer-admin control in the initial rollout. Murph and the Sellers widget apply the advertiser-scoped choice on the buyer’s behalf; no API knowledge or additional setup is needed.
• Measurement: during staging and the first 30 days of production cohorts, review the durable Updated advertiser seller activation preference audit event for distinct-buyer adoption and the Inherit/On/Off mix. Expansion requires successful preference readback with no cross-advertiser changes, plus no sustained increase in activation-controller failures or denied seller work.
• Seller impact: a buyer can now start or stop using a Seller for one advertiser without changing the Seller for the rest of the buyer account. This does not change the Seller’s storefront, protocol, setup, or required actions.
• Monetization: none. This adds no billable surface, pricing, packaging, or commercial differentiation.
• When a confirmation on the Sellers page fails — removing a seller authorization, changing availability, approving direct billing, or enabling data sharing — the failure message now appears inside the confirmation dialog itself. Previously it rendered behind the dialog, so the action appeared to silently stall. And when a host embeds the Sellers page inline — in a chat card rather than a full working canvas — a seller’s details now open as a full-width sheet sized to the card instead of a partial-width drawer over a sliver of the list.
• In embedded hosts that don’t declare a display mode, opening a seller’s details on the Sellers page now shows the full-width detail sheet instead of a partial-width side panel over a sliver of the list. The side-panel layout is reserved for hosts that explicitly provide a full working canvas.
• “Not open for buying” on the Sellers page now says why. The seller and connection APIs carry a modelled marketplaceUnavailableReason — seller_opted_out, pending_review, not_published, or cannot_transact — derived from real listing facts, and the Sellers page renders the matching explanation beside the status (“The seller opted out of marketplace buying”, “Under marketplace review”, “The seller hasn’t published this storefront”, “The seller can’t take buys yet”). Cards for not-yet-buyable market makers now carry that meaningful status instead of an unexplained dead end.
• Creative asset refusals that point at Scope3-internal private storage now read the same whether the value was a managed handle, an object URI, or an HTTPS URL for a private bucket, so a refusal can no longer be used to test whether a guessed bucket name is one of ours. The message names the refused creative and the remedy; it no longer reports which class of storage was detected, the URL scheme, or which slot of the creative held it.
• Refusals that disclose nothing by being specific stay specific. An unsupported URL scheme still names the scheme — you typed it, and the accepted set is published — and now points you at an https:// URL rather than suggesting an inline data: URI, which is not something a buyer can submit. A payload nested past the inspection depth still says so.
• If you cannot tell which asset in a multi-asset creative was refused, contact support: Scope3 retains the exact slot and the specific reason server-side.

​

5.315.0 — August 29, 2026 at 12:29 AM UTC

• When you create a campaign through a connected Meta account, you can now optimize Instant Form lead ads for people likely to become qualified leads — the goal Meta Ads Manager calls “Maximize number of conversion leads.” Select an authorized Facebook Page and one of its active Instant Forms, and you’ll see Meta’s conversion-lead results in delivery reporting. Existing campaigns and other lead products are unchanged. Connecting CRM feedback through Meta’s Conversions API can improve optimization, but it isn’t required to create the campaign.
• Buyers can now link provider accounts to advertisers, configure object-storage reporting buckets, and preview brand domains — all through save_advertiser without separate API calls. Use assignAccount to link a provider account, unassignAccount to remove a link, and updateReportingBucket to set or clear the object-storage bucket on a linked account. Use resolveBrand to preview what domain a brand resolves to before committing — no advertiser is created. Existing save_advertiser calls are unaffected; these are additive fields. Retrieve linked accounts inline via get(kind:"advertiser", include:["accounts"]).
• MANAGED buyers can now call sync_buyer_storefront_accounts and list_buyer_storefront_accounts as MCP tools on /mcp/v2/buyer, wrapping the sandbox REST endpoints AI-6263 shipped. sync_buyer_storefront_accounts declares one or more sandbox account linkages with a MANAGED storefront (every entry must carry sandbox: true and billing: 'agent'); list_buyer_storefront_accounts returns the caller’s grants on one storefront, with optional status / sandbox / cursor / maxResults filters. Both tools coerce string-form integer identifiers so clients that encode IDs as strings pass validation.
• These are Interchange-mediated tools, not vanilla AdCP: the tool wire shape carries a target.storefrontId (sync) or storefrontId (list) selector so a buyer can name which MANAGED storefront to route the request to. Vanilla AdCP sync_accounts / list_accounts address one storefront through the URL and take a different request shape — a buyer that wants raw AdCP semantics still calls the storefront directly. The tool names reflect this by naming the substrate explicitly.
• Production traffic (operator-identity gate, other billing modes, BusinessEntity payload) and buyer-side idempotency semantics ship in follow-up slices on the same tool names.
• Sellers see no protocol or UI change. MCP-issued grants land in the exact same seller-side linking-service tables as REST-issued grants — this is a transport addition on the buyer edge, not a new substrate.
• Monetization: no billable surface, no packaging change, no differentiation. Sandbox account linkage is free at both the REST and MCP surfaces.
• Rollout — gate: none, atomic launch. MCP tools inherit the REST route’s eligibility (MANAGED-only, external/archived/paused rejected) and sandbox-only fencing. Kill switch is apps/api/src/tools/v2-buyer/registry.ts (unregister the two tools if we need to disable). Adoption watch: the standard v2 REST metric labels apply verbatim — every MCP call resolves to an internal REST call.
• Buyers can request proposals from every seller currently eligible for them in one confirmed request_proposals action. Media teams and agencies get a broader proposal set without assembling a seller list or splitting the marketplace into separate rounds. Murph handles the request, polling, and result pages automatically, so chat buyers have nothing new to configure.
• Integrations that call request_proposals must poll with the same idempotency key while status is running, then follow every page.nextCursor after the execution becomes terminal. Remove the deprecated sellerIds field. Calls that still include it remain valid, but its values no longer narrow the seller cohort. A fresh idempotency key still starts an intentional new round.
• Eligible sellers can now receive proposal requests from buyers who would not previously have selected them. This gives each eligible seller’s offer a chance to be reviewed across the marketplace. Sellers do not need to change their setup or response format; existing readiness checks still determine whether they are contacted.
• If Storefront readiness reports missing validation for a Source, run the public validation skill from the Agent or Source diagnostics page, or contact the Agent owner; otherwise, you do not need to act. Successful media-buy validation for the Source’s current Sales Agent version now covers other Sources that use the same version. Each Source still keeps its own credentials, account access, connection health, quarantine, and onboarding status; an older Source-specific exception is never copied to another Source. Sources that are already active keep their completed onboarding state. Buyer-visible certification, catalog listings, and purchasing behavior do not change.
• Creative sync, media-buy execution, and media-buy updates now refuse a creative whose asset URL points at Scope3-internal private storage instead of forwarding it to a sales agent, returning an actionable 422 that names the offending asset.
• Add a fail-closed private-storage boundary to the creative delivery projection.
• buildAdaptedPayload/buildSingleAssetPayload is where a stored creative manifest asset becomes an outbound AdCP asset for sync_creatives, media-buy execution, and creative preview. It now classifies each asset URL and refuses to forward one that addresses private platform storage, raising a 4xx NonDeliverableAssetUrlError that carries only the asset id, the reason, and the URL scheme — never the URL itself. Media-buy execution re-throws that specific refusal rather than falling back to the frozen creative payload, which never passed the boundary.
• Non-http(s) values cannot reach a manifest row today — every buyer-facing asset URL field validates through SafeUrlSchema — but an HTTPS URL pointing at a private bucket can, so the adapted-payload cache key version is bumped to invalidate any pre-boundary entry rather than serve it unchecked for its remaining TTL. Values that are not absolute URLs at all, such as the JSON config a WEBHOOK asset row stores, are explicitly still deliverable. This is the independent output check that keeps the invariant from depending on future writers reusing that one input schema, and it is a prerequisite for adopting managed media sources into buyer creative manifests.
• create_media_buy and update_media_buy now report a failed media buy with the error code that matches why it failed, instead of defaulting to SERVICE_UNAVAILABLE.
• Previously, when every inventory source refused a media buy, the response said SERVICE_UNAVAILABLE with recovery: transient and the suggestion “retry once upstream issues clear” — even when the source had deterministically rejected the request as invalid. An agent reading recovery or suggestion as its next action would retry a request that could never succeed, and the wording pointed at the seller’s ad server for a fault that was not theirs.
• The response now carries an honest code and a suggestion that names what to change:
• Every source refused the request as invalid → INVALID_REQUEST (recovery: correctable), with a suggestion to correct the request.
• Every source deliberately declined the buy (an explicit rejection or a governance denial) → POLICY_VIOLATION.
• No source authorized the buy → ACCESS_DENIED (recovery: correctable), noting the seller holds the source credentials.
• The buy is awaiting reconciliation of an outstanding upstream order → INVALID_STATE.
• Every source was genuinely unreachable → SERVICE_UNAVAILABLE and the retry suggestion, unchanged.
• When a source refuses without saying why, the code stays SERVICE_UNAVAILABLE — we cannot tell an unannounced outage from a decision — but the suggestion no longer tells you to wait for upstream issues to clear, because nothing about the request will change on its own.
• A creative problem reported by one source no longer makes the whole response look like a bad request when another source failed for a reason a retry could clear; the diagnosis still leads, and the suggestion says both.
• update_media_buy also now classifies failures a source returns (the ordinary AdCP status: "failed" response), not only failures that throw — so a deterministic update rejection reaches the buyer as one. When sources fail for a mix of transient and terminal reasons, the suggestion says so explicitly rather than implying a plain retry will clear it. details.per_source and details.reason are unchanged.
• Media buys against a Scope3-hosted storefront whose source product declared trusted_match.identity_match: true were rejected before ever leaving the platform: the storefront-forward pipeline stamped targeting_overlay.axe_include_segment as a single-element array ([outbound_package_id]), but the AdCP CreateMediaBuyRequest / UpdateMediaBuyRequest schema declares that field as a bare string. The bundled @adcp/sdk client-side validator threw Invalid input: expected string, received array at SingleAgentClient.validateRequest, the storefront wrapped the throw as source_unavailable, and the buyer saw SERVICE_UNAVAILABLE / recovery: transient with the guidance to “retry once upstream issues clear” — none of which was true. Every identity-match campaign against an identity-match-enabled storefront failed with this shape. Fix: stamp axe_include_segment as the bare string the AdCP contract specifies, matching the buyer-leg shape in campaign.service.ts and our own TargetingOverlay type declaration.
• The Approvals page in the Interchange app again loads the creative reviews and media-buy approvals waiting on you, and its approve, reject, and reassign actions work. Until now that page could show “You’re all caught up” — and approver settings as unavailable — while Pending operations listed the same reviews as waiting, because the page could not reach the approval queue and rendered that failure as an empty queue. It now says the queue could not be loaded when that happens. Nothing to change on your side: open Approvals, or click Review on a pending creative, and the item is there. Approvals opened from Claude or another MCP host were not affected.
• get(kind: "media_buy") now surfaces why-fields (pending reason, error code, forwarded timestamp, buyer reference) in both the structured and text response. Any include values passed to the media_buy kind now return unavailableIncludes with guidance to use the parent campaign instead of being silently dropped.
• get(kind: "campaign") no longer shows a raw null for advertiserId on campaigns accessible to all advertisers — it now shows a human-readable label.
• Snap get_products country-inventory failures now return fixed buyer-safe messages and a Scope3-generated UUID correlation_id that support can match to logs. Empty inventory or an in-band inventory failure remains retryable; a malformed HTTP-200 inventory payload is identified as an INVALID_PROVIDER_RESPONSE and tells buyers to contact support instead of repeatedly retrying. Snap discovery permission failures now name Snap and tell buyers to reconnect OAuth access or resolve business-review or account restrictions. Provider-authored messages and correlation values remain suppressed.
• TikTok Traffic (tiktok_traffic) and App Install Clicks (tiktok_app_install_clicks) now offer optional maximum-CPC bidding. Omit packages[].bid_price to keep automatic bidding, or provide a positive value to set a maximum CPC. On creation or update, Interchange validates a supplied bid before changing anything in TikTok, then reads the ad group back and reports success only when the bidding mode and cap match the request.
• Before supplying a maximum CPC, rediscover either product with get_products; a selection saved from an earlier discovery response does not advertise this option. A package created from a response that advertises maximum-CPC bidding can later move from automatic bidding to maximum-CPC bidding or change its cap. Clearing a cap to return to automatic bidding is not supported. This release gives Traffic and App Install Clicks new versioned product and pricing-option IDs, so saved selections for either product from an earlier discovery response must be discarded and rediscovered before use.
• Other TikTok products retain their creation-time bidding modes. Interchange rejects bid_price on updates to an automatic-bidding package whose selected product did not advertise maximum-CPC bidding, and automatic-bidding package reads no longer return stale bid values.
• This path has automated contract and readback coverage. It has not received new live-account certification, and TikTok account permissions and eligibility remain authoritative.
• Claimed Sales Agent owners can now start the public test-sales-agent@1.2.0 brief-discovery workflow from the Agent Page or an exact Source diagnostics page. The Page executes the workflow deterministically through ordinary V3 tools and returns a terminal, customer-safe run receipt without using a model. The validation may use a selected reachable Buyer Account for its isolated sandbox Advertiser and Campaign; its Seller Product reads use that same Buyer scope and preserve the terminal catalog revision and exact Source attribution. Transaction profiles remain available to external hosts but unavailable on the Page until deterministic multi-confirmation support ships. The workflow never exposes Source credentials or grants owner execution from Powered-by or admin projections.
• If your LinkedIn connection predates this release, reconnect it to grant rw_conversions; then call sync_event_sources again and replace any stored event_source_id before your next log_event call — the old synthetic ID no longer resolves. sync_event_sources now returns one event source per enabled Conversions API rule in your account, each mapped to the closest AdCP event type (an unrecognized rule type maps to custom), instead of a single synthetic identifier derived from the account ID. Conversion rules are still created, renamed, and deleted in LinkedIn Campaign Manager — sync_event_sources rejects attempts to change them there, and log_event rejects an event whose event_source_id doesn’t resolve to a rule that exists, is enabled, belongs to the selected account, and matches the event’s type. Each event now requires a lowercase SHA-256 hashed email, a LinkedIn li_fat_id, or one advertiser-owned external ID; external IDs are sent through LinkedIn’s externalIds field and never misclassified as ACXIOM_ID. A conversion value is accepted only with its explicit currency, so Interchange never invents USD. Invalid identity or value input rejects the complete call before provider I/O. An account with more than 500 enabled Conversions API rules gets a clear error on unfiltered discovery instead of a partial list — request the specific event_source_id you need instead, which uses an account-scoped exact read and resolves regardless of account size. Insight Tag rules remain valid for native campaign optimization and association, but this direct-event sync and logging surface does not return them. Exact reads are chunked to 100 IDs, and only an explicit LinkedIn 404 means a rule is absent; permission, throttling, malformed-response, and provider failures remain visible rather than being reported as not found. This is a buyer-side event-tracking correction only: no seller-facing behavior changes, and there is no pricing, packaging, or monetization impact.
• Fixed two issues that could leave a Meta Sales/Conversions campaign permanently stuck with no recovery path.
• First, when Meta’s Pixel API call fails during create_media_buy for a Sales/Conversions product, the error is now surfaced as an actionable message (e.g., “Could not retrieve Meta Pixels — ensure a Pixel or Dataset is installed and that your Meta connection has ads_management permissions”) instead of the generic “Upstream request failed”. This lets you diagnose and resolve the root cause.
• Second, create_media_buys with replace: true now works on ACTIVE campaigns. Previously, if a media buy failed and left a stuck DRAFT on a campaign that already had ACTIVE media buys, there was no way to replace those DRAFTs. Call create_media_buys with replace: true to clear stuck DRAFTs and retry with corrected selections, even while other media buys on the same campaign are running.
• Meta-connected media buys using Advantage+ Audience now report their location automation setting consistently when retrieved. No action is required.
• Buyers moving finished video into campaigns can now use large private MP4 upload on every authenticated ad-account connection instead of a single buyer canary. Files up to 2 GB upload directly from the browser into private storage and enter asynchronous inspection; the upload never sends video bytes through chat. Upload completion means the source is queued for inspection, not that every destination can serve it. Destination compatibility and any required managed rendition or VAST publication remain separate delivery checks.
• Seller behavior does not change in this rollout. Sellers continue to declare the AdCP formats and constraints they accept; giving more buyers private source ingress does not add a creative format or widen a seller’s delivery policy.
• Raw upload and source inspection remain included and consume no IUs. Successful managed rendition, retained delivery storage, and delivery egress remain separate measured outcomes and are not billable until catalog and Rate Card pricing is approved.
• The alpha remains reversible through the managed-video-upload PostHog flag; disabling or narrowing it removes customer exposure independently of the infrastructure worker switch. Promotion beyond alpha requires stable upload-to- promotion queue time and inspection error rates across multiple buyers, plus a proven destination handoff. Adoption is measured by distinct buyers completing an upload and sources reaching approved or promoted state; delivery success is measured separately.
• Google campaign plans now keep product pricing, budgets, live forecasts, and provider execution in the selected Google Ads customer’s currency. Non-USD accounts no longer receive pricing or forecasts mislabeled as USD: live forecast values retain the account currency, template floor guidance zeroes out instead of assuming an exchange rate, and create_media_buy rejects a request or product whose currency disagrees with the selected account, or a budget that isn’t exactly representable in that currency (for example, a fractional JPY amount). Product discovery also rejects foreign, manager, or invalid-currency customer snapshots before storing products, and inline and catalog-resolved offering-level allocations must reconcile exactly to their requested package budget before Google receives a campaign-budget write.
• Managed MP4 upload now finishes as a portable hosted-video creative instead of stopping at a private processing reference. After inspection promotes the exact source, the upload task returns an opaque, revocable HTTPS URL that buyers can use as canonical video_hosted with a built-in adapter or an external sales agent. Destination format checks still apply, and upload, inspection, and the source delivery currently consume zero IUs.
• Upload, inspection, and source delivery are included at no additional cost. Pricing for future storage or transcoding capabilities will be communicated before any charges apply.
• Persona impact
• Enterprise brand buyers get one governed upload that can be reused across compatible seller routes without weakening each seller’s delivery policy.
• Agency buyers can upload once and hand the same hosted creative to compatible built-in adapters or external sales agents instead of re-hosting per route.
• Power buyers and MCP builders receive delivery_url after promotion and may use it as video_hosted; an authenticated owner can revoke it later.
• SMB buyers need no technical action: the upload app waits for inspection and returns the usable hosted creative only when processing succeeds.
• Sellers have no setup or buyer-visible storefront change. Their declared formats and media constraints remain authoritative and may reject the file.
• The “Add advertiser” in-chat widget has a refreshed look. When you ask Murph to add or edit an advertiser, the form is now rebuilt on the Scope3 design system — the same fields and behavior, with clearer typography and layout. No action needed.
• Sellers: not applicable — this is a buyer-only surface with no seller-visible change.
• Sales Agent owners can now include an optional endpoints list when they register an immutable implementation revision. Declaring the Agent’s HTTPS endpoint at registration lets Interchange validate that exact implementation before its first Source test. Existing revisions and registration requests are unchanged; no action is required unless an owner chooses to declare endpoints.
• If you previously validated a Sales Agent with the three test-campaign tools, their V2 API endpoints, or the standalone Test Runs launcher, start the supported validation workflow from the Agent page. To validate one specific Source, start from that Source’s diagnostics instead. Historical Test Runs records remain readable, but new readiness evidence comes from Agent validation history and Source diagnostics.
• Sellers who did not use the legacy test tools need take no action, and the ordinary Sales Agent workflow is unchanged. Buyers have no new surface or behavior. This release does not change plans, pricing, entitlements, or billable usage.
• Set your source’s default advertiser yourself, on whichever ad server backs it.
• The ad server source page’s “Set default advertiser” action now lists the advertisers on your ad server and writes the one you pick for Google Ad Manager, FreeWheel, and AdsWizz alike. Previously it only worked on Google Ad Manager, so the Advertiser for live buys readiness blocker told a FreeWheel or AdsWizz seller to contact us — while every buy outside the sandbox kept failing until we set it for them.
• Two things follow your ad server rather than Interchange: Google Ad Manager serves a searchable advertiser cache and lets Interchange create an advertiser for you, so search narrows at the source and a “create a new advertiser” option appears. Other ad servers return a bounded advertiser roster that the picker filters in place — create the advertiser in your ad server first, then pick it.
• PUT /esa/{esaId}/default-advertiser and GET /esa/{esaId}/advertisers are unchanged; the page now uses them, and the readiness blocker links every ad server that has a default advertiser to the control instead of to us. See Buyer routing.
• If your Media Company is enrolled in live campaign management, your Campaigns workspace now shows live advertisers and campaigns for your own inventory alongside your sandbox campaigns — same list, no separate tab or setup step. Sandbox campaigns are unchanged and stay available to every Media Company, enrolled or not.
• If you connected LinkedIn before conversion support shipped and want to sync event sources, reconnect it to grant rw_conversions. The connection guide now documents that action and the boundary between LinkedIn campaign reads and measurement.
• The Pinterest compatibility page now describes what event-source setup actually does: Interchange discovers the Conversion Tags on your selected ad account and returns Pinterest’s own installation code. It does not create, change, or delete Tags, and server-side event delivery is still not available; nothing changes on your side for Pinterest.
• The connection guide also names where to map advertisers in both the web app and the Connections widget.
• Meta’s compatibility page now explains that native ad-account webhook processing can refresh media-buy status for affected campaigns while delivery reads and reporting remain separate.
• Declare the per-product Scope3 Prebid module state on any save_wholesale_product call. Sellers using the V3 tool can now turn the module on or off for a product in the same call that changes name, pricing, or inventory selectors — pass prebidIntegrationActive: true (or false); omit it to leave the current state unchanged. The tool’s response echoes prebidIntegrationActive plus a prebidIntegrationChanged flag. The existing route through Murph in chat still works. See the updated setup docs at Storefront → TMP → Prebid setup for both routes.

​

5.313.0 — August 27, 2026 at 8:40 PM UTC

• Connected TikTok accounts can now buy TikTok Search Ads as explicit wholesale products: Traffic Clicks, Traffic Landing Page Views (each with Maximum Delivery or Cost Cap bidding), and Web Conversions on Target CPA. Select one of these products and provide your keyword set — Interchange creates the campaign paused and confirms success only after TikTok’s exact provider readback matches the keywords, placement, and bid settings you requested. A request with no keywords, or with a keyword or bid setting TikTok Search doesn’t support for the selected product, is rejected before anything is written to your account.
• No action is needed for existing campaigns or other TikTok products — they are unchanged. TikTok Search Lead Generation and negative-keyword targeting are not yet available as wholesale products.
• When Meta reports age and gender automation for an integrated Advantage+ Sales or Leads media buy, get_media_buys now returns those controls instead of rejecting the read. Existing requests require no changes; unproven or malformed automation still fails closed.
• When live proposal generation is unavailable, seller responses now continue to cite applicable approved positioning and case-study evidence from Materials. If either evidence class is unavailable, the response records that limitation instead of silently omitting it. Advertiser-scoped evidence remains excluded unless eligibility is backed by server-owned authorization; no action is required.
• V3 get calls for an Agent can now include validationRuns to return up to five recent run summaries and an exact follow-up for each. Pass the returned validationRunId with include: ["diagnostics"] to see the run’s ordered stages and where it succeeded or failed. Existing Agent reads are unchanged, and diagnostic responses omit payloads, credentials, private prompts, creatives, endpoint URLs, and customer object identifiers.
• Configured and live Agent owners can now have supported validation runs add catalog-quality evidence to their Agent certification after Interchange verifies the full run and cleanup. The first rollout covers the brief-discovery validation scenario on Agent certification and diagnostics surfaces. Existing evidence stays unchanged and sellers do not need to change their setup. Buyer-visible certification status, badges, labels, and fields do not change in this slice; the new evidence is an internal certification input only.
• Inventory from Trusted Media Brands, Bustle, and Carpenter Media Group can serve through their existing Optimera connections again. No publisher action is required, and their existing Sources, products, campaigns, credentials, and account access stay unchanged.
• Campaign media-buy creation now validates products in the same sandbox or live partition in which they were discovered. This prevents an older expired live quote from blocking a fresh sandbox product with the same seller product ID; no action is required.
• Account-wide seller controls are now clearly separated from advertiser-level work on the Sellers page. When someone on your team views a seller from a single advertiser, actions that would change things for every advertiser — connection authorizations, marketplace availability, and media billing — are shown read-only there. A Manage in account view action switches the panel to the seller’s account-wide settings explicitly, so an account-wide change never happens from an advertiser’s context by accident. What stays actionable in advertiser scope is exactly that advertiser’s own work: mapping it to a seller account (a labeled picker with an explicit Map account action), completing its setup, and resolving its payments. The Sellers header in advertiser context now leads with the advertiser’s markets and channels, and an advertiser view with no available sellers offers Browse all sellers instead of a dead end.
• Opening a seller from the Sellers page now shows its details in a side panel instead of replacing the page, so your search and place in the seller list are preserved. The panel leads with your advertisers — each one’s status with that seller and the action it needs — followed by your account authorizations, with the ad accounts each login discovered listed under it. An unconnected seller shows a single Connect action; once connected, use Add another login for an additional authorization and Refresh account list (renamed from “Refresh accounts”) to re-discover accounts without re-authorizing. Data sharing stays account-wide, so advertiser-scoped views now show it read-only, and test-advertiser creation is offered only when your account has no advertisers yet and is labeled as creating an Interchange test advertiser.

​

5.312.0 — August 27, 2026 at 5:28 PM UTC

• Buyer and seller organizations can now call GET /api/v2/organization/advertisers to read one advertiser list across the accounts they are already authorized to access. Each entry says who operates the advertiser, whether it is managed or self-service, and whether it is ready for advertiser and campaign work. Existing advertiser and campaign APIs behave the same, and no setup is required.
• The endpoint is available to authenticated organization members in Buyer and Seller account contexts. It does not match names, domains, or external account data to widen access, and advertiser-scoped credentials cannot use it.
• Seller proposal receipts now distinguish freshly generated responses, reused cached responses, and responses produced without live model output. When a live model produces the response, the receipt identifies the provider and model; degraded attempts include those details when available. This helps storefront operators audit proposal quality and spot degraded responses. No action is required.
• For hands-on buyers configuring direct-sold FreeWheel delivery, an untested VAST version is now reported as needing destination certification instead of being described as unsupported. The previously proven HTTPS VAST 2.0 trafficking path remains available; hosted video and Scope3-managed VAST still require separate proof.
• Seller applicability: no seller notification or action is required. This changes only the buyer-facing preflight classification before any seller API call; it does not change seller account setup, account policy, or certified delivery state.
• Murph can now set the advertiser your live buys book against, on FreeWheel and AdsWizz as well as Google Ad Manager. Ask for it in plain language — “map the advertiser for my live buys” — and Murph reads your ad server’s advertiser roster, sets the one you pick, and confirms the write. Setup used to raise “Advertiser for live buys” as a blocker and then tell you the change could not be made from chat, which left the only working route a hand-written API call. Until buys have an advertiser to book against, every non-sandbox buy on that ad server fails, so this was the difference between a storefront that looks ready and one that can transact.
• Buyer agents starting without a credential are now directed to zero-touch Agent Registration before interactive OAuth. The public activation contract and authentication guide advertise the canonical interchange:read scope and the zero-spend allowance together.
• Seller applicability: not applicable. This changes only buyer-agent authentication discovery and does not alter seller storefronts, seller credentials, payouts, or presentation.

​

5.311.0 — August 27, 2026 at 4:11 PM UTC

• Account analysis has a refreshed look. When you ask Murph to analyze a connected ad-platform account, the in-chat report is now rebuilt on the Scope3 design system — the same sections and data, with clearer typography and cards. Campaign pacing now shows as a colored status chip (on track, behind, ahead); a pacing value we don’t recognize shows as a neutral chip rather than raw text. No action needed.
• Sellers: not applicable — this is a buyer-only surface with no seller-visible change.
• MANAGED buyers can now declare sandbox account linkages with a specific storefront via POST /api/v2/buyer/storefront-accounts/sync and read their per-storefront sandbox grant status via GET /api/v2/buyer/storefront-accounts?storefrontId=…. Every entry must carry sandbox: true and billing: 'agent'; the request body mirrors the AdCP 3.2 sync_accounts natural key — { brand: { domain }, operator }. External-adapter, archived, and paused storefronts are rejected up-front. Sandbox grants land on the same seller-side linking-service substrate that the inbound sync_accounts handler writes to, so no seller-visible change ships with this endpoint.
• Production traffic (operator-identity gate, other billing modes, BusinessEntity payload) ships in a follow-up slice — the sandbox constraint here fences the resulting grants off from production spend, so a caller cannot use this endpoint to hijack another operator’s identity while the gate is still under construction.
• This is the buyer-side entry point AI-6190’s MANAGED_ACCOUNT_LINKAGE_REQUIRED error points at (once production traffic lands in the follow-up).
• Sellers see no protocol or UI change. Sandbox grants land in the existing seller-side linking-service tables exactly as an inbound sandbox sync_accounts would; no new inbox, no new UI, no new operational step.
• Monetization: no billable surface, no packaging change, no differentiation. Sandbox account linkage is free.
• Rollout — gate: none, atomic launch. MANAGED-only (external/archived/paused rejected at the boundary), sandbox-only (fenced off from production spend), and the mutation is idempotent at the linking-service natural-key level. Kill switch is apps/api/src/routes/v2/buyer-accounts.routes.ts (unmount if we need to disable). Adoption watch: sandbox sync_accounts REST request count per customer via the standard v2 REST metric labels.
• Buyer agent integrations can now receive the canonical interchange:read permission during Agent Registration setup and credential rotation. Existing buyer:read credentials remain supported as a compatibility alias, with no removal date planned, so no immediate action is required. New or rotated registrations should use interchange:read.
• Seller applicability: not applicable. This change is limited to buyer registration credentials; it does not alter seller storefront presentation, seller-visible attributes, seller tokens, seller routes, or seller documentation.
• No action is required for existing wholesale selections or media buys.
• Buyers building TikTok briefs can now name an existing account audience to include or exclude. Interchange uses the audience only when it finds one exact, live match on the selected account. Otherwise, it asks the buyer to clarify before making any provider changes.
• Wholesale discovery remains free. Brief composition is also uncharged while we measure its cost and results. Sellers do not need to act: their inventory, storefront behavior, reporting, and charges are unchanged.
• Marketplace selection now understands the complete AdCP media-channel vocabulary, including sponsored intelligence, while preserving existing audio, Google, and Meta scopes.
• Campaign allocatedBudget now says exactly which media buys it counts. It is the sum of every media buy that still holds budget — DRAFT, PENDING_APPROVAL, INPUT_REQUIRED, ACTIVE, and PAUSED — plus delivered spend on buys that have ended. Previously it was described only as “active” media buy budgets, which led agents to add a DRAFT buy’s budget on top of the reported total, conclude the campaign was over-allocated, and refuse a budget increase that had room. unallocatedBudget is likewise the headroom for any allocation, including raising an existing buy’s budget, not just for new buys. The values the API returns are unchanged.
• update_media_buy now accepts geo_countries and geo_regions in a package’s targetingOverlay, matching what adapters already support post-launch — this was rejected outright with a schema error before.
• When a media buy request uses a targeting dimension an ad platform doesn’t support, the error you get back now names the exact unsupported dimension and marks it as correctable, instead of a generic “Upstream request failed” that looked like a transient outage.
• For buyer teams that use Pinterest Conversion Tags through AdCP, event-source discovery now returns only Tags verified on the selected ad account and relays only Pinterest-issued setup code. You can revalidate existing Tag configuration, while unsupported Tag changes or removal requests fail visibly. Discovery-only workflows need no action; manage Tag changes or removal in Pinterest instead of requesting them through AdCP. Server-side Pinterest event delivery remains unavailable pending signed live validation. Oversized Tag inventories now fail without truncation or replacement of the last proven binding snapshot.
• Fixed save_campaign (isArchived: true) so a retried archive call that lands after the campaign was already archived reports the honest already-archived success instead of an error the agent has no way to resolve. Revision-guarded calls fail closed before retry cleanup, and state retries no longer append duplicate archive audit events.
• Fixed a bug where creating or updating a TikTok media buy could fail with a generic “Upstream request failed” error when TikTok’s advertiser account snapshot omitted or blanked out presentation fields (balance, timezone, language, create time) that the media buy itself doesn’t use. The account currency, status, and role are still validated before any mutation.
• New Google Search Traffic and Search Conversions campaigns now stop before launch unless Interchange can apply and confirm the requested targeting exactly. Each package needs a target country or region and reviewed positive keywords. Supported demographics—including explicit exclusions for every omitted Google age and gender bucket—interests, governed audiences, and negative keywords are applied without widening; unsupported or lossy choices return an explanation before campaign or budget writes.
• Existing Google campaigns are unchanged. Buyers using seller-managed campaigns should add geography and reviewed positive keywords to Google Search Traffic and Search Conversions templates and playbooks. People buying through chat do not need technical setup; Interchange asks for clarification when a request cannot be applied safely. Enterprise brand teams receive a durable requested-versus-provider targeting record for campaign governance; attribution and reporting metrics do not change. Sellers operating Google-connected storefronts do not need to change their connection. New campaigns start paused, and an exact-readback failure keeps them non-serving, reducing the risk that a buyer’s mistargeted request consumes budget or requires seller cleanup. Other Google campaign types and other ad platforms are unchanged.
• If you publish an Interchange buyer app in ChatGPT, select Scan tools to import three guided workflows: get the account ready to buy, set up and stage a campaign, and manage an existing campaign. Existing buyer accounts and API integrations need no changes. OpenAI imports skills as submission-time snapshots, so scan again before each submission or upload the buyer-skills ZIP included in the submission download. This does not change what buyers see about sellers, and Seller or media-company sessions do not receive these buyer-only skills.
• Nothing changes on your side when card confirmation succeeds.
• Card confirmation status now persists across navigation and sign-in.
• Missed confirmation updates are reconciled automatically. Duplicate submissions are blocked while confirmation is processing.
• If confirmation fails or expires, Plan & Billing shows the outcome and asks you to retry.
• Murph now recovers malformed exact-document searches without an extra failed tool round, reducing avoidable latency when answering seller questions from the public documentation.
• Teach now lets you upload PDF, PowerPoint, Excel, CSV, PNG, JPEG, GIF, and WebP files up to 100 MB that stay private to your Seller Account. Review, accept, reject, or correct the selling points and case-study stories extracted from each file. Accepted or corrected items can inform future proposals sent to buyers; undecided and rejected items cannot. Buyers have no new step or interface, and existing materials keep working. Uploads use short-lived permissions and are validated by file type, size, and content. Upload credentials are used only for the browser transfer; they are never rendered or sent to the conversation.
• Brand and agency media teams can now ask an agent to show available sellers, see which seller authorizations their account already has, or open connection setup for a specific seller. Each seller appears once, with every authorization shown as a separate connection and its provider accounts kept together beneath it.
• The Sellers widget uses this model end to end and presents one consistent experience across supported hosts. Opening setup does not authorize a seller or change account data until the buyer confirms. Existing sellers, connections, provider accounts, and advertiser mappings are unchanged. Seller-visible connection state, readiness, exposure, and workflows do not change, so buyers and sellers do not need to take action.

​

5.310.1 — August 27, 2026 at 8:19 AM UTC

• Fresh ChatGPT app submission packages for the shared Interchange first-party endpoint now include its missing account-switching tool justification. Download a new package before importing it in OpenAI; no other setup changes are needed. This most directly serves scrappy builder/power-buyer administrators; other buyer personas are unaffected unless an administrator prepares this OpenAI submission. Dedicated customer app hostnames remain account-bound and continue to omit account switching, so seller marketplace presentation and campaign workflows are unchanged.

​

5.310.0 — August 27, 2026 at 7:50 AM UTC

• Enrolled buyer connections can upload large MP4 creatives directly into private managed-video inspection without sending the file through chat.
• Organizations with a buyer account or Seller Account can now use save_billing on the V3 agent surface to accept the current Terms of Service or add a card as the organization’s payment authority.
• For organization leaders and admins, this adds an agent route without changing contract terms, invoices, transaction records, or seller payouts. Terms acceptance still requires a direct organization admin, and the existing Plan & Billing setup does not change.
• For teams that operate their own agents, card setup follows a request-and-confirm flow. After confirmation, the agent returns a one-time hosted link for the cardholder and can poll for verification; card details never enter MCP. Card setup is available only to enrolled organizations.
• If you use Murph or Plan & Billing rather than operating an agent directly, your workflow does not change. For the seller-impact check, this buyer-side billing change does not alter how a seller’s storefront is ranked, rendered, labeled, or presented to buyers, so sellers have no new storefront setup task or presentation incentive. A Seller Account can use save_billing only for its own organization’s billing, and seller payouts do not change. No action is needed unless your organization needs to accept the current Terms or add a card.
• Rollout remains behind the parent-inherited, fail-closed buyer-card-collection flag, which is also the kill switch. Expansion requires every bounded canary to complete current-Terms acceptance and the card request, confirmation, hosted-link, and verified-status sequence without card data entering MCP, while the existing REST and Plan & Billing paths continue to pass their compatibility checks.
• Adoption is the first successful save_billing operation per enrolled organization, measured from tool invocation logs and the authoritative Terms and capture-link records. Usage is measured as successful Terms acceptances, confirmed capture-link requests, verified card completions, and terminal status-poll outcomes; error rates and request-to-verification conversion are reviewed at each rollout step before the flag audience expands.
• A creative delivery no longer revives a media-buy route that has already gone terminal, and a delivery whose route can never reach its source now fails with a terminal answer instead of waiting indefinitely.
• Reddit media buys now attach an account-authorized Pixel to every new ad group and confirm that the same Pixel remains attached after creation or targeting changes.
• Accounts with one Pixel need no action. If the selected account has multiple Pixels, pass the provider-issued ID in context.conversion_pixel_id. Missing, foreign, or ambiguous selections stop before campaign creation.
• For an older ad group without a Pixel, configure an account-authorized Pixel in Reddit Ads Manager before changing its targeting.
• New campaign names include a short unique suffix in Reddit Ads Manager. Interchange uses it to confirm the newly created, paused campaign before creating an ad group or attempting cleanup.
• Seller and storefront behavior is unaffected: this change only validates buyer-owned Reddit campaign resources, so no seller action is required.
• Let FreeWheel sellers set a default advertiser.
• PUT /api/v2/storefront/esa/{esaId}/default-advertiser rejected FreeWheel because AD_SERVER_CAPABILITIES.freewheel.supportsAdvertiserMapping was false, on the grounds that the upstream write did not exist. It did: the embedded sales agent has exposed PUT /tenants/{id}/adapters/freewheel/config since May, and FreeWheelAdapter reads that default_advertiser_id as the fallback whenever a principal has no explicit mapping. The flag left FreeWheel sellers raised as blocked on “Advertiser for live buys” and then refused the only control that clears it, while every live buy failed at adapter construction. Their sole alternative was a full credential rotation, which means re-supplying a client secret Interchange never stores.
• The capability record now names where each ad server keeps its catch-all advertiser (defaultAdvertiserStore) rather than only whether a write is allowed, so setDefaultAdvertiser dispatches to the right store instead of falling through to the GAM path and persisting default_gam_advertiser_id — a tenant column FreeWheel and AdsWizz never read. FreeWheel and AdsWizz resolve to their adapter config, Google Ad Manager to the tenant column, and SpringServe to none, because it models demand as demand tags and has no advertiser entity.
• Ask your storefront agent to set the advertiser, or call the endpoint directly. The advertiser picker in the ad-server source page is still Google Ad Manager only, so the readiness blocker keeps pointing FreeWheel and AdsWizz sellers at us rather than at a control that is not on the page. Readiness reads the advertiser destination live from the embedded sales agent, so the blocker clears as soon as the write lands, whoever performs it.
• Your wholesale pricing now stays live for the window you declared. Previously an upload expired 35 days after you sent it whatever effective_end_date your rows carried, so a quarter of pricing went dark about a month in and took its products off the market with it. The dates in your file now set the expiry, the “pricing feed expires in N days” warning counts down to that date, and a single backstop keeps an upload usable for at most 365 days so an abandoned feed can’t price inventory forever. Uploads declaring a window longer than 180 days are still accepted and now come back with an advisory, since CPM guidance that old rarely still matches the market.
• For buyers with Sellers enabled, Sellers now appears in the main navigation instead of Settings, making seller availability, account connections, billing, data sharing, and advertiser mappings easier to find. Existing connections and settings keep working, and no action is needed.
• Sellers are affected only through this easier buyer access to the same connections. Sellers do not need to change anything.
• Meta-connected storefronts now retain valid brand-safety content-filter controls when reading media buys, preventing those provider-authored controls from interrupting sync. Invalid or unknown values continue to fail closed. No action is required.
• Seller media-buy lists now show a creative as attached as soon as the buyer submits it to that buy, including while delivery setup is still pending. No action is required.
• Proposal Pass now lets you work an RFP turn, not just view it. From the same portable page you already open in Murph, Claude, or ChatGPT, record buyer feedback and open a revision turn built from it. Request a JSON, HTML, PDF, or PowerPoint file of the response, then watch it move from queued to ready and open or download it — all without leaving the page. Releasing a turn or recording its outcome still happens outside Proposal Pass.

​

5.309.1 — August 27, 2026 at 4:49 AM UTC

• Campaign cleanup now recognizes a just-written committed-spend ledger entry while its public sequence is still being published, so agents can archive a completed campaign without an internal-error retry loop.

​

5.309.0 — August 27, 2026 at 3:43 AM UTC

• The campaign drill-in now shows what’s standing between a draft campaign and going live: a plan summary (budget, flight dates, media buys), the budget split across buys, why each buy isn’t live yet, and a readiness checklist of what’s still blocking launch — unapproved creatives, or no media buys yet. Once the campaign goes live, the drill-in goes back to showing delivery. There’s nothing to turn on — draft campaigns show this automatically.
• Download a fresh ChatGPT app submission package before importing it into OpenAI. New packages now use the Apps SDK submission schema required by the portal; the app’s MCP URL, tools, and publication settings do not change.
• Murph now automatically retries a brief, transient hiccup from one of its AI models instead of ending your conversation early. Nothing to change on your side.
• Fixed TikTok account discovery still failing with “0 accounts discovered” for accounts where TikTok returns an empty string (rather than omitting the field or returning null) for presentation fields like language. Discovery now treats a blank value the same as an absent one instead of rejecting the account.
• The Sellers page now follows the account or advertiser selected in the buyer navigation rail. When an advertiser is selected, its Edit button opens setup without leaving the current conversation.
• Selection and data sharing are now separate controls. Data sharing is explained as account-wide consent for a seller, rather than an advertiser-level setting.
• Seller cards open only when there is a useful next step. Sellers that are not available remain passive, and direct-account sellers show direct billing even before they are connected.
• Sandbox advertiser setup is no longer a standalone header action. It appears inside a seller’s workflow when that seller has no eligible advertisers.
• Large agency / hold-co buyer: Moving between account and advertiser views is clearer, and editing an advertiser no longer interrupts the active conversation. No setup change is required.
• Seller: Buyers now see seller readiness, available actions, and direct billing more accurately. No seller action is required.

​

5.308.0 — August 26, 2026 at 12:56 PM UTC

• When you sign up directly as an Advertiser, your organization starts with one account and one sandbox advertiser. To add another account, choose Contact us to add an account in the account selector; once your account limit is increased, Add account appears without moving your members, billing, or account history. The account limit does not restrict how many advertisers or connected advertising-platform accounts you can manage.
• The in-chat campaign drill-in now shows a live workspace view of a campaign: its media buys, budget split, and real per-seller creative approval status — rolled up to the worst status across sellers, with each seller and its open issue listed on the card. Creative readiness reflects the actual seller review state instead of a placeholder, and delivery bars appear only when there is delivery data to show.
• A dedicated get_campaign_workspace buyer read backs the view, returning the campaign’s media buys and creatives projected for the drill-in in a single call.
• Fixed TikTok account discovery failing with “0 accounts discovered” right after a successful OAuth connection. TikTok can return null for balance, timezone, creation date, language, or role on a newly-authorized or not-yet-audited advertiser account; discovery now surfaces the account as selectable instead of rejecting the whole connection over presentation fields it doesn’t need.

​

5.307.3 — August 26, 2026 at 11:27 AM UTC

• Media Company seller accounts can now finish an own-supply sandbox workflow by archiving the exact sandbox advertiser bound to their Storefront. Live advertisers and restore operations remain administrator-only.

​

5.307.0 — August 26, 2026 at 8:02 AM UTC

• Seller RFP responses can now turn explicitly approved Material selling points and case studies into cited proposal arguments, while keeping price, availability, measurement, confidentiality, and visual rights tied to their canonical sources. The first viable Quick RFP can reuse that truth-gated narrative without another model call, and deliberate passes now return a product-free response instead of offer lines disguised as a decline.

​

5.306.1 — August 26, 2026 at 7:47 AM UTC

• Seller media-buy lists now show creatives submitted by external buyers as attached, including while source-side trafficking work is still pending.

​

5.306.0 — August 26, 2026 at 6:35 AM UTC

• The public Sales Agent validation skill now describes evidence exactly as the ordinary V3 tools return it, including Campaign revisions and previews, Seller media-buy timelines, and bounded delivery ranges. The opt-in integrated own-supply acceptance journey executes that same deployed manifest and retains its sanitized, Activity-linked receipt, so catalog or runtime drift fails the journey instead of leaving a second test-only contract green.
• Existing versioned skill links remain immutable. Callers following the stable test-sales-agent URL receive the corrected version automatically.
• Modular-source Media Buys now show their confirmed settlement currency alongside the seller’s net budget and CPM. Nothing changes in seller workflows; newly created modular-source buys carry the complete commercial terms automatically.
• Buyer agents have a more reliable path through an existing Seller Discovery Card: the public page points to its machine-readable card, a reusable guide, and the Seller’s already-published AdCP endpoint. Start from the published card and follow its adcp action; do not substitute /mcp/v3. Existing V2 integrations do not need to change.
• Sellers with an active public Discovery Card receive the new machine links automatically, so no setup is required. This ships without a feature flag because it adds navigation to information active cards already publish. Publication status remains the exposure control: unpublishing removes the public entry point, and a card without a verified adcp action does not advertise a direct buying endpoint.
• Public discovery does not grant access or change plans, pricing, entitlements, transaction terms, or commercial authority. A customer hostname changes discovery and routing only, and buyers still authenticate with their own credentials. Interchange remains the agent of record for resulting campaigns and anchors buyer identity, advertiser, contract terms, governance, reporting, and ledger evidence; the Seller Account continues to manage the one-to-one buy.
• The API landing page now identifies the account-resolved V3 preview, the stable V2 APIs, and direct Seller AdCP endpoints as separate surfaces. V3 remains a preview; the Discovery Card’s verified action is the direct, one-Seller route.

​

5.305.1 — August 26, 2026 at 6:00 AM UTC

• The read-only “Interchange merchandising available” status is gone from Storefront settings, and “Build Discovery Card” setup actions now open the Discovery Card editor instead of the settings modal.

​

5.305.0 — August 26, 2026 at 5:36 AM UTC

• Buyer agents can now use search and get with the connection kind and save_connection to authorize Seller accounts, map or unmap advertisers, and remove connections. Provider credentials stay in a one-time Interchange browser handoff and never enter MCP. Existing V2 integrations do not change; eligible accounts receive this through the Sellers early-access rollout, and no setup change is required.
• If you build or operate a Sales Agent, you can now test your own supply through the same V3 tools used for ordinary buying. Start with the public, versioned Test a Sales Agent skill. It guides an MCP-capable agent through brief discovery and, with explicit confirmation, a no-spend media buy against your organization’s own Seller.
• For builders and power buyers: use search and get with kind: "agent" to inspect software Agents your organization owns, including customer-safe certification status, implementation health, and the recommended validation skill version. Optional run, skill, scenario, and step identifiers connect ordinary MCP or REST calls to Activity diagnostics and downstream seller calls.
• For sellers: use a synthetic or non-confidential brief to check what your Sales Agent returns, then review the exact Products, prices, formats, source identity, media-buy state, and seller-side readback. Run the skill only with a sandbox Advertiser and your own Seller.
• Action: point your MCP-capable agent at the skill, choose the least-mutating scenario that answers your question, and review each proposed mutation before continuing. Existing integrations require no change.
• Boundaries: a validation run is evidence, not certification. Agent reads omit credentials, private evidence, relationship identities, and owner-only actions. Caller-supplied correlation identifiers do not grant access or prove certification. The launch fixture library contains metadata only, so creative handoff remains unproven until an approved executable fixture is published. This release does not remove the legacy test wrappers; their retirement is separate.
• Pricing and packaging: none. This adds no billable surface, entitlement, Intelligence Unit usage, take-rate change, or paid package.
• Rollout and rollback: the Skills catalog is public after deployment, while execution uses the existing V3 preview and its ordinary account permissions. The new Agent reads require an organization administrator or account-bound machine credential. Rollback is a code revert: it removes the catalog, Agent noun, and workflow annotations without a schema, billing, or data migration. Any sandbox resources created before rollback remain subject to their ordinary cleanup lifecycle.
• Measurement: adoption is the number of distinct organizations and correlated runs using the published skill version, split by scenario. Completion is the share of started runs that reach the scenario’s terminal read and cleanup calls. Operational acceptance requires zero production-Advertiser or cross-Seller mutations; failures are grouped by the recorded step and server-issued Activity and trace identifiers.
• Allow buyers to traffic an HTTPS VAST 2.0 creative through Talpa’s managed FreeWheel connection. No new buyer setup is required: select the FreeWheel- backed inventory and provide the VAST tag with the creative. Sellers keep the same FreeWheel connection and operating workflow; the connection now accepts this proven creative type instead of rejecting it before delivery. Only the exact enrolled Talpa connection receives this certification; other FreeWheel connections stay fail-closed. Uploaded video files and other VAST versions remain blocked until their delivery paths are separately certified.
• This compatibility capability is included in the existing buying and selling workflow at no incremental charge. Managed transcoding, storage, and delivery for uploaded video files are not part of this release and may be packaged separately when they launch.
• Inventory Sources and Seller Setup now show Not buyable when an ad-server source’s selling currency has not been verified or is incompatible. The source row explains which currency check failed while leaving unaffected inventory available.
• For Google Ad Manager and FreeWheel, run Test connection after correcting the source’s currency configuration. Successful tests now refresh the verified currencies and clear outdated blockers automatically. If the source remains blocked, follow the inventory source troubleshooting guide or contact Scope3 support with the failed check shown in the row.
• SpringServe sources can be connected and displayed, but remain Not buyable until Scope3 certifies their live booking path. No seller action is currently available for that limitation. Buyers and buyer workflows are unaffected by this fix.
• Show the advertiser and buying operator on seller Media Buys for modular-source transactions. Nothing changes in seller workflows; newly created modular-source Media Buys now carry that identity automatically.
• Murph now directs sellers with an ad-server execution-currency blocker to the supported connection test and avoids unsupported credential-reconnect instructions.
• Sales Agent validation now waits for a complete Product catalog and carries the selected Product’s Seller, query, revision, pricing identity, and any returned Source or Sales Agent route together into the sandbox media buy. If that Product disappears or its provenance changes, the run stops before save_media_buy instead of reusing a stale ID or borrowing another Product’s identity.
• The public test-sales-agent skill advances to version 1.1.0 with bounded steps, sanitized receipts, and reverse-order cleanup. Existing 1.0.0 links stay immutable; callers following the stable skill URL receive 1.1.0 automatically.
• Routed Media Buys now show their confirmed settlement currency alongside the seller’s net budget and CPM. Nothing changes in seller workflows; newly created routed Media Buys carry the complete commercial terms automatically.
• The Sellers page now opens scoped to the advertiser you’re already working in, instead of always defaulting to the account overview. If no advertiser is selected, or the page doesn’t recognize the selected one, it opens on the account overview as before. The page’s own View selector still switches between account and advertiser views the same way it always has.

​

5.303.0 — August 26, 2026 at 1:11 AM UTC

• Seller storefront Pages now make four everyday tuning tasks more complete:
• Demand Inbox shows saved buyer requests immediately, including drafts that have not started a response, and lets sellers load more requests.
• Proposal Pass keeps a readable recent history of response attempts and clearly says when additional history exists.
• Teach shows accepted selling points from seller material, keeps earlier decisions visible and read-only, and lets sellers load more material and selling points.
• Seller Analytics shows current request-performance measures, recent requests, and the saved detail for a selected request.
• No seller action is required. New launches use explicitly versioned v3 Page resources; previously persisted launches retain their released storefront bundles and controls. This has no packaging or billing change and ships ungated because it uses already released storefront records. Indirect buyer persona disposition: not applicable. Buyers see no change to proposal flow, storefront presentation, or seller-readiness signals because the release changes seller-side reads, history, decisions, and analytics without changing the buyer transaction path.
• The integration surface also adds authenticated, Page-scoped storefront tool bridges and bounded Material continuation fields so external MCP hosts can run the same seller Pages with least-privilege access.
• Measurement uses the existing mcp_widget_opened, mcp_widget_load_failed, and mcp_widget_runtime_failed events with widget set to demand-inbox, proposal-pass, product-marketing, or seller-dashboard. For the first 14 full days after release, compare with the preceding 14 days: acceptance is at least 90% retention of weekly unique identified seller accounts opening these Pages, with each Page’s load-failure rate and runtime failures per 100 opens no more than one percentage point above its baseline; report opens and unique seller accounts per Page as ongoing usage.

​

5.302.0 — August 26, 2026 at 12:05 AM UTC

• Seller logo tiles no longer squeeze a wide wordmark into the square tile. When a seller’s brand kit has no square mark, the tile shows initials on the brand color instead.
• Organizations enrolled in IU card charging can now rely on every successful payment remaining tied to the correct billing cycle, including after a retry or a charging rollback. Each payment is recorded as deferred when collected and applied to that cycle’s invoice. Scope3 recognizes collected revenue only after the cycle closes and the invoice is issued.
• Finance leaders and agencies gain a cycle-level audit trail without changing their billing controls or playbooks. Hands-on billing administrators can compare invoice payment applications with usage and the accepted plan when investigating a difference. Smaller teams do not need to learn a new workflow or take any action. This does not change IU prices, plan terms, seller listings, or anything buyers see about a seller.
• Murph now refreshes the approval queue when a saved review reference is stale instead of trying other identifiers. No seller action is needed.
• Setup no longer offers a “connect your ad server” step to sellers whose storefront sells through a third-party sales agent. If you told us how you sell, that choice now drives the setup checklist immediately — before, a fresh third-party-agent declaration could still show the ad-server chooser until a source was connected. Switching your answer still restores the ad-server step.
• Fixed connected Sales Agent discovery and diagnostics for sellers: synchronous wholesale product reads no longer register an async callback, and Refresh capabilities now refreshes the selected Source directly. No setup changes are required; retry the refresh if it previously returned Not found.
• FreeWheel inventory sources can now certify a single vendor-observed execution currency without replacing stored credentials, and advertiser rosters with more than 1,000 accounts can sync completely for authoritative live-buy mapping.
• Fixed the seller detail view in Sellers: it no longer shows two sections both named ” accounts” — your seller-account authorizations and the ad accounts discovered under them now have their own distinct headings. A seller you haven’t added also no longer shows a status chip that contradicted its “Available to add” line; the header now stays quiet until there’s something to act on.

​

5.301.0 — August 25, 2026 at 9:07 PM UTC

• save_advertiser now accepts isArchived (archive/restore) to archive (true) or restore (false) an advertiser through the v3 buyer surface. Cannot be combined with field updates.
• Enrolled sellers can now use V3 MCP tools from their Seller Account to create and manage live campaigns against their own inventory. The tools keep Advertisers, Campaigns, Products, Proposals, and Media Buys within the organization’s own Seller Account; the native Campaigns workspace remains sandbox-only. Live launches still require source currency compatibility, account mapping, publisher authorization, creative approval, funding, standing, and any seller-side approval.
• Buyers can now filter seller search results by classification (global_market_maker, regional_market_maker, or marketplace_seller), marketplace readiness, channel, and region. A get(kind:"seller") call also returns directed campaign subscription state inline (connection.directedCampaignSubscription) when an active subscription exists, so connection state is available in one call without a separate lookup.
• Sellers: buyers can now see your classification, whether you are marketplace-ready, and which channels and regions you cover when browsing for sellers to work with. Keeping these attributes current on your storefront makes it easier for the right buyers to find you in filtered searches.

​

5.300.0 — August 25, 2026 at 6:07 PM UTC

• Official provider cards now show their current logos and recognizable brand colors more consistently. The update is automatic, with nothing for buyers to configure.
• Seller availability and setup requirements are unchanged; sellers do not need to take action.
• With save_rfp on /mcp/v3, you can request seller JSON, buyer JSON, semantic JSON, responsive HTML, PDF, or editable PowerPoint files. Each file preserves the same products, prices, budget allocations, seller claims, and source citations. Existing RFP calls do not create files unless you request one.
• OpenAI submission packages can now be downloaded when the published brand profile has no usable logo. The package includes every ready submission artifact, explains that logo files must be uploaded manually in OpenAI, and links directly from Discovery & distribution to the complete submission walkthrough.
• When a media buy fails because your creative doesn’t fit any of the selected packages, or is missing a required destination URL, the error response now names what to fix instead of the generic “source unavailable, try again later” message.
• The top-line message on the failed create_media_buy response is now a specific, actionable line when we can categorize the source’s rejection — the two categories today are a creative-size mismatch (the response names the sizes the selected packages accept) and a missing destination URL. Categories we can’t recognize still return the current generic message; nothing regresses.
• The message is composed from a canonical template, never the raw source string, so no vendor-internal names travel through.
• A machine-readable, structured shape for this reason is on the way in the AdCP spec (adcontextprotocol/adcp#6833). This release keeps the wire contract unchanged and only improves the human-readable message — buyer clients that branch on error code see no change.
• Your sales agent can now use /mcp/v3 to add and review Materials, complete RFP responses, and download proposals as JSON, HTML, PDF, or PPTX without a separate UI workflow. Every format preserves the commercial details and locale stored with the response. Buyer JSON is available for authorized linked exchanges and keeps the same locale; invalid locale tags are rejected before saving. Nothing to change on your side.
• Buyer account administrators can now complete operator setup without leaving MCP. On /mcp/v3, call get_status and check operatorIdentity.usableForBuying and operatorIdentity.scopeStatus before starting discovery or other new buying work. Follow a returned save_buyer_operator next action even when the saved domain is already usable.
• If usableForBuying is false, an administrator must call save_buyer_operator with the buyer’s real, non-platform operatorDomain. Choose whole_operator, or choose specific_unit and provide a stable operatorUnitId. Discovery and new buying operations remain blocked until the domain is confirmed. If the domain is usable but scopeStatus is unclassified, reuse that domain and choose its scope before new AdCP 3.2 provisioning when locked is false; existing buying remains available. If locked is true, follow the support action from get_status. No operator setup action is required when the domain is usable and the scope is confirmed.
• The scope records whether the account represents the whole buyer organization or one stable operating unit. This tool does not grant login access, change account membership or the login organization, or alter seller inventory or storefront presentation. Buyers who do not administer account setup have no action.
• Snap packages can now target multiple countries when you provide exactly one language in targeting_overlay.language. Interchange validates the language against Snap’s current targeting inventory, maps it to Snap during create and update, and preserves it in readback. Country changes also stop before mutation when a call or message ad makes that axis immutable. Brief discovery explains that multi-country requests require the AdCP 3.2 structured language discovery surface to be integrated.
• Seller product setup and catalog contents are unchanged; this only changes how a buyer’s package targeting is validated and sent to Snap.
• Buyers now see a cleaner Sellers catalog: creative and other non-sales agents stay out of the list, and ordinary Marketplace sellers appear once they can transact. Curated Market Makers remain visible while setup is still in progress.
• For sellers, this means a storefront that is not a sales agent or is not yet Marketplace-ready no longer appears to buyers. Completing Marketplace readiness restores ordinary catalog visibility; curated Market Makers keep their visibility during setup.
• Anonymous buyer agents can now retain their first connected provider account using the standard untrusted registration credential. The activation flow no longer depends on an extra WorkOS permission that operators could not provision.
• Delivery reporting for buys on inventory sources that return cumulative totals without a per-day breakdown (such as GAM adapter sources) now self-heals after deploy. Affected buys catch up one reporting day per poll cycle automatically.
• Media Company campaign workspaces can now find the sandbox Advertisers they just created through the own-supply workflow. The roster remains limited to active sandbox Advertisers bound to the organization’s exact Storefront.
• Fixed Meta Engagement — Instagram Direct Conversations always failing with a generic “service unavailable” error when launching a campaign. Meta returns an extra, disabled default field on this ad type that our verification step didn’t expect and treated as a mismatch. Campaigns using this product now launch successfully.
• Fix signup flow for invited users signing in with Google or SSO. The invitation selection screen was not shown during OAuth/SSO signup, preventing invited users from completing the sign-up process and accepting their invitation.
• Proposal representations now persist in the private Material storage namespace authorized for the renderer, so requested HTML, PDF, and PowerPoint files can finish rendering and become available for download.
• Browse discovery now returns cached products from a prior discover_products call even when the wait tier differs, preventing empty results on quick browse polls. Product details lookup now works for wholesale storefront products that use prefixed IDs, returning details instead of a not-found error.
• Restored daily delivery reporting for media buys routed through a storefront source, and made a report that has fallen behind fill its missing days back in.
• Each missing day is now requested from the source on its own, oldest first, so a gap is filled in order rather than skipped past — a day only counts as reported once the source has actually returned it. Filling a long gap is gradual: expect up to a day or two for the oldest days to appear. If a day is still missing after that, contact support and we can re-collect a specific day on request.
• Fixed a bug where TikTok media buys with an explicit start or end date failed at execution with “The ad platform rejected the request as invalid.” The adapter was sending dates in ISO 8601 format but TikTok requires YYYY-MM-DD HH:mm:ss. Any TikTok buy with a scheduled flight date was affected. Retry affected buys after this release.
• Update the generated ChatGPT submission import to OpenAI’s current canonical schema URL and verify that every customer tool includes the required read-only, open-world, and destructive annotation justifications.
• MCP OAuth metadata now advertises the supported scope consistently, and resource-bound authorization events include enough diagnostics to distinguish an expired grant from a token issued for another MCP endpoint. OpenAI submission packages continue to rely on automatic OAuth discovery instead of duplicating those defaults in a setup file.
• Discovery & distribution now appears only for seller account admins. The page also describes the published account without storefront-specific language. Buyer admins continue to manage browser origins from API keys.
• Meta lead-to-message products (Meta Leads — Messenger, Instagram Direct, and WhatsApp) now return welcome-message-flow candidates in the discover_products/get_products catalog response, so welcomeMessageFlowId (added previously) can actually be filled in with a real value. Previously the field existed but nothing surfaced a candidate to put in it, so every lead-to-message execution still failed with “requires ext.meta_welcome_message_flow_id from account resource readiness.”
• Every Media Company can now test an own-supply campaign from its Seller Account without a separate Buyer account or sandbox entitlement. Create a sandbox Advertiser, build its Campaign and Creative, select Products and Signals from your own Storefront, run the no-spend Campaign, and inspect delivery through the V3 MCP workflow or shared Campaigns workspace.
• This does not enable production spend or access to another Seller’s inventory. Live Media Company-managed campaigns and client self-service remain separate, limited rollouts while their production workflows are completed. Independent Buyer Accounts and their existing sandbox workflows are unchanged.
• The setup and discovery assistant now speaks plain language instead of leaking engineering vocabulary. It names a choice and its tradeoffs — “you can pin which sellers this campaign buys from now, or choose them when you request proposals” — rather than surfacing raw field names like sellerIds, and it no longer narrates internal plumbing (“the schema accepts it but it isn’t wired to the API yet”), which used to make it look like there was a setting you had to change when there was nothing to do. Nothing to change on your side.
• Seller-agent search results now round-trip opaque inventory-source and work-item identifiers into follow-up reads, instead of returning false not-found errors for identifiers containing reserved URL characters. Nothing changes in your integration, and no action is required.
• On the Sellers widget, two states now use plainer, more accurate words. Sellers you haven’t added read “Available to add” instead of “Not enabled for your account” — you always had access; the seller just wasn’t added yet. Sellers that aren’t open for buying on the marketplace read “Not open for buying” instead of “Not transactable yet” — a neutral description, since this state also covers sellers that are unlisted, opted out, or paused, not only ones mid-setup. Seller note: this changes only how a seller’s marketplace readiness is worded to buyers; nothing about a seller’s actual status, presentation inputs, or incentives changes.
• Sellers enrolled in self-service buyers no longer see intermittent “Self-service buyers are not enabled for this storefront” responses on the join-link and sponsored-buyer surfaces. The enrolment check now reads a cached evaluation, so listing join links across an organization no longer depends on one live rollout lookup per organization member, and a momentary lookup failure no longer reads as a denial.
• Reconnecting a seller account can now target the exact authorization you meant to re-authorize, instead of always starting a fresh connection. If you authorize a different account than the one you asked to reconnect, we keep it as its own connection and let you know — we never silently swap it in.
• Buyer-agent builders can now retrieve up to 50 exact Sellers in one V3 search, keep the requested order, and see which IDs were not found. Existing Seller searches work as before, and no buyer setup changes are required.
• This read-only shortcut does not change seller visibility or require sellers to take action.

​

5.299.1 — August 25, 2026 at 12:42 AM UTC

• When your Seller Account has more than one inventory source, an ad-server currency problem on one managed source no longer stops your unrelated modular products from serving buyers. Those modular products remain discoverable and buyable while you repair the affected ad-server connection. Products from that connection stay unavailable, and the account remains blocked if no other buyer-visible inventory source is ready.

​

5.299.0 — August 24, 2026 at 11:39 PM UTC

• Technical sellers and API builders using v3 MCP can now reuse a Quick RFP response skeleton across repeated live RFP requests without reusing commercial facts. Set origin.kind to quick, provide a typed origin.preset, and use purpose: "live"; every response reloads current products, pricing, and availability and applies current request details. Existing Quick draft/evaluation calls and bounded legacy presets remain compatible but bypass caching, while non-Quick calls compose normally. Buyers receive the same response shape, representation, provenance, and current commercial facts on cache hits and full compositions. This beta capability is included with existing v3 Seller Account access with no new entitlement, package, or billing meter; receipt.cacheMode reports each outcome.
• Sellers using /mcp/v3 can now compare grouped RFP response quality, processing efficiency, and commercial outcomes with get_rfp_performance. Choose metrics, optional groupings and exact-match filters, and an inclusive UTC date range. Results distinguish unavailable values, report when small buyer or advertiser groups were withheld, and support snapshot-stable pagination. Every metric reports its own eligible, observed, and excluded population, named exclusion reasons, freshness, and finality.
• The default report covers turns from live RFPs that reached a terminal response state. Add draft or evaluation to purpose for quality and efficiency analysis; commercial metrics always use released live turns. Use get with kind: "rfp" or "rfp_turn" for individual records. Existing integrations require no changes: record_outcome still preserves any nonempty result. Aggregate reporting uses a closed, case-insensitive taxonomy after trimming whitespace and converting spaces and hyphens to underscores: accepted (accepted), won (booked, delivered, won, closed_won), lost (lost, closed_lost, rejected, declined, declined_fit, declined_policy), and pending (pending). Any other nonempty result makes affected commercial metrics unavailable with unknown_outcome. Money is unavailable if an included booked value is negative, nonnumeric, not exactly representable in its currency’s minor units, above JavaScript’s safe numeric maximum, lacks outcome-level currency, produces an unsafe aggregate, or mixes currencies. Valid values are summed as exact integer minor units before a safe numeric result is published.
• Responses are capped at 40,000 UTF-8 bytes and 10,000 estimated tokens. The largest supported response—five rows, six metrics, three dimensions, maximum labels, filters, and cursor—measures 37,282 bytes and 7,136 estimated tokens. Buyers receive no new field, ranking input, or workflow; they may benefit only indirectly when a seller uses these facts to improve future responses. This capability is part of the existing authenticated Seller /mcp/v3 surface with no new package, entitlement, price, or usage meter. The Seller Analytics page is unchanged in this release and any future UI must render this contract without hidden calculations. See the RFP performance guide.
• A currency-verification problem on one managed ad-server source no longer blocks campaigns against unrelated sales-agent inventory. Interchange now counts current public Agent products when deciding whether the affected ad-server source can be withheld on its own, so buyers keep seeing and buying healthy products while the Seller repairs that source. The unverified source remains unavailable, and this check remains blocking when no other buyer-visible source can serve.

​

5.298.0 — August 24, 2026 at 10:52 PM UTC

• Prevent concurrent provider-account binding requests from failing while an adapter credential mirror is in progress.

​

5.297.1 — August 24, 2026 at 10:04 PM UTC

• Modular inventory-feed products now preserve their guaranteed delivery terms when storefronts compose RFP responses, so eligible products are no longer omitted from proposals.

​

5.297.0 — August 24, 2026 at 8:52 PM UTC

• You can now choose how every buyer joining a new sponsored-buyer invite link is billed: Interchange-cleared or Seller direct. Interchange-cleared billing uses the buyer’s existing invoice arrangement or deposited funds; with Seller direct billing, you invoice the buyer under your own agreement and Interchange moves no media funds. The choice appears on the invite link and buyer roster. Sponsored buyers see the resulting readiness path but cannot change your choice. Existing links and links created without a choice remain Interchange-cleared, so you do not need to update them.

​

5.296.0 — August 24, 2026 at 8:37 PM UTC

• Sellers can now use save_material to register a PDF, presentation, image, site, or spreadsheet without reducing it to extracted text. Interchange keeps the original upload or source reference in a new immutable Material revision and processes supported pages, slides, sheets, text, tables, and visual assets with their source locations and reuse rights. For an upload, provide its digest and metadata, upload the bytes to the returned expiring PUT URL, then call replace_source with the returned assetRef. Existing Material calls require no changes.
• get(material) returns bounded rendition summaries by default. Request semantic blocks, visual assets, extraction diagnostics, or expiring source access explicitly; large collections page independently, and large binaries stay out of model context. Unsupported or degraded extraction is reported instead of presenting the Material as complete, and a source refresh retains the previous revision and its evidence.
• This release prepares Material for future proposal composition. It does not change proposal rendering, and Material candidates still cannot update Products, inventory sources, pricing, or Business Rules. See Seller V3 workflows for the upload and retrieval flow.

​

5.295.0 — August 24, 2026 at 7:14 PM UTC

• Authenticated seller assistants and API clients can now save and read RFP work through /mcp/v3. A seller can submit a buyer request, read the saved request-to-response record while it moves from queued or processing to a final response, add feedback as a new follow-up, and record the commercial outcome. Each turn is a locked record of one request and its generated response; revisions create another turn instead of editing the prior one.
• No action is required for sellers using existing Interchange pages today. Those pages do not show this workflow yet; direct integrators can use save_rfp plus search/get for rfp and rfp_turn. The RFP response is saved directly in this workflow, so there is no separate proposal-save call for sellers to run. See the Seller RFP lifecycle guide for catalog prerequisites, terminal-state semantics, revisions, and audit reads.
• Rollout: this ships ungated to authenticated seller accounts because the change only adds tenant-isolated server facts and portable tool access; existing account authorization is the exposure boundary. Removing the RFP tool/read entries from the seller tool registry is the kill switch while UI adapters remain deferred.
• Monetization: no pricing or packaging change in this slice.
• Measurement: track RFP create, revision, replay, conflict, terminal response state, response latency, representation requests, feedback, and recorded outcomes before expanding the workflow beyond the headless contract.
• Facilitated Agreement Terms v1.1 is now the current version, effective 2026-08-24, and governs transactions between buyers and sellers on the Platform. Read it at interchange.io/agreements/facilitated-agreement-terms.
• No action is needed. Scope3 gives 30 days’ written notice before updating the Facilitated Agreement Terms; continued use of the Platform after that notice period is acceptance of the update. A Transaction Order (the agreement for an individual deal between a buyer and seller) formed before an update’s effective date stays governed by the version in place when it was formed. v1.1 applies only to new Transaction Orders and new Relationship Agreements (the standing agreement between a specific buyer and seller) formed on or after 2026-08-24.
• Buyers: v1.1 sets your payment timing, invalid-traffic credit treatment, and measurement/dispute process for every new transaction. Nothing changes about what you do today.
• Sellers: v1.1 incorporates two new documents by reference. Marketplace Policies sets out how your standing is tracked (delivery performance, dispute history, buyer ratings, IVT rates) and what happens if it falls below the required level. The Payment Operations Schedule spells out how Scope3 recovers invalid-traffic credits from your remittance. If a clawback isn’t resolved within 30 days of notice, Scope3 may suspend you from accepting new Transaction Orders — Transaction Orders already in place keep running.
• You can now read a preview of Terms of Service v4.0 at interchange.io/agreements/terms-of-service/v4-0. It replaces the current percentage-of-transaction fee model with a flat Platform License Fee plus metered Usage Fees. It is not yet active: the current Terms of Service (v3.0) still governs, unchanged, until v4.0 is separately made current with its own notice.
• Questions about any of these documents: support@scope3.com.

​

5.294.0 — August 24, 2026 at 4:34 PM UTC

• If a buyer’s media buy fails on your ad server side with an order that couldn’t be cleaned up, a retry of the same buy will no longer create a second live order on the ad server. The unresolved order surfaces in your Pending Operations list, where you can archive or manually resolve it — that’s the single place to close it out, and once you do, buyer retries succeed normally.
• For buyers: if a retry hits this state, the response says the source is temporarily unavailable and the buyer can retry — no duplicate orders are created on the ad server side.
• Sellers can now manage storefront visibility, public-hosting and CNAME status, OpenAI verification, and the submission package together in Settings → Discovery & distribution. Submission packages use the currently published public storefront and its brand logo; existing sellers can continue their current setup, and no action is required unless the page shows a status that needs attention. Buyers will find browser-app origins in the same section instead of API keys; existing origins and API keys are unchanged.
• Official ad-platform sellers now show their provider’s brand color on storefront identity and discovery cards too, matching the Sellers view.
• Fix Meta Engagement — Instagram Direct Conversations failing every execute_campaign call once the connected Instagram account is authorized. The adapter no longer asks Meta’s ad set to carry an Instagram identity field it doesn’t support for this destination; the identity now travels only on the ad creative, matching Meta’s Click-to-Instagram contract.
• The Media Buys page on your storefront no longer offers a clickable timeline for buys that live only in your ad server — those that were trafficked directly and never routed through Scope3. The row still shows the buy and its ad-server id so you can find it on your side, and calls out that its full history is in the ad server, instead of opening a timeline that reads “No buy with id X exists on this storefront.”
• execute_campaign now works for media buys targeting external storefront sales agents such as pubX. Previously, these campaigns failed with a “Could not verify compatible account modes” error and could not be executed. No changes are needed on your side; campaigns that were blocked will now execute successfully.
• save_campaign with desiredPhase: "active" now requires confirmLaunch: true and expectedRevision — calling without confirmLaunch: true returns a preview showing campaign name, budget, flight dates, media buy count, and revision. The confirmation call requires expectedRevision from the preview to detect any concurrent changes between preview and launch.
• New tool get_proposals_diagnostic returns sanitized per-seller outcome detail from a request_proposals execution — allowlisted error codes, outcome counts, and media buy IDs — to help diagnose why sellers did not respond with proposals.
• When your agent creates its first advertiser mapping in its Agent Registration sandbox, Interchange retains the registration and connected provider account beyond the 30-day trial—no WorkOS claim required. The retained sandbox is limited to that one provider account and remains zero-spend; paid capabilities, media buying, and customer-wide access still require customer authorization.
• In v3 MCP, when you add Product marketing material with save_material, get(material) returns suggestions with the exact source passage behind each one. Each suggestion names the save tool that owns the proposed change. Nothing changes in your selling setup until you confirm a writable suggestion through that tool. Private advertiser material stays limited to that advertiser. After a confirmed save, get(material) shows which saved record came from which source revision and suggestion.
• Suggestions that cannot safely preserve a complete Playbook or Business Rules document are marked as unable to save instead of replacing the document with a single extracted line. If the named tool saves successfully but the Material receipt is interrupted, repeat the same confirmation to finish the receipt; the saved record is not created again. If the service cannot tell whether a save finished, it stops instead of retrying and tells you to verify the saved record. A corrected suggestion can then be confirmed once without hiding the earlier attempt. Disconnecting after a save starts does not cancel or duplicate it.
• If a Playbook or Business Rules confirmation saves only some of the requested parts, the response lists what is already live and what remains. Save only the remaining parts through the same named tool. Then use save_material with action: "reconcile_candidate", the returned applicationId, and the saved record in place to finish the Material receipt. The service reads that record from its named save tool and refuses identities supplied by the caller. This step does not repeat the save, and repeating it returns the same receipt. Suggestions cannot be corrected while their save is still running or waiting for verification. A late success is retained, and receipt retries never repeat the seller-setting change. If the named save or its verification exceeds the service deadline, Interchange stops waiting, records the result as uncertain, and does not automatically send the seller-setting change again. During an incident, operators can pause suggestion confirmations without hiding your Material, evidence, or review results.
• Buyers do not see Material suggestions or confirmation receipts. Confirmed changes affect buyer-facing behavior only through the existing Seller record and workflow that the named save tool already controls.

​

5.293.0 — August 24, 2026 at 2:51 PM UTC

• If your Seller Account is enrolled in this V3 preview, you can now test a no-spend campaign against your own wholesale Products from setup through reporting. In V3, create and inspect Advertisers, Campaigns, and Creatives; browse Products and their available targeting Signals; request and inspect Proposals or stage a Media Buy directly from a Product; activate the Campaign in the sandbox; and confirm whether the Media Buy and its targeting were forwarded.
• You can also query Campaign delivery by selecting the metrics and groupings you need for an inclusive date range of up to 90 days. Results remain confined to Advertisers, Campaigns, and Media Buys that use Products from your Seller Account.
• The preview cannot spend or access another Seller’s inventory. Enrolled Seller Accounts can use the organization workspace selector to move between Inventory and a sandbox-only Campaigns workspace; Agents appears there when separately enabled. Marketplace, Connections, Buyer Setup, and production Advertisers are not included.
• This preview has no billing impact and does not introduce a billable surface. It does not change what any external buyer sees about your Seller Account or inventory.

​

5.292.0 — August 24, 2026 at 2:15 PM UTC

• Official ad-platform sellers (Meta, Google Ads, LinkedIn, Pinterest, Reddit, Snap, Spotify, TikTok, Amazon, OpenAI Ads) now always display their provider’s curated brand color on the Sellers and Connections tiles. When the live brand lookup can’t confirm the provider’s logo, the tile shows the provider’s initials on that brand color instead of a blank black tile. These built-in adapter tiles always use the provider’s canonical identity — any operator-stored colors or logos on an adapter row are not used, so a stale or mismatched asset can never render under a provider’s name. Publisher storefronts and all other non-adapter sellers are unchanged.
• If your buyer operator identity is incomplete, finish Buyer Setup step 1 before starting new discovery, account, or media-buy operations. No action is required when your identity is already correct or for existing media buys. Seller-facing presentation and ranking are unchanged.
• The Connections view no longer flashes an old layout while loading.
• Meta lead-to-message media buys (Meta Leads — Messenger, Instagram Direct, and WhatsApp) now accept a welcomeMessageFlowId field on product selections so buyers can specify the welcome message flow used to greet new leads. Pass welcomeMessageFlowId in create_media_buys selections, add_discovery_products selections, or update_media_buy product entries, using one of the welcome-message-flow candidates returned by account resource readiness in the discovery/get_products response — previously there was no way to supply this value and execution always failed.
• Creative synchronization now keeps a creative in Processing when a seller only confirms that it was created, updated, or unchanged. The creative becomes Approved only after the seller sends an explicit approval. No buyer action is needed while the final status callback is pending; if no final status arrives within the normal operation timeout, retrying the synchronization starts a new attempt safely.
• The Sellers page now tells you what to do instead of showing a bare status word. A seller you haven’t enabled shows why — excluded, not yet transactable, out of your advertisers’ markets, or simply not turned on — and opening it lets you enable it, instead of reading “Inactive.” Market makers now show as one combined list instead of two, since which kind a seller is never changes what you can do about it. In a seller’s detail view, each platform account you’ve authorized gets its own row with its own reconnect and remove controls, so removing one authorization can’t be confused with another.

​

5.291.0 — August 24, 2026 at 12:50 PM UTC

• Meta Instagram Direct media buys (Instagram Direct Conversations, Instagram-based Lead Generation) now accept an instagramActorId field on product selections so buyers can specify which Instagram account to use when the connected Meta ad account has more than one authorized Instagram account. Pass instagramActorId in create_media_buys selections, add_discovery_products selections, or update_media_buy product entries. When the account has exactly one authorized Instagram account, the field remains optional and the server now selects it automatically — previously, execution always failed with an unhelpful error even in that case.
• Buyers managing creative and AI provider connections in the new Sellers view again see Update API key for providers that authenticate with an API key. The action opens the existing secure connection page and selects the API-key flow even when the provider also offers OAuth; the Sellers widget never handles or returns the key.

​

5.290.0 — August 24, 2026 at 11:31 AM UTC

• After you add or remove account access with a connected provider, refresh the account list without reconnecting.
• If you use the new Sellers view, choose Refresh accounts next to Reconnect. Your current sign-in stays in place. Accounts you can no longer access remain in history but cannot be used for new activity. If the provider requires you to sign in again, Sellers tells you to reconnect.
• Teams that automate connection management can call the new refresh operation through REST or MCP. The response distinguishes temporary provider failures from grants that require reconnection, so agency and enterprise workflows can retry safely or send the right person to reconnect.

​

5.289.1 — August 24, 2026 at 9:29 AM UTC

• Fixed the Discovery settings screen for the Interchange first-party account so its platform-managed publication can be loaded and configured.

​

5.289.0 — August 24, 2026 at 9:04 AM UTC

• Seller operators using the v3 MCP surface can now teach their seller agent by saving source materials from URLs, uploaded files, crawl manifests, inline notes, or historical references, then search and read those Materials by name, source, processing state, and relevance tags. This is for seller-side setup and catalog-quality work in agent or script integrations; buyers do not see a different proposal or product presentation from this slice, and existing Product Marketing upload flows continue to work.
• This release does not add a new billable package or pricing meter. Rollout is ungated because the capability is limited to authenticated seller v3 MCP calls and does not expose a new UI; existing upload and content flows remain unchanged while background Material processing can be disabled operationally without deleting saved Materials. Adoption will be measured by save_material, search(kind: "material"), and get(kind: "material") usage, created Material and source-revision counts, and ingestion terminal-state rates for ready, partial, and failed revisions.
• In buyer discovery, official adapter Storefront cards now show the channels each provider actually supports instead of outdated channel settings. Buyers see the correction automatically—for example, Google Ads no longer appears as social inventory and Spotify no longer inherits an unrelated social channel. Adapter operators do not need to change their Storefront settings.

​

5.288.6 — August 24, 2026 at 8:05 AM UTC

• OpenAI Ads product discovery now returns buyable products instead of discarding them when validating reporting metrics. Delivery reports include canonical cost-per-click and CPM values for totals and breakdowns.

​

5.288.4 — August 24, 2026 at 7:13 AM UTC

• Keep slow seller products discoverable when an optional forecast timestamp is an empty object, including cached and in-flight discovery executions. Production verification now correlates asynchronous dispatches by their durable trace and completed request window instead of requiring the outbound request ID to equal the buyer request ID.

​

5.288.2 — August 24, 2026 at 6:34 AM UTC

• Discovery cards for official adapters now show buyers the advertising platform they represent, such as Meta or TikTok, while keeping the operator account as separate provenance. Sellers using an official adapter should expect buyers to see that platform name; there is nothing to change in the storefront.
• Online-video sellers can now be reviewed in OLV as a channel separate from display and connected TV. Existing country markets start closed. Marketplace Governance must open a market using public supply evidence before an eligible seller can appear there. The seller’s reviewed scope and commercial entitlement must also include OLV; approval for display or connected TV does not carry over. Buyers and sellers do not need to configure anything for this change.
• Teach V3 agents to list the Seller’s products with the typed wholesale_product search and to avoid invalid empty search calls.
• The first-party Interchange account now shows Discovery settings instead of the retired ChatGPT-specific setup screen. Discovery remains admin-only and its management API now accepts that account’s buyer-classified administrators while continuing to reject other buyer accounts. Publications continue to use the brand-derived identity at api.interchange.io.
• Official provider connections in Sellers now show the provider’s name and logo instead of the connector operator’s brand. Buyers see the correct provider identity, and sellers operating these connections are no longer presented as the provider. Existing connections update automatically; no action is required.

​

5.288.1 — August 24, 2026 at 5:34 AM UTC

• Keep seller inventory discoverable when an optional forecast timestamp arrives as an empty JSON object, while preserving the seller’s original wire payload for any later purchase.

​

5.286.0 — August 24, 2026 at 3:16 AM UTC

• Your Buyer Account Mapping page is now a Buyers directory. Each buyer is one row; expand it to see the advertisers they buy for. Requests waiting on your review open a panel showing the policy outcome, who handles billing, and any CRM match, so you can accept or reject the buyer in place. Accepting doesn’t wait on account mappings. If a connected sales agent manages buyers for your storefront, the page says so and shows what that agent has reported instead of asking you to act. Each inventory source appears with a refresh action, and search, CSV export, and the import feed work as before. This view is enabled per account; until yours is enrolled, the page you see today is unchanged.
• Seller admins can now publish a storefront Discovery Card from a dedicated
• Discovery settings section. Identity, colors, and generated app icons follow
• the storefront brand automatically, while the first-party storefront is served
• from api.interchange.io without DNS setup.
• To use it, open Storefront settings → Discovery, choose private,
• Interchange, or public visibility, and publish. The prior one-off ChatGPT
• category, support/legal URL, and icon-upload fields are no longer part of this
• workflow; existing V1 drafts keep their reusable subtitle, identity overrides,
• and generated assets while those channel-specific values are ignored.
• The direct user is a seller admin. Buyers and buyer agents are the indirect
• audience because they consume the resulting verified identity and public card;
• the removed ChatGPT category does not control Discovery ranking or matching.
• There is no new monetization, entitlement, or charge associated with this
• settings surface.
• Public hosting is deliberately admin-gated and limited to Customer 1 at
• api.interchange.io; other customers can still publish private or Interchange
• visibility. No feature flag is required for that narrow rollout. Operators can
• withdraw a card by returning it to private visibility, and the hostname service
• fails closed on suspension, revocation, or expired verification. During a
• replacement publish, the last verified revision stays live until the new one
• passes verification.
• Rollout health is measurable from publication/revision counts, hostname
• activation and verification status, challenge status, and the existing audit
• records. Initial acceptance is one active Customer 1 public origin with all
• public routes resolving the same verified revision; adoption is the count of
• seller-initiated publications and revisions from the Discovery settings
• surface.
• Keep seller inventory discoverable when a forecast instant arrives in an unambiguous single-value JSON wrapper, while preserving the seller’s original wire payload for any later purchase.

​

5.285.0 — August 24, 2026 at 1:08 AM UTC

• Buyer discovery now accepts unambiguous ISO forecast timestamps and treats null optional timestamps as absent while preserving the original seller payload for forwarding.
• Your proposal passes now show the pitch sentences that were dropped because nothing backed them: a “What didn’t make it” section lists each one with the facts it was judged against. You can resolve each sentence — mark it a fair reading of those facts, confirm the drop was right, or teach the missing fact in your product marketing and link it once confirmed. Resolving only ever adds to your product marketing; the check itself never loosens. Nothing to do unless a pass shows the section.

​

5.284.3 — August 23, 2026 at 11:41 PM UTC

• Buyer discovery now accepts seller forecast timestamps that use an equivalent RFC 3339 timezone offset while preserving the original seller payload for forwarding.

​

5.284.0 — August 23, 2026 at 9:27 PM UTC

• The proposal pass now shows which sentences the truth gate dropped and the facts each was judged against.

​

5.282.2 — August 23, 2026 at 7:45 PM UTC

• Buyer developers using REST or MCP get_products can now set ext.interchange.response_contract to interchange_product_compatibility_v2 to include products from verified AdCP 2.x sellers. These products mark reporting_capabilities unavailable instead of inventing reporting details. Existing calls keep the original required-field response schema. Sellers on a verified 2.x contract can become visible to opted-in buyers without changing purchase forwarding; returning the current reporting block removes the compatibility marker.

​

5.282.0 — August 23, 2026 at 7:05 PM UTC

• If your buyer account is enrolled in the alpha canary, you can turn a ready destination video rendition into one stable, revocable VAST 4.2 URL for ad-server trafficking. Google Ad Manager is the first canary destination; FreeWheel is not yet certified for this path. Raw video upload remains included, and there is no charge for the canary.

​

5.281.1 — August 23, 2026 at 5:16 PM UTC

• Seller account reconnects now show progress while authorization opens and display a retryable error if the provider handoff cannot be launched.

​

5.280.0 — August 23, 2026 at 4:03 PM UTC

• Storefront administrators can now manage browser origins directly beneath
• member API keys in API Access. Empty API-key and browser-origin states use a
• more compact layout so the remaining credential sections stay visible.
• Published Discovery Cards can now have a verified public web address with a
• shareable page, structured JSON, and an embeddable view. Interchange’s
• first-party card uses api.interchange.io/discovery, while a dedicated customer
• hostname can serve its card at the hostname root. The same verified hostname
• can support OpenAI Apps domain verification at OpenAI’s required challenge URL.
• Existing storefronts do not change automatically: publication and hostname
• activation remain an explicit setup step. Once active, Interchange rechecks the
• hostname and current published revision; the public card stops serving if that
• verification expires or no longer matches.
• Meta buyer connections now use the user-token Business Login configuration so approved Marketing API permissions are present during account discovery.

​

5.279.0 — August 23, 2026 at 1:37 PM UTC

• Buyer account requests now land in a review queue with the evidence you need to decide: which buyer and brand are asking, how the account will be billed, and any match against your CRM. Accepting a request is what grants access — a pending request no longer implies authorization — and your existing pending reviews carry over unchanged, with the same review IDs and nothing for you to redo. The Buyer Account Mapping view now shows which accounts were observed from each ad server or sales agent, how fresh that information is, and which actions are actually yours to take: where an external sales agent runs your storefront, that agent keeps ownership of acceptance and billing, and actions that belong to the agent are never offered to you. If an account list from a source comes back incomplete or fails, you keep the last complete picture instead of a partial one, with its age shown.
• For buyers, nothing changes about how account requests are made: sync_accounts works as before, and the released grantId and approve_interchange API spellings remain valid. A request may now show as pending until the seller (or the seller’s sales agent) accepts it, because access is granted at acceptance rather than at request time.

​

5.278.5 — August 23, 2026 at 1:10 PM UTC

• Fixed seller join-link signup so sponsored buyers keep their join context through email checks and OAuth, skip non-buyer account choices, and route to seller-specific admission or seller-branded waitlist state instead of the generic buyer waitlist.

​

5.278.1 — August 23, 2026 at 11:30 AM UTC

• Fixed proposal pitches sometimes composing with no argument even though the seller’s storefront had real inventory and a Playbook configured — a claim citing the seller’s Playbook is now checked against the Playbook’s own text, instead of an empty placeholder that made such a claim impossible to verify.

​

5.278.0 — August 23, 2026 at 11:07 AM UTC

• Product discovery now keeps compatible seller products visible while preserving the seller’s exact original response for downstream buying.
• Buyers: No request changes are needed; compatible inventory no longer disappears after successful discovery.
• Sellers: No configuration changes are needed; catalogs served by agents with older protocol response fields are now presented completely to buyers instead of silently losing compatible products.

​

5.277.0 — August 23, 2026 at 10:21 AM UTC

• Buyer product discovery requests now use the buyer’s declared operator domain when contacting sellers. Sellers now see the correct requesting buyer operator instead of the generic Interchange fallback when the buyer has declared one. Seller storefront previews retain their simulated Interchange preview identity, and buyers without a declared operator domain continue to use the existing platform fallback.

​

5.276.0 — August 23, 2026 at 10:01 AM UTC

• Meta Business Login connections now request the valid Marketing API permissions needed to discover the selected ad account while excluding the unsupported Instagram permission.

​

5.275.1 — August 23, 2026 at 9:39 AM UTC

• Keep valid publisher-hosted formats available while the community registry is still checking a newly discovered publisher, so Property Roster refreshes do not temporarily replace the live catalog with an empty indexing placeholder.

​

5.275.0 — August 23, 2026 at 9:13 AM UTC

• If readiness withholds a managed ad-server source, refresh or reconnect it from Inventory Sources so its execution currency can be verified. Storefront readiness now checks each source’s currency contract before allowing new buys; sources with an empty, incompatible, or temporarily unavailable contract are withheld. Buyers will see fewer products while that source is unavailable, or their buy will be blocked when no other buyer-visible source can serve.
• Keep unchanged progressive discovery polls idempotent, and make explicit refresh=false available-account reads return cached data without contacting or mutating the source. Existing live-refresh behavior remains the default.
• Seller impact: Your storefront presentation, account approvals, and available inventory remain unchanged, and buyers using the normal flow continue to see live state. Only buyers who explicitly request refresh=false may see cached account data that is stale or empty. You do not need to change your setup or tune your storefront.

​

5.272.2 — August 23, 2026 at 7:31 AM UTC

• Sign-up and password reset now show the same live password guidance and accept strong passphrases and password-manager-generated passwords without arbitrary character-composition rules.
• Account administrators can reach browser-origin controls at the top of API
• Access even when the member API-key provider fails. The embedded API-key error
• state now uses its content height instead of filling the settings pane.

​

5.272.1 — August 23, 2026 at 7:11 AM UTC

• Meta connections now use the configured Facebook Login for Business grant instead of requesting a retired Instagram permission directly.

​

5.272.0 — August 23, 2026 at 6:42 AM UTC

• Buyer connection handoffs now show secure API-key entry when provider OAuth is unavailable.
• Sellers can now use save_seller or the Storefront update API to publish or opt out of Marketplace discovery after Scope3 approves their Storefront. Opting out removes the seller card from buyer discovery and automatic selection without changing its eligibility; no action is required to stay published. Buyers will see only seller cards that are both Scope3-approved and published, and a Market Maker label applies only in approved markets and channels with active commercial or Scope3-granted Critical Supply access. Related businesses appear as separate seller cards even when one organization contract covers them, so each card keeps its own approved coverage. Production writes remain disabled until every web and worker process is running these rules.

​

5.271.0 — August 23, 2026 at 6:12 AM UTC

• Murph’s answer no longer streams in real time while it’s being generated. An earlier release added this behind a rollout flag, but it could let unredacted or in-progress text reach the chat before Murph’s safety and redaction checks finished running. We removed it — Murph’s answer still appears in full as soon as it’s ready and checked, the same as before that release.

​

5.270.1 — August 23, 2026 at 5:28 AM UTC

• Creative readiness now reflects two separate checks: the seller’s review of
• the exact creative content, and confirmation that every required destination
• accepted its current media-buy assignment. Existing requests and setup do not
• change.
• Enterprise brand buyers. A creative reported as approved by
• sync_creatives now provides stronger governance evidence: the seller reviewed
• that exact content and every required destination accepted its current
• assignment. No strategy, partner instruction, or setup change is required.
• Agency and hold-co buyers. A reused creative may remain Pending separately
• for each media buy while its required destinations accept the current
• assignment. The seller’s decision carries over when the content and seller are
• unchanged. When sync_creatives reports approved, delivery was accepted for
• that assignment; it does not mean serving or impressions have begun. No
• playbook or setup change is required.
• Power buyers and technical integrations. No request changes are required.
• sync_creatives responses and task notifications keep a creative Pending until
• the seller approves its exact content and every required delivery destination
• accepts it.
• SMB buyers using chat or campaign widgets. A creative may stay Pending
• longer while these checks finish. This is expected, and no action or setup
• change is required.
• Sellers. The Approvals widget and creative review queue now show changed
• creative content as a separate review. Approving one version never approves a
• later content change. Identical content keeps its existing decision, so
• unchanged creatives do not return to the queue.
• Some older approvals did not record enough information to match the decision
• to one exact content version. Those affected creatives will appear once as
• Pending after this release. Open the Approvals widget, filter to Pending
• creative reviews, and approve or reject each resurfaced item. Until reviewed,
• the creative cannot deliver and its buyer sees it as pending. There is no
• separate deadline; this one-time check does not recur for unchanged content.

​

5.270.0 — August 23, 2026 at 5:02 AM UTC

• Navigation within Interchange now stays in the app shell, preserving account context and reducing page reloads as you move between pages.

​

5.268.0 — August 23, 2026 at 3:58 AM UTC

• Account admins can now prepare a customer-branded ChatGPT app in Settings → ChatGPT app. Add the approved listing and icons, verify a dedicated hostname, publish the OpenAI verification token, and download the submission bundle. Your organization must still submit the bundle to OpenAI; Interchange does not submit or publish the app.
• In ChatGPT, buyers with existing Connections access can now open Connections, and sellers can open Approvals. Existing ChatGPT connections need no setup changes, and buyer-visible seller inventory is unchanged.
• For MCP integrations, open_page no longer advertises sellers or approvals. Use open_connections_page or open_approvals for those Pages. Direct calls to the old destinations remain compatible, and all other open_page destinations are unchanged.

​

5.267.0 — August 23, 2026 at 3:24 AM UTC

• Buyer Account Mapping can now explicitly bind an approved advertiser relationship
• to one inventory source, or confirm that a source-native account is not required.
• The version-guarded decision controls whether that source can offer products and
• accept buys for the approved account.

​

5.265.0 — August 23, 2026 at 1:35 AM UTC

• open_proposal_pass now explains WHY no pitch composed, not just that one didn’t. When a proposal pass’s pitch resolves absent because the model’s draft answered but nothing survived grounding (pitchAbsentReason: nothing_grounded), the pass now carries a pitchAbsentDetail alongside it — counts only, never claim or brief text — showing how many of each ingredient kind (products, inventory bundles, signals, pricing facts, affordances, brief references, playbook, corpus) fed the pass, and how many claims the model drafted versus how many were dropped by citation grounding and by the entailment check. Every other pitch status is unaffected, and a pass without this diagnosis simply carries pitchAbsentDetail: null, as before.
• Demand now keeps the buying operator and advertiser relationship visible when
• a brief uses an approved linked account. The onboarding staging walkthrough
• also proves that exact account through the brief, buy, creative, delivery, and
• seller-operated completion.

​

5.264.0 — August 23, 2026 at 1:10 AM UTC

• Murph can stream its answer as it’s generated instead of waiting for the full response, for accounts enrolled in the rollout.

​

5.263.3 — August 23, 2026 at 12:42 AM UTC

• Fixed brief runs (test_storefront_brief, run_practice_brief, and confirm_uploaded_brief) on a curator storefront — one that resells other Interchange storefronts’ inventory instead of its own — losing access to that resold inventory whenever the run named a specific buyer’s operator/brand domain. These runs now compose from the same catalogue whether or not a buyer domain is supplied, so an uploaded RFP response also draws on resold inventory; live buyer discovery is unchanged.

​

5.263.2 — August 22, 2026 at 11:51 PM UTC

• Seller account-mapping links now open the Buyer Account Mapping Page instead of being discarded by the Murph route.

​

5.263.1 — August 22, 2026 at 11:38 PM UTC

• Discovery and purchase now keep products that contain at least one usable creative format even when another legacy reference or sibling product cannot be translated. Unsupported references remain visible as non-blocking Seller Setup diagnostics, and display_160x600 now maps to a canonical 160×600 image instead of suppressing the product.

​

5.263.0 — August 22, 2026 at 11:03 PM UTC

• Creative-library cards and API summaries now identify an HTML5 ZIP as the
• bundle creative instead of classifying it by its backup image.
• Meta accounts with a large number of upcoming, promotable Facebook Events
• could see the Meta Engagement — Event Responses product’s Event
• candidate list truncated with no way to reach the rest. get_products now
• returns Event candidates one page at a time and names meta_after_event_id
• as the field to pass on a follow-up call to continue, matching how Meta
• Sales — Website Catalog Sales already paginates its product-set candidates.
• Accounts with 200 or fewer eligible Events are unaffected.
• Fixed “Try a brief” from the product-marketing Teach page sometimes showing no pitch even though the identical brief produced a full pitch through brief testing — the practice run and the test run now compose the pitch from the same brief facts.

​

5.262.10 — August 22, 2026 at 9:25 PM UTC

• Product discovery continuation requests now return a retryable temporary
• unavailable response when loading the saved query exceeds its preparation
• deadline, instead of reporting an internal server error.

​

5.262.1 — August 22, 2026 at 3:40 PM UTC

• Before this fix, buyers connecting a Meta ad account with more than one
• Facebook or Instagram Shop-enabled Page had no way to tell Interchange which
• Page’s Shop to buy against when using **Meta Sales — Facebook or Instagram
• Shop Purchases**. The product’s readiness now names page_id as the field
• to set, matching how every other Meta product with more than one eligible
• account resource already works. Accounts with a single eligible Shop-enabled
• Page are unaffected.

​

5.260.5 — August 22, 2026 at 12:36 PM UTC

• Buyers can keep discovering and purchasing valid products from an active seller catalog while other products need format repair; sellers do not need to republish the storefront.

​

5.260.4 — August 22, 2026 at 11:24 AM UTC

• Upload an HTML5 banner ZIP in buyer chat and Murph keeps its files together as
• one creative. It reads the banner size and keeps a matching backup image when
• included. Before syncing the media buy, add the destination to the creative’s
• click-through URL field. If the bundle does not meet a seller’s HTML5
• requirements, Murph names what is blocking delivery so you can correct the ZIP
• or choose a compatible placement. Sellers receive a complete banner package
• they can serve as intended.
• Keep external sellers request-eligible when cached products need format repair, and use trusted cached seller projection catalogs to interpret private legacy formats without a live setup probe.

​

5.260.2 — August 22, 2026 at 10:42 AM UTC

• Buyer and seller MCP connections now keep each credential restricted to the
• exact Interchange endpoint it was authorized to use. After rollout, existing
• ChatGPT, Claude, and other MCP connections using legacy credentials will stop
• at their next token refresh and require a one-time reconnect. Reconnect and
• sign in from that client’s connector settings when prompted; until then, the
• legacy connection remains disconnected. New and reconnected clients use
• resource-bound, rotating credentials automatically.

​

5.259.1 — August 22, 2026 at 9:14 AM UTC

• Buyer discovery no longer waits for storefront readiness calculations or source-account setup before contacting sellers. Sellers’ already-published products become available to buyers promptly; this does not change product contents, ranking, or seller setup, and no action is required.

​

5.259.0 — August 22, 2026 at 9:00 AM UTC

• Buyer API clients can now configure third-party impression and click trackers for an advertiser or campaign through the V2 tracking-config endpoints or the V3 MCP advertiser and campaign nouns. Send the vendor URL to the advertiser or campaign tracking field; the response retains that exact input, returns its validated AdCP-macro translation, and shows which advertiser defaults a campaign inherits or overrides.
• Existing integrations may keep sending the original name, url, and tracker_type shape; stable tracker identity and retained vendor input are recovered automatically. Nothing changes in creative delivery yet. Creative mapping, preview, and upstream adapter expansion remain separate follow-up work.

​

5.258.0 — August 22, 2026 at 8:39 AM UTC

• The white-label ChatGPT guide now uses the app owner’s private-label identity
• and exact assigned MCP URL throughout Developer-mode setup, links an example
• review video, and separates the generated submission bundle from the publisher
• steps that still require manual approval.

​

5.256.0 — August 22, 2026 at 7:41 AM UTC

• Use the new white-label ChatGPT app guide to
• connect Interchange in ChatGPT Developer mode, confirm the intended account,
• record review evidence, and prepare a public-submission handoff. This is private
• testing: a separate public customer-branded app still needs either a
• customer-controlled MCP hostname or an explicit arrangement approved by
• Interchange and OpenAI.
• You can now upload a CM360 tag sheet in buyer chat and keep its placement names,
• declared sizes, and raw tag variants without retyping them or changing vendor
• macros.
• Murph preserves the parsed tags, but no tag-sheet creative can be delivered to
• any seller in this release. VAST pre-fetch and Internal Redirect rows also stay
• blocked. Sellers do not need to change their setup.

​

5.254.0 — August 22, 2026 at 6:24 AM UTC

• Storefront sources no longer stay unhealthy when per-product effective coverage
• confirms that every active product is manually priced. With that coverage
• available, mixed automatic pricing remains protected and unresolved manual
• pricing still prompts you to upload a current feed.
• Creative preview guidance now covers every storefront advertising adapter
• available to buyers and shows the exact saved, transient, and fail-closed
• boundaries before a buyer tries an unsupported preview.
• Hosted video URLs are now checked against the storefront’s managed ad server
• before creative sync. Certified Google Ad Manager storefronts can accept
• compatible H.264/AAC MP4 files up to their recorded profile limits; FreeWheel
• video remains unavailable until that integration is certified. Unsupported
• video now returns a compatibility error before the ad server is changed.
• Non-video creative behavior is unchanged.

​

5.253.0 — August 22, 2026 at 6:02 AM UTC

• Google Ads preview_creative can now show Google’s own expiring Performance Max preview for a creative already saved and synchronized to the selected Google Ads account. This lets buyers review the saved creative before it is used, with no setup changes required.
• Interchange returns the link only when it can match one saved creative to the exact account and campaign and validate Google’s URL and expiry. Because Google does not provide placement choices, dimensions, or an embeddable view for this preview, requests for those details fail safely instead of returning an approximation.
• Source Health now uses Healthy, Degraded, Erroring, and Unknown consistently across customer diagnostics, agent summaries, and admin views. Existing diagnostics APIs retain unhealthy as a compatibility wire value, presented as Erroring; typed timeouts remain degraded observer-budget evidence rather than error responses or eligibility decisions.
• Practice pitches show up again: running a practice brief was silently dropping the composed pitch, so the opened proposal showed only the plain product view. The pitch is saved with the practice run once more.

​

5.252.0 — August 22, 2026 at 5:12 AM UTC

• Approved storefront creatives now report the downstream ad-server creative ID
• in buyer creative readback when every destination returns the same ID. No buyer
• changes are required; multi-destination approvals omit the field when any
• destination fails, omits its ID, or reports a different ID.

​

5.251.0 — August 22, 2026 at 4:58 AM UTC

• Your existing member API keys already use their owner’s current access, including buyer advertiser access and seller Storefront access. The shared settings page now says that each key uses its owner’s permissions in the organization. Later permission changes continue to apply without rotating a key; no authorization behavior changed, and no action is required.
• OpenAI Ads compatibility guidance now explains why preview_creative remains unavailable: the provider’s prose-documented, OpenAPI-absent preview operation has no published response contract or verified public HTTPS URL, the nullable account preview URL is only a favicon, and dynamic product templates cannot be faithfully approximated. Existing OpenAI Ads campaigns and creatives are unchanged; no action is required.
• Buyer and storefront agents now refresh the live request list before answering status questions, so answers reflect the latest available progress. No action is required.
• The account-resolved v3 MCP API is now available to every authenticated buyer and seller account at /mcp/v3. Buyers receive buyer workflows and sellers receive Storefront workflows, with each catalog filtered by the account’s permissions and resource access. Existing entitlements still apply to every operation, and existing v2 APIs remain supported.

​

5.250.5 — August 22, 2026 at 2:11 AM UTC

• Wholesale product listings now carry the same placement, availability, and audience facts that composed proposals do. Previously only proposals built from a brief included them.

​

5.250.0 — August 21, 2026 at 11:15 PM UTC

• Every placement in a proposal now shows what you’re buying: the property it runs on, the placement’s available delivery for the window (with an effective CPM shown next to flat rates), and — where the seller has provided them — audience facts with their source. Where the seller hasn’t provided a fact, the proposal says so instead of talking around it. Today the property and delivery resolve for inventory fed through a static avails feed; products sold through other connections show them as not yet resolved. Nothing to change on either side.
• Sellers: gaps like “Property not yet named” and “No audience facts yet” are now visible directly on the buyer’s proposal, so they’re your cue to confirm property mapping in the Property Roster and add audience facts via Teach — the more complete your data, the more your proposals show.
• Source Health now shows buyer-request selection and observed operational health as separate statuses for every inventory Source. A call that does not finish inside the observation budget is reported as a typed timeout with the budget and last success where available; it is not described as an error response or proof that the Source is unreachable. Eligible, compatible Sources continue to participate in discovery after a timeout or health degradation, and create or update operations route through the persisted owning Source.
• No setup change is required for existing connected Sources. Explicit Source and Agent holds, storefront pause/archive, required setup, Agent mapping, and request compatibility remain gates where they apply. Health observations remain diagnostic evidence, while account sync and other recovery checks remain callable. Canonical per-request routing is the deployed default; storefront eligibility snapshots remain an independent optimization and do not decide Source selection.

​

5.249.4 — August 21, 2026 at 10:46 PM UTC

• Buyers can now open the V3 Sellers Page, view seller connections, and complete its existing management actions without errors. Available seller logos now appear in seller discovery; sellers do not need to take any action.

​

5.249.0 — August 21, 2026 at 8:33 PM UTC

• You can now distinguish Global Market Makers, Regional Market Makers, and
• Marketplace Sellers from marketplace readiness, selection, and advertiser
• activation, and complete setup, authorization, direct-billing, and payment
• actions from the Sellers experience. Existing selection, billing, and
• activation data and defaults do not change; no action is needed unless a card
• shows Action required. For sellers, no action is required: approved
• contract and admin facts now make eligible sellers easier for buyers to
• understand and connect with, without exposing new seller data or requiring a
• setup change.
• Storefront setup now clears corrected pass-through sales-agent catalogs without being held by older buyer-specific product observations. Buyer requests still validate their relevant account catalog before products can serve; sellers do not need to clear historical setup data.
• Forward full campaign cancellations to managed sales-agent destinations instead
• of incorrectly treating those destinations as archived modular inventory.
• Agents now remains visible in the workspace rail for every organization that
• can use the Agent page. Clients appears beneath it only when the organization
• has client-management access.
• OpenAI Ads connections can use an account API key while provider OAuth access is unavailable. The connection flow prefers API-key setup until OAuth is configured, then makes OAuth the preferred option without invalidating an existing key. If your API key is already connected, no action is required.
• Preview an already-synced TikTok in-feed video from the selected advertiser account. There is nothing to change in your buyer workflow: Interchange opens TikTok’s expiring preview link after confirming that the saved video belongs to that account, keeps historical DOWNLOAD creatives compatible with TikTok’s current DOWNLOAD_NOW request value, and declines unsupported creative types instead of showing an approximation. Buyers gain this preview for an existing TikTok-connected storefront; sellers do not need to change storefront setup, creative sync, or delivery workflows.

​

5.248.1 — August 21, 2026 at 7:13 PM UTC

• Buyers can now discover your storefront reliably even when they check an older
• format interface. No action is needed, and your current product formats remain
• unchanged.

​

5.248.0 — August 21, 2026 at 6:58 PM UTC

• Buyers can open Snap’s hosted preview for image and video creatives already
• synced to their selected Snap ad account. No setup change is needed. If a
• preview does not load, confirm the creative has finished syncing to the
• selected account and try again; Interchange shows an error instead of opening
• a preview it cannot safely confirm.
• Once OpenAI enables your organization for its OAuth beta, connect an OpenAI Ads
• account from Settings → Connections without copying an API key. Each grant
• links one advertiser account. Existing account-scoped API-key connections keep
• working, so there is nothing to change until OpenAI and Scope3 confirm your
• OAuth enrollment.
• Partner organizations now find Agents in the account menu and move between
• Agents and their nested Clients from a persistent workspace rail instead of
• one-off top-header buttons. Entitled Agent pages also load consistently when
• the separate Agent Page rollout flag is disabled.

​

5.246.1 — August 21, 2026 at 4:35 PM UTC

• Storefront listing now loads reliably even when the marketplace is large. Previously, a shared internal timeout across many storefronts could occasionally fail the entire request; each storefront now falls back to its last-known status instead.

​

5.246.0 — August 21, 2026 at 4:14 PM UTC

• Check Pending Operations for any new manual modular-source tasks that need your
• team now. Booking, creative sync, and final reporting work is grouped by buyer,
• media buy, and source, with a direct link to each task; when the queue says no
• action, there is nothing to do.
• Media-buy and modular-source pages now separate setup readiness, supported
• capabilities, transaction inputs, and open human work. They show seller-authorized
• net terms only when that evidence exists, keep accepted distinct from trafficked
• or delivered, and retain buyer or source-connection identity when two buys use
• the same media-buy ID.
• Buyers do not need to change anything, and buyer-facing amounts are unchanged.
• Inbound buyer gross budgets remain buyer context and are never presented to a
• seller as net terms.
• Managed ad-server media-buy mutations now preserve private-service transport policy when applying per-call timeouts.
• Approved media buys now reach managed ad-server-backed sales agents instead of failing before delivery begins.
• Buyer and seller chat clients now receive explicit safety metadata for every V3 tool, including accurate confirmation and external-action boundaries. This host-side change does not alter what buyers or sellers can see about each other, and requires no action from them.

​

5.245.0 — August 21, 2026 at 11:55 AM UTC

• Allow OpenAI Ads storefronts to finish provisioning so buyers can connect an
• approved OpenAI Ads account through the standard adapter flow. New adapter
• setup starts hidden; safety demotions happen before routing, while promotion to
• listed waits for routing to succeed.

​

5.244.2 — August 21, 2026 at 11:39 AM UTC

• Demand Inbox and seller-response passes now lead with the advertiser brand, show the buying operator separately, distinguish product offers from persisted Proposals, and replace ambiguous pending outcomes with the most specific recorded lifecycle state.

​

5.244.0 — August 21, 2026 at 10:22 AM UTC

• Buyers and sellers can now open Your requests from Help to see support
• requests for their own account and whether a fix is ready. Murph also brings a
• resolved request into the next update it shows them. There is nothing to
• configure, and neither side can see the other’s requests.

​

5.243.0 — August 21, 2026 at 8:54 AM UTC

• In Settings → API Access, new user API keys now inherit their owner’s current account and advertiser access. Buyers, sellers, agencies, and integration builders no longer choose a separate read, write, or admin scope when creating one. Existing keys continue to work unchanged, so no action is required; when you choose to rotate a key, its replacement uses inherited access. This does not grant access beyond the owner’s permissions or change what buyers can see about sellers.
• When storefront-connections is enabled, buyers get one Sellers page instead
• of separate Marketplace and Connections pages. Buyers can browse every eligible
• Storefront, see why it is selected, and take any connection or billing action in
• the same place; no action is required for sellers in this release. Sellers are
• presented as Global Market Makers, Regional Market Makers, or other sellers,
• without exposing how their connection is implemented.
• Scope3 will measure distinct buyer accounts that open Sellers, change a
• Storefront preference, and complete a required action. Activation remains in
• shadow mode, so this release does not provision accounts, change billing,
• pricing, packaging, or spend.

​

5.242.1 — August 21, 2026 at 7:43 AM UTC

• When a publisher’s ad platform rejects a media buy submission, the error you get back now names the actual reason — such as an invalid request, missing account credentials, or rate limiting — instead of a generic “upstream request failed” message. Nothing to change on your side; this only makes certain error responses more specific.
• Fixed Meta Estimated Ad Recall media buys failing to launch. Meta retired the BRAND_AWARENESS optimization goal in favor of AD_RECALL_LIFT for the same estimated-ad-recall measurement; this product now writes the current goal so execute_campaign no longer fails with “Performance goal isn’t available.”

​

5.242.0 — August 21, 2026 at 7:17 AM UTC

• Before using Meta Engagement — Facebook Event Responses, confirm in Meta
• that your connected ad account can access an authorized Facebook Page that
• owns an upcoming, promotable Event. In connected Meta buying, choose the
• product, then select the Event you want to promote. Interchange creates the
• campaign paused, optimizes for Event Responses, and verifies the Event, Page,
• and creative bindings in Meta before leaving the campaign live. If any check
• fails, Interchange reports the failure without leaving a new campaign behind.
• Existing Meta buys do not change. Sellers do not need to take action.

​

5.241.0 — August 21, 2026 at 6:26 AM UTC

• Advertiser creation now accepts an Idempotency-Key header, so safe retries within 24 hours return the original advertiser instead of creating a duplicate. Reusing a key with a different request returns a conflict.

​

5.240.0 — August 21, 2026 at 5:38 AM UTC

• Before using Meta Sales — Facebook or Instagram Shop Purchases, confirm in
• Meta that your connected Page has an active Shop with commerce merchant
• enabled. In connected Meta buying, choose the product and select the Page
• hosting that Shop. Interchange creates the campaign paused against Meta’s
• automatic on-site purchase setup, then verifies the Shop destination, Page,
• purchase event, and automatic bidding in Meta before confirming the buy. If
• any check fails, Interchange reports the failure without leaving a new
• campaign behind. Existing Meta buys do not change. Sellers do not need to take
• action.

​

5.239.0 — August 21, 2026 at 5:29 AM UTC

• Pinterest preview_creative now returns Pinterest’s expiring shareable link for a saved creative with one verified assignment in the selected ad account. Interchange checks the account, ad group, Pin, ad, and placement before returning URL-only output; unsynchronized or ambiguous creatives fail closed, and no transient or approximate fallback is used.

​

5.237.4 — August 21, 2026 at 4:59 AM UTC

• Resetting a demo storefront now also restores its pricing currency to the profile default, so sample products can’t be hidden from buyers by a stale currency setting.
• On both buyer and seller account-settings screens, existing organization-owned service keys continue to work and remain visible for migration and revocation, but API access settings no longer offer new service-key creation. Buyer and seller admins should create a user API key for new integrations.

​

5.237.3 — August 21, 2026 at 3:12 AM UTC

• Fixed resetting a Demo Storefront that had already processed sandbox trades: it could fail with an internal error instead of completing. Resetting refreshes the sample inventory and settings in place — your exchange history and any real activity are preserved, never deleted.
• Deleting a demo storefront that has real activity now either completes cleanly or tells you specifically what still depends on it. Most activity (like notifications) is cleaned up automatically. If the demo holds live commitments — a booked buy’s currency lock, an active adapter canary, or a provider capability attachment — the delete is refused with a message naming each one; those are safety locks on real obligations, and our support team resolves them with you rather than the delete silently destroying them.

​

5.237.2 — August 21, 2026 at 12:55 AM UTC

• Storefront delivery reporting now catches up automatically after a brief reporting interruption, instead of permanently showing zero delivery for the days it missed. If your reporting connection has a temporary gap, the next successful update backfills up to 14 days of missed data on its own — nothing to do on your side.
• If your Meta Engagement — Video Views campaign was failing to launch with an upstream error, that’s fixed. Nothing to change on your side — existing campaign setups will go through on the next attempt.

​

5.237.1 — August 21, 2026 at 12:31 AM UTC

• Fixed Meta Estimated Ad Recall media buys failing to launch with “Performance goal isn’t available.” These campaigns now send the required Facebook Page to Meta, and a media buy without an authorized Page for this goal now fails fast with a clear error instead of silently submitting a request Meta always rejects.

​

5.236.3 — August 20, 2026 at 10:31 PM UTC

• Disabling a sales-agent inventory source now stays disabled. Previously, a background reconciliation job could silently reactivate a manually disabled source within a couple of minutes with no error or signal to the seller.

​

5.236.0 — August 20, 2026 at 9:25 PM UTC

• Nothing changes until Sellers is enabled for your buyer account. Every enrolled
• buyer receives the complete workflow; the existing widget rollout only controls
• whether it uses the current or refreshed visual treatment.
• For smaller buyer teams, Sellers provides one place to browse the network and
• see which sellers are available, how billing works, and whether each advertiser
• is active. Account-wide changes require confirmation.
• For agencies and enterprise buyers, the workspace separates account policy from
• per-advertiser activation. Agent-auth sellers support Automatic, All
• advertisers, or Off. Manual platforms expose account linking, reconnection,
• confirmed removal, reusable advertiser mappings, and preserved mapping history.
• For technical teams and buyer agents using the v3 preview, the seller noun
• exposes the same canonical selection, billing, and activation state through
• search and get. The Sellers page supports the commercial and authorization
• changes that require an interactive workflow.
• This release does not add a fee or change packaging. Direct billing acceptance
• applies to current and future advertisers. Consolidated media appears on your
• Interchange invoice. Billing becomes read-only when Interchange dispatches the
• first eligible advertiser activation; changing a locked policy requires a
• future migration process.
• Sandbox advertisers remain clearly labeled and can be created from advertiser
• setup. This is a buyer-only workspace change; sellers do not receive a new
• surface or required action in this release.
• Demo storefronts now transact and show their sample products to buyer agents without any manual setup. Previously a freshly-created demo storefront could stay blocked from transacting because its Discovery Card (description, channels, countries) was never filled in, so a buyer’s request failed outright. Demo storefronts’ sample inventory availability window now refreshes on every create, reset, and lease extension, so an actively-used demo never ages out — instead of carrying a fixed calendar date that would eventually expire. Every synthetic sample publisher a demo declares — including a Mixed Publisher demo’s second publisher domain — is also now registered the same way a real publisher is, so the seller-side inventory-readiness view no longer reports any of them as blocked.
• Existing account-owned and legacy API keys keep working until you rotate or
• revoke them. New keys follow the creating user’s current access within the
• organization selected at creation, so role and resource changes carry through
• without another key rotation. A read, write, or admin permission level can
• narrow access further. Organization admins can review and revoke user-owned
• keys. For long-running integrations, create the key from a dedicated service
• user.
• This applies equally to buyers and sellers: buyer automation follows buyer and
• advertiser grants, while seller automation follows its seller and storefront
• grants. Each account remains a separate organization boundary, including linked
• parent and child accounts.
• There is no pricing, packaging, or billable-surface change. The feature ships
• ungated because it narrows authorization for newly created keys while preserving
• every existing key as a rollback path. Expansion requires successful staging
• checks for member self-management, administrator review, read/write/admin denial,
• membership removal, cross-organization denial, and revocation; the kill switch is
• to revert the new-key widget/default path while leaving existing credentials live.
• Adoption is measured when a member opens the user-key widget and when a user-owned
• key first authenticates a REST or MCP request. Success requires the motivating
• integration to complete an end-to-end staging call, read keys to be denied writes,
• and membership removal or key revocation to take effect without cross-organization
• access.
• Storefront test campaigns now keep product discovery on the selected inventory source and send the verified advertiser domain to that source.
• Try a brief now opens the full story-first proposal. Practice runs were composing the pitch and then dropping it, so the opened pass showed only the plain product view — the pitch your practice run composes is now saved with it.

​

5.234.0 — August 20, 2026 at 4:55 PM UTC

• Meta lead campaigns bought through Interchange can now run Meta’s own
• Advantage+ automation as a state of your existing campaign, instead of a
• separate product. This applies to every executable lead destination:
• Instant Form, website, Messenger, Instagram Direct, WhatsApp, and calls.
• If you already run any of these, nothing changes: there’s no new setting
• to configure, and this only takes effect once Interchange turns it on for
• your account.
• When it’s on, Meta can manage your campaign budget automatically and
• expand delivery beyond the audiences you selected. Your Page, lead event,
• destination, creative, country targeting, and audience exclusions don’t
• change — country targeting and exclusions stay hard limits Meta won’t
• cross, so compliance and brand-safety rules you’ve already set still
• hold. Included audiences become a starting point Meta expands from, not a
• ceiling. If you compare this campaign’s cost per lead or lead volume
• against a manually run one on another seller, expect a difference: that’s
• the audience expansion, not a setup error.
• Interchange creates every campaign paused and only launches it once Meta
• confirms the automation matches exactly what was requested. If it
• doesn’t match, Interchange removes the campaign rather than running it
• misconfigured.
• This ships as a staged, per-account rollout, expanding as we confirm
• Meta’s automation readback keeps matching the request across more
• accounts; if the match rate holds, we widen to the remaining accounts.
• Accounts not yet enabled keep today’s manual behavior — no action
• needed.
• This is a buyer-side change only: it doesn’t change anything a seller
• sees about their storefront, campaign readiness, or automation state, and
• it doesn’t change what a buyer sees about a seller’s storefront or
• inventory either. Pricing, fees, and packaging for every Meta product
• stay exactly as they are today — this is a capability change, not a
• monetization change.

​

5.233.3 — August 20, 2026 at 3:22 PM UTC

• If your storefront routes buys through AdsWizz, FreeWheel, or SpringServe: a metric your delivery reporting couldn’t confirm against the source’s own per-day figures (for example clicks, when a source states it for the period but omits it from the per-day breakdown) could still show its old, possibly inflated value alongside an already-corrected spend or impressions figure — this is now fixed, and no action is needed on your part.
• Buyers will now see that specific metric as blank rather than a number that can’t be trusted, while spend and impressions for the day remain correct.
• Sellers/operators will see the same clearing behavior on a storefront overview’s realized margin for a metric irrelevant to a package’s pricing model (for example clicks on a CPM package) — it is left at its original value there, since it was never part of what the ledger books and clearing it would only discard informational context for no reason.

​

5.233.2 — August 20, 2026 at 2:44 PM UTC

• The Media Buys page on your storefront no longer offers a clickable timeline for buys that live only in your ad server — those that were trafficked directly and never routed through Scope3. The row still shows the buy and its ad-server id so you can find it on your side, and calls out that its full history is in the ad server, instead of opening a timeline that reads “No buy with id X exists on this storefront.”
• If your storefront routes buys through AdsWizz, FreeWheel, or SpringServe: a single reporting day’s spend and impressions could show an inflated multi-day total mislabeled as that one day’s figure — this is now fixed, and no action is needed on your part.
• Buyers will now see the correct spend and impressions for each reporting day in your delivery reporting.
• Sellers/operators will see a day’s contribution to your storefront overview’s realized margin clear rather than stay wrong when the source’s own per-day figures can’t confirm it — including a day an earlier report already booked incorrectly. A cleared day is not something you need to fix; nothing is required on your part.

​

5.233.1 — August 20, 2026 at 1:20 PM UTC

• Meta creative preview staging proofs now validate the AdCP 3.1 response envelope emitted by the SDK while retaining strict account, identity, and URL safety checks.
• When Meta rejects “Meta Sales — Maximize Website Conversion Value” because your ad account isn’t yet eligible for value-based optimization, create_media_buy now tells you exactly why instead of a generic upstream failure. Meta unlocks this optimization goal once an account has been actively advertising for several weeks, or once its business is verified — use “Meta Sales Campaign” in the meantime.
• Fixed Meta Estimated Ad Recall media buys failing to launch. These campaigns now always run with Meta’s required automatic bidding for this optimization goal, instead of failing when a fixed CPM price was selected.
• Documentation is now organized around using Interchange or building an
• integration, instead of exposing buyer, seller, and API surfaces as separate
• top-level products. The developer section keeps v2 as the stable default and
• adds the enrolled v3 preview to its version picker. The preview now has a
• dedicated quickstart, concepts, buyer and seller workflows, tool catalog, and
• limitations reference instead of one long implementation guide.

​

5.232.4 — August 20, 2026 at 11:46 AM UTC

• Sellers with a connected advertising platform can now see that platform’s complete wholesale catalog on the Storefront Products page and in GET /api/v2/storefront/products, alongside products from managed ad-server sources. These products become visible to buyers after the first complete catalog read. Existing pricing, policies, and connection settings still apply, and no seller reconfiguration is required. See the Storefront product composition guide for how products from connected sources are combined.
• Buyer agents using a valid provider OAuth credential can now call get_products with buying_mode: "wholesale" to read the seller’s complete direct-platform catalog. Brief and refine behavior, account-scoped product IDs, and authorization for write operations do not change. See the wholesale catalog and pricing guide for the buyer-facing contract.
• Routed media buys now keep attributing delivered spend to the correct seller after a seller connection is upgraded. Buyers regain complete reporting for delivery temporarily recorded under an older buy identifier without double counting overlapping days; sellers do not need to take any action.

​

5.232.3 — August 20, 2026 at 9:39 AM UTC

• Meta creative preview checks now recognize completed platform responses, so valid rendered previews can finish verification successfully. No action is required from buyers or sellers, and creative publishing and delivery are unchanged.

​

5.232.1 — August 20, 2026 at 8:28 AM UTC

• When you pause or unpause your storefront, buyers now see the change within
• seconds instead of waiting for a background re-check. Previously, a busy
• re-check queue could leave buyers seeing your storefront as unavailable for
• hours after you opened it.
• Meta creative preview checks now verify the platform-rendered output before it reaches buyers, protecting the review experience from broken previews. Sellers’ creative continues to preview correctly for buyers, and creative publishing and delivery are unchanged. No action is required from buyers or sellers.

​

5.232.0 — August 20, 2026 at 6:50 AM UTC

• Your proposal now reads like a pitch, not a spec sheet. When your agent
• composes a pitch, the proposal pass opens with what the buyer asked for, why
• you’re the right seller for it, the plan built around that argument, proof
• from your own case studies, the terms, and the ask — in that order. Product
• rows lead with the reasoning your agent gave for including them, with price
• and delivery terms right behind. A brief with no matching case study says so,
• plainly — no stand-in, no near-miss example. Buyers see no change from this
• release — the proposal your agent sends them is exactly what it was; this
• changes how you read it.
• You can also try it yourself: paste a brief on the product marketing (Teach)
• page and run a practice pitch to see your storefront’s story-first proposal
• before a real buyer ever sends a brief. It opens right away so you can read
• it. Practice runs are tagged as practice — never billed, never sent to a
• buyer, and never shown in your demand inbox alongside real buyer activity.

​

5.231.0 — August 20, 2026 at 6:13 AM UTC

• Buyer account administrators can now save an account-wide include or exclude
• preference for one exact Storefront. Scope3 also records why a qualified
• Storefront is selected by default, including its Premium Publisher setting or a
• seller market-maker entitlement. These selection decisions do not activate
• accounts, spend money, or accept billing terms; connection setup and any
• required billing, linking, or mapping action ship separately.
• Seller operations teams can see when a qualified Storefront is selected by
• default because Scope3 marks it Premium Publisher or grants the seller
• market-maker authority. No seller action is required in this release.
• Monetization impact: none. This release records selection intent only and does
• not change packaging, fees, billing eligibility, or account activation.
• Rollout: this control plane ships ungated because the buyer mutation is
• authenticated and reversible, while downstream activation remains disconnected.
• Expansion to activation requires a separate reviewed release. The kill switch is
• to keep activation apply mode disconnected and stop the selection reconciliation
• job; durable queued work remains retryable when processing resumes.
• Adoption is measured by distinct buyer accounts that set an override in the
• durable selection audit history. Rollout health is measured by desired-edge
• outbox transitions, zero failed or stale reconciliation events, and zero
• selection-reconciliation Sentry errors before activation expands.
• Murph report assessment and confirmation exchanges no longer consume filing
• quota before a report is actually submitted, preventing ordinary back-and-
• forth from producing repeated throttling messages. When the separate 24-hour
• runaway cap is reached, Murph now gives a reset time after the complete usage
• window has expired instead of a potentially premature retry time.

​

5.230.0 — August 20, 2026 at 5:50 AM UTC

• Buyer product discovery now keeps safely persisted products available when a different seller/source identity cannot be persisted. Unsafe products and proposals are withheld with a bounded storefront diagnostic; a total persistence failure remains retryable instead of looking like an empty catalog.
• Sellers do not need to take action. Buyers may now see that bounded diagnostic when a seller’s inventory is incomplete instead of seeing the storefront as empty.
• OAuth refresh retries from one expired session no longer block other integrations on the same shared network. Nothing needs to change on your side.
• The note under each selling point on your marketing page now tells you how your agent will present that line to buyers. A selling point from your website is carried as your own claim, in your words; a quoted line names the material it came from. And when a selling point states a number with no source, the page suggests adding one — “per Comscore, March 2026” — so the claim reaches buyers with attribution behind it.

​

5.229.5 — August 20, 2026 at 4:09 AM UTC

• Campaign search and list now correctly return campaigns that predate advertiser-linking, instead of silently excluding them from every advertiser-scoped result. Reading one directly by id already worked; it just couldn’t be found through search.

​

5.229.4 — August 20, 2026 at 3:47 AM UTC

• Snap brief-mode discovery now explains why 0 products were returned. When a brief targets multiple countries or no country, the product group description includes an actionable message (e.g. “Snap campaigns target one market at a time. Retry discovery with a single country.”) instead of the generic “No matching products from Snap.”

​

5.229.3 — August 20, 2026 at 3:26 AM UTC

• Fixed reporting for a small number of media buys where delivery data could not be denominated into a reportable currency because settlement-currency records were missing or incorrect. Nothing to change on your side — reporting for the affected buys should now return normally.

​

5.229.2 — August 20, 2026 at 3:04 AM UTC

• search(kind:"advertiser") no longer silently returns an empty list when your search text doesn’t happen to match an advertiser’s name — the response now says the name filter matched nothing and tells you to omit it to see every advertiser you have.
• request_proposals and save_media_buy now declare a machine-readable output schema, so MCP clients can validate and surface the structured product, pricing, and media-buy data these tools return instead of falling back to a bare text summary.

​

5.229.1 — August 20, 2026 at 1:51 AM UTC

• After sellers complete a no-spend test campaign, their storefront and products
• now become visible to buyers promptly instead of waiting for a background
• refresh. No action is required from buyers or sellers, and storefronts that are
• paused, archived, or still missing setup requirements remain unavailable.

​

5.229.0 — August 20, 2026 at 1:36 AM UTC

• Agent owners can now publish a versioned, non-secret connection setup from the
• Agent Page, so every publisher sees the same exact endpoint, protocol,
• authentication, and credential guidance for connecting. Publishing a version
• doesn’t activate any publisher connection — publishers still complete their
• own authorization, credentials, and readiness checks before going live.
• Existing publisher setup keeps using the generic external-sales-agent
• connection contract; it does not yet resolve an owner-published version.
• Referral selection, certification, connection validation, and activation gates
• do not change in this release.
• This feature adds no billable surface or packaging change and is available at
• no incremental charge to customers enabled for the Agent Page.
• Responses from Demo Storefronts (Scope3’s synthetic, disclosed sample
• inventory used for demonstrations) now carry demo: true and a
• demo_disclosure sentence in get_products, so your agent can tell sandbox
• inventory apart from a real seller’s and avoid acting on it as a genuine
• offer. The disclosure also appears in the response’s human-readable summary
• text.

​

5.228.0 — August 19, 2026 at 11:35 PM UTC

• Make a storefront available to buyers immediately after its successful transaction validation is recorded, without waiting for the eligibility cache’s periodic refresh.

​

5.227.2 — August 19, 2026 at 11:09 PM UTC

• MCP connections no longer drop every four minutes. The load balancer in front of the API capped any single response at 240 seconds — counted from when the request started, whether or not data was flowing — so a long-lived MCP stream was severed on the clock and a tool call that ran past four minutes lost its result with nothing to show for it. Keep-alive traffic never helped, because the limit was never about idleness. MCP traffic now has its own limit of 30 minutes, while ordinary REST calls keep the shorter one.

​

5.227.1 — August 19, 2026 at 10:42 PM UTC

• Product selection and campaign staging now use the exact pricing option in the
• buyer’s current discovery result, so a separate catalog refresh cannot reject a
• fresh selection as stale. Older result sets continue to use current catalog
• validation until discovery is run again.
• Seller applicability: not applicable — seller storefront setup, catalog
• visibility, and settlement configuration do not change. Buyers continue to see
• and select the price the seller returned for that discovery result.

​

5.227.0 — August 19, 2026 at 9:58 PM UTC

• Fixed update_media_buy failing on media buys whose inventory is bought through a storefront. Editing budget, flight dates, packages, or creatives on one of these buys returned a server error, and although the change was recorded on your buy it was never sent to the seller — so it sat pending indefinitely. These updates now reach the seller, and stored creative assignments are carried across correctly. Both the REST endpoint and the buyer MCP tool are fixed, along with campaign edits that update a media buy.
• If you have a pending change on one of these buys that never took effect, resubmit it.
• New modular-source storefronts can complete their first no-spend test while readiness finishes updating, instead of timing out before inventory discovery. Nothing changes on your side.

​

5.226.0 — August 19, 2026 at 9:10 PM UTC

• Release validation for Meta creative previews now verifies the already-synced creative on the selected ad account without creating or changing ads. Buyer preview behavior is unchanged.

​

5.224.1 — August 19, 2026 at 8:06 PM UTC

• Meta creative previews now reject authorization-shaped query values when spaces use standard URL form encoding or a literal plus. Ordinary non-authorization literal-plus values remain accepted. No buyer action is required.

​

5.224.0 — August 19, 2026 at 7:38 PM UTC

• MCP connections are no longer cut mid-call when we deploy. Previously a deploy gave every connected client a fixed 15 seconds before closing its connection, so any tool call still running — a product discovery sweep, a campaign creation — was severed and surfaced in Claude or ChatGPT as “MCP server connection lost”. A deploying server now waits for in-flight tool calls to finish, on the same allowance long-running discovery already had, and hands your event stream to a healthy server up front so your client reconnects instead of waiting on one that is going away.
• If a legacy advertiser’s brand update was blocked by mixed terminal-campaign currencies, retry the update with primaryCurrency set to the intended historical currency. Active campaigns and current seller-account links still prevent incompatible currency choices; do not create another advertiser to bypass the repair.

​

5.223.0 — August 19, 2026 at 6:57 PM UTC

• Meta website campaigns bought through Interchange can now run Meta’s own
• Advantage+ automation as a state of your existing campaign, instead of a
• separate product. If you already run Meta website conversion,
• conversion-value, or catalog campaigns, nothing changes: there’s no new
• setting to configure, and this only takes effect once Interchange turns it
• on for your account.
• When it’s on, Meta can manage your campaign budget automatically (the same
• Advantage+ campaign budget behavior you’d see in Ads Manager) and expand
• delivery beyond the audiences you selected (Advantage+ audience and
• placements). Your Pixel event, Page, creative, country targeting, and
• audience exclusions don’t change — country targeting and exclusions stay
• hard limits Meta won’t cross, so compliance and brand-safety rules you’ve
• already set still hold. Included audiences become a starting point Meta
• expands from, not a ceiling. If you compare this campaign’s reach or cost
• against a manually run one on another seller, expect a difference: that’s
• the audience expansion, not a setup error.
• Interchange creates every campaign paused and only launches it once Meta
• confirms the automation matches exactly what was requested. If it doesn’t
• match, Interchange removes the campaign rather than running it
• misconfigured.
• This ships as a staged, per-account rollout, expanding as we confirm
• Meta’s automation readback keeps matching the request across more
• accounts; if the match rate holds, we widen to the remaining accounts.
• Accounts not yet enabled keep today’s manual behavior — no action needed.
• This is a buyer-side change only: it doesn’t change anything a seller
• sees about their storefront, campaign readiness, or automation state, and
• it doesn’t change what a buyer sees about a seller’s storefront or
• inventory either. Pricing, fees, and packaging for every Meta product stay
• exactly as they are today — this is a capability change, not a monetization
• change.

​

5.222.0 — August 19, 2026 at 6:28 PM UTC

• Your storefront test campaign can now launch immediately after setup, even while its readiness status updates. You do not need to change anything, and regular buyers remain blocked until setup is complete.
• Reporting can resume for one older media buy after its seller updates how it
• authenticates reports sent to the existing callback. Buyers do not need to
• change anything. Only the seller for this media buy needs to update the
• callback; all other media buys and reporting paths are unchanged.

​

5.221.0 — August 19, 2026 at 5:35 PM UTC

• Buyers can now discover and select all compatible creative formats from seller
• catalogs that publish both legacy and current SDK representations. Previously,
• compatible formats could be withheld when one representation included extra
• options. Existing legacy identifiers are still forwarded to the seller, and no
• seller action is required.
• Before using Meta Sales — Website Catalog Sales, confirm in Meta that your
• connected ad account is owned by a Meta Business Portfolio and has access to a
• commerce catalog with at least one non-empty product set, a Pixel/Dataset, and
• a Facebook Page. You also need an HTTPS destination and creative. In connected
• Meta buying, choose the product, then select the catalog and one of its
• non-empty product sets. Interchange keeps optional audience signals and
• targeting overlays separate from the product, creates the campaign paused, and
• verifies the catalog relationship, product set, identity, destination,
• optimization, and measurement setup in Meta. If any check fails, Interchange
• reports the failure without leaving a new campaign behind. Existing Meta buys
• do not change. Sellers do not need to take action.
• get_products calls that hit the default wait budget before every storefront finishes now return a normal, pollable page marked incomplete instead of an error. Poll again with the same ext.interchange.execution_id to pick up the rest; nothing to change on your side.
• A background catalog refresh that returns nothing now leaves your existing products in place instead of emptying your catalog and blocking your storefront from transacting.
• Media buy create and update requests now return a clear error when a selected inventory source cannot verify that it will apply exact state or province targeting, instead of accepting and ignoring the setting. Buyers can remove geo_regions and geo_regions_exclude or choose a product whose source supports the requested regions.
• Seller impact: no action is required. Sources without verified exact-region support will reject these requests until that support is available.

​

5.220.0 — August 19, 2026 at 3:37 PM UTC

• Storefront account synchronization now reports an explicit version error when a buyer sends AdCP 3.2 account-identity fields to a storefront that supports only AdCP 3.0 or 3.1. Integrations should read the storefront’s advertised capabilities and omit those fields for older versions.
• This release applies to buyer teams building direct API or agent integrations, including hands-on builders and agency platform teams. Enterprise brand and chat-only buyers do not need to change their workflow unless they maintain one of those integrations. Seller configuration and buyer-visible storefront ranking, labels, and inventory presentation do not change.
• Reporting now tells you honestly when it cannot denominate spend, and names the media buys involved. When one or more media buys have delivery spend with no resolvable currency, GET /api/v2/buyer/reporting/metrics returns the new SPEND_DENOMINATION_UNRESOLVED error (HTTP 422, recovery terminal) instead of FX_RATE_UNAVAILABLE (HTTP 503, recovery transient). The old response advised “retry after a short wait” for a failure that is deterministic and reproduces on every call, and reported only a count — so there was no way to tell which buys to ask about. The error message now names the affected media buy IDs directly, alongside details.mediaBuyIds and details.unresolvedCount, and its suggestions tell you to exclude those buys to keep reporting on the rest of the account.
• FX_RATE_UNAVAILABLE keeps its original meaning — the exchange-rate feed could not price a currency pair — and remains a retryable 503. If you branch on error codes or auto-retry 503s from this endpoint, update that handling: this condition is now a 422 you should surface rather than retry.
• With a connected Meta ad account, self-serve buyers, agencies, and enterprise
• teams can now choose Post-install Event or Maximize In-app Value for an
• app campaign. Interchange lists the exact apps and events Meta authorizes for
• that account and verifies the same selection after creation, so teams can use a
• governed account choice without copying provider identifiers. Existing
• app-install buying and seller storefronts are unchanged. Before using value
• optimization, make sure the event sends value and currency through the Meta SDK
• or your measurement partner; otherwise, no setup changes are required.
• Responses in the agentic setup and discovery chat are now shorter by default. The assistant leads with the answer — the ID, the status, or the blocker — and stops, instead of wrapping a one-line result in extra paragraphs of caveats and commentary. Ask for detail and it still gives you the exact steps or the full breakdown. Nothing to change on your side.

​

5.219.0 — August 19, 2026 at 2:25 PM UTC

• create_media_buys now accepts per-product optimizationGoals when selecting a product. For Meta Lead Generation, this lets you set the “Maximize number of leads” performance goal at creation time — matching what Meta Ads Manager itself offers for that goal, without needing a performance-mode campaign. “Maximize number of qualified leads” and a cost-per-result bid target are not yet available through this field.
• Buyers now receive safe, stage-specific errors from the Meta preview_creative API and MCP operation when a read-only creative preview cannot complete, instead of an opaque validation failure. Successful creative previews and default preview behavior are unchanged. If an existing Meta connection cannot validate Instagram access, an account admin must reconnect it; otherwise no buyer action is required.
• Seller impact: not applicable. This change has no seller-visible effect on storefronts, ranking, rendering, labeling, inventory, or workflows.

​

5.218.0 — August 19, 2026 at 1:51 PM UTC

• Buyer accounts using WorkOS org API keys can now list their own advertisers via search(kind:"advertiser"). Previously, these tokens returned an empty advertiser list even when advertisers existed — the scoping function did not recognise buyer tokens without a user identity (full_access permission or userRole), silently returning no accessible IDs and short-circuiting the database query.
• The duplicate-advertiser conflict message now names the conflicting advertiserId, giving you a concrete value to look up via whichever surface you’re on, instead of a dead end.
• get(kind: "campaign") now states budget, flight window, brief, and advertiser id in its response text, so a buyer agent can verify what a prior save_campaign actually persisted instead of taking the creation response’s word for it. Passing an include that doesn’t apply to a campaign (e.g. diagnostics) is now reported back rather than silently dropped.
• Buyer setup now preserves each seller’s last verified availability when a marketplace-wide readiness refresh runs longer than its deadline, instead of incorrectly showing that seller as unavailable. Completed current checks still take precedence, and buyers do not need to take any action.
• Agents using the V3 buyer surface now correctly surface product names, pricing, and formats returned by request_proposals instead of dead-ending at a bare count. The V3 buyer skill document teaches agents to read structuredContent.perSeller[].products and present the full product list to the user before staging a media buy.

​

5.217.0 — August 19, 2026 at 12:47 PM UTC

• RFC 9421 identity-signed delivery reports sent to previously issued third-party seller callback URLs now continue through the seller’s current storefront route, so reporting stays current after a seller source is re-registered or migrated.

​

5.216.1 — August 19, 2026 at 12:31 PM UTC

• Meta Traffic, Video Views, and App Installs campaigns now default to impression-based billing instead of an outcome-based billing model (clicks, ThruPlay, or installs) that Meta only allows on ad accounts that have cleared its spend/eligibility threshold. Buys on new or unaged ad accounts no longer fail with a generic “Billing Option Not Available” rejection.
• Campaign search now tells you when results are limited to non-terminal campaigns (draft, active, paused) and how to see completed, canceled, or archived ones too — so an empty or short result is never mistaken for “no other campaigns exist” under an advertiser.
• When one of your inventory sources goes quiet or recovers, Murph’s note in your
• channel now names the source the way you named it, instead of showing an
• internal identifier. Nothing to change on your side.
• Completed creative and media-buy reviews now leave the approval queue in a consistent decided state. Previously stuck reviews return to the queue for an explicit decision; nothing changes in the seller review workflow.

​

5.215.0 — August 19, 2026 at 10:39 AM UTC

• Meta creative previews now reject mismatched Facebook Page and Instagram
• identities before contacting Meta and return safe errors when Meta cannot render
• a preview. No buyer action is required.
• “Continue setup” on a modular inventory source now opens the step the checklist
• names — importing an avails feed, resolving the Property Roster, or setting a
• Playbook or acceptance policy. It previously reported “That source did not open.
• Try again.” The Discovery Card opens from this checklist again too.
• You can now send raw email addresses and international phone numbers to the v2 audience-sync API. Interchange normalizes and SHA-256 hashes email and phone values at the API boundary; existing pre-hashed inputs continue to work and are canonicalized to lowercase. Requests fail when supplied raw and hashed values do not match. Existing integrations that send valid hashes do not need to change.

​

5.214.1 — August 19, 2026 at 8:19 AM UTC

• Improved the reliability of large property-list creation under load.

​

5.214.0 — August 19, 2026 at 7:33 AM UTC

• Partners enrolled to operate sales agents for clients can now invite a publisher from Partner, monitor each authorized Source’s setup, health, products, and active campaigns, and open Source-scoped delivery reporting. Partner administrators can see operational status but cannot enter the publisher’s account or read its secrets.
• Invited publishers sign up or sign in to their own organization, choose the exact Source to authorize, and complete their own credentials and payout setup. The invitation creates no account or Source, and authorization never bypasses Agent certification or grants the Partner access to another publisher Source.
• The client-operations workspace is packaged behind the paid operate-agents-for-clients entitlement or an explicitly approved, time-bounded beta; referrals do not add a separate fee or change publisher payout economics. Initial exposure is limited to entitled design partners and can be stopped by revoking or expiring that entitlement without deleting publisher-owned Sources or consent history.
• Launch measurement follows the referral send → publisher acceptance → exact-Source authorization → Partner acceptance → validation → activation funnel, including conversion, p50/p95 completion time, reporting use, rejected cross-Source replays, and delivery failures. Expansion requires every completed referral to remain tied to one exact Source and zero cross-organization authorization or secret-exposure incidents.
• Billing periods in Plan & Billing → Usage & Credits now display as “August 2026” instead of the raw “2026-08” string. No action needed — the numbers and your balance are unchanged.
• OAuth setup for external sales agents is now safer and easier to recover.
• Set or change an OAuth audience. When registering a new inventory-source
• identity or updating an existing source, set oauthAudience only when the
• agent gateway does not publish a public OAuth audience. Open the authorization
• link returned by the source request to finish consent.
• If an update succeeds without returning a link, send the same source update
• again. The audience is already saved, and the retry starts a new consent flow.
• If a new OAuth identity is registered without a link, call the Storefront REST
• API’s Start agent OAuth operation at
• POST /api/v2/storefront/agents/{agentId}/oauth/authorize, then open its
• authorization link.
• Keep OAuth credentials in the consent flow. Do not send auth when a
• source create or update uses OAUTH or NO_AUTH; those requests now reject
• the field. For OAuth, set oauthAudience only for the gateway case above, then
• use the returned authorization link.
• If the seller updates an OAuth source while agent-level consent is open,
• discard the old link and use the link returned by the latest source update. If
• that update returns no link, retry it. If a per-account consent flow was open,
• discard its old link and repeat the Buyer REST API’s **Register source
• credentials** request at
• POST /api/v2/buyer/storefronts/{storefrontId}/sources/{sourceId}/credentials.
• Use the same accountIdentifier, omit auth, and open the new authorization
• link. This replaces only the existing PENDING consent attempt; active
• credentials remain unchanged.
• Read source-version diagnostics. Diagnostics now explain that an AdCP
• 3.0-only agent can still answer live buyer briefs, but its products remain out
• of the Interchange component catalog until its server supports AdCP 3.1. If
• catalog warming reports VERSION_UNSUPPORTED, upgrade the agent server.
• Who this affects. The primary audience is sellers configuring external
• sales agents. A buyer or operator is affected only when their per-account
• consent is already open as the seller changes that source’s OAuth setup; they
• must repeat Register source credentials for that source. Existing valid
• sources and requests need no changes. Normal buyer-agent API contracts,
• storefront discovery, and buying results are unchanged.
• Your billing rates are now easier to find. Buyer media billing rates (public list and effective rate by billing type) are shown in the dedicated Media Billing tab, and seller rates are shown in the Plan & Pricing tab — so each rate type lives in one canonical place with no duplicates. Your actual rates have not changed; only where you find them in the UI has.
• The Plan & Billing page no longer shows contradictory next-action states. Previously, the top banner could say “No action needed” while the Plan & pricing tab simultaneously showed a pending action (such as “Select plan”) for the same account. Both surfaces now derive from the same authoritative signal and always agree. The duplicate “Next action” label in the Account standing card has also been removed.
• Meta preview_creative reliability checks now validate all three Facebook and
• Instagram preview links when a connected ad account has multiple eligible Pages
• or Instagram profiles. No action is required: standard previews still ask for
• an identity when the choice is ambiguous.
• When Murph says it did not find something, it now tells you where it looked.
• Murph’s tools reach your account, your requests, and the product
• documentation — a slice of the answer space, not all of it. A miss in that
• slice used to come back sounding final: “there is no such feature.” Now it
• comes back scoped — “nothing in the documentation I searched” — so you can
• tell the difference between not here and nowhere.
• When the answer sits somewhere Murph cannot reach, it says so and points you
• at what can answer instead of reporting an absence.

​

5.213.12 — August 19, 2026 at 5:59 AM UTC

• No action is required. When comparing Reddit Ads options, buyers now see whether
• each product delivers toward impressions or clicks, so teams can choose media
• and measurement plans without mistaking conversion-intent traffic for
• purchase-optimized delivery. App and community traffic also show their click
• delivery boundary.
• Dynamic Product Ads prospecting and retargeting will not be offered until the
• integration can verify catalog setup, purchase measurement, creative,
• placement, and Reddit’s saved campaign configuration. Hands-on buyers receive a
• clear setup boundary instead of an option that cannot be created. Seller
• storefronts and what buyers see about sellers are not affected.
• Fixed Meta Traffic (LINK_CLICKS) ad-set creation so it no longer fails with a “Promoted Object Invalid” error when the buyer doesn’t select a specific conversion event.
• Buyer product discovery can now return its fast partial page when you ask for a short wait. A get_products request carrying a small wait_seconds or time_budget (under about three seconds) could fail with an internal error instead of the documented first wave, because the request’s own guard expired before the partial page was assembled. Short waits can now return results_complete: false with pending_agents; sellers that finish before the original buyer deadline may appear in later revisions. Seller-facing deadline calculation is unchanged: each seller receives only the remaining portion of the buyer’s original budget at dispatch.
• TikTok product discovery now stops before product selection when a brief asks for unsupported audience exclusions, unresolved interest targeting, unverified creative localization, or instruction-like prompt text. The response lists the clarification needed. Smart+ Website and Catalog products remain unavailable until the selected account proves eligible; no setup change is required.
• Temporary contract-verification outages no longer tell organizations to accept Terms of Service. Protected REST requests now return HTTP 503 with SERVICE_UNAVAILABLE, while MCP calls return a retryable SERVICE_UNAVAILABLE tool error. Child-account creation preserves its existing success response contract and returns the same retryable 503 when post-create verification is unavailable; its durable provisioning receipt makes that retry idempotent. Genuine missing-contract and unaccepted-terms states continue returning 403 TOS_ACCEPTANCE_REQUIRED on REST surfaces and the corresponding contract or acceptance-required tool error on MCP surfaces.
• The full-plan proposal card now leads with the composed pitch instead of technical plumbing: sellers reading a proposal (from a demand-inbox row’s “View full plan”) see the storefront’s argument first — or a plain line stating that the pitch is still composing or wasn’t composed, when there isn’t one. Each product row now shows its own name and description before its delivery/rate/price terms. Technical details (artifact IDs, digests, Copy JSON) stay collapsed, one tap away.

​

5.213.11 — August 19, 2026 at 4:28 AM UTC

• Meta Page Likes (meta_engagement_page_likes) campaigns now return a clear pre-flight error instead of failing at Meta’s API, and the product is no longer advertised as executable in product discovery. Meta no longer accepts PAGE_LIKES as an optimization goal for OUTCOME_ENGAGEMENT campaigns (error 100/2490408). Use meta_engagement for general page engagement while a replacement configuration is investigated.

​

5.213.10 — August 19, 2026 at 4:01 AM UTC

• If your support Slack channel was archived, select Slack again in account
• communication settings to restore it. No action is needed for active channels,
• and the setting confirms success only after the active channel binding is
• durably saved.
• Buyer accounts can now open Plan & Billing through v3 to review and complete
• billing setup.

​

5.213.5 — August 19, 2026 at 1:59 AM UTC

• Buyers now get more of their selected discovery time to receive results. Discovery starts the same way as before, with no action required; the faster path will roll out gradually while we monitor reliability.
• Sellers now receive a deadline based on the time actually left when their request arrives. No seller integration changes are required.

​

5.213.3 — August 19, 2026 at 1:06 AM UTC

• Meta creative previews now carry a self-contained read-only staging proof that
• renders the protected creative manifest without relying on mutable saved
• creative state.

​

5.213.1 — August 18, 2026 at 11:42 PM UTC

• Saved Meta creatives now preview from their tenant-scoped ledger identity even
• when the original asset was localized into private storage. Supplied assets
• still require an exact match, and missing identities fail closed.
• Boolean query parameters now preserve false and reject invalid values across
• reporting, service-token, test-cohort, and system-token endpoints. Their
• published OpenAPI types remain boolean. Media-billing uniqueness conflicts now
• cross the transaction boundary, preserving the existing explicit conflict
• response only after rollback, and the shared wrapper rejects callbacks whose
• commit PostgreSQL converted to a rollback. Existing endpoint names, response
• shapes, and accepted true/false spellings are unchanged.

​

5.212.0 — August 18, 2026 at 10:50 PM UTC

• Plan & Billing → Plan & pricing now shows “Not priced yet” for a rate-card activity whose cost is still being measured, instead of rendering “NaN IUs”.
• In Campaign Creative Assets or through preview_creative, buyers can now see the submitted asset and open Meta’s authoritative render before activation. No campaign setup changes are required. Previews stay bound to the selected account, open safely outside Interchange, and fail closed when the creative or placement cannot be verified.
• Delivery reporting now continues for active direct media buys after their seller moves to typed storefront routing. No buyer action is required.

​

5.211.3 — August 18, 2026 at 9:27 PM UTC

• Large property lists now resolve their inventory identifiers through count-,
• byte-, and time-bounded bulk requests, so creating a list with thousands of
• domains no longer depends on one registry request per domain, long identifier
• values do not overflow the bounded registry response reader, and queued lookup
• waves cannot outlive the mutation. Slow or unavailable registry lookups remain
• safe and do not trigger a wave of registration attempts. No request or response
• fields changed.
• Spotify audience discovery now labels provider audiences as non-activatable until campaign targeting supports attaching them. Provider audience inventory remains visible, custom-audience deletion remains available, and no action is required.
• Inventory-source test planning now gives slow but responsive sales agents more time to return products and keeps them testable when a capability refresh fails. Last-known capabilities and successful product traffic are labeled as separate evidence. Nothing changes on the sales-agent side.
• Pinterest video and Standard Pin retries are now safer and easier to reconcile. If an upload or provider read times out, Interchange resumes the same Pinterest media, Pin, and assignment instead of creating duplicates. Creative listings preserve the original format and identity, paginate large accounts, and no longer mistake changing Pinterest rendition details for a changed creative. If Pinterest’s response is uncertain, the creative stays paused and support is alerted; a missing ad is rechecked for 15 minutes before replacement. Generated 2:3 creative remains planned, while ordinary Standard 2:3 Pins remain available. This buyer-side reliability update does not affect seller storefront ranking or exposure. No action is needed.
• Older unchanged pending approvals can now be decided when their historical routing record is incomplete or missing, provided the person deciding is in the storefront’s current eligible approval audience.
• Buyer API and MCP brand updates now repair older advertisers with missing settings instead of returning 404, while preserving currency already established by campaigns or seller accounts. Retry the same v2 update_advertiser or v3 save_advertiser call; no request changes are needed, and advertisers with existing settings are unchanged.

​

5.211.0 — August 18, 2026 at 6:59 PM UTC

• Google Ads Search conversion campaigns can now be tested with one exact website or phone-call event goal. The selected conversion actions must be enabled, primary actions that cover their complete Google category and origin groups; partial groups, value targets, and target CPA remain unavailable. Interchange creates the campaign paused and returns an error unless Google reads back the same advertiser, effective conversion customer, campaign goal, and conversion-action set.
• Responsive search ads and keywords still require a separate creative-sync call, and this change does not make Google Ads Search conversions generally available. Existing campaigns need no action.
• Murph now answers from the whole of what you gave it.
• Ask Murph about a long page, a document you uploaded, or a long Slack thread,
• and it used to receive only the beginning of it — then answer as though that
• were everything. It now gets the whole thing. If something is still too long to
• fit, Murph says its view is incomplete and asks you for the missing part rather
• than guessing at it.
• This applies to Murph wherever you talk to it, in the Interchange app and in
• Slack. There is nothing to change on your side, and nothing about your
• storefront, campaigns, or reporting changes.
• Several v3 agent surface improvements to reduce buyer confusion and agent verbosity:
• Permission prompt titles are now buyer-readable: search shows “Search campaigns, sellers, proposals, and more” (was “Search”) and get shows “Look up a specific item” (was “Get one object”).
• save_advertiser sandbox description now explains the choice in plain language before the buyer is asked to decide, and notes the choice is permanent.
• Tool descriptions for save_campaign, save_advertiser, request_proposals, and save_media_buy are shortened to reduce agent response length. save_campaign now instructs agents to ask the buyer three questions (goal, audience, what is being promoted) before writing the brief, and the brief field notes that null is a no-op.
• When you use product discovery to plan a Snap campaign, complex purchase briefs now keep the exact Snap product, price, currency, targeting, and creative asset selected for execution. If a brief asks for an existing Public Profile post, an audience exclusion that is not available for Snap, or an unsupported placement, it asks you to revise the brief instead of silently choosing a different setup. Nothing changes on your side, and the Snap products available today are unchanged.
• When buyers review a LinkedIn campaign plan, they now see the proposed objective, geography, creative, placement, and required setup before execution. Delivery requests now return an error instead of potentially incorrect totals when LinkedIn’s account or campaign data conflicts with the recorded package; retry after that data is repaired. Existing campaigns need no migration, while Lead Gen activation remains restricted pending signed staging validation.

​

5.210.0 — August 18, 2026 at 3:32 PM UTC

• Meta Lead Generation campaigns that reference an optimization event source which isn’t the account’s authorized Facebook Page now fail with a clear, correctable error instead of a misleading “temporarily unavailable” one. Retrying won’t help here — the event source needs to match the authorized Page before resubmitting.
• Meta Traffic (Landing Page Views) campaigns will now go through. The fix for the missing custom_event_type on this ad set’s promoted object (shipped in #10870) used a value Meta doesn’t accept for that field; the conversion event now maps to Meta’s own closest accepted value. Nothing to change on your side.
• Several v3 buyer surface improvements based on offsite testing:
• request_proposals now includes per-seller detail in the response text: failed sellers show the error code (e.g. PRODUCT_NOT_FOUND), and sellers that return bare products show the product count, the productQueryId needed to call save_media_buy, and a pointer to structuredContent.perSeller for full product details.
• save_campaign now includes the current revision number in the response text so buyers can pass expectedCampaignRevision to request_proposals without an extra round-trip. Required create fields (name, flight, budget) are now validated together and returned in a single error instead of one at a time.
• save_advertiser now explicitly warns when primaryCurrency is omitted (the field still defaults to USD — no existing callers need to change anything). The warning makes the lock visible: primaryCurrency cannot be changed after the first campaign or after any seller account binding, and a EUR budget on a USD advertiser is immediately rejected at campaign creation.
• search with kind: "advertiser" is a new capability: buyers can now list their own advertisers (with optional name filter and cursor pagination) instead of receiving an unsupported-search error.
• Each health check on an inventory source now raises and clears its own “needs attention” item. Previously all checks shared a single item, so one check recovering could clear an item another check’s unresolved problem still justified. A source with two separate problems now shows two items, and each closes when its own problem is fixed.

​

5.209.1 — August 18, 2026 at 12:26 PM UTC

• Meta Traffic (Landing Page Views) and Engagement campaigns will now go through. Traffic ad sets were missing a required conversion-event field on the promoted object; Engagement ad sets were billed on an event type Meta no longer accepts for that optimization goal. Nothing to change on your side.

​

5.209.0 — August 18, 2026 at 12:01 PM UTC

• Existing progressive-discovery clients need no changes. In incomplete initial
• REST discovery and later browse-poll responses, SSE revision events, and
• discovery.revision webhooks, pendingAgents is now always an array; when no
• seller is currently pending it is [] instead of being omitted. Complete
• responses are unchanged.

​

5.208.0 — August 18, 2026 at 11:36 AM UTC

• Older approvals that were already waiting before approver routing was recorded can now be decided by the storefront’s current approvers. An active approver can clear these stale items without resaving the routing rule; approvals still fail closed when no eligible approver exists.

​

5.206.0 — August 18, 2026 at 10:14 AM UTC

• Meta Engagement, Traffic, and Sales campaigns will now go through when interest targeting is configured in the campaign brief. Meta’s ad-interest search results carried extra provider metadata (audience size estimates, taxonomy path) that was being echoed back into the ad set’s targeting spec, which Meta rejects on write. Only the interest ID and name are sent now. Nothing to change on your side.
• When a campaign launch fails because a seller’s media buy cannot be executed, the error now includes the ADCP error code and recovery hint (for example SERVICE_UNAVAILABLE, transient) so the buyer knows whether to retry. Previously the message said only “execution failed” with no actionable detail.
• Meta city targeting now ignores non-city entries returned by Meta’s city search while continuing to require an exact city type, name, and country match and rejecting malformed city data. Nothing changes for buyers whose city targeting already resolved successfully.
• Buyers now see billing status and guidance that match the live payment rails: they can still fix card failures, and Media Billing is clearly labeled preview-only. Sellers now see payout-setup activity drawn only from payout-specific audit events. The Media Billing preview label does not change seller settlement or pay-when-paid behavior; those policies are still being defined. No integration changes are required.

​

5.205.0 — August 18, 2026 at 8:21 AM UTC

• Connections now shows each provider account’s effective reporting time zone and flags when it differs from the advertiser preference, so reporting-day boundaries are clear before buying.

​

5.204.1 — August 18, 2026 at 7:28 AM UTC

• Google Ads creative image uploads now accept only bounded GIF, JPEG, or PNG files from public HTTPS URLs and protect provider connections from private-network requests, redirects, stalled downloads, and mismatched file content.
• Meta live geo diagnostics now report the failing provider response schema path, expected category, and received JSON type without exposing provider values.

​

5.204.0 — August 18, 2026 at 6:31 AM UTC

• Sellers adding their first modular source now remain in its workspace after creation, ready to upload availability. If the workspace cannot open, the setup task stays available to retry.
• Restore first-party inventory Sources whose binding snapshot proves they were active before Agent identity classification, including the two affected Triton Sources.

​

5.203.1 — August 18, 2026 at 5:52 AM UTC

• Updated self-contained HTML creatives now keep measurement working after an edit by using browser-ready tracking URLs without unresolved identity placeholders.

​

5.203.0 — August 18, 2026 at 5:34 AM UTC

• Meta buyers can now resolve city targeting when Meta returns the city’s parent region identifier as a number, including briefs targeting Paris. The identifier is normalized without changing the requested or provider geography.
• Existing posts from connected ad platforms now appear as Existing post in Claude, ChatGPT, and Murph while keeping the same creative identity as uploaded ads. Uploaded creatives and existing posts remain together in one list, and post-only views use the shared creative asset shape instead of provider-specific controls. No action is needed unless Meta asks you to reconnect for Page permissions.

​

5.202.3 — August 18, 2026 at 4:28 AM UTC

• Meta Awareness campaigns will go through even when interest targeting is configured in the campaign brief — Meta does not allow it with the Awareness objective, so it is now automatically excluded for those campaigns. Nothing to change on your side.

​

5.202.2 — August 18, 2026 at 4:08 AM UTC

• Your marketing email preference is now retained when you create an Interchange account. Nothing to change on your side.

​

5.202.1 — August 18, 2026 at 2:58 AM UTC

• Meta ad set creation no longer fails when brief-derived interest themes (e.g., “web browsing”, “video”, “social media”) cannot be matched to Meta’s interest taxonomy. Interest themes that resolve to a taxonomy entry are applied to the ad set; themes with no match are skipped gracefully. Previously, any unresolvable theme caused the entire buy to fail with a 400 error before reaching Meta. No seller action required — interest theme targeting from briefs is best-effort and does not change how products are configured.

​

5.202.0 — August 18, 2026 at 2:26 AM UTC

• Your product marketing now has its own page in the Teach section of the seller rail, so you can see what your agent has learned from your own marketing material. It opens with how many claims are teaching the agent, how many your live inventory backs, how many are gaps, and how many haven’t been checked, each with the time those verdicts were measured. Below that, one card per piece of material under the name you gave it, showing its version history and every claim in your own words with the provenance it actually has: the verbatim quote and where it sits, the stated reason there is no quote, or a plain note that the claim is your own account of a page we did not fetch. Each gap comes with both ways to close it: open your setup to bring the inventory, or retract the claim behind a confirmation. Each claim also shows the proposal passes it fed, named by buyer and date. The rail row shows your gap count so you learn a decision is waiting without opening anything, and when a proposal’s fed-by detail names “Your marketing”, tapping it opens the page on that exact claim. Nothing is written to your corpus from the page except a retraction you confirm; adding material still goes through Murph’s existing confirmation step, and site claims are still stored as your own account rather than a quote, because we don’t fetch that page.

​

5.201.3 — August 18, 2026 at 1:52 AM UTC

• The inventory source example pack now downloads as a ZIP from both seller setup guides. No setup behavior changed, and nothing needs to be updated on your side.

​

5.201.2 — August 18, 2026 at 1:30 AM UTC

• Meta Facebook Page Likes ad sets now correctly include promoted_object.page_id, resolving HTTP 400 errors (subcode 1487079) that previously blocked delivery for OUTCOME_ENGAGEMENT / PAGE_LIKES campaigns.

​

5.201.1 — August 18, 2026 at 1:10 AM UTC

• Sellers can now download a synthetic onboarding pack and carry the inventory sources created in guided onboarding directly into a buyer-and-seller transaction test. Buyers do not need to change their workflow. Cancelling a media buy now releases its reserved inventory even when an earlier cleanup only partly completed.
• Seller account deletion now returns a safe identifier for the linked resource that blocked removal. Scope3 operators can use that identifier to complete cleanup without exposing raw database error details.

​

5.201.0 — August 17, 2026 at 11:29 PM UTC

• When your organization already has a designated account owner, the signup page now asks additional teammates to request an invitation from that owner. This prevents a later signup from taking over the organization; existing members and invited teammates can continue to sign in or accept their invitation as usual.
• A seller that passes the wiring check but has no active routing agent is now classified as seller_unavailable in get_status instead of appearing as ready and then failing with ACCOUNT_NOT_FOUND at proposal time.
• When a buyer creates a wholesale media buy from a discovery result, each line
• item now keeps the seller’s accepted image, video, and other creative formats.
• Media-buy API responses return those requirements in format_options, and
• creative validation and delivery use the same requirements—even when the same
• product is selected more than once or its pacing changes. Buyers do not need
• to change existing requests.
• Sellers’ published format requirements now remain attached to the buy through
• validation and delivery, so buyers see the formats sellers intended to accept.
• Sellers do not need to republish catalogs or update their format declarations.
• Wholesale media buys created before this change may not include
• format_options. To assign creatives using current requirements, run discovery
• again and create a new media buy.

​

5.200.4 — August 17, 2026 at 10:21 PM UTC

• Feed-backed modular inventory sources now release their booking-ledger capacity when a buyer cancels a media buy. Cancellation retries converge safely, and a source cannot be removed while an active typed media-buy route still depends on it.
• Ad platform compatibility pages now use one consistent Feature / Availability / References / Comments layout, with plain “Available / Partial / Testing / Planned” status instead of the old “who sets the limit?” column. Every page also explains how the connection works (OAuth vs. API key, account mapping), what Interchange actually does for webhooks versus polling, and reporting freshness and currency handling — with raw provider codes and object-field mappings moved into an optional “Technical mapping” section instead of the main tables. Roadmap references are now shown as plain text instead of linking to Scope3’s internal issue tracker.

​

5.200.3 — August 17, 2026 at 9:52 PM UTC

• Agency buyers creating Meta campaigns for Île-de-France or Paris can rely on exact location targeting: campaigns stay paused unless Meta returns the requested geography exactly, and a failed verification cannot spend. No workflow changes are required.
• This buyer-side assurance does not change how seller inventory appears or operates.

​

5.200.2 — August 17, 2026 at 9:32 PM UTC

• Sellers enabled for modular inventory sources can now finish setting up feed-based inventory in Murph. Add a source creates the booking ledger and manual fulfillment workflow required to accept buyer bookings, then opens the new source workspace for availability upload. Existing sources require no changes.
• Buyers can now archive a campaign when a seller has already removed its full media buy. Cancelling selected packages still surfaces the seller’s error instead of changing the local buy; no action is required for full campaign deletion.
• Inventory sources that were already active when their seller-owned Sales Agent identity was recorded now stay active while the newer connection-authorization setup is completed. Agent readiness is shared across that Agent’s Sources once any governed Source completes a transaction. Pre-split readiness is retained as an explicitly labelled compatibility grandfather, without claiming that a transaction or certification occurred. Sources incorrectly moved to pending are restored automatically; sellers do not need to reconnect them or repeat setup.

​

5.200.1 — August 17, 2026 at 8:49 PM UTC

• Reconnect your Google Ads account if account discovery failed during setup. New
• and reconnected accounts can now discover accessible ad accounts normally;
• existing successful connections need no action.

​

5.200.0 — August 17, 2026 at 8:25 PM UTC

• Ad platform compatibility pages now link every incomplete capability to a named roadmap ticket and explain what is missing. Pinterest’s generated 2:3 Pin is now correctly described as an incomplete generation-to-Pin workflow, while the ordinary 2:3 Standard Pin remains available.

​

5.199.0 — August 17, 2026 at 7:11 PM UTC

• Existing advertisers and integrations continue to work with the same defaults for Countries, Reporting time zone, Channels, and Sandbox. No action is required.
• When you create an advertiser in Interchange, one guided task now collects Brand domain, Countries, Currency, Reporting time zone, Sandbox, and Channels. Confirm the buyer account’s Operator in Buyer Setup, then link sales-agent accounts in Connections. Events and Audiences switches appear only when the sales agent declares support, and remain off until you turn them on.
• After creation, you can edit the advertiser name and Channels. Reporting time zone stays editable until the advertiser is first used by a campaign or linked sales-agent account. In the Interchange UI, Brand domain, Countries, Currency, and Sandbox stay fixed; direct v2 API integrations can update Brand domain, Countries, Currency, and Reporting time zone before first use. Sandbox stays fixed in both surfaces. A seller may use a different effective reporting time zone.
• Sellers do not need to act. Buyers now see each sales agent’s declared Events and Audiences capabilities in Connections; seller setup and transaction behavior do not change.

​

5.198.0 — August 17, 2026 at 6:20 PM UTC

• Products with Meta interest theme targeting now resolve correctly at buy time. Previously, any product configured with interest themes (e.g. “running”, “social media”) would always reject buys before reaching Meta — regardless of whether those themes exist in Meta’s interest taxonomy. That blanket block is removed.
• How it works now: When a buyer submits a buy, each interest theme is looked up against Meta’s interest taxonomy and applied to the ad set. If every theme resolves, the buy proceeds. If any theme has no match in Meta’s taxonomy, the buy is rejected pre-flight — no ad set is created — and the create_media_buys response returns an error identifying the unrecognised theme (e.g. Interest theme "obscure_niche" has no match in Meta's interest taxonomy and cannot be applied). The buyer sees this error in the tool response; the seller sees buy failures on that product until the unrecognised theme is corrected.
• What to check: If your Meta products have interest themes configured and buys have been failing, they will now succeed on the next attempt — as long as the configured themes match terms in Meta’s interest taxonomy. If a theme is too niche or misspelled, update the product’s interest configuration to use a term Meta recognises.
• When creating an advertiser and the brand domain is already in use, the error now includes the existing advertiser’s id so you can reuse it immediately without an extra lookup.
• search with kind: "advertiser" in a buyer account now returns a clear message explaining how to recover the advertiser id, instead of a generic wrong-account error.
• request_proposals failures for unconfigured sellers no longer point back at readyDestinations as the fix — the error now directs to your account manager.
• Media buys on your approval queue now say whether they can actually deliver. Each pending entry carries a readiness block naming every package that would be forwarded with no creative, why each of the buyer’s campaign creatives could not fill it — the measured value against your declared requirement, or an ambiguous format identity naming the options the buyer has to choose between — and any creative whose sync to your storefront failed. The Approvals Page shows the same facts on the card and flags the row before you expand it.
• Nothing is blocked. An unready buy still forwards when you approve it, because a creative can be attached after booking. What changes is that you see the problem before spending a decision on it, and can hand it back to the buyer instead of approving a buy the destination will refuse.
• This is a seller-side view only. Nothing changes in the buyer’s own tools, so a buy you hand back still reaches them as an ordinary rejection with whatever note you write — tell them what you saw, or they have nothing to act on.

​

5.197.3 — August 17, 2026 at 12:48 PM UTC

• Storefront adapter connections stay usable while media buys wait for operator approval. Pending approval handles are no longer sent to providers as campaign IDs, so sellers are not asked to reconnect a healthy account.

​

5.197.2 — August 17, 2026 at 12:34 PM UTC

• Fixed Meta Traffic (LINK_CLICKS) ad set creation failing with a 400 error due to a missing promoted_object.pixel_id, and Meta Engagement Page Likes ad set creation failing due to an invalid destination_type.
• A “15 second” audio or video creative is no longer turned away from a 15-second slot for being a few milliseconds off. Nothing for you to do: creatives that were rejected this way now attach, and the length a product asks for has not changed.
• This affected slots where the seller publishes their formats in the older style, as ids like audio_15s — the duration is part of the name, and we were treating it as an exact target. Measuring a file’s duration is not precise to the millisecond, so an ordinary 15-second master could measure 15047ms and be refused. Those slots now accept anything within 100ms of the stated length, and a rejection quotes the length the slot asks for so it is clear what to deliver. A genuinely wrong-length file is still rejected: 100ms is a tiny fraction of the gap between standard spot lengths.
• If you want the detail: an MP3 without a Xing header is measured from its byte rate, so re-tagging the same audio changes the number, and with a Xing header the value snaps to the MPEG frame grid — at 44.1kHz a value like 15000ms is not even representable, since 574 frames is 14994ms and 575 is 15020ms.
• If you sell inventory: a duration_ms_exact you declare directly in a product’s canonical format_options is unchanged — it is your stated requirement and is still matched exactly. The 100ms applies only where we derived the pin from a legacy format id’s name, which we can no longer treat as an exact constraint you asserted. If you accept a range of spot lengths, declare duration_ms_range: both ends are enforced exactly as written, with no tolerance.

​

5.197.1 — August 17, 2026 at 12:12 PM UTC

• Meta media-buy updates now distinguish failures that happened before any
• provider write, so buyers can retry those transient failures safely while
• ambiguous post-write failures remain fail-closed.

​

5.195.0 — August 17, 2026 at 10:00 AM UTC

• When a buyer attaches a JPEG or PNG while working with any connected sales-adapter storefront, their agent can use the storefront’s private image-upload task instead of putting the file contents in chat. The uploaded file is stored privately in Interchange and is accessible only within that buyer account. Delivery currently works only through the Meta sales adapter; other adapters reject it before sending the file to an ad platform. Sellers do not need to change their storefront setup.

​

5.194.8 — August 17, 2026 at 9:29 AM UTC

• Google Ad Manager setup guidance now distinguishes the base trafficking grant
• from optional automatic-approval permissions and explains how externally
• approved orders return to active status.
• No seller action is required; this documentation-only update does not change
• runtime behavior.
• Meta French region and city campaigns now carry signed proof of their exact provider geography without claiming unrelated audience targeting.

​

5.194.7 — August 17, 2026 at 8:48 AM UTC

• If your managed sales-agent integration submits a custom signal-pricing option,
• include a non-empty metadata object that explains how the charge is calculated.
• Requests without that metadata are rejected at submission. CPM,
• percent-of-media, flat-fee, and per-unit pricing options are unchanged.
• Campaign launch failures now name each failing media buy and seller with the reason in the response text, plus the campaign’s current revision so a retry can be composed without re-reading. Previously the details were only in a structured field many hosts do not display.

​

5.194.3 — August 17, 2026 at 7:01 AM UTC

• Clarify that agents should use assets.published_post to identify an existing-post creative in Claude, ChatGPT, or Murph. Host controls are not yet uniform, and ordinary buyer availability is unchanged; no action is required.

​

5.194.2 — August 17, 2026 at 6:12 AM UTC

• Meta campaigns with an immediate start time (“start now”) now create and update successfully. Previously, the “asap” scheduling sentinel was passed literally to Meta’s API, which requires a datetime value and rejected it with a 400 error.

​

5.194.1 — August 17, 2026 at 4:56 AM UTC

• Meta adapter permission errors (e.g., Facebook Page not authorized for the ad account) now surface with a clear PERMISSION_DENIED error message instead of the generic “Upstream request failed” response.

​

5.194.0 — August 17, 2026 at 4:19 AM UTC

• If Scope3 has already mapped your sales agent to your organization, your Agents page now shows it as “Needs confirmation” instead of “No Agents yet.” Organization administrators can review the mapping evidence and claim the agent in one step — or flag it to support if it isn’t yours. The create-agent flow also surfaces these unclaimed agents, so you won’t accidentally create a duplicate.

​

5.193.1 — August 17, 2026 at 3:37 AM UTC

• When you view a Meta campaign after creating or updating it, disabled placement controls now remain shown as disabled even if Meta omits the empty value from its response. No action is required.

​

5.193.0 — August 17, 2026 at 3:09 AM UTC

• If your organization runs its own sales agent, you no longer wait on Scope3 to wire it up — you can connect your agent to your inventory source yourself, and the connection records your organization as the agent’s operator with no separate verification step. This is API-only today (POST /api/v2/storefront/inventory-sources/{sourceId}/agent-binding, organization administrators, in preview): the agent must belong directly to your organization, an existing connection returns a conflict instead of being overwritten, and connecting a partner’s agent from another organization is still arranged with Scope3.
• Separately, the powered-by-agent lookup (GET /api/v2/storefront/inventory-sources/{sourceId}/powered-by-agent) now works at its documented path instead of returning a 404.

​

5.192.2 — August 17, 2026 at 2:53 AM UTC

• No action is needed. Meta media-buy readback now preserves explicit proof of
• disabled placement controls, including Messenger, and verifies device
• placement exactly so targeting checks cannot mistake missing or drifted
• placement evidence for an exact match.
• Paused Meta campaign budget updates now appear on the media buy as soon as Meta accepts them, while the campaign remains paused and cannot spend. This does not activate the campaign or change how buyers submit updates, so buyers do not need to change their workflow.
• Seller integrations now receive a retry if Interchange cannot safely record an accepted media-buy update, rather than a success response while buyers may still see stale data. Successful webhook acknowledgements are unchanged, and sellers do not need to change their integration.

​

5.191.4 — August 17, 2026 at 1:33 AM UTC

• No action is needed. When buyers view package targeting on a Meta media buy, French regions that Meta represents with multiple locations now show an exact targeting match instead of an unproven result. This does not change anything sellers see.

​

5.191.3 — August 17, 2026 at 1:18 AM UTC

• Meta ad set creation with create_media_buys no longer fails with a “page_id is required” error on ad accounts with multiple authorized Facebook Pages.

​

5.191.2 — August 17, 2026 at 12:52 AM UTC

• The seller setup “Partner sales agent” option now explains how to connect a certified partner’s agent through Scope3, instead of showing a disabled button.

​

5.191.1 — August 17, 2026 at 12:38 AM UTC

• No action is required for existing partner-agent connections. New storefront connections must start and finish authorization in the same browser; if that flow is interrupted, restart it in that browser.
• Buyers comparing sellers now see the individual-brand price until both brands confirm their brand-house relationship. Quotes that previously used an unconfirmed house discount may therefore increase; the discount returns automatically after confirmation.
• Sellers need no storefront setup changes. Buyers see a seller’s house discount only after both brands confirm the relationship, and otherwise compare that storefront at the individual-brand price.

​

5.191.0 — August 17, 2026 at 12:25 AM UTC

• Agent pages now link straight to Source diagnostics for owners, and inventory sources label their Agent connection state accurately — including your own agents as “Your Agent”.
• Isolate creative-delivery proof from independent targeting equality while preserving actionable broad-canary diagnostics.

​

5.190.2 — August 16, 2026 at 11:55 PM UTC

• Keep Meta no-spend canaries independent of the buyer reporting feature gate,
• attribute governed CRM readiness failures to their measurement stage, and
• publish safe pre-dispatch cohort diagnostics.
• Meta product discovery now keeps the exact French region or city you asked for attached to the product it returns, so create and update can verify the same location before spending. This is for API and MCP buyers who target France; sellers and other buyers are unaffected. Nothing to change on your side.
• Use the Ad platform compatibility guide to compare every active direct
• ad-platform adapter before planning or reviewing an integration. Each provider
• page shows what the current implementation supports, what has deterministic
• contract-test coverage, whether fresh signed provider evidence exists, and
• which account or relationship gates still apply. Existing REST and MCP calls
• behave the same, so no integration changes are required.
• The primary readers are buyer engineers and agency operators integrating over
• REST or MCP. Sellers and provider partners should expect these pages to expose
• review-ready, not-provider-endorsed readiness states and named gaps to buyers;
• partner corrections are treated as compatibility feedback, not certification.
• Monetization: none. This documentation adds no billable surface, packaging, or
• unit-economics change; brief composition remains a separate product surface.
• Rollout: ungated documentation-only publication with no runtime feature flag or
• kill switch because adapter behavior does not change. Reverting the docs commit
• removes the publication if a factual correction requires withdrawal.
• Measurement after 30 days: each newly listed provider page has at least one
• external unique view, all partner feedback is triaged within two business days,
• and no known factual correction remains untracked.
• Use the AudioStack creative-tool compatibility page to see exactly what can be
• built and what requires separate work. AudioStack can render one hosted audio
• creative at a time, but it does not support preview-only auditioning, provider
• creative-library round trips, or multiple output lengths from one brief. To
• audition or produce both 15-second and 30-second versions, run separate full
• builds. No API behavior changes and no action is required for existing builds.
• The primary readers are buyer engineers and agency creative operators using
• AudioStack through Interchange. Sellers and AudioStack partners should expect
• the public page to expose review-ready, not-provider-endorsed limitations;
• corrections are treated as compatibility feedback, not certification.
• Monetization: none for this documentation. It introduces no new billable
• surface, packaging, or pricing change. A full AudioStack render continues to
• use the buyer’s mapped provider account under the existing provider terms.
• Rollout: ungated documentation-only publication with no runtime feature flag or
• kill switch because runtime behavior does not change. Reverting the docs commit
• withdraws the page if a factual correction is required.
• Measurement after 30 days: the page has at least one external unique view, all
• AudioStack partner feedback is triaged within two business days, and no known
• factual correction remains untracked.

​

5.190.1 — August 16, 2026 at 11:11 PM UTC

• You can now use the Ad platform compatibility guide to compare OpenAI Ads, Meta
• Ads, Snap Ads, and Pinterest Ads when planning or reviewing an integration. It
• shows exact AdCP-to-provider object mappings, distinguishes implementation and
• contract-test status from fresh signed live evidence, and covers account
• permissions, market and beta-access constraints, known gaps, and public review
• endpoints. Existing REST and MCP calls behave the same, so no integration
• changes are required.

​

5.189.0 — August 16, 2026 at 10:07 PM UTC

• Pinterest log_event is no longer listed or callable through the storefront MCP tool surface while safe Tag setup is incomplete. Earlier calls could mistake an event-source ID for an advertiser account and report events processed before Pinterest confirmed them. If you relied on an earlier Pinterest processed result, verify it in Pinterest Ads Manager. Seller-facing storefront behavior is unchanged. The tool will return only after account-scoped Tag setup and live provider validation are complete.
• LinkedIn-connected storefronts now show only campaign types the adapter can
• create successfully. Buyers can inspect account-scoped professional traits,
• such as job seniority or company size, as non-live inventory, but cannot select
• them for ordinary campaign creation until protected provider certification is
• retained. Invalid, conflicting, or ambiguous choices are stopped before
• anything is created.
• If you are newer to LinkedIn ads, the campaign menu may look shorter. This is
• expected: choose from the options shown, and no settings change or other action
• is required. Existing LinkedIn campaigns are not changed.
• Brand teams and agencies get account-scoped inventory with explicit activation
• status. Builders receive exact signal identifiers for inspection and a clear
• pre-provider error if an ordinary create request attempts to target them.
• Sellers do not need to reconnect LinkedIn; hiding unsupported campaign and
• targeting choices prevents buyers from selecting options that would fail later.
• This does not change prices, billable units, fees, or packaging. It is a
• reliability and catalog-accuracy improvement, not a new monetization surface.
• Inventory follows the existing LinkedIn connection and approved campaign list;
• there is no new switch to configure. Operators can remove a campaign type or
• disable the connection to stop new campaign creation. Professional targeting
• activation remains unavailable to ordinary buyers until the protected test
• account completes a paused create, read, update, cancel, and cleanup cycle with
• matching targeting and no resources left behind.
• We will monitor campaign selections, successful creations, validation errors,
• differences between requested and returned targeting, cleanup failures, and
• LinkedIn rejections. Availability expands only after the protected test passes,
• returned targeting matches, and cleanup leaves no resources behind. Operators
• will narrow availability if any of those results get worse.
• When you create a Meta Instant Form Leads campaign, Scope3 now keeps the
• selected Page, form, audience, location, age range, and creative together
• throughout the campaign. No setup changes are required.
• Sellers: not applicable. This changes only the connected Meta buying workflow
• and does not change storefront ranking, inventory labels, or readiness shown
• to buyers.
• Fixed a precision bug in the Amazon Sponsored Products adapter where very
• large campaign, ad group, product ad, keyword, and targeting-clause ids could
• be silently rounded, and a DSP order id could be miscoerced into a Sponsored
• Products campaign id during create_media_buy. Amazon provider ids are now
• kept as exact strings end-to-end, and a newly-created id that doesn’t look
• like a valid Amazon id now fails the request instead of being trusted.
• Snap’s published creative-format catalog (the AAO community mirror) no longer lists the “existing post” format as generally available — it requires a separate provider allowlist most accounts don’t have yet, and create_media_buy/sync_creatives already rejected it for everyone else. This catalog fix makes the published capability list match that existing behavior; it does not change what any account can already do, and Awareness and Traffic campaign creation are unaffected.

​

5.187.3 — August 16, 2026 at 7:51 PM UTC

• Account and Partner workflows now recover when staging’s cancellable Core database reader cannot verify the certificate chain.

​

5.187.2 — August 16, 2026 at 7:20 PM UTC

• Account creation now rejects unconfirmed organization conversion cleanly, while explicitly confirmed onboarding flows can provision their first account.

​

5.187.0 — August 16, 2026 at 6:29 PM UTC

• New Seller accounts can now complete their confirmed no-spend source test through the Buyer campaign stack without gaining general Buyer access.
• Google Ads API buyers should update new campaign requests to use Search website traffic. get_products no longer lists conversion, Display, Performance Max, Demand Gen, Video, Shopping, or App products, and create_media_buy requests for those product IDs now return UNSUPPORTED_PRODUCT_CONTRACT before Google Ads changes. Continue managing those campaign types directly in Google Ads; reconnecting your account will not unlock them in the API. Existing campaigns need no action, and this does not change what buyers see about a seller.
• Search website traffic requests now keep quoted wording and apostrophes intact when Google selects the matching product. Adding or replacing an ad on a running Search campaign no longer pauses the campaign or removes its current ad before the replacement is ready. If Google rejects the new ad or its safe removal cannot be verified, the request fails and alerts the operations team while the existing campaign remains available.
• Publisher catalog refreshes now keep using explicit creative formats from the publisher’s live file when the registry is temporarily unavailable. Nothing changes on your side, and registry community catalogs retain their existing precedence when the registry responds.
• For enterprise brands and agencies, adding another Buyer or Seller account from
• a standalone account now requires an explicit governance decision. Before
• Interchange creates the organization, an administrator confirms that contract
• and billing authority will move to it and that they will become an organization
• administrator. Account resources and direct memberships remain scoped to each
• account; account-specific standing still overrides organization standing. No
• existing account changes unless an administrator starts this flow.
• People using the Interchange UI do not need to update anything. When they add
• the account, the UI presents the disclosure and sends the confirmation after
• they accept it.
• Seller impact is indirect and limited to Seller administrators or integrations
• that use this account-creation flow. It does not change what buyers see about a
• seller, storefront inventory or demand, media-buy execution, settlement,
• pricing, billable units, packages, or commercial approval.
• Integrations that call POST /api/v2/accounts/create-child from a standalone
• Buyer or Seller account must present the disclosure and send
• confirmOrganizationConversion: true. Omitting the field or sending false
• on a new conversion returns 409 Conflict before anything changes. Calls from
• an account already managed by an organization should continue to omit the
• field.
• Use the same idempotencyKey only to retry the same account-creation request.
• If Interchange already saved the organization and account structure before a
• later setup step failed, a retry with that key finishes the missing
• administrator access, contract transfer, Buyer access setup, and account-view
• repairs instead of creating duplicates. This remains true if the retry omits
• confirmation or sends false: confirmation can stop a new conversion, but it
• cannot undo one already committed. The retry still requires the appropriate
• administrator authority, and reusing the key for different account details
• returns 409 Conflict. Separating the account again requires a supported
• migration.
• Enforcement starts only after the confirmation-compatible API and UI release
• (#10473) is fully deployed across the fleet and 100% of Interchange UI
• conversions send explicit confirmation. Rollout health is measured from the
• create_child_account organization-attachment audit
• (confirmationStatus: explicit), responses from
• POST /api/v2/accounts/create-child, and audit-relay dead letters. After
• enforcement, pause or roll back if conversion 409 responses exceed 1% for 15
• minutes or if any attachment audit is dead-lettered.

​

5.186.0 — August 16, 2026 at 5:36 PM UTC

• Approved design partners can receive audited, automatically expiring beta access before billing begins, while paid support, service commitments, and tenant authorization remain separate.

​

5.185.0 — August 16, 2026 at 5:16 PM UTC

• You can now teach your Merchandising Agent how you sell, from the marketing material you already have. Point Murph at your media-kit page, or upload a deck, one-sheet, package menu, case study, audience card, or spec sheet. Murph reads it and proposes the merchandising claims it found; nothing joins your product-marketing corpus until you confirm it. Confirmed claims change how the products your agent composes are named and described, and never change price, floors, eligibility, or availability. Each response in your demand inbox names “Your marketing” among the ingredients that fed it, alongside the claim that shaped it. A claim that promises something checkable — a channel, a creative format, a named audience signal — is reconciled against your live inventory, and anything your catalog can’t back is marked a gap and held back from shaping proposals until you add the inventory or withdraw the claim. A claim with nothing checkable carries no verdict; it is never marked backed. Claims from an upload keep the exact quote and location they came from, or the stated reason that part of the document had nothing quotable; claims from a URL are kept as your own account of the page — we don’t fetch it — and all three kinds are labelled distinctly everywhere they appear, so they are never confused or treated as equally proven. Withdrawing a claim stops it shaping new proposals and keeps the source material and the record of what it already shaped, and re-confirming updated material lands as a new version instead of a duplicate — a page is matched by its address and an upload by the name you give the material, so re-uploading a refreshed deck under the same name replaces the old one and its claims stop feeding proposals right away.

​

5.184.0 — August 16, 2026 at 4:49 PM UTC

• Buyer and Seller administrators using Create account from a standalone
• account in Interchange now see the organization consequences and must confirm
• them before continuing. Interchange creates an organization and adds the
• existing account to it. Existing Buyer advertisers and campaigns stay with
• their current account, while existing Seller storefront and inventory
• resources stay with theirs. Contract and billing authority move to the
• organization, the confirmer becomes an organization administrator, and current
• direct members remain members of the account rather than the whole
• organization. Hands-on administrators need no setup change; they review and
• confirm only when they create another account from a standalone account.
• An account’s own credit limit, payment terms, and verification status continue
• to override the organization’s defaults; otherwise the account inherits those
• settings. If the account later needs to be independent again, Scope3 Support
• can plan a dedicated migration; this is not a self-service action. See the
• Buyer account overview or [Seller account
• overview](/v2/storefront/account/overview).
• Existing REST account-creation calls that omit
• confirmOrganizationConversion continue to work in this preparation release.
• Integrators ready to adopt the new flow can present the same disclosure and
• send confirmOrganizationConversion: true after a standalone administrator
• accepts it. For a fresh standalone conversion, sending false returns `409
• CONFLICT` without changing the account hierarchy. Omission remains compatible
• until the separately released enforcement phase.

​

5.183.4 — August 16, 2026 at 4:27 PM UTC

• Allow governed Meta cleanup to prove zero spend from exact non-dispatch evidence and authoritative zero local inventory, including safe normalized failure reasons while rejecting unbounded diagnostics.

​

5.183.3 — August 16, 2026 at 4:12 PM UTC

• Storefront product discovery now checks explicit, currency-qualified hard CPM ceilings against server-calculated pricing, including localized price formats and dollar signs resolved from a known dollar currency. Offers above the maximum are declined without falling back to an unfiltered catalog.

​

5.183.1 — August 16, 2026 at 3:38 PM UTC

• Buyer agents now receive safe AdCP recovery fields when an in-process storefront rejects create_media_buy; raw provider details remain hidden. Existing requests require no changes.

​

5.183.0 — August 16, 2026 at 3:02 PM UTC

• Existing accounts do not need to change. Signup now asks what you want to do
• first, then creates the matching Buyer or Seller account or starts sales-agent
• registration. It explains that an organization can have multiple accounts,
• that Buyer or Seller accounts can be added later, and that buying and selling
• use separate accounts.
• Enterprise brand buyers. Choose Buyer when registering your brand to
• plan and run advertising. A verified work email can make you the first
• administrator of the one matching ownerless Buyer account or organization for
• your domain instead of creating a duplicate. Otherwise, your existing account
• and access remain unchanged.
• Agency buyers. Choose Buyer when your agency will buy on behalf of
• clients. The signup choice creates or claims your agency’s Buyer workspace; it
• does not create a Seller storefront or change any client’s existing access.
• Scrappy and power buyers using REST. Send accountType: "BUYER" when your
• integration creates a Buyer signup. accountType controls the workspace that
• is provisioned; companyType remains a company-classification field. A
• matching verified domain may claim one ownerless Buyer account, otherwise the
• request follows the normal Buyer signup path.
• SMB and novice buyers. Choose Buyer if you want to advertise your own
• business. You do not need to understand account structures: this creates or
• opens your buying workspace. It does not publish inventory or create a
• storefront.
• Sellers. Choose Sell inventory only when you publish, represent, or
• manage inventory for buyers, and only where public Seller signup is enabled.
• That choice creates or claims the Seller account and then continues to
• Storefront setup. Choosing Buyer or Partner does not create a Storefront. This
• changes identity and administrator signup only: it does not change Storefront
• inventory, buyer-facing rendering, ranking, or what buyers see about any
• seller.
• Partners and commercial access. Choose **Offer a sales agent to other
• sellers** only when your organization provides a sales agent that other sellers
• use to sell media. Signup creates or reuses the organization and its free
• Partner workspace, then continues to sales-agent registration and certification.
• It does not grant the paid right to operate the agent for clients; that still
• requires separate commercial approval. No pricing, entitlement, or Seller
• commercial status changes with this signup update. The Partner choice remains
• behind the independent partner-account-signup rollout flag until the additive
• API support is deployed across the full API fleet; operations must enable it
• only after old pods have drained.
• Meta EU campaign setup failures now explain that the selected account needs default DSA beneficiary and payor identities. The message remains account-safe, confirms that no provider write was sent, and gives the account administrator a clear next step.

​

5.182.1 — August 16, 2026 at 1:27 PM UTC

• Pricing, billing, plan, and payout surfaces now call seller-owned commercial setup a Seller Account, including when sellers view or manage their own commercial account, and call buyer-facing counterparties Sellers. Legacy v2 storefront API identifiers keep working unchanged, and no pricing or billing behavior changed.

​

5.182.0 — August 16, 2026 at 1:12 PM UTC

• Account creation and switching now make it clear whether you are working in an
• organization or a Buyer, Seller, or Partner account; whether people and API
• clients can enter it; and, for Buyers, whether it is sandbox-only or eligible
• for live spend. Existing accounts, memberships, contracts, and access stay as
• they are.
• Enterprise brand buyers. In Interchange, administrators can distinguish the
• organization that governs their accounts from each Buyer workspace before they
• create or switch accounts. No action is needed for existing accounts. A newly
• created Buyer account starts sandbox-only and needs separate approval before it
• can create or execute live-spend work.
• Agency buyers. When you add an account for a client or operating team,
• Interchange shows whether it is a Buyer or Seller workspace and whether it can
• be entered. Choose the workspace that matches the work you need to do; existing
• client access is unchanged. New Buyer workspaces begin in the sandbox, so do
• not plan live spend until they are separately approved.
• Power buyers and REST integrators. Account-creation and account-switching
• responses now provide the canonical nodeKind, accountType, and enabled
• fields, plus buyerAccessPosture for Buyer accounts. Use these fields for new
• reads; the existing customerRole field remains compatible for Buyer and
• Seller integrations. Partner has its own registration and commercial-status
• fields: enabled only means the account can be entered, not that it is
• commercially approved.
• SMB buyers. If your administrator adds a new Buyer account, you can use it
• for sandbox work right away. You do not need to change your current account or
• campaigns, and you cannot use the new account for live spend until it has been
• approved.
• Sellers. In Interchange and storefront account responses, Seller accounts
• are now clearly separate from the organization that governs them. Existing
• storefronts and inventory remain where they are; only a newly created Seller
• account receives a new storefront. No action is needed unless an administrator
• is creating or switching accounts.
• Availability, packaging, and measurement. Buyer admission and entry remain
• behind the alpha-opt-in customer gate; turning that gate off retains the
• current Buyer waitlist, while Seller access is not gated this way. This change
• adds no plan, entitlement, price, or contract change. Adoption is a Buyer
• successfully creating or switching into a new account and reading its account
• context; ongoing usage is a sandbox media-buy lifecycle run. We will review
• those signals at 30, 60, and 90 days before expanding Buyer availability.

​

5.181.4 — August 16, 2026 at 11:45 AM UTC

• Meta media buys targeting EU locations now use the selected ad account’s DSA beneficiary and payor defaults, and stop before creating a campaign when Meta has not configured both.

​

5.181.1 — August 16, 2026 at 9:37 AM UTC

• Archived media buys remain discoverable through campaign media-buy references while their substantive details stay omitted. Meta canary cleanup uses that terminal reference only when the immutable exact-run artifact proves the failed write was never dispatched upstream.

​

5.181.0 — August 16, 2026 at 7:35 AM UTC

• Publisher catalog refreshes now report a retryable failure when the registry
• lookup is indeterminate, instead of incorrectly reporting that no catalog
• applies while retaining the publisher’s last known formats.
• Meta campaigns now resolve exact region and city targeting across every provider search page while preserving fail-closed validation.
• Existing live inventory sources in your storefront now stay available to buyers when Interchange records the sales agent that already operates them. Nothing changes on your side and no action is required; provider account ownership, certification, and activation remain separate setup steps.

​

5.180.0 — August 16, 2026 at 6:33 AM UTC

• Campaign delivery no longer fails to load for platform-managed media buys created directly or approved through an embedded provider. No buyer action is required. Seller approval status and reporting behavior are unchanged.

​

5.179.0 — August 16, 2026 at 5:48 AM UTC

• Nothing changes for existing TikTok campaigns. Eligible buyers can now create
• app campaigns that prioritize the value of purchases or advertising revenue,
• instead of optimizing only for installs or actions. Choose whether to seek the
• most total value or work toward a specific return goal. Return-goal campaigns
• can count either same-day or first-week results.
• To use these options, connect an eligible advertiser account, select the app,
• and provide a positive return goal when requested. Interchange shows only the
• choices available to that account, creates the campaign paused, and verifies
• the saved goal before reporting success. It never swaps purchase value and
• advertising revenue or silently chooses a different bidding approach.
• Teams managing several brands can review each value strategy as a distinct
• wholesale product, making results and prerequisites easier to compare across
• accounts and channels. Campaigns for returning app users are also supported
• when the account has an eligible app event and a suitable existing-customer
• audience. Unsupported return-user strategies remain unavailable rather than
• being replaced with a different campaign.
• This buyer-side addition does not change seller inventory or reporting, and
• sellers do not need to act.
• From connected TikTok buying, choose **TikTok App Install Purchase Value —
• Target ROAS (Day 0)**, select an eligible app, and enter a positive
• return-on-ad-spend target. Interchange creates an app-install media buy
• optimized for same-day purchase value, then verifies the saved app, Purchase
• Value goal, exact target, Target ROAS bidding, and Day 0 window before
• reporting success. It will not substitute Highest Value or Day 7. Existing
• TikTok campaigns and the behavior of other TikTok products do not change.
• Seller storefronts and reporting do not change, and sellers do not need to
• act.
• From connected TikTok buying, choose TikTok Smart+ App — In-App Event,
• then select an authorized iOS or Android app, one of its available post-install
• events, a TikTok identity, and one uploaded or Spark asset group. Interchange
• preserves TikTok’s Every or Once event-counting setting, creates the Smart+
• campaign paused with automatic placement and the matching operating system,
• and verifies the exact app, event, counting setting, identity, assets, and
• optimization before reporting success. The app, event, identity, and assets
• are activation resources. Compatible audience signals remain optional;
• geography and age remain targeting overlays.
• The product can execute only when TikTok reports the selected app and event as
• eligible. Selecting and executing it directly adds no brief-composition or
• account-analysis charge; normal media spend and existing connected-account
• charges still apply. Smart+ App Value is separately available as seven products
• with distinct value events, bid strategies, and measurement windows.
• Interchange will not substitute Install or In-App Event for a Value request.
• Existing TikTok campaigns and the behavior of other TikTok products do not
• change. Seller storefronts and reporting do not change, and sellers do not need
• to act.
• From connected TikTok buying, choose TikTok Smart+ App — Install, then
• select an authorized iOS or Android app, TikTok identity, and one uploaded or
• Spark asset group. Interchange creates the Smart+ campaign paused, optimizes
• for installs with automatic placement and the matching operating system, and
• verifies the exact app, identity, assets, and optimization before reporting
• success. The app, identity, and assets are activation resources. Compatible
• audience signals remain optional; geography and age remain targeting overlays.
• Smart+ App In-App Event and the seven Smart+ App Value products are available
• separately. Interchange will not substitute App Install for any of them.
• Existing TikTok campaigns and the behavior of other TikTok products do not
• change. Seller storefronts and reporting do not change, and sellers do not need
• to act.
• From connected TikTok buying, choose one of seven TikTok Smart+ App Value
• products spanning Purchase or Ad Revenue Value, Highest Value or Target ROAS,
• and Day 0 or Day 7 where TikTok exposes the choice. Select an eligible app,
• TikTok identity, exact value event, and one uploaded or Spark asset group;
• Target ROAS products also require a positive ROAS target. Interchange creates
• the Smart+ campaign paused and verifies the exact app, event, bid strategy,
• value window, ROAS bid when applicable, identity, assets, and automatic
• placement before reporting success.
• Apps and events appear only when TikTok reports that they are eligible for the
• selected Smart+ value contract. Provider-account and buyer-synced audiences
• remain optional signals; geography and age remain targeting overlays. Selecting
• and executing a product directly adds no brief-composition or account-analysis
• charge. Normal media spend and existing connected-account charges still apply.
• Existing TikTok buys do not change.
• These products are available to connected TikTok accounts with eligible app and
• event pairs. Interchange verifies the required resources and eligibility before
• spend; a write or readback mismatch is reported as a failure and triggers
• cleanup. Rolling back removes the seven products from new buying. Seller
• storefronts, seller reporting, and buyer-visible seller data do not change;
• sellers do not need to act.
• Nothing new is available for buyers to try yet, and no customer action is
• required. We prepared TikTok Smart+ Catalog Conversion and Purchase Value, but
• kept both choices hidden until TikTok can confirm that an advertiser’s Pixel is
• eligible for Purchase optimization and, for Purchase Value, sends usable value
• and currency data.
• This is intentionally gate: none: the products are structurally excluded
• from discovery and execution, so there is no exposed audience for a feature
• flag to meter. That same exclusion is the kill switch. A separate reviewed
• change may expose them only after we capture eligible and ineligible real TikTok
• responses, cover partial and malformed responses in tests, and complete a
• signed paused live canary with exact readback for each product.
• Before exposure, the acceptance metric is zero discovery results and zero
• execution attempts for both product IDs. The enablement change must measure
• discovery, create attempts, successful paused creates, prerequisite failures,
• readback substitutions, and cleanup by product. Existing TikTok buys, seller
• inventory, and seller reporting do not change.
• From connected TikTok buying, choose TikTok Smart+ Traffic — Clicks or
• TikTok Smart+ Traffic — Landing Page Views. Select the required geography,
• TikTok identity, destination, and creative; compatible audience signals remain
• optional. Use either uploaded assets or Spark posts in one buy, not both.
• Interchange creates the campaign paused and verifies the optimization,
• targeting, identity, destination, and creative before reporting success.
• Existing TikTok buys do not change. Smart+ Web Conversion and Purchase Value
• remain explicitly blocked and undiscoverable until TikTok Pixel event/value
• eligibility can be read from provider evidence.
• This is an atomic, ungated addition to the connected-account TikTok catalog:
• each product fails closed unless every required resource can be proved, and
• removing the two product registrations is the rollback path. A human release
• approver must accept that gate-none plan before merge. The products use the
• same billing path as existing direct TikTok buys; this release adds no new fee
• or SKU. Paid brief composition and advanced account analysis are separate from
• these wholesale products.
• Seller check: these are buyer-side direct-platform products. They do not alter
• seller inventory, seller reporting, or anything a buyer sees about a seller,
• and sellers do not need to act. Launch measurement will track discovery and
• selection of each product, successful and fail-closed creates by prerequisite,
• readback and activation failures, and cleanup containment. Beta promotion
• requires signed live-canary evidence for a representative Traffic composition.
• Nothing changes for existing campaigns. Buyers and agencies can optionally use
• TikTok Sales — Website Catalog Ads to launch a paused, purchase-focused
• catalog campaign from a connected advertiser account. Interchange verifies the
• selected catalog, group of products, tracking connection, and video before it
• reports success, making the campaign easier to review alongside work on other
• channels.
• To use it, connect an advertiser account that your organization administers and
• provide an eligible catalog, product group, tracking setup, and video. Automated
• Smart+ catalog campaigns and TikTok Shop campaigns are not included. This
• buyer-side capability does not change seller-visible information or expose
• seller data; it uses only resources from the buyer-connected advertiser.
• You can now manage connected TikTok Smart+ campaigns from Interchange: list
• them alongside manual campaigns, then pause, resume, rebudget, change
• end dates, update targeting or package status, and cancel them. Completed
• changes are confirmed against TikTok before Interchange reports success.
• Nothing changes for existing manual TikTok campaigns, and no setup action is
• required. If TikTok returns the same campaign ID in both its manual and Smart+
• inventories, Interchange stops the change and reports the ambiguity so you can
• choose an unambiguous campaign instead.

​

5.178.6 — August 16, 2026 at 5:37 AM UTC

• Organization administrators can reliably open governed Agent pages, while other members no longer see an Agents link they cannot access. No client configuration changes are required.

​

5.178.5 — August 16, 2026 at 5:24 AM UTC

• Card-paying businesses now see a simpler Plan & Billing page: billing details,
• receipts, and invoices remain visible, while credit and payment-term controls
• stay collapsed unless requested or already active. Credit approval and payment
• authority remain owned by the business, including for a single-account setup.

​

5.178.4 — August 16, 2026 at 5:10 AM UTC

• Child storefronts now honor their organization’s merchandising entitlement when serving products from ready modular inventory sources.

​

5.178.3 — August 16, 2026 at 3:13 AM UTC

• Let sellers complete no-spend sandbox campaign tests against their own pre-launch storefront, including product discovery and media-buy dispatch.

​

5.178.0 — August 16, 2026 at 12:16 AM UTC

• Let modular inventory sources satisfy publish validation through a Storefront-owned no-spend booking test without requiring an external Agent sandbox.

​

5.177.0 — August 15, 2026 at 11:54 PM UTC

• Feed-backed modular sources configured for manual execution now accept buyer media buys through a provider-neutral seller workflow. Interchange creates work items for upstream booking, creative handoff, and final reporting, and records the completed evidence through delivery without requiring a custom ad-server adapter.

​

5.176.2 — August 15, 2026 at 10:16 PM UTC

• Align AAO-slugged publisher format scopes with exact live AdCP property IDs.

​

5.176.0 — August 15, 2026 at 8:50 PM UTC

• Buyers can now request account-level credit and payment terms from Plan & billing. Requests start at Net 60; sellers can approve, reject, or send different terms for an account administrator to accept. Existing terms stay effective until a counteroffer is accepted, and card or prepay accounts do not need to act.

​

5.175.0 — August 15, 2026 at 8:14 PM UTC

• The unpublished v3 Seller API now uses Seller Account terminology end to end: connect to the seller account kind, read get({ kind: "seller" }), and save configuration with save_seller. V3 has no live external customer traffic, so no existing integrator needs to migrate from the preview vocabulary.
• V2 Seller APIs are unchanged. Existing /mcp/v2/storefront paths, operation names, and fields remain supported as the legacy v2 contract.
• Buyer-facing behavior is not affected by this seller-side account and tool rename. The separately owned v3 buyer terminology work is outside this change.

​

5.174.0 — August 15, 2026 at 8:00 PM UTC

• French agencies and enterprise media teams can now carry the geography in a brief through to Meta without translating today’s régions into Meta’s older regional map. New and updated media buys can target all metropolitan French régions, supported départements, and verified cities such as Paris. Interchange checks the exact provider geography before reporting success and rejects unsupported or ambiguous places instead of substituting a broader area.
• Existing media buys do not change unless their geography is updated. Hands-on buyers can use the documented region, département, and city targeting fields; buyers working through Murph or a widget need no setup. Support for the forthcoming AdCP 3.2 place format is compatibility-only and will remain unavailable to buyers until Storefront negotiation, authenticated place lookup, and signed canary proof are live.
• Seller impact: Not applicable. This changes buyer-side Meta campaign targeting and does not change how a seller, storefront, or inventory appears to buyers.
• Monetization: None. This is included in existing media-buying access with no pricing, packaging, fee, or unit-economics change.
• Rollout and control: This ships without a PostHog flag because it is structurally limited to explicit Meta geography requests; defaults and untouched media buys are unchanged, and invalid geography fails before any provider mutation. The current buyer-visible path expands only after the Île-de-France and Paris signed no-spend canaries both prove exact readback. AdCP 3.2 exposure additionally requires successful Storefront negotiation and an authenticated place resolver. Rollback of this adapter release is the kill switch; withholding the 3.2 place capability keeps that compatibility path disabled independently.
• Measurement: Release acceptance is 100% exact readback in the signed Île-de-France and Paris create canaries, with zero provider-key mismatches. Adoption is measured from successful create_media_buy operations carrying French Meta region, département, or city provenance; ongoing usage is measured from successful update_media_buy operations carrying the same evidence. For the first 30 days, report distinct buyer accounts, successful media buys, the région/département/city split, rejected unsupported requests, and any exact-readback failure. Any exact-readback failure stops expansion and triggers rollback review.

​

5.172.7 — August 15, 2026 at 6:34 PM UTC

• Keep Meta delivery reads inside the API response boundary, avoid unnecessary placement lookups for totals-only reports, and retry bounded read-only readiness failures.

​

5.172.4 — August 15, 2026 at 5:57 PM UTC

• Hosted Seller endpoints now use /seller/{platformId}/mcp in discovery and OAuth metadata. The retired hosted /storefront/{platformId}/mcp path now returns 404.
• Sellers will see the new hosted URL in discovery and OAuth metadata, but there is no catalog or dashboard action to take and no need to notify buyers: these per-Seller URLs were changed before they were issued externally, and Interchange rewrites its stored hosted URLs automatically.
• REST and MCP buyer-agent builders receive the new URL through discovery. If an unpublished preview URL was copied manually, replace its /storefront/ segment with /seller/.
• Platform-direct, enterprise, and agency buyer workflows are unchanged. V2 Seller Account data and third-party Seller endpoints are also unchanged.

​

5.172.3 — August 15, 2026 at 5:37 PM UTC

• Start the directed-delivery deadline at request entry so provenance and adapter setup cannot consume the client response buffer.

​

5.172.0 — August 15, 2026 at 4:54 PM UTC

• Connecting your own organization’s inventory Source to your own Sales Agent now
• confirms that Agent as owned and operated. You do not need to sign in again to
• claim both sides of the same connection, and an already-active Source stays
• active while its durable Agent identity is added. Normal serving-readiness
• checks remain authoritative afterward. If the accounts later split, only the
• claim and approvals created by that owned-and-operated shortcut are removed;
• explicit provider claims and pre-existing client requests remain intact. Agents
• operated for another organization still follow the Partner connection workflow.

​

5.169.1 — August 15, 2026 at 1:36 PM UTC

• Sellers can now run a no-spend sandbox test on their storefront at any time, even after they’ve already passed one successfully before. Previously, once a storefront passed its first sandbox test, it could never run another one — so a seller who fixed a broken inventory connection had no way to verify the fix without exposing the storefront to real buyers. A sandbox test still fails if the inventory source it’s testing is genuinely unhealthy.

​

5.169.0 — August 15, 2026 at 1:14 PM UTC

• Buyer administrators can now correct an account’s operator domain, scope, or
• operating-unit ID after setup and after connecting storefronts. The identity
• becomes locked only when a complete advertiser account is created or bound
• under it; changing the key after that point requires an advertiser-identity
• migration.

​

5.167.0 — August 15, 2026 at 9:55 AM UTC

• Connecting your own organization’s inventory Source to your own Sales Agent now counts as claiming that Agent. Parent and child accounts in the same organization are treated as owned-and-operated, so existing sellers do not have to sign in again on the Partner page. Historical active O&O Sources stay active while support adds their durable binding; the next health, certification, validation, product-mode, and quarantine reconciliation is still authoritative. Agents run for another organization still require the explicit Partner claim and connection workflow.
• TikTok campaign creation now proceeds when the selected advertiser has no existing campaigns. Existing campaigns and non-empty provider inventories are unchanged.
• In Account Center, a buyer administrator can now confirm whether each buyer
• account represents the whole operating domain or a specific operating unit.
• Interchange and connected storefronts then use that seller-visible identity to
• map the account consistently. Existing accounts can continue buying without
• immediate action, but remain marked as needing identity confirmation. After the
• confirmed identity is first used for an advertiser or storefront binding, it is
• locked; support must migrate those bindings before the identity can change.
• Full-term prepayment choices now preserve their exact amount and currency from proposal through acceptance instead of rounding to a whole number of monthly payments.

​

5.165.4 — August 15, 2026 at 8:48 AM UTC

• V3 buyer preview fixes. Writes now scope to your current account without a
• redundant switch_account confirmation. save_creative validates
• formatKind against the canonical enum before dispatch and returns the same
• camelCase creative detail as get, including update warnings and a dedupe
• signal when a same-name creative already exists. Campaign list rows show the
• advertiser name instead of its id. open_page for release notes returns a
• structured page marker. get_status now lists readyDestinations with the
• seller ids request_proposals accepts, and the sellerIds field documents
• that source.

​

5.165.2 — August 15, 2026 at 8:12 AM UTC

• TikTok campaigns and creatives can now proceed when an account has an empty provider inventory. Nothing changes for accounts with existing provider resources, and no action is needed.

​

5.164.0 — August 15, 2026 at 6:29 AM UTC

• Storefront operators with an approved OpenAI Ads account can now connect it to
• Interchange with one account-scoped API key per ad account and offer both
• current ChatGPT formats: chat cards and product ad templates. Campaigns support
• CPM, CPC, and conversion-optimized CPC, with country, region, DMA, ready
• custom-audience, context, and product filtering; new campaigns start paused, and
• Interchange verifies creates, updates, and reporting against OpenAI before
• reporting success. The dated availability snapshot covers nine markets, while
• OpenAI’s live account-scoped catalog remains authoritative when a campaign is
• created. Product ad templates require an existing feed: connect the feed and
• make its initial upload in OpenAI Ads Manager or over SFTP before using the feed
• ID in Interchange.

​

5.163.2 — August 15, 2026 at 5:37 AM UTC

• Storefront Setup now clears the intake hold through an explicit Go Live action,
• and completed setup can no longer make a held storefront appear previously live.
• If Setup says your storefront is ready but new business is on hold, click Go
• Live once after this update. Storefronts already accepting transactions need no
• action. Buyer integrations need no changes; storefronts that are still held or
• blocked will no longer be presented as available until the existing readiness
• and marketplace checks pass.

​

5.162.0 — August 15, 2026 at 4:47 AM UTC

• Seller administrators can now review and accept current platform terms and
• enter primary payout authority inside the private Plan & Billing Page, without
• bank details passing through the assistant. The v3 product contract now covers
• the modular feed onboarding, Ask lifecycle, and bounded storefront setup paths
• needed by the journey certification harness. A clean live staging run remains
• a separate deployment gate. Buyer agents reading the shared billing account
• also receive the current terms version and review URL; buying behavior and
• seller eligibility remain unchanged.

​

5.160.0 — August 14, 2026 at 9:14 PM UTC

• Activating a provider-connected inventory source now checks that source’s current health evidence directly, rather than a stored status value that several unrelated checks all wrote to. A source is allowed to activate when it has been observed and nothing currently reports a problem with it; a source that has never been checked, or whose newest evidence reports a problem, is held back until that is resolved.
• This closes a case where a source could be activated on stale evidence: previously a single failed check older than a week was ignored, so a source whose only recorded problem had aged past that window could be brought live without anything having re-verified it. Freshness is now measured against that source’s own most recent check rather than the calendar, so an old failure keeps blocking activation until a newer check supersedes it.
• If activation is refused, resolve the source’s health problem and let it be re-checked, or trigger a re-check yourself; the refusal names the source and the reason.
• Fix: accepted media buys with real delivery now appear in reports
• Buyer and storefront reports previously excluded media buys that the seller had accepted and was delivering, when those buys were still awaiting a final status confirmation from the seller. This hid real spend for these buys from both buyers (who could not see the delivery activity) and sellers (whose own storefront reports omitted the same buys).
• The reporting queries now include accepted buys in this state. Historical spend that was previously hidden may now appear in your reports. No action is needed on your end.
• The status-sync job also now advances these buys to completed after their flight end date passes, so they surface correctly in any views that show only finalized buys.
• V3 buyer proposal rounds now preserve seller-returned products that are not
• allocated into a Proposal. To stage one directly with save_media_buy, use its
• seller-scoped productQueryId and preserve productId plus any
• inventorySourceId and salesAgentId. Seller-facing behavior does not change,
• and sellers do not need to take action.
• When buyers create or update a media buy through the API or MCP, subdivision targeting is now checked against the selected inventory source and advertiser account. This prevents one seller source’s region support from being applied to another source when they share a connection. No setup changes are required; unsupported targeting is still rejected before the seller is changed.
• Re-syncing a creative with corrected content (for example, fixed dimensions)
• under the same idempotency key now reaches the inventory source instead of
• being answered from its cached response for the earlier request. Retrying an
• unchanged sync_creatives call still dedupes the same way it always has.

​

5.159.0 — August 14, 2026 at 8:44 PM UTC

• Canceling a media buy now immediately reflects as canceled on the seller side,
• rather than waiting for the next poll cycle (which could be minutes later).
• Previously, sellers would see the buy as still active or pending after a buyer
• canceled it.
• Fixed a bug where Murph in Slack could reject advertiser-scoped requests (e.g. sandbox test campaigns) from a real member of the connected account with “No user context available for advertiser permission check,” even though the same request worked fine from the in-product chat.
• Newly committed modular products can reach buyer discovery without waiting for
• the next catalog refresh. The Inventory Feed API now attempts that refresh
• before returning and reports catalogRefresh.invalidated and
• catalogRefresh.warmed. Feed publication still succeeds if this best-effort
• refresh cannot finish; warmed: false means buyer visibility may lag. Existing
• seller integrations do not need to change. Buyers may discover newly committed
• products sooner, but their workflow, API contract, and setup do not change.
• In the Merchandising Simulator, briefs that need human review no longer look
• like policy declines or hide otherwise eligible products. This changes
• seller-side simulation evidence only: it does not approve a buy or bypass
• seller review, and buyers need no setup change.

​

5.158.0 — August 14, 2026 at 8:18 PM UTC

• Terminology now distinguishes Interchange seller accounts, their one-to-one storefronts, connected provider accounts, and seller-side Buyer Account Mapping records. Active documentation and model-visible API descriptions call externally mirrored accounts connected provider accounts and campaigns mirrored from them tracked campaigns; legacy operation identifiers remain unchanged.
• Sellers using modular sources can run a no-spend test campaign through their
• storefront after committing a catalog. External sales-agent sandbox
• requirements are unchanged, and existing modular sources need no reconfiguration.
• Seller agents using V3 can now open the portable modular source setup flow, create a feed-backed source, and continue into the existing inventory-feed upload and preview task without sending feed bytes through the model.
• Pinterest-connected storefronts now publish their current exact state and region catalog per storefront source and provider account. Unsupported ISO 3166-2 inclusion values can be refused before dispatch; exclusion behavior and other providers are unchanged.
• In the storefront Property Roster, sellers can explicitly re-check a publisher after publishing adagents.json and immediately see refreshed authorization, property identity, and creative-format catalog states. If the re-check cannot persist fresh state, it now asks the seller to retry instead of presenting the previous catalog as refreshed.
• A “needs attention” item raised for one failing check on an inventory source now stays open until no check reports a problem, instead of being closed the moment any single unrelated check succeeds. Previously a source with a real, unresolved problem on one check could have its item auto-completed by a different check’s success, so the problem silently left your queue while still being broken.
• Two related improvements come with it:
• Repeat alerts are quieter. A check that reports the same failure twice no longer re-raises, because each check is now compared against what that same check last saw, rather than against whatever check happened to write most recently.
• An item can no longer be raised for a source that has already recovered. If a source comes back while the item is being prepared, the item is skipped.
• Items are also reconciled against current evidence on a regular sweep, so one that no longer has any failing check behind it is closed within the hour rather than waiting for unrelated activity on the source.
• There is nothing to configure, and sources with no open issues see no change.

​

5.157.0 — August 14, 2026 at 6:10 PM UTC

• From connected TikTok buying, choose TikTok App In-App Event Optimization,
• then select an authorized app and one of its available in-app events.
• Interchange creates an app-install media buy optimized for that exact event,
• retains TikTok’s counting setting, and verifies the app, event, and counting
• setting before reporting success. Existing TikTok app-install buying remains
• unchanged.
• From connected TikTok buying, choose TikTok App Retargeting In-App Event,
• then select an authorized app and one of its available in-app events.
• Interchange creates a retargeting media buy for existing app users, optimized
• for that exact event, and verifies the campaign type, app, event, and TikTok
• counting setting before reporting success. Existing TikTok app-install buying
• remains unchanged.
• Ask Murph to see your advertisers — “show my advertisers”, “where do I start” — and it now opens your advertisers view directly instead of listing them back as text.

​

5.156.0 — August 14, 2026 at 2:16 PM UTC

• Add executable TikTok Instant Messaging App Clicks buying for Messenger,
• WhatsApp, Zalo, LINE, and custom HTTPS messaging destinations, with exact
• provider readback and full-composition certification.
• When a buy against a managed storefront couldn’t serve its creatives because
• your account wasn’t linked with that storefront, the error you saw said only
• “an underlying managed inventory source is unavailable” — nothing about how
• to resolve it. Now the same failure surfaces as a
• MANAGED_ACCOUNT_LINKAGE_REQUIRED error with a copy-pasteable sync_accounts
• request that points you at the linkage step: run it with that storefront to
• request an account, then wait for the seller’s approval. If you already have
• an approved account, sync_creatives accepts your opaque account_id
• directly, and the retry after approval proceeds even for buys created before
• linkage.
• sync_creatives also now authorizes an opaque account_id against the
• calling buyer principal — a caller cannot sync creatives against an account
• they don’t hold an active grant on. Buyer-side callers automatically resolve
• the calling principal’s opaque account for each MANAGED storefront route, so
• you don’t need to send it explicitly; if no active grant exists, the same
• actionable error surfaces.
• Source health and diagnostics now report what each individual check most recently found, rather than a single shared value that any check could overwrite. A source with an unresolved problem on one check no longer reads as healthy just because a separate, unrelated check succeeded. Sources with no open issues see no change, and there is nothing to configure.
• If you or a system you operate reads source health from the storefront readiness or diagnostics API rather than viewing it in the dashboard, three response fields change meaning (the shape is unchanged):
• lastSuccessAt now reflects the last success of whichever check is currently reporting the worst status, not the most recent success across all checks. If that check has never succeeded, lastSuccessAt can be empty even though a different, healthy check has a success history.
• lastErrorAt now clears as soon as the source is healthy overall, instead of continuing to show the time of an error that has since been resolved.
• On the storefront readiness endpoint, source health timestamps are now full ISO-8601 (for example 2026-06-18T12:45:00.123Z) instead of a plain-text database format (for example 2026-06-18 12:45:00.123+00). If your integration parses these as strings rather than dates, account for the format change. Diagnostics endpoint timestamps were already ISO-8601 and are unchanged.

​

5.155.0 — August 14, 2026 at 1:18 PM UTC

• Connected ad platforms now return a stable, certified adapter-executable wholesale seed without running brief interpretation, performance ranking, forecasts, or proposal generation. Each catalog identifies its static Scope3 pricing source, keeps retailer-specific products distinct, can be versioned reliably across repeated reads, and states that provider-UI parity is not yet certified.
• The inventory source example pack is now organized by the question each file
• answers, so you can distinguish production-importable inventory files from
• merchandising material, optional CRM context, lifecycle evidence, and proposal
• tests at a glance. Every file has a plain-language explanation and a copyable,
• collapsed example. The guide also clarifies that Scope3 creates seven-day Demo
• Storefronts, only a commit activates capacity, and channel is descriptive —
• declare the matching creative format for whichever channel you sell.
• The Prepare inventory source inputs guide now shows where it fits in storefront
• onboarding, numbers each step, and distinguishes required work from recommended
• supporting evidence. Its checklist names and lifecycle vocabulary now match the
• status your source actually reports. The campaign rehearsal also records stage
• modes separately from readiness, so an automated but blocked stage cannot be
• mistaken for a proven path.
• When you open a Sales Agent from Agents, the new Who this Agent can serve card shows whether it is ready for Partner operations and guides you to any required setup. Your existing first-party Sources keep working, and buyer-facing storefronts and labels do not change.
• Direct-adapter wholesale catalogs are now generated and certified against adapter execution manifests rather than their own template counts. Coverage metadata distinguishes product archetypes, audience signals, activation resources, and targeting overlays; classifies known blocked configurations; and makes clear that adapter execution coverage is not provider-UI completeness.
• Meta and TikTok brief plans now show the connected account resources needed to execute each product—including eligible Pages, forms, Pixels, identities, destinations, events, and creatives—and distinguish a safe unique selection from missing setup, buyer input, ambiguous choices, or unavailable provider inventory.
• Stop an approval from being offered for a file upload that could never run. When
• an action referenced an attachment that was not on the conversation turn, the
• Approve control still appeared, accepted the click, and then reported a failure
• that no retry could get past. Murph now catches the wrong reference before asking
• for approval and names the file it can actually use, so the upload can be
• corrected and committed in the same conversation.
• Murph now follows direct links between canonical Storefront guides and honors
• linked section anchors, improving answers that require evidence from more than
• one documentation page.
• When you upload a wholesale pricing feed in Murph chat and a row is rejected —
• whether on the preview or when a commit is refused — Murph now names the row
• number, the field, and the value that would pass, such as `row 7:
• effective_start_date must be an ISO date (YYYY-MM-DD)orrow 2: p75_cpm must be
• 1,000 or less`. A refused commit previously reported only how many rows failed, so
• you had to run another preview to find out what was wrong. A row priced in a
• currency your storefront cannot settle in now says which currency it needs.
• Correct the named rows and upload the file again; nothing else about your existing
• pricing changes.
• Snap and TikTok now interpret campaign objectives semantically instead of matching objective phrases with platform-local regular expressions. Recommendations fail closed unless the model returns a supported goal with evidence quoted directly from the advertiser brief and deterministic validation maps it to an executable catalog product.
• Gemini-backed brief planning and creative review now default to Gemini 3.7 Flash with low thinking. Flash-Lite is rejected as a planner override, and 3.7 low/medium remain paired in the recurring model frontier so quality, latency, and attributed cost can be compared.
• Connected TikTok product discovery now returns relevant products when a clear objective only needs geography, instead of presenting an empty catalog. Ready Meta and TikTok brief plans also carry the exact product, price, targeting, objective, and optimization snapshot needed to execute the returned choice safely.

​

5.154.1 — August 14, 2026 at 8:06 AM UTC

• The source input and authority worksheet now tells you what to put in it. Every input it asks about — inventory identity, availability, creative formats, reporting, and the rest — has a plain-language definition, each column says what belongs in it, and the page opens by explaining where in setup the worksheets are used. Every blank worksheet is now a copyable CSV you can paste straight into a spreadsheet instead of rebuilding the table by hand. Nothing you have already sent us needs redoing.
• When buyers choose post-engagement optimization for a Meta storefront media
• buy, the paused ad set now uses Meta’s required destination and can be created
• successfully. Nothing changes for buyers or sellers, and Instant Form lead
• buys continue to use their existing destination.
• Connected Pinterest accounts now expose provider-ready and eligible audiences
• as live signals. A complete account inventory with no live signals remains
• visible as non-live evidence instead of failing the conformance report; empty,
• incomplete, or cross-account feeds still fail. Nothing changes in buyer setup.

​

5.154.0 — August 14, 2026 at 7:24 AM UTC

• Plan & Billing now shows readable names and descriptions for every activity under calibration instead of raw translation keys.
• TikTok audience discovery now returns Customer File audiences for the selected
• advertiser as stable buyer audience IDs, with canonical pagination and
• account-scoped readback. Provider audience IDs remain private, giving buyer
• agents a consistent audience selection surface. Applying those audiences to
• TikTok media buys remains limited to the governed rollout while staging
• conformance completes.

​

5.153.0 — August 14, 2026 at 5:28 AM UTC

• Selecting an Agent from Organization → Agents now opens that Agent’s canonical page. Certification and Source destinations are unchanged, and there is nothing to change on your side.

​

5.152.1 — August 14, 2026 at 3:37 AM UTC

• If your Meta Traffic or Engagement campaign was failing to launch with an upstream error, that’s fixed. Nothing to change on your side — existing campaign setups will go through on the next attempt.

​

5.149.2 — August 13, 2026 at 11:34 PM UTC

• Third-party storefront discovery no longer goes empty for sellers that answer on the legacy AdCP wire. Account-scoped catalog fetches now use the SDK’s canonical get_products surface with the seller’s own format catalog (matching the wholesale catalog warm), including async task completions, so persisted catalog evidence always carries interpretable format_options and the canonical-format readiness audit no longer withholds the storefront over raw legacy format_ids it cannot map.

​

5.149.1 — August 13, 2026 at 11:03 PM UTC

• HTML5 creatives attached directly to a media buy now carry their width and height, matching creatives synced through the creative library. Sales agents that check a creative’s dimensions before accepting it no longer reject a buy for missing width/height, and resubmitting a media buy no longer clears dimensions a sales agent had already stored for that creative.

​

5.149.0 — August 13, 2026 at 10:47 PM UTC

• You can now register a supported inventory feed through the Storefront API or your agent, then use the returned upload steps to send inventory. Registering the same feed again returns the same feed, so retries are safe. If your storefront is set up to send inventory automatically, registration returns the push path; otherwise, it returns preview, upload, and commit paths. Existing feeds need no changes. Registration alone does not change what buyers see; buyer-visible inventory changes only after submitted feed data is committed.
• From the Agents page, your team can now open an Agent to see who operates it, whether it is certified and healthy, and what to do next. Sales Agents also show the Sources you are allowed to see, with links to Source diagnostics for health and mappings; private certification evidence and other organizations’ Sources stay hidden. Nothing changes in your current setup.
• Interrupted Google Ads Customer Match syncs now recover without creating duplicate audiences. Existing connections need no changes; Google account eligibility is still required.
• Google Ads Search and Display campaigns can now include or suppress synced Customer Match audiences and return the same buyer audience IDs in campaign readback. Existing connections need no changes; Performance Max and Demand Gen remain unsupported for this targeting.
• For buyers: Universal Ads now returns a clear error before making changes when a media buy includes unsupported region or package targeting, instead of misapplying or dropping those settings.
• For sellers: Storefront capability responses now reflect the targeting support of the connected inventory source, so buyers see accurate country and region availability. Billing support and defaults follow the explicit storefront or connected-provider contract rather than a legacy routing label.
• No action is required. Existing supported country targeting continues to work.
• Snap media buys can now include and suppress tenant-owned Customer List audiences by buyer audience ID, with exact targetability checks and buyer-ID readback. The signed staging canary remains disabled until the protected no-spend proof passes; existing legacy signals requests continue to work when canonical audience fields are absent.

​

5.148.0 — August 13, 2026 at 6:53 PM UTC

• Prospective buyers can now say whether they need a campaign management system or plan to use an AI agent, identify that agent when applicable, and describe their markets, channels, and timing. The commercial team uses those details to route the request. Submitting the form does not create an account, connect an agent, or grant access; access follows only after review and approval. Existing buyers do not need to take action.
• Universal Ads connection capabilities now show CRM audience sync as unsupported, and sync attempts stop before changing provider data. Existing connections need no reconfiguration; if you need CRM audience activation, choose a connected ad platform that reports audience sync support.
• Sellers with the modular sources capability can now send inventory feeds through authenticated Storefront API endpoints. You can preview pasted or uploaded static avails before committing them, commit a signed preview when it looks correct, or use the push endpoint for a single authenticated submit. Static avails and wholesale pricing feeds use the same source, contract, and tenant checks as the existing modular source setup.
• Action: no action is required for existing sellers. Existing sources, existing feed defaults, buyer-facing fulfillment, and runtime buyer behavior are unchanged. Nothing is converted automatically, and a seller must still have the existing modular-sources entitlement before creating or extending modular source feed workflows. Buyer impact is not applicable: this changes seller-side feed ingestion only and does not change buyer APIs, discovery, pricing, or media-buy behavior.
• Monetization: this does not introduce a new fee, buyer charge, billing meter, or UI package. Access follows the existing Enterprise modular-sources entitlement; any commercial value is through that existing entitlement and agreement path, not a new per-feed or per-request charge.
• Rollout and controls: rollout is gated by the existing modular-sources entitlement, not a new PostHog flag. Expansion means granting that entitlement through the existing admin entitlement ledger for approved seller cohorts. The kill switch is to stop granting or revoke the modular-sources entitlement for affected customers, which blocks new modular source composition and module attachment while leaving existing buyer fulfillment and runtime operations unchanged. Operational adoption is measured before expansion: at least one entitled pilot seller must complete preview, upload, commit, and push on a real modular source; stale baseline and invalid-token rejects must return the documented validation codes; and support must be able to diagnose any rejected row from the returned feed diagnostics without manual log inspection.
• Media buys across every storefront now reject an ISO subdivision before dispatch when a seller’s value-aware capability explicitly marks that inclusion or exclusion value unsupported. Buyers do not need to change valid targeting requests; an unsupported value now returns a validation error before spend begins. Existing seller boolean region declarations require no change. Sellers who want value-level preflight enforcement can publish structured inclusion and exclusion evidence under ext.scope3.storefront.geo_region_evidence; the standard AdCP media_buy.execution.targeting.geo_regions field remains boolean. Storefronts without namespaced evidence keep their current behavior. The deprecated supportedRoutingTypes v2 field now returns the same behavior-free compatibility values for every storefront; ROUTED and DECISIONED do not classify storefronts or control targeting.

​

5.147.0 — August 13, 2026 at 5:49 PM UTC

• Sellers can now price display and video inventory independently, even when both formats share the same ad-server selector. Add a format reference to each row in your wholesale pricing feed and the platform applies the matching rate; buyers then see the price intended for the specific format they requested. Existing selector-only pricing feeds continue to work unchanged — format references are optional and only needed when you want format-specific rates.
• Reporting no longer converts delivered spend on a media buy that was never booked cross-currency. When a source reports delivery in a currency it is not paid in, that is a labelling defect, not an exchange: applying a rate to it multiplied correct spend by a real exchange rate and returned a plausible, wrong number. Delivery spend is now converted only where the buy’s own booking evidence says the source is paid in the currency it reported. Where it isn’t, the daily view keeps the row in the reported currency and the summary view returns FX_RATE_UNAVAILABLE instead of a converted figure.

​

5.146.0 — August 13, 2026 at 4:54 PM UTC

• Fixed a crash that caused WAV and other large audio file uploads to fail with “No creatives could be saved from the upload.” The failure was a Node.js call stack overflow in the base64 validator when processing files larger than ~7.5 MB. Files are now accepted correctly.
• Fixed two defects in managed ESA media buy forwarding. HTML5 creatives now include their display dimensions when forwarded, resolving invalid creative rejections. Brand-safety signal exclusions now route to the correct targeting fields instead of being dropped by the GAM adapter.
• Merchandising Simulator proofs can now stay bound to one modular inventory
• source, with matching source evidence in API responses and the portable Page.
• Existing storefront-wide scenarios remain readable.
• When a buyer requests an account with your storefront, you can now approve
• them into an existing record in your ad server — the GAM Company, FreeWheel
• advertiser, or equivalent you already use for other advertisers you traffic.
• Their campaigns land against that record from their next media buy on. When
• you approve this way, you also state whose legal entity should be invoiced
• (the operator or the advertiser), so the invoice recipient matches the party
• you agreed to bill. Approving through Interchange billing and rejecting still
• work as before; this adds a third option for sellers who prefer to keep
• buyers inside their own account tree.
• Direct-billing is dark-by-absence until each seller opts in per the
• settlement-election spec, so ungated day-one behavior is unchanged for every
• buyer whose sellers do not use this decision. Buyers whose linked account
• flips from Interchange to direct billing will see the new invoice recipient
• when their sellers opt in and use this decision.

​

5.144.0 — August 13, 2026 at 9:52 AM UTC

• Buyer and seller reports now retain real delivery regardless of a media buy’s lifecycle status. Control-state buys without delivery remain absent from summaries, preventing unapproved or pre-seeded budgets from affecting pacing while ensuring contradictory delivery is never hidden.
• Sales agent webhooks now return 410 Gone when the sending agent is disabled, instead of being silently accepted. If your integration receives a 410, verify that your webhook sender is using your current active agent ID. You can look up your active agents via the AdCP API or contact support.

​

5.143.5 — August 13, 2026 at 8:41 AM UTC

• GET /api/v2/buyer/creative-dashboard-url now accepts an optional manifestId query parameter. When advertiserId, campaignId, and manifestId are all provided, the returned URL navigates directly to that specific creative manifest in the Interchange UI rather than landing at the campaign level.
• Power buyers and agency teams using the buyer REST API can now update packages[].targetingOverlay.audience_include and audience_exclude on an existing media buy. Only the named package’s audience lists change; its other targeting and sibling packages stay unchanged. Existing requests need no changes.

​

5.143.2 — August 13, 2026 at 6:12 AM UTC

• Fixed seller-adjusted demand revisions failing when an automatic approval tried to send the revised proposal.

​

5.141.12 — August 13, 2026 at 2:54 AM UTC

• Release the exact pre-fix Spotify rejection lease after verifying its reviewed zero-mutation evidence and immutable source.

​

5.141.11 — August 13, 2026 at 2:12 AM UTC

• Fixed Meta Engagement campaigns failing with “Upstream request failed” after setting pageId via update_media_buy on a multi-page account. The explicit page ID stored in the media buy is now correctly resolved and forwarded as promoted_object.page_id on the ad set. Meta API rejection details are now also surfaced in error responses to aid diagnosis.

​

5.141.10 — August 13, 2026 at 1:48 AM UTC

• Preserve Spotify’s safe audience-upload rejection code through the adapter boundary.

​

5.141.9 — August 13, 2026 at 1:00 AM UTC

• Pin the legacy Spotify canary’s text flight timestamp by digest before confirming paused containment.

​

5.141.8 — August 13, 2026 at 12:36 AM UTC

• Recover the exact interrupted staging Spotify canary only after fresh paused, zero-delivery containment is verified.

​

5.141.5 — August 12, 2026 at 10:46 PM UTC

• Sales agent registration and disabling now write an audit log entry, including for storefront-hosted agent rows that previously left no record. These entries appear in the storefront activity feed and record adcp_agent.updated_by so the row itself shows who last touched it.

​

5.141.3 — August 12, 2026 at 9:54 PM UTC

• Fixed two pacing period bugs that artificially constrained spend on replacement draft media buys (AI-6096).
• First, clearing per-buy pacing periods on a DRAFT or PENDING_APPROVAL media buy was incorrectly blocked when any period had already started. Since pre-execution buys have no deployed packages, clearing is always safe and is now allowed.
• Second, when a draft buy with per-buy pacing periods is executed mid-campaign, elapsed periods’ budgets are now redistributed into the remaining active periods rather than being silently dropped. This matches the behavior of the campaign-level pacing fallback path and ensures the buy’s full product budget reaches the seller.
• Meta governed CRM staging canaries now recognize the protocol’s explicit idempotent-replay marker while still requiring the replayed audience payload to match exactly.

​

5.141.1 — August 12, 2026 at 8:56 PM UTC

• Your one-time 100-IU credit now expires exactly 60 elapsed days after acceptance, regardless of billing-cycle dates. Settings → Plan & Billing and MCP Apps show the same stored expiry, and existing credits keep their original dates.

​

5.139.0 — August 12, 2026 at 7:48 PM UTC

• Your storefront can now decide whether a brief is worth answering, before your Merchandising Agent composes anything. Set a selling doctrine on your Playbook: a minimum category fit to respond, how readily you counter-pitch instead of walking away, and what to do when a stated budget meets an unpriceable catalogue. Your Merchandising Agent then pitches the brief in full, counter-pitches with a credible reframe, or passes with a short, branded decline. Adopt a named starting point (premium_scarcity_house, volume_partner, consultative) or set your own numbers. Doctrine rides the same Playbook versions you already author, so reverting means activating the previous version, and every decision is recorded on the proposal pass with the doctrine version and the rule that reached it. On a pass your storefront withholds the composed proposal and returns its existing no-fit response shape, so a buyer can’t tell a decline from nothing having matched; passthrough inventory and already-finalized proposals still ship. The decline is recorded for you, not sent to them.
• Signing out now fails safely: if the sign-out request doesn’t reach the server, you stay signed in and see an error instead of a false “signed out” screen. This matters most on a shared or public computer, where the previous behavior could leave your session active even though the screen showed you as logged out.
• A brief that a storefront’s Merchandising Agent genuinely has nothing for now returns a normal empty product set instead of an INVALID_REQUEST error. AdCP has one shape for “no bid” — an empty catalog — and this aligns the composer’s silent no-fit with it, so your agent can treat every empty discovery the same way. A seller who deliberately authors a decline note in their rulebook still sends it; only the default silent no-fit changed. An empty catalog is also, by design, all your agent sees when a seller’s own selling rules chose not to answer a brief — the two are deliberately indistinguishable, so treat any empty discovery as “nothing here for this ask” and move on or re-brief.

​

5.138.0 — August 12, 2026 at 6:42 PM UTC

• If your operator domain was saved with an https:// prefix, that prefix is now stripped automatically. Nothing to change on your side.
• Agencies and consultants verifying a client domain: you can now self-serve verification from account settings instead of filing a support request. Two paths are available:
• Verify via AAO: If your agency’s work-email domain matches the operator domain you’re claiming, sign in through your AdCP Alliance Organization account. Verification completes automatically.
• Request manual review: If the operator domain belongs to a client whose email domain differs from your agency’s, submit a review request from account settings. Scope3 reviews within one business day and follows up on the outcome. This path resolves email-domain mismatches only. If the stored operator domain itself is wrong for your account (for example, it points to the wrong client), contact Scope3 support to have it corrected — manual review will not resolve that case.
• Already verified and transacting? No action needed. Verification status and transacting access are unchanged for existing accounts.
• A verified operator domain is a transacting prerequisite. There is no separate charge for verification.

​

5.137.0 — August 12, 2026 at 5:47 PM UTC

• Seller Setup and modular source diagnostics now show the same setup progress and next action for each modular source. If a feed row’s publisher properties or creative formats cannot be verified against that source’s current Property Roster, the row is rejected; resolve the shown issue before committing the feed. Existing valid feeds need no changes.
• Your organization now receives its one-time 100-IU setup credit when it accepts its first IU plan through Plan & Billing or Murph, including for an existing account. Retries and later plan revisions do not create another credit.

​

5.136.0 — August 12, 2026 at 4:31 PM UTC

• The inventory source input guide now provides copyable files through a public example-pack page, distinguishes complete external-agent pass-through from sources that need inputs supplied separately, names the built-in provider paths, and organizes setup around five customer questions plus explicit operating tracks.

​

5.135.0 — August 12, 2026 at 3:38 PM UTC

• Account analysis now presents campaign health, format performance, and metric labels in consistent sentence case — status values like “Needs attention”, “Behind”, and “Above benchmark” read cleanly instead of raw lowercase, while metric acronyms (CTR, CPM, ROAS…) keep their standard casing. No action is required.
• Agent collection rows now open their canonical Agent Page in the web app.
• Buyer discovery no longer withholds a third-party pass-through sales agent
• because a product from an older, brief-specific response remains in its local
• history. Interchange now evaluates the source’s newest live response alongside
• its seller-authored catalog. Unresolved products in that current evidence are
• still withheld.
• Previously returned product IDs remain protected: if a buyer later tries to
• purchase one, Interchange checks that exact product’s format declaration before
• forwarding the media buy.
• Enrolled sellers can open the legacy Source mapping workspace reliably again. Access remains limited to enrolled customers, with nothing to change on your side.
• v3 search for creative and creative_collection now supports cursor-based pagination. Previously the result was capped at 100 rows with hasMore: true and no nextCursor, leaving items past the first page unreachable. Pass limit (up to 200) and the returned nextCursor to page through large sets.

​

5.134.0 — August 12, 2026 at 2:41 PM UTC

• Approved storefront media buys with no creatives attached now reach the sales agent instead of being rejected. Forwarding added an empty creative_assignments list to each package, which AdCP does not allow — the field must name at least one creative or be omitted entirely. Buys that are booked before their creatives are ready now forward with the field omitted, and the seller reports them as awaiting creatives. Assignments the buyer has since cleared are no longer forwarded from the frozen request, and a package carrying inline creatives forwards untouched while its creatives still match the buy.
• Creative syncs to a storefront no longer fail when the seller has accepted a creative but has not yet placed it on an ad server. A seller’s platform creative ID is now recorded as evidence whenever it arrives — on the sync acknowledgement or on a later creative webhook — rather than being required up front. A seller that echoes the buyer’s own creative ID back as its platform ID is still reported as unconfirmed.
• For buyers: a creative you sync to a storefront before assigning it to a package now reports as synced instead of failed, and its platform ID fills in once the seller’s ad server issues one. Nothing changes in how you call sync_creatives, and no action is needed on your side.
• For sellers: a creative you have accepted but not yet trafficked now registers as synced on the buyer’s side instead of showing as a failed sync against your storefront. Nothing changes in what you send — report your platform creative ID once your ad server issues one, and keep sending it on the acknowledgement when you have it there.
• Campaign delivery now loads correctly after a single-storefront media buy is created through Interchange. No action is required.

​

5.133.1 — August 12, 2026 at 12:54 PM UTC

• Provider-backed campaigns now return delivery and accept updates using the correct platform campaign while keeping the same buyer-facing media-buy ID. Nothing changes in buyer requests or responses.
• Third-party storefront catalogs no longer go stale indefinitely on the buyer
• discovery path. Cache-only product reads now revalidate a stale catalog in the
• background instead of serving the same cached products forever. Previously, a
• third-party source whose live discovery calls chronically timed out could
• serve month-old products, which newer creative-format validation then filtered
• out entirely - surfacing as empty discovery results and failed media buy
• submissions for otherwise healthy sellers.

​

5.133.0 — August 12, 2026 at 11:38 AM UTC

• Audience syncs now fail safely unless a connected platform can prove it can create, update, use, and remove the exact customer list. Meta, Snap, and TikTok receive continuous lifecycle verification; Spotify refuses unverified uploads; and Google, LinkedIn, Pinterest, and Reddit remain unavailable for governed sync until their safety checks are complete. Buyers do not need to take action. Seller storefront display and readiness are unchanged.
• Meta Sales media buys now accept a pixelId field on product selections so buyers can specify which Meta Pixel / Dataset to use for conversion tracking. Pass pixelId in create_media_buys selections, add_discovery_products selections, or update_media_buy product entries. Unlike pageId, there is no auto-select: every Meta Sales (OUTCOME_SALES) buy must explicitly specify a pixel.
• Partner organizations can now use one accepted Offer to operate a certified sales agent for explicitly authorized client organizations. In the Partner page and Partner access API, accepting the Offer grants the paid operating right after payment, ownership, registration, and certification are current. An existing Partner needs an Offer that expressly includes this right before operating for an unrelated client; free Partner registration, testing, and certification are not converted or removed.
• This pilot does not add a buyer-visible badge, directory placement, promotion, or ranking change. Certified Partner listing remains a separately verified manual program, and any Featured Partner placement is labeled and cannot affect organic ranking or Murph recommendations. Existing Partner API integrations do not need to change immediately: featureKey keeps its legacy value during the v2 rollout, while the additive entitlementFeatureKey identifies the paid right. New and existing Partners can review the operating boundary in Partner Program and agent operations.

​

5.132.0 — August 12, 2026 at 10:50 AM UTC

• Use the Prepare your inventory onboarding materials guide to separate
• operational source truth from merchandising decisions. Sellers can download
• CSV and JSON compatibility templates validated against
• static-avails-feed:v1, complete a source-authority worksheet, and rehearse a
• fictional campaign while seeing
• exactly which files are production-importable, supporting evidence, manual
• pilot steps, or gaps. Existing inventory-source behavior is unchanged.
• The compatibility templates retain the parser’s exact legacy collectionId,
• collectionName, and collectionDescription fields; those values do not
• establish AdCP Collection identity, and the templates are not the target
• Inventory Feed schema.
• Activating, archiving, or renaming a product in Inventory Components works again. The widget sent the change as a full product replacement while carrying only the field you touched, so the sales agent rejected it for the name and inventory such a body leaves out — the product stayed in Draft behind a REST call failed (400). Edits now send only what this surface edits — Activate and Archive send the status alone, the edit form sends name, description, and status — so the pricing, coverage, and formats it never shows you keep their stored values. The edit form also opens with the product’s current name, description, and status filled in instead of blank.
• For anyone changing a product through the API: the partial-update endpoint is now reachable over REST as PATCH /api/v2/storefront/esa/{esaId}/products/{productId}, and both it and the patch_esa_product operation take the partial-update body the sales agent documents — a field sent as null keeps its stored value instead of being rejected. The Storefront API reference now shows that body.
• Meta CRM audiences now keep their buyer identity when provider metadata is
• temporarily omitted, and governed test fixtures are deleted and verified by
• their exact provider identities.
• Creatives you submit to Meta now appear in list and get responses exactly as
• submitted, with nothing to change on your side.

​

5.131.0 — August 12, 2026 at 8:43 AM UTC

• Storefront health now reports Available, needs attention when one external
• sales-agent source is withheld for unresolved product formats while another
• source continues serving buyers. The affected source keeps its independent
• connectivity result, so a successful Agent response is not mislabeled as an
• outage.

​

5.130.1 — August 12, 2026 at 6:17 AM UTC

• Meta media buys now accept a pageId field on product selections so buyers can specify which Facebook Page to use when the connected Meta ad account has more than one authorized Page. Pass pageId in create_media_buys selections, add_discovery_products selections, or update_media_buy product entries. When the account has exactly one authorized Page the field remains optional and the server selects it automatically.

​

5.129.1 — August 12, 2026 at 5:03 AM UTC

• Buyer discovery no longer withholds a third-party sales-agent source merely
• because its last interpretable product-format declaration crossed the catalog
• cache freshness window. Catalog refresh continues independently. Unresolved
• formats and sources with no persisted declarations remain withheld. Other
• healthy sources in the same storefront continue selling.
• Sellers do not need to republish an otherwise valid canonical declaration or
• exact shared-catalog legacy reference just because its cached snapshot aged. A
• corrected declaration takes effect on the next readiness evaluation after the
• refreshed product is recorded.
• New Rate Cards now omit human expert support, audio/video understanding, and modular source management as separate Intelligence Unit activities. Human support and modular-source access remain Enterprise contract terms, while audio transcription used with Murph stays included in the Murph session. Sellers do not need to update existing accepted Rate Cards or Offers: their immutable activity schedules remain unchanged.

​

5.128.0 — August 12, 2026 at 3:16 AM UTC

• When a buyer or seller/storefront organization has an IU plan offer, its organization admins can review the exact terms of the selected Rate Card plan in Settings → Plan & Billing and in the portable IU-plan authorization task. Each offer shows whether it uses the plan’s standard terms or explicit customer-specific customizations.
• No action is required. Existing accepted offers, including accepted 250-IU terms, remain unchanged, and existing V2 API requests continue to behave as before. This release does not republish or change the staging Rate Card.

​

5.120.0 — August 11, 2026 at 8:49 PM UTC

• TikTok creative inventory drift errors now include a precise, identifier-free reason, helping buyer integrations distinguish stale inventory, format provenance, and provider digest conflicts without changing requests.
• Set a fixed CPM when you create a product
• You can now give a product a fixed rate as you author it. Asking for one in Murph chat used to fail with unsupported product fields: pricing_options, and the only way to create the product was to drop the price — which shipped it as an auction with no floor, so buyers never saw it.
• This matters most when one ad-server selector needs more than one price. An uploaded pricing feed keys each row on the selector, so a single ad unit serving both display and video gets the same price for both. A rate set on the product is per-product: create one product per format and price each one on its own.
• The rate must be in your storefront’s settlement currency — there is no FX. If it isn’t, the product is still created but stays hidden from buyers, and the response now tells you which currency was wrong instead of leaving you to find an invisible product.
• TikTok carousel creatives remain available when the provider’s broader image search takes longer to publish their readiness details. Nothing changes in buyer requests.
• When a buyer’s OAuth connection to an adapter storefront (such as Meta Ads) becomes invalid, discover_products previously returned 0 results with no explanation — indistinguishable from a genuine empty inventory response. Buyers now receive a connectionIssues signal in the response indicating that the connection needs re-authentication, so the problem is visible rather than silent.
• No action is required beyond reconnecting the affected account via Settings > Connections. Once re-authenticated, product discovery resumes automatically.
• TikTok creative inventory now ignores non-reusable external-identity assignments regardless of the material fields TikTok reports for them, preventing those account-owned ads from blocking buyer media-buy creation. No request changes are required.
• When TikTok rejects creative image evidence, buyer integrations now receive a precise validation_reason for invalid single-image counts, carousel counts, or image formats. No request changes are required.
• The Murph agent debug-calls lookup (GET /api/v2/murph/agent-debug-calls) now honors and echoes the lookback window it applied. Every response includes a window object reporting the hours covered, the hours you requested, and the exact start/end timestamps — so a short lookback can never be mistaken for a longer one. windowHours is now documented and bounded to 1–720 (30 days); values above 720 return 400, and omitting it defaults to a 7-day window instead of an unbounded most-recent scan.
• AdsWizz-connected storefronts now keep order status and booked-flight checks
• working when their agency credential has limited order-read permissions.
• Existing buy dates are unchanged, and no action is required.
• Make storefront discovery previews and source tests distinguish a completed empty seller catalog response from discovery that stopped before a seller get_products round-trip.
• A storefront no longer hides its entire product catalog when one inventory source cannot be format-audited. A single source with stale or uninterpretable product-format evidence used to block everything: get_products returned no products and every media buy was refused, including for healthy sources whose formats were perfectly valid. That source is now withheld on its own, so the rest of the catalog stays discoverable and buyable. A buy that does route to a withheld source is refused with a distinct reason rather than an unknown-product error, so a buyer agent can tell “try again later” from “wrong product id”.
• For sellers, this changes what one troubled source costs you: the rest of your storefront keeps selling instead of going dark, and only the affected source is held back until its formats can be read again. Product-format evidence for third-party sales agents now refreshes on its own as well, so it no longer expires while your storefront waits for the buyer request it was being blocked from serving. Nothing to change on your side.

​

5.119.1 — August 11, 2026 at 1:08 PM UTC

• Ignore externally managed TikTok Spark assignment formats that are not reusable advertiser creative inventory.

​

5.119.0 — August 11, 2026 at 12:58 PM UTC

• Buyers can now ask Murph to open Notifications and review campaign and account events. Sellers can open the same Page to review storefront events and manage Product Updates and source-health alerts in their primary Slack channel. No setup is required. Read and acknowledged states remain separate for each recipient. Slack, email, and webhook delivery never changes either state. Release history remains in the separate Release notes Page.
• Keep TikTok reusable creative inventory available when an advertiser also contains ads backed by provider identity types that cannot be reassigned through authorization-code inventory.
• Reconnect your existing Reddit Ads connection once in Settings → Connections so it can keep working after the initial one-hour token expires. New and reconnected Reddit Ads connections refresh automatically.
• Murph can now look up your storefront’s published brand identity without asking you to approve a read-only action or losing the action between turns. Direct storefront API behavior is unchanged.

​

5.118.0 — August 11, 2026 at 11:49 AM UTC

• Enrolled sellers can use get_delivery on /mcp/v3 to query up to 90 days of seller-reported delivery or cumulative storefront margin in pages of up to 100 rows; the response makes unavailable values and pagination explicit, and neither buyer measurement nor /mcp/v2 behavior changes.
• Keep TikTok reusable creative inventory available when an advertiser also contains linked-account Spark ads that cannot be reassigned through authorization-code inventory.

​

5.117.0 — August 11, 2026 at 10:58 AM UTC

• Meta Engagement campaigns can now be created successfully. Previously, any attempt to launch an Engagement campaign failed with a generic “Upstream request failed” error. No storefront configuration changes are needed — previously failed campaign creation requests should be retried.
• If your storefront uses AdsWizz and you want to open new buys, confirm the
• currency in your ad-server setup with your Scope3 contact. Interchange applies
• that currency to every AdsWizz campaign and checks any optional CPM ceiling
• before sending it. New buys remain closed until Scope3 independently verifies
• that AdsWizz accepts the currency; existing live buys keep running and need no
• action.

​

5.116.0 — August 11, 2026 at 10:34 AM UTC

• Accept TikTok’s empty non-applicable ad material fields without weakening validation of reusable creative evidence.
• The v3 agent surface now supports the creative_collection noun for non-executable grouping and joint review of creatives. Buyers can search, read, create, update, and manage collection membership through search, get, and save_creative_collection.

​

5.115.2 — August 11, 2026 at 10:16 AM UTC

• Keep TikTok reusable creative inventory available when an advertiser also contains provider-managed catalog carousel or live-content ads.

​

5.115.1 — August 11, 2026 at 9:16 AM UTC

• Keep TikTok creative inventory usable when an advertiser contains externally authored carousel ads, while preserving strict ownership checks for adapter-managed carousel assets.

​

5.114.5 — August 11, 2026 at 6:57 AM UTC

• Murph now shows storefront product results as they arrive in one live discovery view, labels provisional totals as “so far,” and waits for completion or the buyer’s explicit choice to continue before showing recommendations. Wait explanations stay specific to an individual storefront’s observed outcome instead of generalizing latency across countries, regions, or groups of sellers. For sellers, buyer-facing status now uses neutral storefront-specific outcomes without characterizing the seller, its geography, or its peers as slow.
• discover_products and browse_discovery now surface a connectionIssues field when an adapter OAuth credential (e.g. Meta, Snap) has expired. Previously, products from that storefront were silently omitted with no indication that re-authentication was needed. The new field names the provider and affected storefront so the buyer can navigate to Settings > Connections to reconnect.

​

5.114.4 — August 11, 2026 at 6:30 AM UTC

• Background meeting reconciliation now leaves exhausted, unchanged Zoom transcripts terminal instead of retrying them indefinitely. Source-health notifications can also recover when Murph can join a public customer channel but the provisioning bot cannot invite it. No action is required.

​

5.112.0 — August 10, 2026 at 11:57 PM UTC

• create_media_buys and update_media_buy now warn as soon as a media buy is staged or updated if the owning campaign’s pacing schedule has no period covering today or later — instead of only failing later when you try to execute. The warning tells you to call update_campaign with pacingPeriods covering the new dates before executing.

​

5.110.0 — August 10, 2026 at 9:55 PM UTC

• Sellers now get notified about a few more storefront issues they can actually fix, like rejected delivery reports or a sales agent responding with errors, instead of only finding out by checking the storefront dashboard.

​

5.108.0 — August 10, 2026 at 6:48 PM UTC

• Organization account admins enrolled in Organization Agents can open the Agents collection and choose Create Agent to register a private Agent. Choose a claimed operator or name a new one, then continue in Agent Overview. This does not connect a Source, publish the Agent, or change existing Agents.
• Spotify connected account sync now reuses media buys created through its legacy direct adapter flow instead of failing on a duplicate. No action is required.
• Preserve authenticated Spotify account identity when reading media buys so account sync can safely reconcile legacy direct-adapter campaigns.
• Delivery reporting no longer records a zero-impression day when a publisher’s sales agent reports that it has no delivery data for that day yet. Previously the day was stored as zero, and because a past day is never re-read, that zero was permanent — a campaign that was delivering could report zeros indefinitely. The day is now left absent until real figures arrive, and the source’s reporting is no longer counted as healthy on the strength of a response that reported nothing.
• Publishers need take no action, and nothing changes in what they are asked for or shown: their own reporting is unaffected, and a day their ad server could not report yet is now recorded as pending rather than as zero delivery. The one indirect effect is that a sales agent whose reporting is genuinely not returning data will no longer be counted as healthy on those responses, so a real reporting outage becomes visible instead of looking like a campaign that simply did not deliver.
• Creative sync now reports the state your seller actually sent, instead of a
• state we filled in. A seller may acknowledge a creative without stating a review
• status — the ad protocol allows it, and it means “accepted, nothing further to
• report”. We substituted “processing” and then read our own guess back as a
• seller-side stall, so a creative the seller had accepted showed as failed with
• “is processing and is not live”. That invented status is gone.
• Several related misreports go with it, all in the same direction: a creative
• that was not ready being shown as ready. A creative is still only reported live
• once the seller names it on their delivery platform.

​

5.107.0 — August 10, 2026 at 5:17 PM UTC

• Buyers now see clearer storefront language that distinguishes a seller’s wholesale price from your price and explains advertiser routing, with no workflow change. Sellers now see plain mapping and coverage labels across setup, exports, and guidance, making it easier to confirm which catalog details are ready for buyers; no setup or API behavior changed.
• Organizations enrolled in the Agents preview can now review the software
• Agents they operate, including their certification and implementation-health
• summaries. A storefront can also see the Agent that powers its own Source
• without exposing other organizations’ connections or credentials.
• Connected account sync no longer fails or creates a duplicate when it finds a media buy placed through an older adapter route. No action is required.
• Expanded buyer and seller chat widgets now scroll through their full content without requiring per-widget host configuration.
• Fixed get_storefront_reporting_metrics returning zero impressions and spend for media buys delivered through managed ad-server sources. Reporting now correctly includes delivery data for all source types on a storefront.
• Storefront logos now come only from identity asserted through brand.json or the AAO registry. If no authoritative identity exists, the storefront shows no resolved logo instead of substituting one inferred from a website or enrichment service. Murph also keeps unsupported flat-rate, time-based, click, and engagement pricing in their original commercial units rather than translating them into invented CPM or impression figures, and explains that a storefront run by experts uses the canonical https://interchange.io publisher-authorization identity rather than its buyer-facing MCP endpoint.
• The v3 agent surface now supports the creative noun. Buyers can search, read, create, update, and archive creatives through the standard v3 verbs (search, get, save_creative). Campaign creatives are also available via get(kind: 'campaign', include: ['creatives']). This is the BYO-first slice: generation sessions and collections are separate follow-up nouns.
• Storefront media buys now reject stale or invalid creative-format selections before entering manual approval, instead of failing only after seller review.

​

5.106.0 — August 10, 2026 at 3:38 PM UTC

• Connected account sync now reuses the buyer’s existing campaign when the provider returns the same media buy, instead of failing while attempting to create a duplicate.

​

5.105.0 — August 10, 2026 at 2:56 PM UTC

• When you upload a zip containing files that Murph doesn’t recognize (for example, an HTML5 ad bundle packaged as a nested zip), those files now appear in a notice telling you which ones weren’t added and why. Previously they were silently dropped with no feedback.

​

5.104.0 — August 10, 2026 at 1:01 PM UTC

• Add an advertiser right in chat. Click + Add advertiser or just ask Murph
• (“add an advertiser called Acme at acme.com”) and a guided form opens,
• pre-filled with whatever you said — fill in the rest, and it creates the
• advertiser and links its brand. When it’s done, Murph confirms and can switch
• you straight into the new advertiser, with Switch into it and **Add
• another** actions right on the form.

​

5.102.0 — August 10, 2026 at 10:21 AM UTC

• Creative sync status now includes the publisher’s public AdCP agent or inventory
• source identifier in sourceId. The existing agentId remains unchanged for
• compatibility. Approvals, history, and seller workflows are unchanged, and no
• action is required.
• Discovery Card and Business Rules now use the full available Page width, keep long content reachable through one dependable scrollbar, link brand management to the identity’s real owner, and make worldwide country coverage explicit when editing legacy cards.

​

5.100.0 — August 10, 2026 at 8:55 AM UTC

• Managed ad-server sources now prove their execution currency before they can be connected or accept a new buy. The storefront checks that currency against the seller’s settlement currencies, rechecks it after credential changes, and no longer assumes USD when an adapter has not supplied a currency. Existing buys keep their original currency while a mismatch is repaired.

​

5.99.0 — August 10, 2026 at 7:16 AM UTC

• Canonical product discovery and forwarding now use the SDK’s supported additive projection and durable legacy-route sidecars while keeping advertised format options URL-free.

​

5.98.0 — August 10, 2026 at 6:36 AM UTC

• Reddit campaigns without an update timestamp now sync correctly; no buyer action is required.

​

5.97.0 — August 10, 2026 at 6:01 AM UTC

• LinkedIn connections now ignore legacy personal ad accounts during discovery, so setup completes when supported business accounts are available. Nothing needs to change on your side.
• Reddit media-buy sync now remains compatible when Reddit adds a new raw campaign status, using the campaign’s configured lifecycle status for buyer-facing state and actions.
• When buyers create a media buy through a provider-policy-owned social storefront (LinkedIn, Meta, Pinterest, Reddit, Snap, or TikTok), the storefront no longer reports itself unavailable solely because it has no Interchange acceptance policy. The social platform continues to apply its own review rules, while adapter and managed storefronts configured for Interchange approval still require an active policy and approver routing. Nothing to change on your side.

​

5.96.1 — August 10, 2026 at 5:42 AM UTC

• Snap storefront account sync and media-buy reads now complete when Snap omits redundant account ownership or returns empty demographic targeting. No action is required.
• Fixed execute_campaign failing with “This storefront is blocked and cannot accept media buys” for adapter storefronts on accounts that own multiple storefronts. The eligibility check now evaluates the specific target storefront rather than an arbitrary storefront belonging to the seller.

​

5.96.0 — August 10, 2026 at 5:25 AM UTC

• Before connecting a new ad server, confirm the default and payment currencies in Storefront setup. The connection then verifies its execution currency instead of assuming USD:
• For AdsWizz, enter the agency billing currency in the ad-server connection form.
• Google Ad Manager discovers its supported currencies automatically.
• FreeWheel and SpringServe use the confirmed storefront default.
• Already live? Existing buys keep their original currency. If the ad-server connection reports a missing or mismatched currency, update the Storefront currency settings or reconnect the ad server before accepting a new buy.

​

5.95.2 — August 10, 2026 at 4:42 AM UTC

• Buyers can update creatives while a media buy awaits storefront approval without losing those changes when the buy is forwarded. Storefront operators receive the forwarded media buy with the buyer’s latest creative assignments intact. Neither audience needs to take action. Background reconciliation and source-health checks now retry transient provider failures without repeated alerts.
• When you buy through a connected Reddit account, product discovery now returns the full wholesale catalog without a brief, and campaign syncs use the credential attached to the selected account. Nothing to change on your side.

​

5.95.1 — August 10, 2026 at 4:21 AM UTC

• Forced publisher-agent discovery refreshes now return the latest authorization directly from the publisher’s live adagents.json, including newly added or removed agents, while the registry mirror catches up. The response keeps the registry’s last-validation timestamp and identifies the live origin as its freshness source, so a stale crawl timestamp no longer means the refreshed authorization was ignored.

​

5.95.0 — August 10, 2026 at 4:13 AM UTC

• Discovery Card logos with transparent backgrounds now receive a contrast tile in both seller setup and Marketplace, so light or dark artwork remains visible instead of disappearing into the card.

​

5.94.0 — August 10, 2026 at 3:16 AM UTC

• Murph now presents updates to an existing ask with the correct ask reference and requester state instead of describing them as a new, unrecognized ask.
• Pass-through media buys now preserve source-authored canonical creative format selections when forwarding, preventing valid buys from failing before they reach the source sales agent.

​

5.93.11 — August 9, 2026 at 4:32 PM UTC

• Preview accounts can now use the Inventory sources selector at the top of the seller rail to switch between the overall Storefront and an exact source, or add another source. Each source opens its established detail page. The mapping-workspace preview is no longer shown in the UI, while existing API compatibility reads continue to work. No setup or integration change is required, and product delivery, pricing, and packaging are unchanged.

​

5.93.10 — August 9, 2026 at 4:12 PM UTC

• Storefront composition now preserves selectable creative formats and their exact delivery routes when a wholesale source publishes legacy formats only.

​

5.93.9 — August 9, 2026 at 3:17 PM UTC

• Media buys against pass-through inventory now reach their source when the buyer picks a creative format from a source that publishes its formats in the legacy form. Product discovery already offered those formats as canonical options, but the forwarding step did not recognise the option ids it had just advertised, so an approved buy failed with invalid_format_selection and could not be retried. Discovery and forwarding now read a source’s legacy formats identically, so this holds however the source declares them. A package that selects several of a source’s legacy formats now forwards all of them.

​

5.93.3 — August 9, 2026 at 12:41 PM UTC

• Buyers now see reliable Discovery Card logos, a consistent description label, and the seller’s complete description instead of a trapped scrolling field.
• Sellers editing a managed Discovery Card in Seller Setup must now choose at least one accepted country or select every country before saving. Existing cards remain visible until they are edited, and sellers who already listed countries do not need to do anything.
• Buyers filtering Marketplace by country will still see a storefront when that seller has not yet finished listing where it sells, so existing sellers do not disappear during this update. A storefront that names supported countries appears only in those countries, and one that explicitly supports none stays hidden. Buyers do not need to take action.

​

5.92.2 — August 9, 2026 at 10:37 AM UTC

• Reddit audience signals and campaign syncing now complete reliably instead of failing on valid Reddit responses. No action is needed.

​

5.92.0 — August 9, 2026 at 6:48 AM UTC

• Meta creative retries after a rate limit or rejected sync are now safer: they avoid duplicate ads and reuse existing uploads when possible. No action is needed on your side.

​

5.91.0 — August 9, 2026 at 5:18 AM UTC

• Your storefront now writes the argument behind a proposal, not just the plan. When a brief arrives, your Merchandising Agent composes a pitch that leads your proposal pass in the demand inbox: a thesis for why this plan fits this buyer, each product’s role and its fit, what will and won’t be measured, the case for the price, and an honest note on anything the brief asked for that your catalogue doesn’t cover. The product table moves below it, unchanged, as the plan appendix. Every sentence in the pitch cites the brief, your inventory and product data, your Playbook pricing, or your Playbook instructions — an unsourced sentence is dropped before you see it. That’s why a thin setup reads plainer: audience-size claims and superlatives have no source in the platform today, so they never compose, while a maintained rate card and a written Playbook give the pitch more to argue from. The pitch is included in your existing storefront plan — no new billable surface. Buyers still receive products and prices exactly as before; the argument is on your side of the exchange for now.

​

5.90.0 — August 8, 2026 at 9:05 PM UTC

• When you assign creative to a Meta media buy, temporary provider failures are now retried automatically without risking duplicate ads. Terminal failures no longer expose raw provider details. Nothing to change on your side.

​

5.89.1 — August 8, 2026 at 8:10 PM UTC

• Signing in to Interchange now remains available when an OAuth integration repeatedly retries an expired session. No action is needed on your side.

​

5.89.0 — August 8, 2026 at 7:39 PM UTC

• For completed v3 requests, Activity call records now list each buyer or storefront API operation routed through the compatibility layer, in order. This makes retries and downstream failures easier to diagnose; cancelled requests report the evidence as unavailable instead of showing a partial history. Nothing to change on your side.
• On each Source page, you can now review coverage separately for Storefront-built products and products supplied by a connected Agent. Existing Sources need no action. A Needs attention section names the owner and next step: Storefront catalog or routing gaps identify what to provide to Scope3 support, while Agent-owned product gaps must be corrected in the connected Agent and resynced. A catalog that has not synced successfully is shown as unavailable instead of empty. Direct mapping edits are not yet available in these workspaces, and Agent-supplied products remain read-only in Interchange. Switching product modes keeps inactive mappings for later without applying them to current products. Product paths are not separately priced, and buyer API fields, product labels, ranking, and delivery behavior do not change.
• On the Connections page, you can now unlink an ad platform connection from its card or detail view. Unlinking stops future syncs and campaign subscriptions for every advertiser using the organization-level grant. Historical reporting and advertiser mappings remain.

​

5.88.0 — August 8, 2026 at 6:02 PM UTC

• Buyer and seller REST integrations can now pass clientRunId to
• GET /api/v2/activity/calls; list and detail responses also expose nullable
• clientRunId and server-observed apiVersion. clientRunId is caller-supplied
• correlation, not independent provenance: cross-check workloadUid, runUid,
• apiVersion, and the time window. Results remain account-authorized, and
• service tokens remain restricted to their workload. Existing integrations
• require no changes unless they adopt the optional filter or fields.

​

5.87.2 — August 8, 2026 at 5:20 PM UTC

• Buyer supply requests now save against the authenticated Interchange account even when it has no Linear customer association. Repeating a withdrawal safely reports that there is nothing left to remove. No customer action is required.

​

5.87.0 — August 8, 2026 at 4:15 PM UTC

• Pausing Meta media buys now succeeds when Meta omits disabled manual-placement controls from its response. Nothing needs to change on your side.
• Product authoring now presents every publisher coverage option declared by the inventory source, including property tags, without implying that publisher verification is required. This seller-authoring change does not affect buyer-facing storefront rendering.

​

5.86.2 — August 8, 2026 at 3:44 PM UTC

• Pausing Meta media buys now succeeds when Meta omits an optional placement setting from its response. Nothing needs to change on your side.

​

5.85.0 — August 8, 2026 at 1:57 PM UTC

• Enrolled sellers can now open an Inventory Source page to see whether Scope3 builds products from that Source’s inventory or the connected Sales Agent supplies finished products. This is operational context only: it does not change how buyers discover, rank, name, or buy the seller’s products, and neither option is priced separately. Existing active Sources keep their current behavior and need no action. If an inactive Source says its product setup is unresolved, ask the Sales Agent provider to confirm what it supports; Scope3 support owns the follow-up selection when both approaches are supported. The Source remains inactive until that setup is resolved. Buyer API fields, product labels, and delivery behavior do not change.
• You can now see delivery reporting problems as a diagnosis on your source, alongside the inventory problems that were already there. If a source returns a delivery report we can’t accept, the diagnosis names the exact field that failed validation, so you can fix the cause instead of guessing from a generic failure. Selling is unaffected while one of these is open: inventory, pricing, and orders keep working, and only the reporting for that source is incomplete.
• Two new troubleshooting sections cover what to do: Delivery reports rejected and Delivery reports not returned.

​

5.84.2 — August 8, 2026 at 9:24 AM UTC

• Large third-party sales-agent catalog responses no longer stall while diagnostic logging captures a preview of the response.
• Buyer Setup now recognizes active media pricing inherited from your billing
• organization. Missing Organization IU pilot terms no longer appear as a missing
• media rate card, and a confirmed buyer operator no longer needs domain
• verification to go live. Nothing to change on your side. Seller availability,
• authorization, and setup are unchanged.

​

5.84.0 — August 8, 2026 at 8:15 AM UTC

• Seller navigation now keeps the binding Discovery Card alongside Business Rules and inventory setup under Connect. Business Rules also renders policy, disclosure, and approval controls on one consistent card surface.
• Storefront operators using an agent with the gated v3 preview can now get more reliable answers from Interchange documentation. The agent can follow a cited page to the relevant guidance and stop once it has enough evidence, helping it preserve field names and safety steps. Nothing changes in buyer-facing storefront responses, and sellers do not need to update their setup.

​

5.83.2 — August 8, 2026 at 7:01 AM UTC

• The Discovery Card editor now presents its identity and buyer-facing fields together on one clear card surface.

​

5.83.0 — August 8, 2026 at 5:53 AM UTC

• Buyer teams can now use the Calls view in Activity to see whether connected workflows succeeded, how long they took, and what happened when one failed. They can share the details with a technical teammate when they need help. Seller teams get the same view for requests handled by their storefronts. Existing history remains available, and no setup or integration changes are required.
• Anyone using Murph can now choose Google Drive files without enrollment. Buyer teams can also choose Drive files in campaign creative uploads. Each import requests access only to the files selected in Google’s window; it does not create persistent Drive access.

​

5.82.2 — August 8, 2026 at 5:27 AM UTC

• Connections now show the full integration grid on page and Settings surfaces instead of clipping the bottom of the list. Sellers can also save Discovery Card descriptions, channels, and accepted countries from the current storefront surface.

​

5.82.0 — August 8, 2026 at 4:06 AM UTC

• Buyers can now compare storefronts by the countries and channels they accept, with Advertising Policies when disclosed by the seller or connected sales agent. For pass-through sellers, each connected source’s standard AdCP primary_channels and primary_countries form one binding, correlated declaration; separate sources are never combined. Sellers manage how they appear in Marketplace from one Discovery Card in Setup. Managed sellers keep Brief Acceptance, Creative Policy, and human approval settings separate; external pass-through sellers continue to use coverage and policies from their own sales agent. Existing V3 media_kit integrations remain available as deprecated compatibility surfaces.
• Your generated adagents.json files are now ready to copy or download: Murph
• uses valid property IDs and current timestamps, reports exactly what it checked,
• and attaches each file to its Slack reply. No setup change is required. If you
• copied a file from an earlier Murph response, generate it again before publishing.
• Parent organization admins now manage payout destinations for child storefronts. In Plan & Billing → Payouts, select a direct child storefront to create or replace its destination, or use the REST billing API with targetCustomerId; child-account admins can no longer change payout routing. Standalone storefront payout management is unchanged, and inventory, reporting, and other storefront operations remain child-scoped. Generic MCP payout operations do not support direct-child targeting.

​

5.81.1 — August 7, 2026 at 10:38 PM UTC

• The ”+ Add advertiser” button on the Advertisers overview is temporarily
• unavailable while we finish improving the in-chat add-advertiser flow. To add
• an advertiser in the meantime, use ”+ Add advertiser” in the advertiser menu at
• the top of the left sidebar, or just ask Murph to add one.

​

5.80.0 — August 7, 2026 at 9:19 PM UTC

• You can now create an advertiser without leaving the chat. Use the **+ Add
• advertiser** button on your Advertisers view, or ask to add one — then name it,
• look up its brand by domain, and set its primary currency. When you’re done, you
• land in the new advertiser’s campaigns. Nothing changes for advertisers you’ve
• already set up.

​

5.79.1 — August 7, 2026 at 7:55 PM UTC

• Opening Billing in an advertiser’s settings no longer yanks you to the organization billing page and silently switches your active account. Advertisers now see an inline note that billing is handled at the organization level, with an explicit button to open it — the account context only changes when you choose to.

​

5.78.0 — August 7, 2026 at 3:44 PM UTC

• Your agent can now request fresh offers from named sellers against a campaign with request_proposals. Each seller’s answer is stored as a Proposal: list a campaign’s Proposals with search, and read one with get, including the resolved detail of every product the seller allocated. Accepting one by passing fromProposalId to save_media_buy stages a draft media buy built exactly from that offer, and records which version of the Proposal was accepted even if the seller later revises it. Evaluation instructions on request_proposals are accepted but not yet applied to results, and the staged media buy follows the normal draft flow: nothing is sent to the seller when you accept.
• Property exclusion lists are now enforced when buying: products on excluded properties are filtered out of discovery results, and executing a campaign fails with a clear error if a selected product conflicts with the advertiser’s exclusion list.
• Brand logos now stay fresh when a brand replaces the bytes at a stable logo URL. Previously, once a logo was cached, it was served indefinitely. The cache now uses ETag/Last-Modified conditional revalidation: a 304 Not Modified response keeps the cached copy; a 200 re-downloads and replaces it.

​

5.77.0 — August 7, 2026 at 1:11 PM UTC

• The buyer agent skill now teaches the multi-storefront get_products progressive-response contract: poll until results_complete: true, replace provisional snapshots instead of appending them, paginate with the cursor only after completion, and read storefront_results[].message on successful empty results. Agents built on the skill no longer risk presenting an early partial snapshot as the whole marketplace.

​

5.76.0 — August 7, 2026 at 10:32 AM UTC

• capabilityHealth.inventory.status and capabilityHealth.reporting.status on GET /api/v2/storefront/readiness and GET /api/v2/storefront/inventory-sources/{sourceId}/diagnostics keep the same field name and position, but status is now nullable: it is null when nothing has ever reported on that capability, where it previously read the string unknown. The other five fields on each axis change entirely. lastError, lastErrorCode, lastErrorAt, lastSuccessAt and lastCheckedAt have been removed, because a single set of them could only ever describe one check. The equivalent detail now sits on each entry in observations, described below: lastError becomes detail, lastErrorCode becomes cause, lastCheckedAt becomes observedAt, and lastSuccessAt becomes lastOkAt. There is no direct replacement for lastErrorAt; for a check that is not healthy, observedAt is when it recorded that result.
• Each axis now also carries observations: one entry per health check that reported on that capability, each with its own status, plus observer, cause, and observedAt. Several checks can watch the same capability and disagree, for example one confirming the connection is fine while another reports the reporting feed failing. Before, you could only see whichever check happened to run most recently; now you can see all of them.
• status itself is more trustworthy for it: it is computed across every check that reported, discounting one that has gone stale, instead of reflecting only the last write. An axis nothing has ever reported on now reads null, not healthy.
• If you want one verdict, keep reading status: do not build your own collapse from observations. If you want to see checks disagree, read observations.
• For a managed ad-server source, a failure reported by any check now shows up in that source’s health, the same as for every other source type: for example, a creative-sync failure now flips the badge even while the pipeline check itself reports healthy.
• If you look at your storefront’s health from the seller-setup widget or the account switcher, nothing changes: the health badge and its wording are the same as before. Only someone reading the raw API response sees these new fields.
• This is a data-model and API-contract correctness change, not a change to pricing, packaging, or your plan.

​

5.75.3 — August 7, 2026 at 5:18 AM UTC

• Sellers approved for the modular inventory source pilot now receive its setup
• and management surfaces directly from their modular-sources entitlement. A
• separate rollout flag is no longer required, preventing pilot access from
• drifting between two customer lists.

​

5.75.0 — August 7, 2026 at 12:29 AM UTC

• No action is required unless your organization is invited to the controlled Enterprise Contract pilot. Existing integrations also need no changes: get_iu_rate_card_offer and get_storefront_rate_card_offer continue to return the same contract details and response structure.
• If invited, an organization administrator can open Settings → Plan & Billing to see purchased product rights, premium support, package history, and current status. Enterprise brand administrators can confirm their organization’s governance, product, and support rights in one place. Agency teams use the same organization record to verify exactly what is included. Power buyers and builders can use open_iu_plan_task to open the authenticated view through MCP with standard labels and safe links. Small-business buyers do not need to act; the page remains hidden unless their organization joins the pilot.
• Invited seller administrators see the same purchased rights, premium support, package history, and status for their organization. This gives sellers one authenticated record for confirming what they purchased and whether it is active. It does not change how buyers discover or rank seller storefronts.
• Packages awaiting payment appear as “Payment required” and remain inactive. A billing hold marks a purchased package as “Paused.” Once a prepaid package’s payment is confirmed, using the package will not return it to “Payment required.” A refund or payment reversal changes the package to “Payment required” until funding is restored.
• We will expand the pilot only after Plan & Billing and MCP show the same contract state, private terms remain limited to authorized organization administrators, and failed next actions and support requests stay within the approved pilot limits. Turning off iu-rate-card-pilot hides the new views without changing accepted contracts.

​

5.74.2 — August 6, 2026 at 3:02 PM UTC

• The Modular source workspace now opens reliably instead of failing when a redundant access check on its static app shell is temporarily unavailable. Source data and actions remain protected by authenticated customer and tenant authorization checks.

​

5.74.1 — August 6, 2026 at 2:41 PM UTC

• Advertiser property lists now attach to new media buys only when the seller declares property-list targeting support in its capabilities. Sellers that do not support the dimension no longer receive it, which prevents them from rejecting the buy outright.

​

5.74.0 — August 6, 2026 at 1:35 PM UTC

• Accept exact legacy {agent_url, id} product-format references indefinitely
• when the shared AdCP catalog can interpret them. Product-format enforcement now
• blocks only unresolved custom references and missing catalog evidence; it no
• longer requires direct canonical format_options[] based on source age or a
• September 1 deadline.
• Sellers using shared-catalog references do not need to duplicate canonical
• options on their products. Sellers with custom references must move them into a
• shared interpretable catalog entry or publish an interpretable custom canonical
• declaration before their storefront can transact under the flag.
• Buyers need no setup change. They continue to discover products whose formats
• are interpretable. A storefront with unresolved custom formats returns no
• products to buyers until the seller repairs those formats, preventing buyers
• from selecting inventory that cannot be trafficked.
• Fixed a failure where a live storefront’s products could be discovered but not bought. Storefronts that were created before going live carried a stale internal status that two execution steps still checked, so execute_campaign rejected the storefront’s own products with “Sales agent not found”, and creative attachment reported the agent as inactive. Nothing was ever sent to the seller, so no orphaned orders were created. A storefront’s availability is now read only from its live pause and readiness state, everywhere in the buying path.
• If your Reddit connection is already marked expired, reconnect it once in Settings → Connections. Active Reddit connections now refresh OAuth credentials automatically before they expire.

​

5.73.0 — August 6, 2026 at 11:39 AM UTC

• The Murph Storefront rail now lets enrolled sellers open every inventory source on its own Source Page, including Scope3-managed adapters and sources still being connected. No migration or buyer-side action is required, and buyer discovery, ranking, labels, and delivery do not change. Switching sources clears the prior source’s work, while shared links restore the exact source instead of falling back to another connection. Add and manage sources from Seller Setup, which now presents one collection with Scope3-managed, certified-partner, operator-managed, and advanced modular paths.
• Connections now explains when Scope3 must configure a provider app and disables the unavailable connection action instead of sending buyers into a broken authorization flow. Nothing is wrong with the buyer’s provider account, and no buyer action is needed until the provider app is available.

​

5.72.0 — August 6, 2026 at 11:04 AM UTC

• Storefront administrators can now list pending buyer account requests in Buyer Account Mapping through the storefront REST API or MCP, then approve Interchange-cleared billing or reject a request with a reason. Requests stay pending until an administrator decides them; existing grants, source bindings, and billing defaults do not change automatically.

​

5.71.5 — August 6, 2026 at 7:44 AM UTC

• Buyer-facing adapter errors now retain bounded, host-authored diagnostics for malformed audience inventory and TikTok response envelopes. Provider messages, numeric response codes, request identifiers, and account data remain suppressed.
• Connected Pinterest, Spotify, and LinkedIn storefronts now distinguish audiences that exist but are not ready from accounts with no audiences. Non-ready audiences remain visible with a non-live deployment and cannot be mistaken for targetable inventory. Failed adapter reads also retain bounded, allowlisted diagnostics for readiness probes without exposing provider messages or identifiers.

​

5.71.0 — August 5, 2026 at 10:09 PM UTC

• Media buys now carry the advertiser’s property list from the moment they are sent to the seller. Previously, a property list only reached media buys that were already active when the list was created - a buy executed after the list existed shipped without it until it was manually attached.
• Creatives produced by generation sessions are now stamped with creative_source: "generated" instead of the default "uploaded". All other creation paths are unchanged. The "connected" value remains reserved for a future inbound-import path.
• Geo targeting specified as countries (instead of the canonical geo_countries) now flows through to media buy packages correctly. Previously, campaigns stored with the legacy field name had their geo constraints silently dropped at execute time.
• Products created from ad-server inventory now declare the publisher inventory they cover, so buyers can see whose inventory a product sells. The Inventory Selector task asks for coverage alongside the delivery formats, offering your ad server’s own authorized options — typically all properties on a publisher domain, or the specific properties it has verified. One option is prefilled; with several you choose. Previously coverage could only be set when the draft started from a publisher format, so drafting from ad units or placements produced a product the ad server rejected with no way to fix it from the task.
• Because the options come from your ad server, the domain shown is the publisher that authorized you — for a representation network that is the network, not each represented site — and the product declares the properties underneath it. If the task offers nothing, that source has no authorized publisher properties yet, which is a publisher-side step to resolve.
• Validation findings are also grouped now by whether they stop you. Advisory warnings appear under their own heading instead of below “Fix these items before creating”, so a recommendation no longer reads as a blocker.
• Normalize TikTok’s documented human-readable custom-audience detail types into canonical adapter signal types while continuing to reject unknown provider values.
• Media buys discovered from a linked account now stop background status checks as soon as the source reports them completed or canceled. No action is required.
• Treat TikTok custom-audience list types as advisory and validate the authoritative detail type before projecting signal inventory.

​

5.70.0 — August 5, 2026 at 6:26 PM UTC

• TikTok storefronts now discover custom audiences when the provider returns the audience_type list-field variant. Conflicting, malformed, or unsupported audience types still fail closed.
• Open Partner to activate paid operations for unrelated clients. If the Partner activation pending banner appears, follow its Plan & Billing action to add a verified card, fund prepay, or resolve a billing hold. In Partner, claim your provider and complete production certification for its current revision. Operations open when your accepted Partner Program contract is in force and every requirement is current.
• Provider registration and production certification remain free while paid operations are pending. Buyers do not get an automatic connection: Partner-only operations and attribution activate only for eligible Partners, while buyer consent and client authorization remain separate requirements.
• Fixed inventory-source test-campaign diagnostics so the run record’s seller calls now match the storefront activity log. When a test campaign reached a seller during discovery but then failed at product selection or media-buy dispatch, the run record previously showed no seller calls — making it look like the seller was never contacted. The completed discovery round-trip now appears in the run’s diagnostics, so an empty seller-call list reliably means discovery never reached a seller.

​

5.69.0 — August 5, 2026 at 4:15 PM UTC

• Campaigns that have been archived now correctly block new creative operations. Attaching or creating a creative against an archived campaign returns 404 (the campaign is treated as no longer present). Sales-agent sync no longer fires on behalf of archived campaigns. The advertiser creative library no longer counts archived-campaign attachments in each creative’s campaign usage count.
• Buyer-facing adapter errors now retain bounded, host-authored diagnostics for malformed audience inventory and TikTok response envelopes. Provider messages, numeric response codes, request identifiers, and account data remain suppressed.
• customer_get_users now includes administrators from parent accounts in your organization. Previously those users had access to your account but were not returned in the response.
• No permissions have changed. If your account is part of an organization, you will see additional users in the response. Nothing to update on your end. Sellers are not affected.
• Connected social storefronts now expose real audience lists reliably instead of failing only after an account has inventory. Large lists are paginated, and invalid or cross-account inventory fails visibly. Sellers do not need to take action; buyer agents targeting these audiences should use each result’s signal_agent_segment_id.
• Creative sync now reports failure when a sales agent accepts a creative but refuses the package assignment that puts it on your media buy, rejects it through its review status, or returns no result for it at all. Previously those synced as succeeded while the creative stayed pending, so a creative that never reached the buy looked live. The reason now travels with the failure, quoted from the sales agent in their own words — including any package they name — instead of a bare sales-agent name.
• Storefront source test campaigns now attach the buyer-facing pricing option returned by their own discovery run, preventing valid account-scoped products from being rejected during selection.
• Buyer Account Mapping imports can now bind uniquely matched sandbox relationships to authenticated inventory-source accounts. If sandbox and live relationships share the same operator and brand domains, the import quarantines the row instead of choosing one.
• Pacing plans now enforce budget limits on live buys. When you write a pacingPeriods schedule on a campaign, each active buy’s package budget cap is updated to match where you are in the current period - and a background worker advances those caps at each period boundary going forward.
• What this means in practice: Budget cap updates go through each seller’s standard approval flow. Sellers with auto-approval apply the change near-immediately; sellers with manual review apply it after their team acts. Check your approval queue if you expect delivery to change quickly.
• Previously, pacing schedules were accepted and stored but never applied to buys already running. Existing stored schedules on active campaigns will begin enforcing when the next period boundary is crossed.
• Connected Pinterest, Spotify, and LinkedIn storefronts now distinguish audiences that exist but are not ready from accounts with no audiences. Non-ready audiences remain visible with a non-live deployment and cannot be mistaken for targetable inventory. Failed adapter reads also retain bounded, allowlisted diagnostics for readiness probes without exposing provider messages or identifiers.

​

5.67.0 — August 5, 2026 at 10:37 AM UTC

• Organizations can now review and accept a private Enterprise Offer in Plan &
• Billing. The Offer clearly shows what is included, the contract term and
• renewal rules, and monthly or discounted prepayment choices. Customers can
• download the same proposal as a PDF for internal approval, accept one payment
• choice online, and continue to payment setup.
• Offer administrators start from the standard activity pricing and change or
• waive only the exceptions agreed with the customer. Existing plans, prices,
• and billing terms do not change unless an administrator issues a private Offer
• and the customer accepts it.
• Persona pass
• Enterprise brand buyer: gets one approval-ready record of scope, term,
• renewal, entitlements, support, and payment choices.
• Agency / hold-co buyer: can take the same proposal through approval
• across client stakeholders without reconciling separate documents.
• Power buyer: can inspect the exact accepted pricing and product rights in
• Plan & Billing after acceptance.
• SMB novice: sees a plain-language proposal and does not need to configure
• anything unless their organization receives one.
• Seller: a seller organization can receive the same private Offer for its
• own plan; this does not change how a storefront or its inventory appears to
• buyers.
• Rollout and measurement
• This is an atomic GA launch with gate: none. Exposure is inherently limited
• to organizations for which an administrator issues a private Offer, and no
• commercial terms change until an organization administrator explicitly
• accepts it. Rolling back the authoring and acceptance surfaces stops new Offers
• without changing immutable terms that customers already accepted; an unaccepted
• Offer can also be revoked.
• We will review Offers issued, proposal PDF downloads, acceptance events,
• monthly-versus-prepayment selection, and payment-setup starts each week. For
• the first ten issued Offers, success means every accepted binding preserves the
• selected payment choice and requires no manual document or billing correction.
• Those first ten Offers establish the conversion and time-to-acceptance baseline
• for the next adoption target.
• Creative delivery to legacy sales agents now translates both canonical format
• identity and package assignments into the seller’s supported wire shape. This
• prevents a seller from accepting the media buy but rejecting every creative
• because its required legacy format ID or assignment container was missing.

​

5.66.1 — August 5, 2026 at 8:42 AM UTC

• Meta connections now use Page authorization for Page-native event-source discovery and send schema-valid audience discovery requests, allowing targeting and Instant Form checks to complete reliably.

​

5.66.0 — August 5, 2026 at 8:14 AM UTC

• A proposal pass now shows what fed each product. Expand a product row and you see which of your own ingredients your agent consulted when it built that line — the inventory it selected, the audience it layered on, and the rate-card entries it priced against — plus, under the table, what fed the whole response: the Playbook version it composed under and the terms resolved for that buyer. Tap an inventory, audience, rate-card, or Playbook chip to open the thing that owns it and change it there; a chip with no place to go — buyer terms, or inventory from another seller’s storefront — says so instead. Nothing to set up: your agent records this while it composes, so it appears on responses from here on. Passes composed before this simply do not expand, and a chip for something you have since deleted says so rather than sending you to a stand-in. This is included in your existing storefront plan — no new billable surface and no packaging change.

​

5.65.4 — August 5, 2026 at 6:14 AM UTC

• Storefronts that are still completing launch requirements now open Get ready to sell as one focused page, even when the legacy transaction switch was enabled early. Pre-chat widget navigation also removes stale tucked pages instead of restoring them over the active setup task.
• Seller Setup source cards now show a consistent status and explanation across connection, products, and health. No action is needed; pass-through cache gaps and health that has not yet been observed stay out of required setup work.

​

5.65.2 — August 5, 2026 at 5:06 AM UTC

• Third-party sales-agent storefronts now use the inventory source’s status as the single lifecycle signal, preventing a stale internal agent copy from blocking readiness, discovery, or seller-owned test campaigns.

​

5.65.1 — August 5, 2026 at 3:47 AM UTC

• OAuth-protected sales agents now use the AdCP client’s standard web OAuth flow, including protected-resource discovery for identity providers hosted separately from the agent. When authorization cannot start, the secure credential form shows the actionable reason instead of a generic retry message.

​

5.65.0 — August 5, 2026 at 3:22 AM UTC

• Opening Plan & Billing from Settings now starts parent and standalone organizations on Overview, so buyers and sellers see their plan, next action, usage, and account standing before choosing a billing task. Child storefront payout setup and other task-specific links still open the relevant tab directly.
• For each active third-party sales-agent source created on or after August 4, 2026 at 05:17 UTC, publish a URL-free canonical format_options[] declaration on every product. Enrolled storefronts now see source-level legacy and unresolved format details in Seller Setup > Inventory sources; sources awaiting current cached evidence remain blocked while a non-serving buyer brief refreshes them. Before September 1, exact legacy mappings from older sources remain temporarily grandmothered while observed non-canonical products from newer sources and unmappable declarations block storefront transactions. On September 1, the grandmothering period ends and every active external sales-agent source must publish direct canonical declarations.
• Buyer impact: buyers do not need to change their requests. While a seller is blocked by this check, buyer discovery returns no products and media-buy admission rejects the storefront; service resumes after the seller publishes canonical declarations and readiness passes.
• Monetization: none. This changes neither pricing, packaging, billable units, nor marketplace economics.
• Measurement: use the named readiness check source_product_format_compliance to track the percentage of enrolled active sources that pass, the count of storefronts blocked, and median time from first warning to compliance. Launch acceptance is 100% enforcement for newly created sources with no non-serving refresh failures left unresolved; September 1 acceptance is 100% of enrolled active sources passing direct canonical declarations, with the flag-off kill switch retained for incident response.
• Approving a creative now records your decision instantly and delivers it to your sources in the background. Previously, a slow sales-agent response during an approval could hold the request open long enough to time out — making a saved approval look like it failed, and a retry then surfaced a misleading “no valid routing policy” error. Approvals are now acknowledged the moment they’re saved, delivery finishes on its own within seconds, and retrying an already-decided creative reports its real status.
• In the Interchange web app, buttons that open a related tool from inside a panel — for example Import seller feed, or opening campaigns and diagnostics from a widget — were failing with “Couldn’t open that workspace. Try again.” Those actions work again. Nothing to change on your side.
• Attaching a CSV to set wholesale pricing in Murph now works even when your browser sends the file as plain text — a common case that previously failed with “the attached pricing feed could not be read.” And when a referenced file can’t be found, Murph now names the attachments it can see instead of a generic error. Nothing to change on your side.

​

5.64.0 — August 5, 2026 at 1:19 AM UTC

• Check your storefront status in Murph for next actions instead of waiting for a storefront nudge. When you ask Murph for status, it lists each setup or source-health step as required or recommended and links to the relevant tool or page when one is available. Complete required steps to make your storefront available, and use recommended steps to improve readiness; if no action appears, nothing needs attention. The separate always-on storefront nudge ladder has been retired, so these next actions are no longer pushed to the in-app feed, email, or Slack. Existing source-health alerts remain separate and continue to follow your notification preferences. This does not change the storefront information buyers see.

​

5.62.0 — August 4, 2026 at 10:58 PM UTC

• If you are an organization administrator and see Scope3 mapped · unclaimed
• in Partner, review the provider name and sales agent, then select **Claim this
• operator**. Claiming confirms the mapped identity belongs to your organization
• and preserves its existing agent identity and history. It does not grant Partner
• Program access, certification, client authorization, or commercial activation.

​

5.61.0 — August 4, 2026 at 6:38 PM UTC

• Reporting responses now carry conversion value, CPA, and ROAS alongside the
• existing metrics, at every level — totals, campaign, media buy, package, and
• timeseries — and in the CSV export. CPA is spend divided by conversions; ROAS is
• conversion value divided by spend. Both follow the surface’s own spend
• denomination, so buyer figures are computed against gross fee-inclusive spend and
• storefront figures against net spend. These fields populate only for buys whose
• seller reports conversion data; where a seller reports none, conversion value is
• zero and CPA and ROAS are null.
• reference creatives stored in the advertiser library can no longer be accidentally assigned to campaigns or synced to sellers. To use a reference creative in a campaign, promote it to evergreen via save-to-library first.

​

5.59.0 — August 4, 2026 at 3:00 PM UTC

• The advertiser filter on the Activity page now correctly scopes the Changes feed and the Calls feed. Previously the picker was visible but not forwarded to either data fetch.
• Behavior change: DELETE /campaigns/{campaignId}/creatives/{creativeId} now detaches the creative from that campaign only — it no longer permanently archives the creative. Existing integrations calling this endpoint will receive the same 204 response, but the creative and its assets remain live in the advertiser library and any other campaigns it belongs to. Active or paused media buys still block the operation. To permanently archive a creative across all campaigns, use the new DELETE /advertisers/{advertiserId}/creatives/{creativeId} endpoint.
• If you manage creatives through Murph or the Interchange UI, removing a creative from a campaign keeps it intact in your library and available for reuse.
• For enterprise buyers and agencies: campaign-level removal no longer risks destroying a creative shared across campaigns. Global archive is now a separate, explicit advertiser-scoped action.
• Daily delivery reporting now reports each day separately when a seller returns a reporting window covering more than one day. Previously, if the seller split the days only within each package and reported the media buy as a single whole-window total, all of that delivery was recorded against the window’s first day: that day read roughly double its real delivery, and the remaining days of the window read as blank. Each day now carries its own spend, impressions, and other counts, taken from the per-package figures the seller reported for that day. Realized spend on the storefront margin ledger is attributed by day the same way, so the two agree on which day earned what. Re-running a report for a past date repairs any days already affected.

​

5.58.0 — August 4, 2026 at 2:08 PM UTC

• Advertiser brand logos now show in the All Advertisers view instead of falling back to initials.

​

5.57.0 — August 4, 2026 at 1:07 PM UTC

• Organizations that operate a sales agent can now register the provider and agent from Partner before commercial approval. Registration begins the free technical certification path for an exact implementation revision; it does not grant Partner operations access, connect clients, or award certification.

​

5.56.0 — August 4, 2026 at 11:58 AM UTC

• Storefront readiness now checks that live buys have an advertiser to book against. A storefront could previously report itself ready to transact with no advertiser configured — inventory synced, credentials passing, sandbox tests green — while every buy outside the sandbox failed. Sandbox buys skip advertiser routing entirely, so a clean smoke test was never evidence that live buys would work.
• If you sell through several ad servers, this blocks going live only when none of them can route a live buy. When one ad server is missing an advertiser and the others can still transact, readiness names that ad server as a warning and your storefront stays live.
• What the check asks of you depends on your ad server, and it says which on the check itself:
• Google Ad Manager and AdsWizz — choose the advertiser yourself. The check reads it back from your ad server rather than a stored copy, so it clears on your next readiness read with nothing else to do.
• FreeWheel — the advertiser is real but cannot be set from the storefront yet, so the check asks you to contact us and we map it for you. There is no self-service step to wait for.
• SpringServe — no advertiser exists to map, so the check never applies to your storefront.
• Your sandbox test still runs while this check is open: a no-spend test books against your sandbox advertiser, which is a different advertiser that never touches live routing. The separate sandbox advertiser check stays advisory as before.

​

5.55.0 — August 4, 2026 at 11:26 AM UTC

• The Partner page now shows the Scope3 Embedded Sales Agent as a registry-backed reference agent, including its currently deployed production version and current certification status. The reference never exposes deployment digests, evidence, clients, or health data, and Scope3 is not shown as certified until the exact production revision has current evidence for every requirement, including the zero-spend creative canary. No action is required from buyers or storefronts; companies offering an agent to others can use the example to understand the Partner certification path.
• This has the same awareness-only posture for enterprise brand, large-agency, builder, and novice buyers. Seller check: not applicable—the reference does not change storefront ranking, catalog facts, inventory presentation, or anything buyers see about a seller.
• Rollout uses the existing Partner entitlement for private operations and ships the customer-safe reference atomically without a new flag; a registry read failure falls back to the existing explanatory copy, and third-party expansion still requires the current provider registration and certification boundaries. Measure reference-card reads, Partner applications following a read, release-registration freshness, certification currentness, and any private-data exposure (target: zero).
• This adds no billable surface and changes no packaging, price, or entitlement tier. Partner approval remains an enterprise application, while technical certification remains evidence-based and cannot be purchased.

​

5.54.0 — August 4, 2026 at 10:45 AM UTC

• From the organization account selector or Add account, companies that offer a sales agent to other businesses can now open Partner, learn the certification path, and apply to the Partner Program. Buyers and storefront operators that only use another company’s agent do not need to act. Opening the page does not grant operational access: buyer identities, source health, incidents, and debugging stay hidden until Scope3 approves the organization’s Partner entitlement, while existing entitled operators keep their agent cockpit. No self-service purchase or pricing is added; approval remains an enterprise commercial decision.
• Fix invitation acceptance broken for all customers. Accepting an invitation was failing with a PostgreSQL type mismatch caused by parameter inference in the grant_lock CTE.
• Fix creative tracking URLs keeping the previous campaign’s ID when a creative is assigned to a new campaign. Impression and click tracker URLs are now regenerated against the campaign being assigned, so click and impression attribution reports against the correct campaign instead of the one the creative was originally created under.

​

5.53.0 — August 4, 2026 at 8:43 AM UTC

• Organization admins can now choose Partner from Add account, and new
• organizations can choose it during signup. If your organization already has
• Partner Program access, Partner opens normally and there is nothing to change.
• If it does not, Apply opens a Contact Us path so your organization can
• request approval; it does not create an account before approval. Buyer and
• Storefront accounts, provider health, and pricing are unchanged.

​

5.52.1 — August 4, 2026 at 7:53 AM UTC

• Fixed two copy issues on the demand inbox and proposal pass: the ledger’s scoreboard caption led with internal roadmap caveats instead of what the win-rate figure means, and the proposal pass could show two contradicting sentences about whether a brief’s condensed facts were captured. Both now lead with the fact the seller needs, with any caveat moved into a Technical details disclosure.

​

5.52.0 — August 4, 2026 at 7:29 AM UTC

• External-agent pass-through storefronts now show the connected sales agent and its endpoint in a billing-first overview instead of presenting an empty seller analytics dashboard. Sellers can open Plan & Billing or confirm a switch to Interchange merchandising from the same surface.
• Organization admins now open their Partner account from the account switcher,
• alongside Buyer and Storefront accounts. Partner operations no longer appear as
• an organization setting, and customer-facing pages use Partner terminology
• instead of “Fleet.”
• Sellers who haven’t yet turned on merchandising can now see what it unlocks.
• The Demand, Test runs, Components, Signals, and Merchandising rules rows in
• the storefront navigation show as locked — with a short explanation — instead
• of disappearing entirely. Clicking a locked row opens the same “Get ready to
• sell” setup step used today to turn merchandising on. Storefronts that have
• explicitly chosen to route through their own third-party sales agent are
• unaffected: those rows stay hidden, as they do today.
• The proposal pass now offers the right verb for the exchange it’s actually looking at, instead of one “Send” button everywhere. On an exchange your agent already answered, Adjust composes a correction you save as training guidance for your agent — it’s labeled honestly, since there’s no buyer to notify. On a sandbox or simulator run, there’s no send affordance at all: run it again or compare it in the Merchandising Simulator instead.

​

5.51.0 — August 4, 2026 at 5:22 AM UTC

• Before account setup, buyers can check whether requested ISO countries and
• channels are open for a pilot, with domestic and global supply reported
• separately. Failed supply reads are shown as unknown rather than empty, and
• this preview does not change alpha access or enroll an account.
• Interchange now preserves the countries and channels your sales agent advertises
• in get_adcp_capabilities.media_buy.portfolio. These primary values are positive
• evidence, while your storefront’s separate accepted-country setting is the
• exhaustive brief-routing policy. When connecting a new sales agent, confirm
• either the complete country list you accept or that you accept briefs globally;
• you can clear that choice later to return to an unconfigured scope. Existing
• unconfigured storefronts continue to receive briefs while setup reports the
• missing confirmation. Interchange never infers acceptance from your Media Kit
• or treats an AdCP primary-country list as an exhaustive deny list.

​

5.50.0 — August 4, 2026 at 4:49 AM UTC

• You can now revise a proposal your storefront has already sent, from the demand inbox. Open the proposal, choose Adjust, and set any of three overrides: negotiation posture, price, or a cap on how many products the revision carries. The Merchandising Agent composes a draft revision from what you declared, and you review it before anything leaves your storefront. There is no new setting to turn on.
• A draft is yours alone until you send it. Your buyer sees nothing while it is a draft, and discarding it leaves the proposal they already have untouched. Sending obeys the same media-buy approval setting your storefront uses today. If that setting requires manual review, someone other than the person who drafted the revision approves the send — you can reject or withdraw your own draft, but not approve it.
• Sending does not reach your buyer’s agent. There is no delivery channel for a follow-up proposal yet, so a sent revision reads as sent, not delivered. Your buyer is not notified, and their agent sees nothing new — this is a seller-side change only. If your buyer needs to see it, reach them the way you do today.
• This is included in your existing storefront plan behind the demand-inbox-ledger pilot flag — no new billable surface, no packaging change.
• Asking Murph to list, show, or browse your advertisers now opens the visual All Advertisers view instead of a plain text list, so you can see campaign and draft counts, brand identity, and pick one to work in right from the same reply.

​

5.48.0 — August 4, 2026 at 1:55 AM UTC

• Registered Partner organization admins can now use the Partner account to see
• an overall production certification status for each sales capability, the seven
• checks behind it, and when its evidence expires. The status follows the
• capability’s current implementation revision and appears next to the existing
• creative canary. Partner terms, client connection approvals, deployment health,
• marketplace listing, and pricing are unchanged. No action is required unless a
• check is missing, expired, or revoked. Availability remains limited to
• organizations already configured and entitled for agent certification; this
• does not widen Partner access.

​

5.47.0 — August 4, 2026 at 12:11 AM UTC

• Partner sales-agent connections now stay available only while the seller’s setup
• is approved, healthy, and ready to serve. If approval is withdrawn, the setup
• stops responding, or the Partner account is paused, the Partner account shows the
• connection as inactive and keeps its previous activation time for audit history.
• For buyers: In the Interchange signup form, select every country where you plan to run a pilot. If buyer pilots are not yet available in a selected country, we keep the application for follow-up and use that country-level demand to guide market expansion. This demand signal does not change which Storefronts are shown or how they are ranked.
• For Storefront prospects: If you were waiting to open a Storefront, you can complete signup now under Scope3’s standard Terms of Service. Accepting those Terms creates the account’s standard agreement. Organization IU plan selection, signup codes, and pricing previews remain unavailable until the Organization IU Rate Card rollout opens. This release does not publish a Rate Card, enroll your organization in a paid IU plan, enable IU charging, or change current prices.
• Registered Partner organization admins can now retrieve a bounded statement of
• AI usage produced by assisted testing and Partner-authored debugging for their
• explicitly bound client sources. Every line retains the exact capability,
• implementation revision, client, Storefront source, and Partner-safe session
• reference; full-period totals stay complete when detail rows are truncated.
• This first stage is tracked operating evidence, not a charging path. All
• Partner-attributed rows remain platform-bearer and settle zero IUs until a
• separately accepted Effective Rate Card term and entitlement authorize a debit.
• Normal client workloads remain with the client, deterministic checks emit no AI
• usage, and confirmed Scope3 defects carry incident-backed zero-rating provenance.
• Persona check: this is for third-party Partner admins, not the standard seller
• persona. It does not change what a buyer sees about a seller or what a
• Storefront-owning client sees about its provider. Commercial screen: the
• statement exposes no price, accepted term, invoice line, or client charge, and it
• cannot debit either organization’s wallet.
• Adoption acceptance starts with at least one registered Partner retrieving a
• statement containing attributed assisted-testing or debugging usage. Measure
• statement request count, distinct Partner organizations, attributed event count,
• zero-rated event count, and truncation rate; the launch target remains zero
• client-bearer Partner events and zero non-zero IU settlements.
• Roll back by disabling the Partner AI usage statement and producer seam, then
• reversing the attribution migration. Monitor attribution conflicts, unexpected
• non-platform bearers, zero-rating guard rejections, statement truncation/latency,
• and cross-tenant privacy-test failures.

​

5.46.0 — August 3, 2026 at 10:35 PM UTC

• Registered Partner organization admins can now retrieve a bounded support-effort
• statement attributed to the exact capabilities and client inventory sources they
• operate. The statement separates included support, overage candidates, and
• incident-response effort zero-rated because of a confirmed Scope3 platform
• defect. Full-period totals remain complete when detailed lines are truncated.
• The ledger is append-only and derives every Partner, client, capability,
• Storefront, and source identity from the explicit provider binding. Zero-rating
• requires an authoritative Scope3-owned provider incident affecting that binding.
• Only Partner-safe descriptions and references are returned; credentials, raw
• incident details, internal notes, and unrelated clients remain private.
• Persona check: this is an operating statement for third-party Partner admins and
• the Scope3 staff who record support evidence, not the standard seller persona.
• It does not change what a buyer sees about a seller or what a Storefront-owning
• client sees about its provider. Buyer campaign users do not see it. Commercial
• screen: OVERAGE_CANDIDATE is reconciliation evidence only—not a price, invoice
• line, accepted term, or client charge—and deterministic reads spend zero IUs.
• Roll back by disabling the statement and recording routes, then reversing the
• support-effort migration. Monitor recording conflicts, zero-rating guard
• rejections, statement latency/truncation, and cross-tenant privacy-test failures.

​

5.45.0 — August 3, 2026 at 9:54 PM UTC

• Seller administrators with a future-dated Enterprise package can keep operating
• their existing inventory sources, while adding a new modular inventory source stays
• unavailable until the accepted contract term begins. The setup unlocks from that
• same contract automatically when its effective date arrives.
• Existing sources, readiness, diagnostics, and bookings are unchanged. Buyer
• administrators and customers without a negotiated Enterprise package have no
• workflow change, and no action is required.
• In the Storefront API, a seller account admin can now invite the certified
• Partner already connected to one inventory source to inspect that source’s safe
• diagnostics. The admin selects the exact provider binding UID, chooses an expiry
• of up to seven days, and can revoke the invitation immediately. A Partner admin
• uses the Partner API routes to list live invitations and open the permitted
• source diagnostics.
• Access covers read-only, redacted source health. It never exposes credentials or
• other clients, and it does not grant source changes, test execution, client
• account membership, or shared-room access. Every read rechecks the live source
• connection, Partner status, production certification, expiry, and revocation.
• Persona check: the seller admin grants access and the third-party Partner admin
• uses it. Buyer campaign users do not see this surface, and this seller-side
• change does not alter anything a buyer sees about a seller. Commercial screen:
• delegated diagnostics is an operating benefit of the existing paid Partner
• relationship, not a new SKU or paid add-on; deterministic reads spend zero IUs
• and never charge the client.
• Roll back by disabling the four provider debug-grant routes, then reversing the
• new migration. Monitor grant creation/revocation counts, denied or expired reads,
• diagnostics latency, and any cross-tenant privacy-test failure.

​

5.44.0 — August 3, 2026 at 9:06 PM UTC

• Your advertisers now open on a single landing view — every advertiser you work with in one place, each showing its brand, how many campaigns it has, and a one-tap way to jump back into an advertiser you left mid-setup. It’s the starting point for choosing which advertiser to work in, and it loads in one step instead of stitching the list together as you go. Per-advertiser spend totals aren’t shown on this view yet — that’s coming.
• Enterprise customers with a negotiated package can now see exactly what their
• subscription includes in Plan & Billing and the IU-plan task. Packages can include
• Partner Program participation, agent certification, SSO setup, publisher
• self-serve, modular inventory sources, and either unlimited named support or a
• monthly support allowance with an IU rate for additional hours.
• Included features become available when the Enterprise offer is accepted and
• remain tied to its contract term. Existing Enterprise access continues through
• this upgrade. No customer action is required, and customers without a negotiated
• Enterprise package are unaffected. This does not change seller storefronts or
• seller workflows.
• Unassigning a creative from a campaign now safely reconciles downstream state. Media buys in DRAFT or PENDING_APPROVAL are updated to remove the creative. Attempting to unassign while the creative is on an ACTIVE or PAUSED buy returns a validation error. The join row is now soft-deleted (status: INACTIVE) rather than hard-deleted, preserving audit history.
• PUT /api/v2/buyer/campaigns/:id now returns a fully hydrated mediaBuyRefs array in the response, matching what GET returns. Previously the field was always empty, causing AI callers to incorrectly infer that media buys had been removed.
• Three fixes to the flighted pacing contract:
• Setting pacingPeriods where every period has already ended now returns a validation error instead of silently accepting an inert schedule.
• The update_campaign response now includes a pacingApplicationNote field when you write pacingPeriods, telling you how many DRAFT buys will use the schedule on the next execute_campaign call and that live buys are unaffected.
• DRAFT media buys with start_time: "asap" that have never been dispatched to a seller can now have their start_time updated to a specific future date. Previously this was blocked by a validation error even on never-forwarded buys, which made per-buy pacingPeriods (which requires a concrete window) impossible to configure on the normal asap default.
• Provider-organization operators now receive always-on open and recovery
• notifications for provider-attributed incidents. Each notification links
• to the Partner account and includes the capability, safe classification, confidence,
• detection time, and aggregate affected-client count without exposing client
• identities, connection IDs, credentials, or raw errors.
• This extends the existing Partner workspace and adds no billable surface or paid
• tier gate. Buyer interfaces and buyer notifications are unchanged; each affected
• publisher continues to receive only its own tenant-scoped source-health status.
• Seller-persona check: new provider-wide status is not applicable to an affected
• publisher because it could reveal other clients; that publisher sees only its
• own source state and next action.
• The routing ships with the existing provider-organization admin cohort because
• it closes an operational alerting gap without changing serving, quarantine,
• support, or billing decisions. Rollback disables the worker delivery call while
• the append-only incident evidence remains inert. Measure delivered open/recovery
• edges, delivery errors, acknowledgement time, and incident recovery time before
• adding delegated diagnostics or support metering.

​

5.43.0 — August 3, 2026 at 7:08 PM UTC

• Fixed a case where sellers who declared “the Scope3 Prebid module is active on this product” on an ESA-hosted product were not seeing that declaration take effect at ad-serve time — the package-ID key-value that gates the resulting ad-server line item on Prebid-enriched traffic was silently being skipped for these products. New forwards on affected products now correctly carry that targeting. Existing forwarded buys are not backfilled by this change.
• The Partner account now shows a connection as inactive when client approval has
• been withdrawn, or renewed but validation has not finished. The previous
• activation time remains available as history. No action is needed: the status
• returns to active after the client approves the connection and validation
• completes. This corrects status display only; it does not change billing,
• packaging, access, or what buyers see.
• Provider operators can now see grouped active incidents in the Partner account,
• including safe attribution, confidence, detection time, and affected client and
• connection counts. Persistent source failures are grouped by client, endpoint,
• implementation revision, or provider capability and recover without exposing
• client credentials or unrelated inventory.
• This is included in the existing Partner workspace and does not add a billable
• surface or paid tier gate. Deterministic provider health remains zero-rated. Buyer
• interfaces are not changed and buyers do not receive incident-derived signals
• about a provider or another client.
• The read-only projection ships to the existing provider-organization admin
• cohort without a feature flag because it does not change serving, quarantine,
• support routing, or billing decisions; rollback is an application rollback and
• the append-only evidence remains inert. Adoption is measured through Partner →
• Partner-account route usage. Incident events measure detection and recovery time, affected
• clients, and classification mix before notification or delegated-debugging
• behavior expands in a later release.
• A buyer requesting preview access with a work email from an organization Scope3 already knows will now see its company name pre-filled. This saves re-entry without granting account access or changing who can join.
• Seller impact: not applicable. This changes buyer signup and the internal TARS admission workflow only; sellers do not see a new or changed surface.
• Buyer persona: first-time and SMB preview requesters benefit from the plain-language company prefill; no opt-in mechanics are exposed to them.
• Monetization: none. This does not change pricing, packaging, billable surfaces, or commercial differentiation.
• Rollout: the advisory signup prefill is intentionally ungated because it has a one-second database deadline and falls back to the existing signup flow without changing access. Its kill switch is reverting the signup resolver. Account admission remains Scope3-SuperAdmin-only, and only the admitted customer is enrolled in alpha-opt-in; the global flag stays off. Expansion requires reviewed admission receipts without unresolved delivery/errors and a separate market/channel governance decision.
• Measurement: auth:signup_flow_start records canonical_org_ref; adoption is the share of eligible preview requests with that property populated. Operational acceptance is an applied or explicitly warned admission receipt with verified customer-scoped enrollment, one confirmed Account edge, and an active administrator or ADMIN invitation.

​

5.42.0 — August 3, 2026 at 3:41 PM UTC

• Fix execute_inventory_source_test_campaign returning 0 products when the storefront is in a pre-launch (paused) state. Sellers can now run end-to-end inventory tests against their storefront before it goes live on the marketplace.
• Provider organizations can now open the Partner account to see their capabilities,
• explicitly connected client sources, connection status, and safe health
• diagnostics. Partner registration and paid commercial status remain separate
• from private provider ownership.
• Optimization suggestions no longer ask for your approval when there is nothing to approve. A suggestion that carries no budget or bid change — most often for a media buy with no optimization goal, where the suggestion is pacing information only — is now recorded and closed out instead of landing in your queue, as is a suggestion whose campaign or media buy is no longer active by the time it reaches you. Suggestions that propose a budget or bid change on an active campaign and media buy are unaffected, and nothing changes on your side.

​

5.41.0 — August 3, 2026 at 1:44 PM UTC

• A handful of small honesty and clarity fixes across your Ask Murph workspace.
• The “Per-buyer auto-approve” rail item and its widget now say the same thing —
• the rail used to read “Buyer trust” while the page it opened read “Per-buyer
• auto-approve.” The “Sales agent” rail item and its page now match too, and the
• page’s “Evidence” tab is now labeled “Calls.” Connecting a sales agent now
• speaks your language instead of ours: “Connect a sales agent your partner
• runs — paste the address they gave you” replaces “Register an external ADCP
• sales agent by its endpoint,” the address field is now called “Agent address”
• with a plain-language hint, and the technical MCP/A2A protocol choice now has
• a note telling you to just ask your partner if you’re not sure. Pending
• operations no longer shows a false “nothing is waiting on anyone” when we
• can’t read the underlying data — it now shows the honest retry state instead.
• Its “Review escalation” button, which never actually escalated anything, now
• reads “Open timeline” — exactly what it opens. The demand inbox’s buyer filter
• now says “Buyer (loaded 100)” directly on the control, so it’s honest about
• its own scope no matter which buyer you have selected, instead of a footnote
• you could miss.
• On the v3 preview surface — flagged off today, with no accounts enrolled — every task waiting on you reads through one work_item search. Alongside creative reviews and media-buy approvals, search({ "kind": "work_item" }) and get now cover modular source follow-ups: the source-side tasks a modular inventory source raises for itself, such as confirming avails or resolving a trafficking error. Each one tells you the requiredResultFields it needs, and save_work_item completes it with them. Complete the same follow-up twice and you get "action": "unchanged" with nothing written; a conflicting correction is refused with the original record and its evidence intact.
• Approved is still not the same as delivered, and the response now tells you which one you have. Completing a follow-up applies its side effects as part of completing it, so COMPLETED is proof the effect landed. An approved media buy with a forwardedAt timestamp was sent — not a guarantee every downstream leg accepted it. One with no timestamp was never forwarded at all; that is reconciliation work, and the response points you to the approvals page to retry the forward.
• The two status vocabularies stay separate on purpose: a follow-up has no approved state and a creative review has no COMPLETED one. Ask for a status one queue cannot have and the response names the queue it did not search, rather than returning nothing and letting that read as “nothing is waiting”. Follow-ups are held per inventory source, so a storefront-wide read fans out across your modular sources and reports how many of them it reached. Two limits are reported separately: sources the scan did not reach, and sources whose own read window filled up. A single queue reads up to 100 follow-ups at a time, and one that comes back full is named in the coverage as an exhausted window — a floor, not a total, which filter.status can narrow. Neither limit is ever reported as an empty queue. To read one queue on its own, pass a sourceId together with filter.workItemKind: "modular_source" — a sourceId alone is refused, because the approval queues are storefront-wide and would silently ignore it.
• Getting an advisory AI evaluation, reassigning an approval to someone else, and retrying a forward stay on the approvals page rather than becoming fields on save_work_item. The first two cost money per call or move who is accountable for a decision, and a retry re-sends the buy to your ad server — none of them is a state you can declare, and re-recording a decision will never trigger one.
• This is a flag-only preview rollout. Monetization: none. It adds no package, differentiation, price, billing, entitlement, usage meter, or metering change. Disabling v3-agent-surface removes this v3 reachability but does not undo durable decisions, completed follow-ups, or their module side effects; corrections remain separate follow-up or reconciliation records. The v2 completion response’s additive changed field is backward-compatible, and no data repair is required.
• Preview measurement uses the existing redacted MCP action ledger. At each cohort review, count modular-source work_item searches and gets plus save_work_item completions, split by success, unchanged retry, conflicting correction, unreachable source, and exhausted source window. Expand only after every enabled modular-source test storefront has completed one follow-up successfully, repeated that completion with an unchanged result, and read the completed result back. Pause expansion if any completion is recorded without its module side effect, a conflicting correction overwrites the authoritative record, or an incomplete source scan is presented as an empty queue.
• Nothing else on /mcp/v2 changes.

​

5.40.0 — August 3, 2026 at 12:01 PM UTC

• Business Rules can now tell a storefront admin which human reviews each approval kind. On the /mcp/v3 agent surface, get with include: ["approvalRouting"] returns the primary and fallback approvers by name, their roles, the channels they’re notified on, and the reminder and escalation clock for media buys and creative review, alongside the acceptance policy and approval gates you could already read. Approver email addresses are deliberately not returned to the agent. Reading routing requires an admin; a non-admin session gets an explanation of why, never an empty table. Changing routing stays on the Approvals Page, where a human picks who can act, and no approval gate changed behavior. Separately, the seller documentation was wrong about rolling an acceptance policy back and now describes both routes: saving the earlier content again mints a new version, while the Business Rules Page reactivates an existing version and mints nothing.
• Monetization: none. This read remains part of the existing v3-agent-surface preview and adds no package, entitlement, differentiation, price, usage meter, or billing change.
• Preview measurement uses the existing redacted MCP action ledger. During each cohort review, count get calls with kind: "business_rules" and include: ["approvalRouting"], split into successful reads, admin denials, and unavailable upstream reads, without retaining approver details. Expand only after every enabled test storefront has completed at least one successful read and no unavailable read has been presented as an empty routing table. Pause expansion immediately on any email-address exposure or any routing mutation outside the Approvals Page.
• Creatives with publisher-scoped format assignments (format_option_ref: { scope: "publisher", publisher_domain: "facebook.com", format_option_id: "..." }) now sync to Meta, Snap, and Pinterest storefronts correctly. No change to your integration is required if you were already setting this field — it was accepted but silently dropped before; it now flows through. If you were not setting it, nothing changes. Sellers will see these creatives flowing to their publisher placements where they previously did not.
• This ships ungated. No kill-switch is needed: the previous behavior was a silent drop (not a deliberate gate), and this restores the intended end-to-end flow. Adoption will be measured by sync_creatives success rates on publisher-scoped storefronts (Meta/Snap/Pinterest). Full AAO registry validation (confirming the format_option_id exists on the publisher’s catalog) is a follow-up tracked in AI-5171.
• Testing your storefront now tells you the truth in your own language. A test
• buy that was still waiting on a few details from you — a budget, flight dates,
• an advertiser, a test brief — showed up with a red “Failed” chip and a raw run
• ID for a title, even though nothing had actually run yet. It now shows a
• distinct “Needs details” status and names exactly what’s missing (Budget,
• Flight dates, Advertiser, Test brief), and the title reads as “Test buy against
• your storefront” instead of an internal ID. Each step in a test now reads as
• what it proved (“Storefront reachable”, “Sandbox advertiser ready”) instead of
• an internal tool name; the exact endpoint and HTTP status behind each step
• moved into one “Technical details” disclosure. Internal notes about what our
• test tool doesn’t support yet no longer show up on your test results at all.
• Public seller signup is now fail-closed behind the existing IU Rate Card pilot flag. The storefront option and public pricing preview stay hidden until that flag is rolled out globally, while the complete IU signup experience remains available for launch.
• New AdsWizz connections now pin a versioned API-key contract with fixed Domain and Forecasting endpoints, so setup and credential rotation reject incompatible configuration before it reaches the ad server. Existing AdsWizz connections continue to work without changes.
• New SpringServe connections now pin a versioned authentication contract for email/password exchange or API-token access, so setup and credential rotation reject incompatible configuration before it reaches the ad server. Existing SpringServe connections continue to work without changes.
• Media buys, Pending operations, and ad-server connection warnings now read in
• plain language instead of internal codes and ids. A stuck buy’s reason and
• error now show as a sentence (“The source couldn’t be reached — the platform
• is retrying”) with the underlying code kept as a reference line, not the
• headline. A row without a resolved buyer name leads with an honest “Media
• buy” or “New buy awaiting review” instead of the bare mb_…/cr_… id. A
• failed-forward group’s recovery class (“transient”, “structural”) is now a
• sentence too. An unreachable ad-server source now names the source (“Your
• ad-server source Google Ad Manager couldn’t be reached…”) instead of “ESA
• connection 42”, and a widget or task that fails to open now says so in plain
• language (“This view didn’t load — try again.”) instead of “MCP app failed
• to load.”
• Setup now tells you the truth about where you actually are. Clicking around
• the rail while your storefront setup checklist was open no longer scolds you
• to “finish or cancel it before it gets buried” — that warning only fires when
• you’ve actually left something unsaved elsewhere; opening a checklist you
• haven’t touched yet never triggers it. The go-live progress band on a
• brand-new storefront now reads “N to do” instead of “N blocked” — a required
• step you haven’t started yet isn’t the same as one you tried and got stuck
• on, and the band now agrees with what each step’s own card already says
• (“Not started”). And the “Your storefront is live” banner no longer shows up
• by accident: if we don’t have a clear signal your storefront is actually
• live, we say so instead of guessing green.
• Sellers can now declare, per product, that a product’s inventory has the Scope3 Prebid module installed — ask Murph “turn on the Scope3 Prebid module for product X” and Murph flips the flag through the wholesale-authoring API. Read + write in the same tool: ask “is the module active on product X?” for a read-only check. When on, Scope3 stamps a package-ID key-value on the resulting ad-server line item at forward time; when off, Scope3 skips the stamp. Only ESA-hosted wholesale products are managed through this tool — third-party sales-agent products stay under your own agent’s get_products response.
• On the early-access /mcp/v3 surface — not switched on for any seller yet — your Playbook now owns your brand and operator house discounts, and you can pull up any earlier version of your selling guidance in full.
• Setting a discount is part of saving your Playbook, alongside your guidance and your pricing. It works one rule at a time, not as a list you replace: a discount you don’t mention stays exactly as it was. To remove one, name the buyer’s domain and whether it is the brand discount or the operator discount, since a domain can carry both and they are different rules. If you set several at once and one fails, we tell you which one and keep the rest.
• You can also read your discounts back — on their own, or beside your pricing when you read the Playbook — and ask what a specific buyer’s domain would resolve to. That preview shows the corporate chain the domain rolls up (converse.com → nike.com) and the nearest rule on each side. It is not the price a buyer gets. A real buy resolves the buyer’s brand and their agency separately and applies whichever discount is larger, so treat the preview as “where would a rule for this domain land”, not “what will they pay”.
• Every Playbook save still creates a new version and makes it live in the same call — there is no separate step that reactivates an old one, which is why rolling back means saving the old content again. You can now read one past version in full to do that, and it tells you up front whether it would still be accepted: guidance written before we split pricing, discounts, markets, and acceptance rules into their own surfaces gets rejected if you save it back unchanged, and you find that out before the save rather than from the error.
• Nothing on /mcp/v2 changes.
• Monetization: none. This remains part of the existing v3-agent-surface preview and adds no package, entitlement, differentiation, price, usage meter, or billing change.
• Preview measurement uses the existing redacted MCP action ledger. At each cohort review, count house-discount searches, Playbook reads that request discounts or one historical version, and Playbook saves that set or remove discount rules, split by success, unchanged, refusal for incomplete evidence, and partial application. Expand only after every enabled configured test storefront has completed one successful relevant read and every attempted discount write has a confirming read that agrees with the reported outcome. Pause expansion if a response presents a hierarchy preview as the buyer’s effective price, reports an incomplete list as complete, or omits a rule that was already applied from a partial-failure result.
• Ask your storefront agent to retire a wholesale product and it now covers both endings: archive and delete. Archiving takes the product off the market. Buyers stop seeing it, its name, inventory selection, and prices stay as you left them, and making it active again brings the same product back under the same id. Deleting removes the product from the source permanently. Because that cannot be walked back, your agent confirms the product’s exact stored name before it removes anything, and it refuses to delete one that is still active, since buyers can discover and buy it right now — archive it first. Deleting an id that is not there is reported as unchanged, not as a deletion. Deleting never touches your ad-server inventory: the ad units, placements, and targeting you packaged stay where they are, and selling that inventory again means authoring a new product, which gets a new id rather than the one you deleted. Creating and editing products behave as they did before.

​

5.39.0 — August 3, 2026 at 10:09 AM UTC

• On the v3 agent surface (still a preview), save_coverage can now add or remove one publisher domain, and claim or retract one property under a domain, without restating your whole domain set.
• Single-domain edits used to work by rebuilding that whole set from a fresh read and writing it back. That could lose an edit someone else made while the read was in flight, and it could delete domains the read did not return — so when a read came back incomplete, save_coverage refused the edit outright rather than risk it. Neither applies now: one edit is one declaration, so a single add or remove goes through however much of your roster the read covered. Removing a domain we discovered on your site rather than one you declared now comes back as a conflict, instead of reporting a success that removed nothing.
• Property claims are new here, and they stay at property grain. A claim needs a property id, an identifier, or a name — we never invent property identity. When the publisher’s own adagents.json declares the same property, the publisher’s record is what takes effect and your claim is kept on it, so it returns if the publisher later stops declaring that property. A property that came from the publisher cannot be retracted this way. Retracting a claim that is already gone is a success with nothing changed, not an error, so a retried retraction converges instead of alternating.
• Declaring the complete set still replaces the set, and it now tells you when its own report is partial. The write always applies your full declaration — the set is yours to declare. But we compute what was added and removed by comparing against the domains we could read first, so when that read is bounded the response says removalReportComplete: false, tells you how many of your domains it could see, and warns that more may have been deleted than it listed. When the read is complete the lists are exact, as before. Only domains you declared are ever reported as removed: one we discovered for you follows its own source and survives, whether you ask to remove it directly or leave it out of a full declaration.
• Two details for anyone reading the response programmatically. Every outcome list is now { items, count, truncated } — a replace can touch thousands of domains, so the list carries at most 50 while count stays the real number; read count, not the length of items. And a read that trimmed a domain’s properties no longer counts as an incomplete domain list, so a declaration matching your domains is still reported as changing nothing even on a publisher with thousands of properties.
• The v3 preview guide now covers reading and editing coverage, and the v2 publisher-domains guide documents the single-domain add and remove routes and when to prefer them over replacing the whole set.
• The v3 lifecycle remains inside the existing v3-agent-surface preview and does not expand enrollment. Availability, entitlements, pricing, paid-add-on composition, and packaging do not change; rollback is disabling the preview flag or reverting the surface commit, with no data or billing migration to unwind.
• Your seller dashboard and Signals now offer a real “Try again” when they can’t load, instead of a dead-end message with no recovery but closing and reopening the page. The error also shrinks to fit its own message instead of leaving a tall empty space beneath it.
• A bookmarked or shared demand-inbox link now opens the same view as the rail: every entry path opens the newer ledger where it’s on, instead of the older read-only history.
• Seller Setup source cards can now open their existing specialist detail and diagnostics surfaces directly.
• New FreeWheel connections now pin a versioned authentication contract, including sandbox setup, so setup and credential rotation reject incompatible configuration before it can reach the ad server. Existing FreeWheel connections continue to work without changes.
• Storefront avails feeds now reject rows with impossible dates, unsupported
• currency codes, booked capacity above total capacity, or CPM values likely
• entered in the wrong unit. Expired rows stop appearing as sellable inventory,
• so buyers see only current, valid availability. Existing valid rows are
• unchanged. No action is needed unless a feed relies on data that was previously
• accepted despite one of these errors; rejected rows include diagnostics to guide
• correction.
• Replacing your publisher-domain set no longer discards what was already resolved for the domains you kept. PUT /api/v2/storefront/publishers and the MCP replace_publisher_domains operation now apply as a diff: a domain that is in both your current set and the one you send keeps its resolved properties, collections and creative formats, your own seller-declared property claims, its authorization verdict and reason, and its sync timestamps. Only the declared domains you left out are deleted, and only domains that were not there before are created — those start at pending because nothing has resolved them yet.
• Previously those two surfaces rebuilt the whole declared set, so resending a set you already had cleared the resolved data on every one of those domains and reset them to pending, discarding their authorization verdicts until the next sync re-resolved them. Echoing your own list back is an ordinary thing for a client or an agent to do, so this was easy to hit and slow to notice: the domains reappeared immediately and only their resolved detail was missing.
• Updating businessProfile.publisherDomains is a separate path and is unchanged. It already preserved the rows for domains that stayed in the set. Note that its deletion semantics differ from the two surfaces above: it removes every domain absent from the set you send, including ones we discovered or crawled for you, where PUT /publishers only removes domains you declared yourself.
• Nothing to change on your side. If a recent replacement left domains showing as pending or without properties, the background sync will have re-resolved them; re-read the property roster to confirm.
• Availability, entitlements, pricing, and packaging do not change. This preservation fix ships ungated because it prevents an ordinary replacement request from silently discarding already-resolved seller data; rollback is a code revert, with no schema, entitlement, or billing migration to unwind.
• No seller integration changes are required. Creative delivery now adapts canonical manifests against each seller’s exact declared format option before the SDK translates them for legacy sellers, preventing stale labels or guessed seller URLs from selecting the wrong format. Existing buys created before exact seller options were persisted continue sending their concrete canonical payload as before; they are never assigned a guessed legacy ref. Historical creatives that store only an ownerless format ID must be re-uploaded instead of being attributed to whichever seller is selected.

​

5.38.0 — August 3, 2026 at 8:47 AM UTC

• On the /mcp/v3 preview, a seller agent can now read the media buys on its own storefront. search({ kind: "media_buy" }) lists every buy that landed there — the buys routed through your storefront and the buys your ad server manages upstream alike — with filters for one inventory source, one buyer, a seller-side status (sellerStatus), or a flight-start window. get({ kind: "media_buy", id }) returns that buy’s timeline as your storefront saw it: the approval it went through, the stages it reached, and one entry per inventory source it was sent to, with the source’s own reference, the Scope3 reference to quote alongside it, and a summary of what was sent (flight, budget, packages, targeting dimensions). Every stage names its most recent failure with an error code and whether a retry can succeed, so a stalled buy explains itself without a second call.
• The reads say where they stop. A list built while a source was unreachable says so instead of reading as complete, and stale statuses say how stale. Raw request and response payloads are not returned; the timeline already carries the answer they would be read for. A buy that never touched your storefront comes back as not found, not as a partial answer.
• There is no seller-side test-campaign tool, and there will not be one. Testing your storefront means switching to a buyer account and buying from yourself. That path is still being built, so keep using the v2 test-campaign endpoints until it lands.
• /mcp/v3 stays behind a feature flag with nobody enrolled, and nothing on /mcp/v2 changes. The v3 Agent Surface (preview) page in the docs carries the full shape.
• Availability, entitlements, pricing, paid-add-on composition, and packaging do not change. These are read-only diagnostics inside the existing preview, not a new billable action; rollback is disabling the preview flag or reverting the surface commit, with no data or billing migration to unwind.

​

5.37.0 — August 3, 2026 at 6:56 AM UTC

• If you have asked Murph to switch your storefront’s composition mode, check your capability flags: creative review and campaign approval may have been switched off at the same time. Switching composition mode no longer touches your other flags, but earlier resets were not restored, so ask Murph to show your storefront’s capabilities and turn back on whatever you still want to advertise to buyers. Storefronts running on a storefront adapter are the ones to check first, because there your declaration is exactly what buyers see. Elsewhere the reset reached buyers only while composition mode was on; with it off the reset was invisible at the time, and it comes back as off the next time you turn composition on. Storefronts backed by a connected ad server were never affected. The switch was rejected outright for them, so nothing was ever stored.
• One new refusal comes with the fix. Now that a creative review declaration survives the switch, turning composition on can be refused when your storefront advertises creative review and nobody is left to approve that queue: no active approver in your approval routing, and no organization admin to fall back on if you never set routing up. With composition off that promise was suppressed; with composition on buyers can submit creatives, so we refuse the write rather than open a queue nobody owns. Nothing is saved when that happens, and the refusal names both ways forward: name an approver for creative review, or turn creative review off before you switch.
• When you check your flags, expect two values that can legitimately disagree: the ones you declared, and the effective set buyers get after your ad-server setup, your composition mode, and your media-buy approval setting are applied. A save can succeed without changing anything buyers see, so read the effective set back after a write rather than trusting the flags you sent.
• Availability, billing, and packaging do not change. Composition mode remains the same paid add-on with the same eligibility and price; this release corrects how its capability change is stored and refused. The safety fix ships to the existing seller surfaces so it stops further flag resets immediately, while the v3 agent surface remains limited to its current preview cohort.
• For API and MCP integrations, the existing write distinction is unchanged: PATCH /api/v2/storefront keeps the capability flags you leave out, while PUT /api/v2/storefront stores every flag you omit as off. Continue using the partial patch when you mean to change only selected flags, and read the effective capability set after the write.
• Archiving a storefront signal now says what else it archives, updating one explains which fields are silently ignored, and the signal reference matches what the API accepts.
• Testing your storefront now tells you the truth about what happened. Before, a
• test brief that failed before your agent could answer — rejected credentials, an
• unavailable inventory source or service, an internal error — was reported the
• same way as a genuine “no products matched”, so you could go rebuilding
• inventory that was never the problem. A run that couldn’t finish now says so
• plainly and offers a retry, and a run that finished with nothing to offer says
• that your agent answered and nothing in your storefront matched this brief. The
• test also states up front, while it runs, and again in its result that it creates
• no media buy and commits no inventory.
• Your demand inbox also leads with the answer you came for. Brief history sits at
• the top, so “has my agent been answering demand?” is the first thing you see, the
• list stays a fixed height instead of stretching down the page, and its totals now
• describe the same set of briefs. A brief your agent declined reads as a normal
• outcome rather than an error — choosing not to bid is your acceptance policy
• working — and red is reserved for a brief your agent could not answer at all. The
• two load-error messages that were nearly invisible are now legible in both light
• and dark mode, a failed decision lookup says your brief history is unaffected,
• and if a background refresh doesn’t complete the screen says your history may be
• out of date and offers Refresh in place instead of quietly showing you stale
• rows. When you have no briefs yet, the screen coaches you to run a starter brief
• rather than showing an empty table. Any row opens from the buyer name, so
• keyboard and screen-reader users get one clear control per row. Dates, prices,
• and counts follow your account’s language and time zone, and the whole screen is
• available in Portuguese and Japanese.
• Buyer product discovery and creative workflows now use canonical format declarations instead of guessing from legacy IDs. Products and delivery for legacy external sales agents remain supported through exact SDK compatibility boundaries, while internal CreativeMaster identity requires canonical format evidence.

​

5.36.0 — August 3, 2026 at 5:45 AM UTC

• From Refer a company in the account menu, signed-in buyer and seller
• organizations can introduce another company and follow its review status. The
• page shows the current offer: 100 Intelligence Units, valid for 60 days and
• usable for IU-rated Interchange activity, after
• the company starts a paid plan or a referred buyer reaches $10,000 in agentic
• media spend. Scope3 handles outreach and eligibility review; there is nothing
• to enable, and submitting a referral does not itself earn the reward.
• Prospective buyers can now share their target markets, channels, pilot plans, and self-service experience when joining the preview, so suitable pilots can move to solutions review sooner.

​

5.34.1 — August 2, 2026 at 7:56 PM UTC

• Media-buy reads now preserve the canonical delivery-format requirements of newly composed products. Read formatOptions for their format_kind and params; older composed buys keep their exact legacy format readback until those product rows are refreshed.

​

5.34.0 — August 2, 2026 at 5:26 PM UTC

• The Connect sales agent Task now uses a versioned connection definition and labels its existing token authentication as a bearer token. New Google Ad Manager setup also pins a built-in versioned contract for its numeric network code and platform service account. Existing API integrations keep working through the legacy request shape while connection types migrate.

​

5.33.0 — August 2, 2026 at 4:08 PM UTC

• The “Your advertisers” card on the buyer home page now shows “Current” instead of “Open” when displaying the currently-scoped advertiser, making it clear which advertiser you’re already in.
• If your storefront had a connected source that wasn’t an ad server (for example a modular feed), Signals and Inventory Components previously told you to “connect an ad server” as if nothing were connected at all. Both now say your connected source doesn’t expose ad-server targeting or inventory, so it’s clear an ad-server connection is what’s still missing — not your existing source. The go-live checklist’s “Connect ad server” step gets the same acknowledgement when another source is already connected. Nothing to change on your side.
• If your storefront is enrolled in modular inventory sources, add formatOptions and publisherProperties to every collection before your next avails feed preview or commit. Existing collections without valid declarations stop at MODULAR_CATALOG_NOT_READY until you refresh the feed; Interchange does not infer a format from channel or a URL-based legacy ID. Buyers need no action: catalog-ready collections continue into buyer products with the seller-declared formats and properties.
• The go-live “Successful transaction” check now matches what you’ve actually connected. If every connected source is your Scope3-managed sales agent, the check reports done automatically as “Covered by your managed sales agent” — no separate no-spend test needed. If you also connect a third-party sales agent, the check still applies, and now names which source it’s asking you to test.
• The Test Runs page no longer leaves you stuck when you have no sandbox test history yet — a “Run a test brief” button on the empty state (and in the history list once you have runs) asks Murph to run a sample buyer brief against your storefront, with the result shown right there.

​

5.32.2 — August 2, 2026 at 2:50 PM UTC

• Collapsing a widget on the Ask Murph page now leaves a quiet single-line row — the widget’s name and a small expand arrow — instead of a large bar with a bold “Expand widget” button, so several collapsed widgets stack as a tight list instead of a stack of white slabs. The “still open” reminder for an unfinished setup task also no longer repeats every time you open something else in the same session.

​

5.32.1 — August 2, 2026 at 2:08 PM UTC

• Renamed the shared “Choose an IU plan” surface’s internal identifier from storefront-plan-selection to iu-plan to match the plan’s organization-wide scope across buyer and storefront workloads. The Task itself is unchanged — same review, same accept/decline/renewal flow. Any host or integration that referenced the old storefront-plan-selection resource URI keeps working: the old URI stays aliased for one release while every client picks up the new one.

​

5.31.2 — August 2, 2026 at 1:23 AM UTC

• The demand inbox and its proposal-pass view now read as one clean document instead of stacked panels. Each screen is a single card with a quiet header, aligned figures, and a flat ledger — no more nested boxes, and a metric with nothing to report reads as its reason in one glance, never as a fabricated zero.

​

5.31.0 — August 1, 2026 at 10:43 PM UTC

• Products built from ad-server inventory now keep the delivery options you selected through buyer discovery and checkout. Inventory Components and Inventory Selector show practical format details, ask for a video length when one is required, and catch options that the selected inventory cannot deliver before saving. Existing composed products continue to work during the upgrade; no action is required.
• Meta’s community catalog now identifies Messenger and Threads as Meta-owned properties while keeping formats and placement targeting limited to verified Facebook and Instagram surfaces. No buyer action is required.

​

5.30.0 — August 1, 2026 at 8:29 PM UTC

• Agency and power buyers using Meta product discovery and campaign creation now get safer property handling. Standard products remain limited to disclosed Facebook and Instagram placements, so no action is required. Buyers whom Scope3 enrolls in the AdCP 3.2 candidate can also discover Advantage+ products; those products identify that Meta may deliver beyond the disclosed property list and cannot be targeted to a chosen property list. Contact Scope3 to request candidate access.

​

5.28.4 — August 1, 2026 at 7:34 PM UTC

• Composed product prices now appear on decision records. Simulator comparison cards, the proposal pass, and demand-inbox projections show each offered product’s CPM and the cost basis it was priced over — the numbers previously lived only in the agent’s written reasoning. Non-CPM pricing is left unlabeled rather than shown as a CPM.
• Simulator comparison cards now read as business documents. A run that made an offer speaks through its products, prices, and reasoning — no status chip, and no “Why declined” label on a run that responded. Runs that produced no offer say so plainly (“No offer”, “Did not complete”) with the reason. The pinned brief shows the budget, the buyer, when it was observed, and what inventory was frozen with it, instead of raw field names and timestamps.

​

5.28.0 — August 1, 2026 at 5:33 PM UTC

• You can now create a draft product from a publisher’s custom creative format. In Property Roster, Create product opens a focused task with the publisher format and property scope already attached. Choose an Ad server, select the inventory and Delivery formats reported by that source, review the product, and select Create draft product. The work stays in the task instead of being sent back through chat. Existing products and other product-authoring workflows are unchanged, and the draft remains hidden from buyers until you activate it. Sellers who do not use publisher formats do not need to act.
• For API integrations, V3 wholesale_product.formatOptions now uses the same canonical format concepts as V2 and returns saved inventory and format details when a product is read. Calls that omit formatOptions keep their existing behavior. During the gated preview, the previously documented snake_case option fields continue to normalize to the canonical shape; legacy agent URL references remain invalid.
• Launch: This is an atomic ungated addition to the existing GA Product Authoring feature (gate: none). It expands with the deployment. Reverting this change removes the new Property Roster entry point without changing existing products or the underlying V2 product operations.
• Measurement: Track prepare_wholesale_product launches, successful validate_esa_product and create_esa_product operations for drafts carrying publisher format options, validation-to-create conversion, and create failure rate. Acceptance is at least 20 successful publisher-format draft creations across five storefronts with no confirmed regression in existing product authoring and a create failure rate below 5%.
• Monetization: None. Product-authoring entitlements, packaging, pricing, and Intelligence Unit treatment do not change.

​

5.27.0 — August 1, 2026 at 4:29 PM UTC

• Modular inventory-source readiness pages now load correctly when account-scoped lifecycle stages are present.

​

5.26.0 — August 1, 2026 at 3:50 PM UTC

• If your storefront uses a CitrusAd modular inventory source, open Buyer Account Mapping, refresh its accounts, and select the CitrusAd team for each operator-and-brand relationship. Interchange then scopes product discovery, media-buy creation and history, delivery reporting, and account resources to that team. Buyers keep using the same requests and receive the newly mapped account-scoped results. No CRM setup is required. Other modular inventory sources are available for binding only when they support all of these account-scoped operations; existing agent, Google Ad Manager, and FreeWheel bindings are unchanged.

​

5.25.1 — August 1, 2026 at 2:53 PM UTC

• Property Roster now turns each discovered creative format into a product-planning action. Expand Creative formats to see the inventory where a format can run and the creative a buyer needs, then choose Use in a product to continue. If a format does not match a current property, the roster guides you to review its property mapping instead. Format IDs and sources remain available under Technical details when you need them.

​

5.25.0 — August 1, 2026 at 1:27 PM UTC

• Media buys now send package pacing to sellers only when the buyer explicitly authored it, so an internal default no longer blocks otherwise valid Meta campaigns.
• You can now catch problems with publisher format options while authoring a wholesale product. When an entry in format_options[] includes a publisher’s publisher_domain, format_option_id, format_kind, and params, product validation warns if the connected publisher catalog does not contain that option, declares a different canonical kind, or limits it to properties the product does not select. A product can still narrow the catalog option’s parameters.
• No action is required for existing products. These warnings are advisory: a catalog lookup problem does not block authoring or change the managed sales agent’s validation result. Validation covers product-level format options, not placement-specific availability. AAO registry data still does not authorize a sales agent.

​

5.24.1 — August 1, 2026 at 12:13 PM UTC

• Keep the v3 account status response navigable when buyer readiness is temporarily unavailable.

​

5.24.0 — August 1, 2026 at 11:00 AM UTC

• Sellers can now see source call health alongside ad-server status, sync history, sandbox readiness, and modular-source readiness, without one unavailable check hiding the others. Ad-server setup and credential changes remain in the secure interactive setup experience, and unavailable operations are reported clearly. No action is required.
• Simulator runs no longer appear in the Demand inbox. What-if executions were surfacing as phantom ledger rows with an empty buyer and counting into the scoreboard; the ledger now shows only real demand, exactly as the Simulator’s isolation promise states.
• In Buyer Account Mapping, sellers with a managed FreeWheel source can now refresh authenticated advertiser choices, then select or import a source binding for each operator-and-brand relationship. Interchange uses that binding for product discovery, media-buy creation and history, delivery, and account resources; no CRM setup is required. Google Ad Manager and third-party sales-agent behavior is unchanged, and modular sources remain unsupported.
• Child storefront admins can now add their own payout entities in Settings → Billing → Payout entities without needing access to the parent organization’s commercial billing account. Your inherited parent payout details remain the read-only fallback until you add an account-owned destination; no action is required unless you want the child storefront paid separately. Parent organization admins can continue managing a direct child’s payout entities on the child’s behalf.
• Meta media-buy requests that use a nested ISO subdivision now return an actionable validation error before any provider write. Supported top-level regions and country targeting are unchanged.
• Inventory discovery now reports live, modular, and cached-catalog source failures as a retryable error when no source or fallback completes. It preserves genuine empty successes and no longer describes an unfinished or failed source task as zero matching products.
• When no payout entities are configured, the empty state now shows a labeled Add payout entity action that assistive technology can identify. Nothing changes on your side.
• Agents using the v3 storefront surface can now open the portable Demo Storefront Page to inspect and manage an existing synthetic demo. Demo creation remains a Scope3 platform-administrator action, and Plan & Billing continues to require the authorized human for legal and payout changes.
• Made modular source setup, readiness, avails import, and external sales-agent connection available through the same portable typed Tasks and Pages in every MCP Apps host.
• Storefront operator-domain updates now preserve profile and verification data when a domain is first set or changes only by an equivalent spelling. Account-domain updates keep mirrored storefront domains synchronized without clearing their profile, and storefront configuration remains available when demo status cannot be loaded. Active managed inventory sources without a connection marker now continue to report their connected state. No action is required.
• PUT /storefront now protects your existing operator profile when you change operatorDomain. If an omitted description, channels, membershipStatus, or website contains a value, the request returns a validation error naming the fields that would be cleared. Resupply values for the new operator, or pass confirmOperatorDomainProfileReset: true to clear fields you do not resupply.
• If the operator domain or affected profile fields change before your confirmed retry, the API returns a conflict; read the storefront again and retry. An unset or previously mirrored storefront domain continues to sync with the account’s customerDomain while preserving populated description, channels, membershipStatus, and website values. Only an explicitly divergent operator domain remains isolated from account-domain changes. Calls that keep the same operator domain continue without confirmation.
• Spotify placement IDs in catalogs and delivery reports now use
• spotify.com:in_stream or spotify.com:in_feed instead of
• spotify.com:MUSIC. Update code and dashboards keyed on the old ID. Mixed
• podcast and Audience Network inventory remains unpublished.
• You can now review the canonical creative formats discovered for each publisher in Property Roster. Expand Creative formats to see format kinds, dimensions or duration constraints, applicable properties or tags, and whether each format came from the publisher or the AAO registry. No setup changes are required.
• Format discovery does not change authorization. Only the publisher’s live adagents.json can authorize your sales agent. Media buys still use the format options on each product, which can be narrower than the publisher’s discovered formats.

​

5.23.1 — August 1, 2026 at 6:50 AM UTC

• Buyers: Meta paused/no-spend verification now waits a bounded interval for provider cancellation to become visible instead of failing on an immediately stale read.

​

5.23.0 — August 1, 2026 at 6:09 AM UTC

• Buyers: Meta cancellation readback now keeps a directly deleted campaign canceled even while Meta’s derived effective status is still catching up.
• Buyers: Meta cancellation readback now treats a directly read deleted campaign as authoritative without querying its unavailable child ad-set edge.
• No action is needed. Spotify campaigns created with regional targeting now complete successfully instead of failing during provider verification, while changed placements, regions, demographics, and unsupported targeting remain blocked.

​

5.22.0 — August 1, 2026 at 4:26 AM UTC

• Buyers: Meta’s no-spend verification now distinguishes a campaign that is waiting for creative from the provider-level pause that contains spend. Nothing changes on your side.

​

5.21.3 — August 1, 2026 at 3:53 AM UTC

• Buyers: Meta Instant Form campaigns now accept the provider’s disabled Page signal-enrichment default during promoted-object verification while continuing to fail closed for conflicting provider values.
• Buyers: age-targeted product searches now return the age range and determination method on each product, as documented. A product composed against a seller’s age signal was answering without its ext.scope3_product_targeting.demographics.age block, so the response named an age range in the product title while declaring none of it structurally, and there was no way to confirm the provenance you asked to accept. Requests that restrict accepted_determination_methods were affected the same way. No change is needed on your side.

​

5.21.2 — August 1, 2026 at 3:08 AM UTC

• Eligible Meta on-platform conversion campaigns now accept the account-scoped product IDs returned by discovery, avoiding an invalid-product rejection for built-in lead, messaging, and shop goals.

​

5.21.1 — August 1, 2026 at 2:39 AM UTC

• Meta campaign product discovery no longer returns an empty conversion target list, so strict AdCP clients can proceed with eligible campaigns. Nothing changes for value-optimization campaigns.

​

5.21.0 — August 1, 2026 at 2:12 AM UTC

• Spotify ad-set creation and updates no longer stall when Spotify omits the account ID from its response, and invalid region targeting now returns a clear correction before anything is changed. No seller action is required.
• Sellers: In Signal Manager, you can now classify an ad-server signal as Generic, Property, or Age. For an Age signal, map one exact adult range and choose how the age was determined: survey-based, assumptive, user-provided, or user-verified. You can also name the data provider. This lets age-targeted buyers find eligible products instead of receiving a misleading “no inventory” response. Property signals remain available for inventory setup and are not offered as buyer targeting.
• Buyers: Age-targeted product searches now distinguish unavailable age targeting from an empty storefront. A product is eligible only when its age range matches exactly, its age signal comes from the same inventory source, and its determination method is one you accept. If inventory exists but its age mapping or provenance cannot satisfy the request, the storefront explains that age targeting is unavailable instead of claiming there is no inventory. You can optionally restrict accepted determination methods; no action is required if you do not need that restriction, and requests without an age range are unchanged.
• Restore delivery reporting for media buys routed to sellers on the pre-2026-07-28
• MCP protocol.
• Reporting for affected media buys stopped updating on 2026-07-31 and returned an
• authentication error, even though the seller connection was healthy and its
• credentials were valid. Delivery for those buys now flows again, and the missing
• days are backfilled.
• The cause was in the AdCP SDK’s protocol negotiation. It probes a seller for the
• newer protocol before falling back to the older one, and a seller that answered
• that probe with an authorization error was treated as having rejected our
• credentials rather than as simply not speaking the newer protocol. Sellers on the
• older protocol are now reached correctly on the first attempt.
• If you export delivery or spend for a date range covering 2026-07-30 or
• 2026-07-31, re-run the export after this release to pick up the backfilled rows.

​

5.20.0 — August 1, 2026 at 1:26 AM UTC

• When work linked to one of your asks is verified as live in production, Interchange sends an update and keeps the ask in Your requests for 90 days. The update shows the release date and version, what changed, and what to do next. Closing an internal ticket or merging a pull request does not trigger this update; after delivery, you can confirm the outcome or say you’re still blocked.
• Settings now reflect successful credential, payment, connection, notification, team, and storefront changes immediately and remain correct after a refresh. Nothing changes in how you manage these settings.
• Wait boundedly for exact Spotify placement and targeting readback when an ad-set create response is incomplete.

​

5.19.0 — August 1, 2026 at 12:27 AM UTC

• From the Modular inventory source workspace, select Preview buyer discovery under a Ready Get products stage and enter a buyer brief to see only the products that source would return. The preview rechecks source status and readiness, records the decision for later review, and never includes products from another configured source. It does not create a media buy, change live products or source setup, or turn on transacting; brief tests started outside a source workspace remain storefront-wide.
• Seller accounts enrolled in the v3 preview can now update their canonical operator domain with save_storefront, and get({ "kind": "storefront" }) includes the domain’s verification state. A no-op save returns "action": "unchanged" without writing.
• If changing the domain would clear a populated identity profile, the error names the affected fields. Review them, then retry with confirmOperatorDomainProfileReset: true to clear them. Use PUT /storefront instead when you need to preserve or replace those profile fields. The v2 Storefront API remains supported.
• Authenticated storefront administrators can now refresh advertiser choices for
• an active managed Google Ad Manager inventory source through the storefront API
• or MCP api_call operation refresh_seller_account_source_accounts, then
• select the advertiser through Buyer Account Mapping. Interchange automatically
• applies that binding to product discovery, media-buy creation and history,
• delivery, and account resources; buyers do not need to change their requests,
• and no CRM setup is involved.
• FreeWheel and modular sources do not yet support explicit bindings. Leave
• required coverage unresolved rather than importing a guessed account, and use
• Not required only when the seller’s contract does not require a source
• account.
• Calling the buyer or storefront api_call tool with an unknown operation, unsupported path parameters, or missing required path parameters now returns a normal structured error instead of failing client-side output-schema validation.
• Meta connections now discover eligible Page-native conversion sources through the current Business Portfolio ownership and Page advertising-access model when Meta’s legacy promoted-Pages inventory is empty.
• Connections now shows an ad platform as disconnected immediately after you unlink it and keeps that state after a page refresh. Nothing to change on your side.
• PUT /storefront now protects your existing operator profile when you change operatorDomain. If an omitted description, channels, membershipStatus, or website contains a value, the request returns a validation error naming the fields that would be cleared. Resupply values for the new operator, or pass confirmOperatorDomainProfileReset: true to clear fields you do not resupply.
• If the operator domain or affected profile fields change before your confirmed retry, the API returns a conflict; read the storefront again and retry. Changing an account’s customerDomain also leaves a populated storefront and its operatorDomain unchanged, so make that change directly through PUT /storefront. Account-domain synchronization still runs for an unset or mirrored storefront domain when those profile fields are empty. Calls that keep the same operator domain continue without confirmation.
• Seller-owned inventory-source test plans now find and reuse an existing sandbox advertiser from its brand domain and currency. Complete REST plans bind the resolved advertiser and currency into the single-use execution token and require explicit currency plus creative/no-creative readiness. Product previews stay in the same sandbox account, so repeat no-spend tests no longer require buyer-side advertiser access or a previous run’s history. Nothing changes for production advertisers.
• Wait boundedly for exact Spotify optimized ad-set identity, delivery-goal, and targeting readback before accepting a media-buy create.

​

5.17.0 — July 31, 2026 at 8:51 PM UTC

• When buyer-serving calls stop before reaching an inventory source, storefront readiness, Murph, V3 account status, and inventory-source reads now share one explanation of the blocker, its effect, supporting evidence, and exact fix. Billing incompatibilities show advertised and required modes. Source diagnostics also distinguish storefront candidacy from direct source calls, historical empty or slow responses from ranking inputs, and source-exchange latency from total test duration. No setup change is required unless a surfaced blocker names one.
• Require an Enterprise entitlement to create modular inventory sources or attach modules. Existing sources and their buyer-facing storefront behavior remain operational, and managed ad-server connections stay included. Sellers who already have the entitlement need take no action; sellers who need access should contact their account team.
• Wait for Spotify’s bounded paused-campaign readback before creating child ad sets.

​

5.16.0 — July 31, 2026 at 8:18 PM UTC

• Parent-organization admins working in a child storefront can open payout details from Settings without being redirected back to the storefront home.
• Source diagnostics now show a real reporting status for sources Scope3 polls,
• instead of always showing “unknown”. When a source returns delivery we cannot
• accept, the diagnostics name the field that was rejected, so it is clear what to
• change rather than only that reporting is empty. Re-reading a past day now
• records the same status, and leaves an entry in the report-processing view even
• when the day’s delivery is declined.

​

5.15.2 — July 31, 2026 at 8:00 PM UTC

• Select the deployed Meta Facebook Login for Business configuration during OAuth authorization.

​

5.15.1 — July 31, 2026 at 6:56 PM UTC

• Failed inventory-source test campaigns now distinguish a local media-buy preflight failure from reaching the buyer-side create_media_buy dispatch boundary. Murph shows the specific per-buy failure and makes clear when no seller call could have been issued instead of replacing the reason with a generic Buyer API error or implying that an attempted buy necessarily reached the inventory source.
• Meta connections now use the Page-scoped access Meta requires when discovering active Instant Forms, allowing eligible lead-optimization sources to appear without exposing or storing Page tokens.

​

5.15.0 — July 31, 2026 at 5:43 PM UTC

• You can now fill wholesale pricing and availability gaps from an ad-server source; prices already supplied by the ad server stay in place. Choose Import seller feed to download a pre-filled template, preview accepted and rejected rows and selector matches, and commit the reviewed feed. Each commit replaces only that source’s previous uploaded wholesale feed; rate cards and buyer discounts remain in their existing setup flows.
• Buyer catalog and pricing presentation are unchanged; committed source data continues through the existing catalog flow. This release does not change billing, packaging, margins, or monetization.
• Creative-to-product matching is now safer and more predictable for buyers and sellers. Creatives must match a product’s declared format and scoped option exactly; stale or ambiguous legacy labels are no longer guessed. Buyers should re-check creatives that previously matched through legacy aliases, and sellers should verify that their product format declarations are current because those declarations now determine which creatives are accepted. No action is needed when canonical format declarations are already accurate.
• Meta adapter responses now identify Meta request-limit failures as rate limited instead of reporting a generic service failure.
• If your Meta integration sends targeting_overlay.signals, replace it with
• targeting_overlay.audience_include; the Meta-specific extension is no longer
• accepted.
• On connected Meta accounts, boostable posts from authorized Facebook Pages now
• appear automatically as read-only creatives. Ready Custom and Lookalike
• Audiences returned by get_signals can be included or excluded with
• audience_include and audience_exclude, with no separate ID-mapping step.
• If Page posts are missing from an older connection, reconnect Meta to grant the
• required Page permissions. Creating media buys from existing posts is not yet
• available to ordinary buyer accounts; image and video creative workflows are
• unchanged.
• Meta reconnects now re-request missing or previously declined Page permissions, so eligible Instant Forms appear as lead-optimization sources after reconnecting.

​

5.14.2 — July 31, 2026 at 3:23 PM UTC

• Reconnect Meta once to grant the Page advertising and lead permissions needed
• for Instant Form discovery. Scope3 now requests those permissions and continues
• to fail closed when Meta does not return authorized Form inventory.

​

5.14.0 — July 31, 2026 at 2:11 PM UTC

• Image creatives missing a click-through URL now fail at sync time with a clear error instead of trafficking to GAM with the image URL as the ad destination.
• Meta Instant Form campaigns now discover forms through Pages the connected
• principal can advertise as, using Meta’s supported Page-scoped form inventory
• when the ad account’s promotable-Page list is empty.
• Your agent now has one way to tell Scope3 what you are waiting on. Use
• save_ask for support, product, integration, and commercial asks—and for
• supply when a buyer is looking for inventory—then use the returned id to say
• whether the answer resolved the problem, you received it without disputing it,
• left you blocked, or should be withdrawn.
• Use search and get with kind: "ask" to read the same list from either a
• buyer or seller account. Direct MCP remains limited to enrolled accounts;
• Murph adopts the new tools automatically.
• Enterprise buyers keep the same account and approval workflows. Agency and
• MCP-builder teams can use one filing integration across account contexts.
• Sellers get the same support, product, integration, and commercial filing
• vocabulary plus ask reads; supply filing remains buyer-only. There is no
• pricing, billing, plan, or entitlement change, and storefront ranking and
• inventory visibility are unchanged.
• MCP builders should replace report_issue, report_integration_need,
• track_my_product_ask, create_supply_request, and remove_supply_request
• with save_ask. New Murph turns no longer advertise the retired Murph writers;
• POST /api/v2/supply-requests and POST /api/v2/supply-requests/remove keep
• working through the API release containing this change. Those calls and
• list_my_requests may be removed no earlier than the following API release,
• after usage review; migrate reads to search and get now.
• Removal also requires 30 consecutive days with at least 95% of first-party ask
• writes using save_ask; each compatibility endpoint or alias below 1% of its
• corresponding canonical write or read volume; and filing success no more than
• one percentage point below the 30-day pre-release baseline.
• Keep authoritative zero-value budgets in Meta and Snap media-buy readbacks so one zero-budget campaign cannot invalidate the account’s complete creative and media-buy inventory response.
• Ad-server signal drafts now use the source’s valid value types and mapping fields consistently, so supported targeting can be validated and created without manual payload repair. Nothing changes in existing saved signals.

​

5.13.0 — July 31, 2026 at 12:58 PM UTC

• Media-buy reads now return their applied optimization goals directly. Campaign updates also reject performance configuration on discovery campaigns instead of silently changing mode, and existing performance configuration can be cleared explicitly with null.
• Meta connected accounts now discover active Instant Form conversion sources
• from the selected ad account even when Meta’s promotable-Page list is empty,
• while campaign creation continues to verify the exact published Page and native
• optimization readback before returning success.
• When buying Meta inventory through an adapter storefront, buyers can now select one of each product’s advertised optimization_goals; requests that omit the field continue to use the product default. Meta products advertise their supported metric, conversion, and vendor-metric goals with max_optimization_goals: 1. Create, update, and media-buy reads return the selected goal only after Meta confirms the exact optimization-goal and billing-event pair. Invalid combinations fail before any Meta write.
• Existing bid_price requests remain supported when the selected pricing option allows a maximum bid. Meta treats the value as the per-auction maximum, and responses return it as bid_price. AdCP 3.1 clients cannot request cost caps, ROAS floors, or the AdCP 3.2 bidding field. Those requests, including monetary goal targets that would require a stronger policy, fail closed instead of changing the requested semantics.

​

5.12.0 — July 31, 2026 at 12:07 PM UTC

• Your modular source workspace won’t send you to add a module you don’t need. When we can’t read what one of a source’s modules does, the lifecycle stages it might have run now say it hasn’t declared them, instead of reading as unsupported and pointing you at another module to attach. A stage that genuinely has no module still tells you which kind to add. Murph makes the same distinction now, rather than calling those stages unsupported. Nothing to change on your side: a module we can’t read is ours to fix, not a gap in your setup. Every other stage on the source reports as before, and if a stage you’re counting on reads this way, telling Murph gets it to us.

​

5.11.1 — July 31, 2026 at 11:45 AM UTC

• Keep Meta placement-only controls scoped to explicit manual-placement buys so exact demographic requests can use Advantage+ placements while retaining strict audience-expansion and age readback checks. Campaign deletion now tolerates bounded provider readback propagation without repeating the delete mutation.

​

5.11.0 — July 31, 2026 at 11:02 AM UTC

• Fix budget updates on pending-creatives media buys not reaching the seller.
• When a buyer updated a media buy using a product-level budget while the buy was waiting for creatives, the updated budget was saved locally but not forwarded to the seller. The buy would continue running at the original budget.
• Fixed the self-serve Prebid.js orgId reveal — asking Murph “what’s my Prebid.js orgId” now returns the URL instead of an error. The tool had been failing since it shipped because the REST route wrapped its response outside the standard envelope; the response now follows the same shape as every other v2 endpoint.
• Social media buys now report the actionable AdCP setup state consistently across platforms. A paused buy with no creative reports pending_creatives, then pending_start while a creative-ready flight is still in the future; its retained pause becomes visible only when the buy is otherwise launch-ready. If you filter media buys by status, include these pending states when looking for paused setup holds. The underlying ad-platform campaigns remain safely non-serving throughout setup.
• Products are refreshed after an advertising account connection or credential changes, so a newly selected product can be bought without replaying stale account authorization.
• A new PUT /esa/{esaId}/default-advertiser sets the default advertiser — the advertiser a buyer’s spend books against when no per-buyer rule matches — on whichever ad server backs an embedded sales agent. It works for Google Ad Manager today; pair it with GET /esa/{esaId}/gam/advertisers to find an advertiser id. AdsWizz sources are accepted but both setting the default and listing the roster with GET /esa/{esaId}/advertisers return an error until a pending embedded sales-agent release lands, so wait for that release before using either against AdsWizz. PUT /esa/{esaId}/gam/default-advertiser is unchanged and existing Google Ad Manager integrations need no update; per-buyer mapping rules remain Google Ad Manager only, and FreeWheel and SpringServe are not supported.
• Image uploads now validate that the file can be decoded before storing it. Uploads of corrupt or truncated JPEG, PNG, GIF, or WebP files are rejected with a validation error instead of being silently stored and sent to ad servers.

​

5.10.0 — July 31, 2026 at 9:17 AM UTC

• Fix canceled media buys reverting to pending approval.
• A race between the cancel database commit and the forward-worker claim stamp allowed the approval-forward worker to pick up a just-canceled buy and push it back to the seller, reverting the buyer’s cancellation.
• Seller-specific canonical format selections now carry their exact scoped identity through media-buy creation and creative sync, while injected or inconsistent route metadata is rejected.
• Meta storefronts now preserve exact brief-grounded age targeting when Meta adds
• known disabled audience controls to its readback. Requested controls must still
• round-trip, and active, missing, or unknown controls continue to fail closed.
• Existing /mcp/v3 searches are unchanged unless kind: "ask" is explicit. Buyer agents can keep the requests their account filed in the same workflow they use for buying, while seller agents can do the same in their storefront workflow. Each can optionally narrow their own account’s asks by type or open/closed state, then pass the opaque result id to get with the same kind for one ask.
• The read keeps Scope3’s workflow status beside the requester’s separate answer, so Scope3 marking an ask resolved and the requester reporting that they are still blocked remain two facts. Internal workflow fields and account-routing identifiers are not returned. An ask id from another account is indistinguishable from one that does not exist.
• Ask titles can contain customer-supplied text, so asks appear only when kind: "ask" is explicit; unrelated broad searches do not pull them into context. The existing v3-agent-surface flag remains the rollout and kill switch.
• The glossary now defines Supply ask — an ask for inventory we do not carry —
• including the part that decides whether yours is one: it needs a buyer who can
• actually spend, so a curator buying on behalf of demand qualifies while a
• publisher who wants demand for their own inventory is asking for something else.
• A withdrawn supply ask keeps its record as evidence the demand existed.
• It also settles a phrase you may have seen: “demand signal” describes what an ask
• is evidence of, not an object you create or read, and not a kind of signal —
• those are targeting material a seller authors.

​

5.9.3 — July 31, 2026 at 8:09 AM UTC

• Meta storefronts now preserve exact brief-grounded age bounds when Meta returns
• its canonical age-range alias or omits the default false unknown-age control.
• Explicit unknown-age choices still round-trip, and a broader provider readback
• still fails closed.
• Your ad server source was upgraded on 30 July 2026. These fixes are already
• live — this note is late, and one of them is worth acting on.
• Check any media buy you cancelled before 30 July. Cancelling a buy did not
• reliably reach your ad server, so a buy you believe is cancelled may have kept
• delivering. Cancellation is dispatched upstream now, but it does not retroactively
• stop anything that was missed: please verify directly in your ad server for buys
• you cancelled before that date.
• Also fixed, no action needed:
• Delivery reports honour the window you ask for. A report for a specific
• date range previously returned a different period’s numbers.
• Product targeting keys are kept when you save. Custom targeting keys on a
• product were merged rather than dropped.
• An explicit delivery_type is no longer overridden. Saving a product as
• guaranteed without pricing options could silently return it as a
• non-guaranteed auction product.
• Creative format selectors are emitted in canonical form, and adapter
• booking-lifecycle capabilities are now declared, so a buying agent can tell
• what your source supports before it tries.
• Canonical selections projected from a seller’s older named formats now retain that seller’s exact route through later media-buy creation, updates, and assigned creative sync. Buyers and sellers do not need to change their integrations; missing or ambiguous mappings remain excluded rather than guessed.
• The seller widget now calls a signal a signal, in all nine languages. The
• menu entry, the workspace heading, its tabs, and the create and validate
• controls all match the API and the documentation, which already used that word.
• Its two tabs still name the two layers they always did: Ad-server targeting
• is what your ad server already contains, and Signals are the ones you
• authored from it — browsing the first still creates nothing.

​

5.9.1 — July 31, 2026 at 7:01 AM UTC

• Seller Setup labels a modular source “Modular source” on its card, matching the name every other surface uses. It still said “Feed-backed source” there.
• Three things a seller or their agent could look up and not find are now in the
• glossary:
• Composed product (cf_…) — built to a buyer’s brief at discovery time,
• not authored by you — and Passthrough product, which belongs to a
• third-party sales agent you connected. Together with Wholesale product,
• all three kinds you see in reporting now have a definition and an id prefix.
• Property signal — the ad-server key-value that lets a property you
• declared in adagents.json be found in the ad server that serves it. It is a
• signal by mechanism, not something a buyer targets, and it never appears in a
• brief.
• Component or selector? The same ad unit is both, in different roles. There
• is now a rule: component when the subject is what you sell, selector when it is
• where it runs.

​

5.9.0 — July 31, 2026 at 4:20 AM UTC

• Modular inventory source access no longer drops out mid-session when the
• feature-flag service is briefly slow to answer. A seller who is enabled for
• modular inventory sources keeps access for the cached verdict window instead of
• seeing “Modular inventory sources are not enabled for this customer” on the next
• call.

​

5.8.0 — July 31, 2026 at 3:16 AM UTC

• Buyers: When you call get_products, a seller’s older named format can now appear as a canonical format_options[] entry if that seller published a valid mapping. Nothing changes in your integration; existing canonical options and legacy format_ids[] keep their current shapes.
• Sellers: To make an older named format available through get_products, add a matching canonical declaration to that format in list_creative_formats. Dimensions and duration must match. Interchange ignores invalid or conflicting mappings; if a returned product remains unresolved, the seller result includes details in projection.diagnostics. For new products, publish canonical format_options[] directly. See Get products across storefronts.

​

5.7.2 — July 31, 2026 at 2:37 AM UTC

• Murph now files integration requests from a concise description and the conversation already in progress, instead of asking sellers to complete a repetitive setup form. Nothing changes on the seller’s side.

​

5.7.1 — July 31, 2026 at 1:57 AM UTC

• A media buy the storefront could not place with its source now reports canceled instead of pending_start.
• When create_media_buy is accepted but the forward to the underlying source fails (a malformed request, an unreachable source, a credential fault), no media buy is ever created upstream and none ever will be. Those buys previously reported pending_start, which AdCP defines as “ready to serve and waiting for its flight date to begin” — so a buy that had already failed looked like one that was about to launch, indefinitely. They now report canceled with cancellation.canceled_by set to seller, and the cause (invalid_request, source_unavailable, not_authorized) in the response errors[].
• rejected is unchanged and still means what it always did: a source considered the buy and declined it. A transport or credential failure is not a seller’s refusal, so it does not read as one, and retrying such a request may succeed.
• get_media_buy_delivery also changes for a buy spread across several sources: a source whose delivery could not be read this call no longer drags the whole buy’s status down to pending_start. The status now reflects the sources that did respond, and the unreadable source is reported in errors[]. When no source can be read at all, the call still returns SERVICE_UNAVAILABLE rather than zeroed totals under a misleading status.
• The storefront API and the seller assistant now call a signal a signal. The
• operations that list, create, read, replace and delete one are described that way
• in the API reference, and the assistant uses the same word when it talks to you
• and when it asks you to approve a change. The raw material you build a signal
• from keeps its own name, ad-server targeting — browsing it still does not
• create anything.
• Nothing you call changes: operation names, paths and fields are untouched
• (create_signal, list_esa_signals, signalId), so integrations need no
• update. This completes the API half of the rename announced earlier; the seller
• widget still reads “Signal components” and follows once its translations are
• reviewed.

​

5.7.0 — July 31, 2026 at 12:39 AM UTC

• Buyer agents using V3 now receive account setup and destination readiness
• directly from get_status, without being offered a V2-only setup tool that the
• V3 surface does not support. The V2 Buyer Setup page remains available and is
• unchanged.
• Pinterest connections now request the catalogs:read and catalogs:write OAuth scopes, so syncing an advertiser catalog to Pinterest works. Previously the connection only asked for ad and Pin permissions, and Pinterest rejected every catalog feed registration made through it.
• If you already have Pinterest connected, reconnect it to grant the catalog permissions. Your existing campaigns, Pins, and reporting keep working in the meantime — only catalog sync needs the new grant.
• Nothing changes for your existing support and product calls if you do nothing.
• save_ask now covers everything you can be waiting on Scope3 for, and lets you update an ask after you file it. Alongside support and product, file supply for inventory we do not carry (name the domain in subject, the channel in channel), integration for a counterparty we do not connect to (name it in subject), or commercial for pricing, terms, billing, or a rate-card exception. type is optional now — omit it when you are not sure and we route the ask instead of you holding it back. A supply ask is the one type that needs an account set up to buy; every other type files from any account.
• To update an ask, call save_ask again with the askId it returned, passed back as id, plus a requesterState: confirmed_resolved (what you wanted happened), accepted (you have heard our answer and are not disputing it — not the same as resolved), still_blocked (our answer did not work), or withdrawn (never mind; the record is kept). An optional note replaces the note on that ask; omit it to leave the existing one alone — this door cannot blank a note. Your answer sits next to ours instead of overwriting it, so “we called it resolved” and “I am still blocked” both stay visible as separate facts.
• Filing needs only read access. Updating needs write access from that account’s own session — a staff or agent session without a customer identity can file and read asks but cannot answer them. Withdrawing narrows further: only the person who filed that ask, or an account admin, can do it. title, type and severity are fixed once an ask is filed.
• Buyers and sellers use the same door for support, product, integration, and commercial asks. A seller-only account cannot file a supply ask because that route represents inventory a buyer intends to purchase; sellers can still file every other ask type, and no seller workflow is removed.
• This does not change pricing, billing, packaging, take rates, or any other monetized surface. The v3-agent-surface flag is the rollout and kill switch. We will measure adoption by the share of save_ask calls using supply, integration, or commercial, and operational health by successful opaque tracking-id issuance; index failures now alert through Sentry as well as logs.

​

5.6.0 — July 30, 2026 at 10:45 PM UTC

• When you open Source Diagnostics for an inventory source, you can now see its
• recent outbound call latency, successes, errors, and timeouts alongside the
• preceding equal window. Only calls linked to that source appear there; calls
• made without a source link are excluded. Nothing to change on your side.

​

5.5.1 — July 30, 2026 at 10:17 PM UTC

• Allow exact zero-spend nested-geo DRAFT cleanup before transient lifecycle projection fields materialize.
• Storefronts we broker buys for are now recorded with the reporting arrangement
• they actually use, which is the schedule Scope3 reads delivery back on. Where a
• stale setting had us also asking your endpoint to push daily report webhooks, we
• no longer send that request. Nothing changes for buys whose products declare
• their own reporting capabilities, and nothing changes about the delivery figures
• buyers see.

​

5.5.0 — July 30, 2026 at 9:42 PM UTC

• Sellers running an AdsWizz embedded sales agent can now list their ad-server advertisers through the storefront API. GET /esa/{esaId}/advertisers reads your roster live from AdsWizz and returns it whole, so finding the advertiser id your buys book against no longer means asking us to look it up for you.
• Applying that id as your source’s default advertiser is not part of this release — that step is still Google Ad Manager-only. If you run AdsWizz, contact support to have your default advertiser set.
• Google Ad Manager sources are unchanged: a GAM network holds far more advertisers than is practical to read live, so it keeps listing from its synced cache via GET /esa/{esaId}/gam/advertisers.
• Buyer and Seller Setup now use the same clear checklist for going live.
• For buyers, Setup separates the three account-level requirements—confirm the company operating the account, accept the terms, and keep the account in good standing—from the requirements of each seller or buying platform. This makes it clear whether the buyer can transact anywhere and what remains before a specific destination can accept a buy.
• The company website used for buying is now separate from the organization used for sign-in. An account admin can confirm or change it without changing SSO, invitations, memberships, or advertiser brands. When trusted company records show that a brand belongs to the verified parent organization, Setup can recognize that relationship; agencies and other operators can still verify their own domain directly.
• Connecting is free. Sellers that do not require credentials have no connection step. Other destinations show only the provider connection, account selection, advertiser mapping, or payment setup they actually require. Payment details are requested only when Interchange processes the transaction.
• For sellers, the same activation language and company control now appear in Storefront Setup. Payout work has its own Get paid track, and missing bank details are identified as a payment delay rather than a storefront-launch blocker. Inventory and settlement-currency requirements remain separate.

• ​

  Who notices what

• SMB and first-time buyers: Setup provides one next step and explains “can buy now” without protocol language.
• Enterprise brand and agency buyers: company identity and account standing apply once across every seller, while each destination says who controls the account and who bills it.
• Builders and power buyers: account status now distinguishes platform readiness from destination readiness, with the same result available in chat and the Setup page.
• Sellers and storefront operators: Storefront Setup uses the shared go-live checklist, while payout tasks remain visible without blocking launch.

• ​

  Monetization

• No new charge is introduced. Connecting a seller or platform, finding accounts, matching an advertiser, and viewing existing campaigns remain free. Existing media costs and payment requirements are unchanged.

• ​

  Measurement and acceptance

• Acceptance covers sellers that need no credentials, destinations whose payments are processed by Interchange, choosing the correct advertising account, cases where company information cannot be found, verified parent-company and brand relationships, and independently verified agencies. It also covers matching status results across chat and Setup, production widget builds, and browser screenshots of missing-company, known-domain, unknown-domain, and ready-to-buy states. Activation measurement uses the platform’s readiness result rather than reconstructing readiness from clicks.
• The launch dashboard will use the existing activation:choice_shown, activation:door_chosen, and activation:choice_deferred events for entry-path adoption, plus successful and failed get_buyer_readiness requests for setup reliability. Readiness responses provide the outcome measures: platformReady, canBuyAnywhere, destination totals, and the counts for ready, connection-needed, and blocked destinations. During alpha we will review the choice-to-door conversion rate, readiness-request error rate, platform-ready rate, and can-buy-anywhere rate by entry path each week.

• ​

  Rollout and rollback

• The feature remains behind alpha-opt-in. Start with internal organizations and invited alpha buyers. Expand the cohort only after the staging and production browser flows are green for open signup, invitation bypass, known domains, unknown domains, and a ready-to-buy account; after at least 20 admitted buyer setup sessions have produced a readiness result; and while readiness requests remain below 1% server errors with no Sev-1 or Sev-2 activation incident for seven consecutive days. A wider rollout additionally requires a reviewed weekly dashboard for the named adoption and outcome measures above.
• The kill switch is the existing alpha-opt-in cohort. Stop expansion immediately on a threshold breach. Remove the affected cohort entries to return those buyers to the waitlist gate, while retaining only the internal test organizations needed to diagnose the failure. Organization-scoped invitations remain the controlled admission path during recovery. Re-enable a cohort only after the failing browser scenario or readiness request has a regression test and the seven-day reliability window restarts.
• Storefront administrators can now update account routing across inventory sources in
• one reviewed change instead of editing each GAM, FreeWheel, or other source mapping
• one by one. In the Buyer Account Mapping Page, choose **Import buyer account
• mappings**, upload source_account_bindings.csv, review every create, update, and
• archive, then commit the accepted change atomically.
• No migration or immediate action is required; use the import when you want to replace
• manual source-by-source maintenance. Manual mappings and mappings owned by another
• feed remain protected. This first release imports only source_account_bindings.csv;
• it does not import seller_accounts.csv or account_mappings.csv, or create CRM
• records, relationships, grants, inventory sources, or native source accounts.
• Campaign search now returns nextCursor so agents can paginate past the first page. save_campaign warns on silent no-ops (brief/flight null clears, create-path flags). save_media_buy now validates budget and flight upfront instead of silently discarding them, and reports phase in V3 vocabulary. Error codes unified across the buyer surface.
• Widgets now fit the window they open in instead of guessing at it. Twelve surfaces — the demand inbox, seller dashboard, seller setup, release notes, property roster, activity, inventory components, source diagnostics, modular and third-party sources, buyer discounts, and the avails upload — capped themselves at a fixed height that overflowed shorter screens, leaving the bottom of the widget out of reach. Each now takes exactly the height your window allows, keeps its summary band pinned while the detail scrolls beneath it, and uses the full width of the pane. The widget bar also no longer repeats the title the widget already shows.
• Creative sync now correctly reports error when per-creative results from the storefront source all fail. Previously, sync_creatives reported synced at the top level even when every creative was rejected by the downstream agent, masking failures and making retries appear to succeed. Additionally, non-object asset values (null, string, number) inside a creative’s assets map are now rejected before the payload leaves the platform, surfacing an actionable error message instead of a cryptic downstream validation failure.
• Sellers: You can now stop accepting new business without interrupting existing delivery or losing an approved buy that has not reached a source. In Storefront settings, choose Hold new business; API integrations can set isPaused: true through the v2 Storefront API. This removes products from buyer discovery and blocks new buys and buyer edits. Approved unsent buys remain queued and forward automatically when intake resumes, while storefront preview remains available. No migration is required. Use campaign controls if you need to stop live delivery.
• Buyers: When a seller holds new business, its products are unavailable in discovery and you cannot create or edit a media buy with that storefront. An already-approved buy that has not reached a source remains queued and forwards automatically when the seller resumes intake, so you do not need to resubmit it. Campaigns already delivering continue unchanged. Buys that failed before this release remain unchanged.
• TikTok audience and signal reads no longer fail on accounts where TikTok’s reported audience count includes entries its list API does not return.
• Agents connected to the v3 MCP storefront preview can now read and manage
• storefront settings, exact advertiser relationships, signals, and approval
• work items with dedicated tools. Existing settings do not change on
• their own, so sellers only need to act when they want an agent to update this
• information. Buyers continue to see the capabilities and selling terms a
• seller publishes; they do not see the seller’s setup records or get a new
• buying workflow from this preview.

​

5.4.0 — July 30, 2026 at 6:31 PM UTC

• If you maintain a custom buyer or storefront API/MCP client, or a sales-agent
• integration, regenerate it against the current schema and adopt the canonical
• fields below. This is the only customer action required.
• Product discovery, creative sync, and media-buy creation now use the same
• URL-free AdCP format contract across buyer and seller surfaces. Declare product
• options with format_options, select creative formats with format_kind,
• select package formats with format_option_refs, and read product cards from
• their inline fields.
• A connection explicitly negotiated onto the legacy protocol can continue
• unchanged. At that compatibility boundary, Interchange continues to accept and
• project legacy {agent_url, id} references and media-buy format_ids;
• connections using the current schema must use the canonical fields above.
• Interchange chat, the Interchange UI, and built-in adapter connections adopt
• the contract automatically. Their setup and workflows do not change.
• Media buys now keep billing responsibility consistent from creation through
• execution, so fee and ledger reporting continue to match the seller account
• even if account mappings change later. Buyers and sellers do not need to change
• their workflows, and historical ledger entries are unchanged.
• Audience discovery on TikTok and Snap storefront connections now returns the account’s full customer-list audience inventory, including audiences created outside Scope3 — previously only platform-created audiences were visible.

​

5.3.1 — July 30, 2026 at 3:45 PM UTC

• Fix campaign pacing under-delivering on mid-campaign executes.
• Campaign fallback pacing now distributes a buy’s budget only across periods that are still active at execution time. Previously, a buy executed mid-campaign had most of its budget silently assigned to elapsed historical periods and dropped before being sent to the seller.

​

5.3.0 — July 30, 2026 at 3:11 PM UTC

• Your agent can now create and update campaigns and media buys with save_campaign and save_media_buy; campaigns and media buys are also now readable through the search and get tools. When updating a campaign, pass expectedRevision from your last read to prevent overwriting concurrent changes. Launching a campaign to active still requires human confirmation, and seller acceptance of media buys is not yet available through the agent surface.
• Creative operations (get, update, delete, bulk-update) now recognize creatives attached to a campaign via all three membership paths — the original ownership field, campaign_creative_mapping, and creative_manifest_campaign. Previously, creatives linked via the assignment API were invisible to get and update.
• Users with multiple Interchange accounts can now log in via magic code and password as well as the standard OAuth flow. The previous fix only covered the OAuth code exchange path.
• When running a source test campaign, Murph now correctly reports that discovery was blocked (for example, because the agent doesn’t have sandbox mode enabled) rather than saying the source returned 0 products. The two situations require different follow-up actions: a sandbox capability gap needs the agent updated; zero products from a working discovery means checking the agent’s inventory or advertiser targeting.
• Sellers can now self-serve their Prebid.js orgId — the value they paste into the scope3RtdProvider real-time data module’s config — by asking Murph “what’s my Prebid.js orgId?” (or any variation of the same question). Previously this required an issued credential from the Scope3 team; now Murph returns the exact URL directly from your storefront so you can drop it into pbjs.setConfig(...) and continue with the install. Prebid Server’s auth_key remains issued by Scope3 — the self-serve reveal covers Prebid.js only.

​

5.2.0 — July 30, 2026 at 12:34 PM UTC

• Creative files uploaded from Creative Assets now keep the social ad format you
• selected all the way to the connected ad account. An upload stops with a clear
• error if the social network needs information that is missing or does not
• confirm the creative and package assignment; it no longer appears successful
• with an empty or unusable ad. Meta image uploads use your authorized Page,
• default to Learn more, and do not require headline or body copy.
• When you attach a creative to a campaign in chat, the success summary shows
• which ad placements are ready only after the seller confirms the creative is
• available for delivery. A rejected or still-pending assignment returns a clear,
• retryable error instead of a success summary. Pending approval details also
• name the affected creative files.
• Connected social platforms now offer only the creative formats they can create
• reliably. An unsupported format fails before anything changes in the connected
• ad account.
• No buyer setup changes are required.
• Seller impact: no operational workflow changes. Sellers keep the same catalog,
• approval policies, and package controls; the buyer now sees a success summary
• only after the seller’s existing confirmation is received.
• You can paste a failing request into a support ask, headers and all. Bearer tokens, API keys, JWTs and cloud access keys are now replaced with [REDACTED] before the ask is stored, sent to the Scope3 team, or recorded in the audit trail — on every copy, not just some of them. Only the credential is replaced: your sentences, timestamps, ids and error text arrive exactly as written, because they are what makes the ask answerable. Nothing to change on your side, and it applies to every ask type. It recognises known credential shapes rather than every possible secret, so still rotate anything you think was exposed.

​

5.1.0 — July 30, 2026 at 11:41 AM UTC

• Connected Meta products now list verified Facebook and Instagram Feed, Stories,
• and Reels placements. Buyers and agencies can select the product’s
• publisher-domain placement references when creating or updating a media buy;
• leaving placements unspecified keeps Advantage+ and all existing calls
• unchanged.
• API buyers can request package performance by setting
• reporting_dimensions.placement; directed-campaign REST callers use
• placementBreakdown=true. Spotify reports only publisher-contained MUSIC
• inventory. Spotify Audience Network podcast inventory, TikTok’s
• cross-publisher bundle, and any placement without exact provider readback stay
• unpublished.
• No seller setup is required. This adds no charge and does not change product
• pricing or packaging.
• Editing a product through Murph is now a change rather than a rewrite. Ask it to
• rename a product or take one off sale and it sends just that, leaving everything
• it did not mention exactly as you set it — so an edit can no longer quietly drop a
• price, a channel or a targeting rule. The approval step now shows you exactly
• which fields are changing, rather than a whole rebuilt product to check line by
• line.
• Paused media buys now retain the provider’s authoritative revision and action metadata, and live adapter checks verify that nested region requests fail closed before any provider mutation.
• Provider capability coverage for audiences, signals, and event sources on connected ad platform accounts is now documented. The new reference page shows, per platform, which reads return the account’s complete inventory and which are partial (bound-only), synthesized, or platform-managed — including the TikTok and Snap audience caveat, where only audiences created through Scope3 are visible.
• Controlled Meta products now preserve exact age and gender targeting through
• launch while rejecting any targeting that no longer matches the selected
• product.
• In Buyer Account Mapping, sellers can now review one relationship per
• operator and brand, see its private coverage across active inventory sources,
• and search or paginate the account roster. Open it with get_seller_accounts.
• The Page is read-only and does not change existing account routing.
• Download the normalized source-binding CSV template, your current healthy
• bindings, and the active native accounts reported beneath each
• source. Equal native IDs in different sources remain separate, CRM is optional,
• and no source topology or native ID is shown to buyers. CSV upload and commit are
• not enabled yet; imports will require a signed preview and one atomic,
• version-checked commit rather than applying rows partially.

​

5.0.0 — July 30, 2026 at 9:54 AM UTC

• Spotify storefront connections now support event-source discovery (sync_event_sources); Amazon’s get_signals no longer returns a demo placeholder — Amazon signal enumeration is unavailable until AMC integration ships.
• Ask for one exact adult age range in a product-discovery brief—for example, “ages 21–35”—and storefronts now offer products only when the connected platform can execute those exact bounds. The selected range is preserved through media-buy creation and readback; on Meta, people whose age is unknown are excluded unless you explicitly include them. Meta and Spotify accept continuous ranges within their limits. Snap, TikTok, and Pinterest accept only exact combinations of their native age buckets, while other adapters do not support age targeting yet. Open-ended, disjoint, exclusionary, ambiguous, under-18, or unsupported requests are not widened or guessed: an adapter that cannot represent the request contributes no matching product. Existing supported briefs require no changes; if discovery returns no matching product, rewrite the brief as one explicit supported range. This applies to age carried by the selected product, not targeting_overlay or changes to an existing media buy.
• If you call seller MCP tools directly, replace get_business_profile with
• get_media_kit; replace get_merchandising_rules and get_selling_terms with
• get_playbook; and replace get_acceptance_policy with
• get_business_rules. Your saved configuration and version history are
• unchanged.
• Seller configuration now uses three matching names: Media Kit for what
• buyers see, Playbook for how you package and price, and Business Rules
• for what you accept and when a person reviews it.
• Fixed execute_campaign failing with “no pricing options” for wholesale products stored under account-scoped catalog keys. The reconcile path now reads all catalog account keys for the storefront instead of only the public partition, matching the forward path’s behavior.

​

4.150.0 — July 30, 2026 at 8:30 AM UTC

• Buyers can now select supported performance goals on TikTok, Snap, Pinterest,
• LinkedIn, Google Ads, and Spotify packages. Product discovery states each
• platform’s exact goal capabilities, creation fails before spending when a goal
• cannot be applied, and creation verifies the provider’s stored goal before the
• buy can proceed. Reddit and Amazon reject optimization-goal requests until
• their provider identity and readback gaps are implemented.
• Buyer agents can now call get_account_resources on a platform-composed
• storefront to list the audiences, signals, and event sources attached to a
• linked account. The tool returns live, cursor-paginated, opaque references with
• per-source capability and coverage metadata. It does not return audience
• membership, event payloads, setup secrets, private source IDs, or source-native
• account IDs. Check partial, truncated, and each source’s coverage before
• treating the response as complete.
• Who this is for: Buyer agents are the direct user; enterprise brand and
• agency buyers receive the same account-scoped result through their agent. The
• seller impact is disclosure of opaque capability, coverage, freshness, and
• error state for sources already attached to an active buyer grant. Sellers get
• no new workflow, and buyers still cannot see native source topology or account
• IDs.
• Packaging and rollout: This is included in existing sales-agent connections
• with no new billable surface or pricing change. gate: none is intentional for
• this atomic, read-only launch because the existing authenticated principal,
• active account grant, and bound-source relationship are structural gates. The
• kill switch is removal of the custom-tool and adapter signal registrations;
• broader provider coverage requires authoritative account-scoped enumeration and
• acceptable partial/error rates.
• Measurement: Standard MCP calls to get_account_resources are the adoption
• event. Monitor calling buyer principals and linked accounts, successful grant
• resolution, complete versus partial responses, unavailable-source and
• truncation rates, resource counts, and cursor completion.
• When updated Terms of Service appear in Interchange and require a new acceptance, eligible organization administrators can review them immediately or choose Review later until the displayed deadline. After that deadline, other members see that an administrator needs to act. Negotiated pricing stays attached when the update is a minor version.
• Nothing changes for the current v3.0 terms, and no action is needed until an updated version is published. Patch revisions that do not materially change the terms continue with notice and continued use; material minor and major revisions require an administrator’s affirmative acceptance. If agreement status cannot be verified, API and agent actions pause with a retryable error instead of proceeding without confirmed terms.

​

4.149.0 — July 30, 2026 at 3:27 AM UTC

• The Demand inbox now reads as an honest scoreboard. A figure the platform
• couldn’t compute says why — “Nothing decided yet”, “Nothing booked yet” — instead
• of showing a bare “N/A” or, worse, a zero that looks like a real result. A lost
• brief is presented as history rather than an error, and “agent-led” is no longer
• coloured as the better outcome than “human-led”. The scoreboard now stays pinned
• at the top while the ledger scrolls beneath it, so a long list never pushes your
• numbers off the screen, and the ledger fits a phone-width window without
• scrolling sideways. Filtering to a buyer with no briefs now says “No matches for
• this filter” and offers a one-click reset, rather than showing a blank table. You
• can refresh without leaving the page; if the refresh fails, your last figures stay
• on screen with a note instead of the page going blank. Dates, currencies and
• counts follow your language and region, and the screen’s own labels are now
• translated.

​

4.148.0 — July 30, 2026 at 3:10 AM UTC

• Region targeting now refuses nested ISO subdivisions on Meta, Google Ads, Snap,
• TikTok, LinkedIn, and Spotify because those provider searches do not return
• enough hierarchy to distinguish a child from a larger same-named parent.
• Previously, some French département codes and other nested subdivisions could
• silently resolve to a larger region, causing broader delivery than requested.
• Top-level state and region targeting, including Meta’s translated provider
• names, continues to work as before. Pinterest, Reddit, and Universal Ads
• continue to accept nested subdivisions because their provider paths do not
• infer identity from a provider name.
• Merchandising decisions now quarantine inventory bundles that the current creative-format contract cannot execute safely and show a clear seller-readable explanation instead of raw validation details. The Simulator also identifies its starter fixture as a Display brief tested against the seller’s current inventory, so non-Display sellers know to use a channel-matched brief.
• Release notes now says what each update is and who it is for. Every entry
• carries how significant it is (Fix, Improvement, Feature, or Headline), whether
• the capability is still Alpha or Beta or is being retired, and why it is in your
• list — Changed for you and In your setup only when Interchange verified
• your account, and For all accounts when the change applies to everyone in
• your role, so a general change never reads as one about you. The feed also
• states what New means and what clears it: opening For you moves your
• read position, and browsing Explore or Recent updates does not.
• The page itself now fits the window instead of growing without limit — the
• count of what changed for you stays visible while the feed scrolls beneath it —
• and dates read in your own locale and timezone. An empty For you points you
• to Explore rather than dead-ending, a failed refresh keeps the updates you were
• already reading instead of blanking the page, and every update can be sent to
• Murph for an explanation, including ones with no linked feature page.
• Buyer agents can now resolve a brand from its domain before creating an advertiser. Existing advertiser creation and REST integrations continue to work as before, with no setup changes required.
• Seller agents can now read the active account, selectable accounts, delivery and margin reports, and safe modular-inventory product and capability data by stable operation name. Booking, configuration, work-item detail, and credential changes remain in their confirmation-gated tasks or trusted operator screens.

​

4.147.0 — July 30, 2026 at 1:50 AM UTC

• Eligible connected ad accounts can now find platform-managed conversion
• outcomes in sync_event_sources and use them in compatible media-buy
• optimization goals without adding a buyer pixel or server event. No setup
• change is required: eligible sources appear automatically for the selected
• account, and existing calls behave as before unless a built-in source is
• selected.
• Media teams can optimize eligible Meta campaigns for shop purchases, Messenger
• contacts, or Instant Form leads. Amazon profiles and Google Ads accounts can
• also discover supported platform-managed outcomes from their account data. For
• API and agent builders, Meta verifies the native optimization goal, destination,
• and promoted object before returning a paused media buy. Built-in sources are
• discovery-only: attempts to change them fail per source, events cannot be logged
• to them, and Scope3 does not invent health scores for them.
• Seller agents using the v3 surface can now reach every supported field, including wholesale-product status filters. Misspelled fields return a correctable validation error instead of being silently dropped. No action is required.
• Campaign teams can now include or suppress Meta Custom and Lookalike Audiences with AdCP’s native audience_include and audience_exclude fields. Create, update, and tracked media-buy reads return the audience IDs confirmed by Meta. No change is needed for Meta packages that do not target these audiences.
• API integrators that send Meta audience IDs through the legacy targeting_overlay.signals extension must move them to targeting_overlay.audience_include; the old field is no longer accepted.

​

4.146.0 — July 29, 2026 at 10:41 PM UTC

• Operator-domain verification now only accepts brand records backed by domain control. A record you published at your own domain (/.well-known/brand.json) or registered yourself through the AAO registry counts as evidence; a record contributed about your domain by someone else does not, because it does not show that you asserted the relationship. This tightens who can claim to operate under a domain.
• Verification also no longer consults the AAO brand-hierarchy endpoint, which was retired in the move to AdCP v3. While it was unavailable, that check could not complete, so an alias or rebrand operator domain that we could not confirm is now reported as “Scope3 could not complete this check” rather than as missing evidence — you will not be told to fix or republish a declaration that is already correct. Confirming these relationships against the AdCP v3 model is in progress.

​

4.145.1 — July 29, 2026 at 8:09 PM UTC

• Bulk-update format_id now applies correctly. Previously, setting format_id in a bulk-update request always silently failed with a validation error because the required internal flag was not threaded through the bulk-apply path.
• Fix two bugs blocking TMB Chime campaign execution.
• Cancel no longer reverts: cancelMediaBuy now stamps both pending and approved rows in storefront_pending_media_buys so an operator approval that arrives after the buyer cancels cannot resurface a dead buy. A new guard in updateMediaBuyFromResponse blocks any incoming status update (including authoritative v3) from reverting a buyer-canceled buy out of CANCELED.
• Execute no longer 500s: the completeDiscoverySession call in executeCampaign now handles “not found or not accessible” and “lapsed” session errors the same way it handles “already completed” — by skipping cleanly instead of propagating a 500.
• upgradeManifest now validates the resolved format_kind through the same canonical identity check as creative creation. Upgrade requests where the format_kind is inconsistent with the creative’s existing assets return a validation error.

​

4.145.0 — July 29, 2026 at 6:35 PM UTC

• Sellers can now disable and re-enable inventory sources directly from the source diagnostics setup panel, without needing to contact support or run SQL queries. The disable action includes a confirmation step to prevent accidental changes.
• Creative assignment now enforces advertiser ownership: a creative belonging to one advertiser can no longer be attached to a campaign belonging to a different advertiser within the same account. The assign endpoint returns 422 when advertiser IDs conflict.
• Collection fan-out skips cross-advertiser members and returns an ownership_excluded count in the response — if that count is non-zero, promote the skipped creatives to the correct advertiser before retrying. Sellers are not directly affected by this change.
• Fixed intermittent REFERENCE_NOT_FOUND errors when discovering products from pubX. The SDK’s async polling was making account-less requests to sources that require account context on all calls.
• Meta campaign data stays reachable after an access-token refresh. Meta
• partitioned its stored adapter state — targeting provenance and account
• pagination — using a key derived from the access token whenever host credential
• identity was unavailable. Refreshing that token changed the key, so anything
• recorded under the previous token became unreachable and a later targeting
• update could fail to find its own history.
• The partition now comes from durable account identity, which a token refresh
• does not change. Snap, TikTok, Spotify, Pinterest, Reddit and LinkedIn already
• work this way; Meta was the last one that did not.

​

4.144.0 — July 29, 2026 at 4:58 PM UTC

• Campaign reads can now bypass cached media-buy state when a buyer needs to
• confirm a lifecycle change immediately. This prevents a successful pause,
• update, or cancellation from briefly appearing unchanged.
• Users belonging to multiple WorkOS organizations can now log in. Previously, if a user was a member of more than one org, WorkOS returned an organization selection error that blocked login entirely.
• Ask Murph what you have open and you get one list of support, product, and supply asks, each with a status that moves as the work does. A product ask now follows the engineering work it is attached to; a supply ask follows that seller and channel through onboarding. Before this, a product ask read “Tracked for product review” from the day you filed it until the row dropped off the list; that is now just its starting state, and it moves from there. Every ask carries one status from a closed set (received, accepted, in_progress, done, closed) plus a statusLabel and statusDescription written for you. Internal workflow state names and ticket references never appear in a customer response, and a state we cannot describe honestly stays at received.
• GET /api/v2/asks is now documented in the buyer and storefront API references, so your own agent can read the same list. It is read-only, takes no customer parameter, resolves your account from the API key you call with, and returns up to 25 asks per call alongside hasMore. If a source cannot be read, the response names it in unavailableKinds instead of returning an empty list that would read as “nothing open”. The two undocumented reads it replaces, /api/v2/customer-picture/requests and /api/v2/customer-picture/ask-status, now return 404 — point any call you have at GET /api/v2/asks.
• Which statuses a kind reaches differs, and the read says so rather than implying otherwise: support and supply asks both keep a short recently-resolved window, so a supply ask shows up as ready before it ages out instead of quietly disappearing — dated from the marketplace evidence that made it ready, not from when your request row was last touched, so a seller that went live yesterday shows as ready even on an old request. Two gaps are named rather than papered over: a product ask leaves the list once the work ships or is dropped, and a cancelled supply ask leaves the list too, because we have no reliable record of when it was cancelled and would rather drop it than show you a made-up date. Supply asks are the sellers and channels you asked us to bring into the marketplace, so you see them only if you have filed one. Support asks filed before this change may not yet show a next-update date or a still-blocked confirmation. Full details: Ask Murph → Your requests and support.

​

4.142.0 — July 29, 2026 at 1:22 PM UTC

• Reading an ad-server-backed product now reports its pricing the way buyers see it. Uploaded wholesale pricing is applied when your catalog refreshes, but a product read went straight to your ad server, which never learns about that upload — so a product your feed had priced still came back as “pricing unresolved”, permanently on any ad server that doesn’t report pricing. A product you priced with a fixed rate reads as priced too. Products your feed hasn’t priced are unchanged: still unresolved, with the reason.
• Wholesale pricing uploads now accept CSV files that arrive as text/plain. Text editors, Slack, and some operating systems label a .csv attachment this way, and those uploads were previously rejected before reaching the parser even though the file was valid CSV.
• Creative asset URLs are now round-trip safe for filenames containing %, ?, or #. Such filenames previously produced a URL that could not be resolved back to the stored asset.
• Changing one field on a wholesale product no longer means re-sending the whole
• product. patch_esa_product applies only the fields you name and leaves
• everything else exactly as it was, so renaming a product or flipping its status
• can no longer clear the prices, channels or targeting you never mentioned.
• update_esa_product still replaces the whole product for callers that hold a
• complete one.

​

4.141.0 — July 29, 2026 at 12:45 PM UTC

• The Campaigns page now shows filters by phase, handling, and search; a stats band with live/draft/blocked counts; per-campaign attention signals; and load-more pagination. Launching the Campaigns page from the agent also now scopes to an advertiser when one is active in the conversation.
• Fix brief-mismatch in inventory-source test campaign execution. The plan tool now includes the captured brief verbatim in its nextActions so Murph carries it to the execute call, and the execute tool description makes clear the brief must match the one used during planning. A different (or defaulted) brief causes discover_products to return zero results and silently breaks execution.
• The connected-account subscription read now reports the tracked-presence sweep cursor: lastPresenceSyncedAt, lastPresenceSyncStatus (SUCCESS, ERROR, or SKIPPED), and a sanitized lastPresenceSyncError. An empty audience/event-source presence list is now distinguishable from a sweep that has not yet visited the account.
• Seller approval verdicts (approved/rejected) are no longer reset to pending on every creative re-sync when the creative content has not changed. Previously, each outbound sync overwrote the stored verdict regardless of whether the adapter reported any content change.
• Fixed an issue where retrying execute_campaign on a cross-currency media buy always failed with “This media_buy_id is already bound to a different immutable FX rate.” The FX lock’s rate_as_of_date column (PostgreSQL DATE) was returned by the driver as a JavaScript Date object, but compared with === — which checks reference identity, not value equality. Two separate reads of the same date always failed the comparison.
• Fixed an issue where reconnecting a Meta storefront connection via Settings → Connections left the connection in an error state. The OAuth flow completed successfully but the credential status remained broken on subsequent reads.
• Fix storefront forwards silently failing after ESA v1.30.0 enforcement. When forwarding a media buy to a canonical managed sales agent, legacy format_ids are now stripped from the outbound packages before dispatch. The canonical format_kind/params selector is preserved. Legacy AGENT sources are unaffected.
• You can now change the geography of a running campaign on every social ad
• platform Scope3 connects: TikTok, Reddit, Pinterest, LinkedIn and Spotify join
• Meta and Snap. Previously these five refused every targeting change on
• update_media_buy, so the only way to correct a campaign’s geography was to
• create a new media buy.
• Geography is declared state, not an edit. The regions you list are the regions
• that deliver, and a region you stop listing stops delivering. Send
• geo_regions: [] — or omit geo_regions while supplying geo_countries — to
• return a campaign to country-level delivery. Countries you don’t restate carry
• forward, and a country with no region of its own is untouched. Omitting
• targeting_overlay entirely leaves targeting alone, so budget and date changes
• don’t require restating geography.
• Unresolvable region codes are refused before the platform is called, so a failed
• targeting change never leaves a campaign half-updated. Dimensions other than
• geography are still refused on update with UNSUPPORTED_TARGETING_DIMENSION.
• One Spotify correction worth checking your integration against: a Spotify ad set
• carries a single country, and a request naming more than one used to deliver to
• the first and discard the rest without telling you. That request is now refused
• with a 400 naming the countries it received. If you send multiple countries to
• Spotify today you are already only delivering to one of them — split them across
• packages to reach all of them.
• See the connect guide for the current per-platform table.
• Google Ads now applies geo_countries and geo_regions on create_media_buy.
• Country and region codes resolve against Google’s own location inventory at
• request time, so any ISO 3166-1 country or ISO 3166-2 subdivision Google
• supports is available rather than a fixed list.
• This closes a gap where Google Ads advertised four targeting dimensions through
• get_adcp_capabilities and applied none of them: a campaign you targeted at one
• country delivered everywhere, and nothing in the response said so. That silent
• failure was already stopped — Google began refusing targeting it could not
• apply — and geography now works rather than being refused.
• Two Google-specific behaviors to build against:
• Google targets geography at the campaign level, not per ad group, so every
• package in one Google media buy must declare the same geography. A buy whose
• packages disagree is refused with INVALID_PACKAGE_MIX before anything is
• created — use separate media buys for separate geographies.
• A region code that doesn’t resolve to exactly one Google location, and a
• location lookup that fails, are both refused before any campaign is created.
• Nothing is half-built.
• keyword_targets and negative_keywords are still not applied on Google Ads
• and are still refused. Geography applies on create only; changing it on an
• existing Google buy is refused.
• One reporting limitation to plan around: Google delivery reports break geography
• down by country, so a campaign you target at a region reports against its
• country rather than the region. The targeting applies — you just can’t yet see
• the region back in get_media_buy_delivery.
• Murph now says plainly when an approved action failed before anything could be written, while continuing to ask for state verification when a timeout or server error leaves the outcome uncertain.
• TMP eligibility on storefront forwards is now derived entirely from Product.trusted_match.identity_match. An additional internal enrollment step required behind the scenes on top of the product declaration has been removed.
• Sellers: no change in how you set up TMP — declaring identity_match: true on a product remains what enables it. Outbound line items on identity-matching products now carry the package-ID key-value automatically once the declaration lands, without waiting on an internal follow-up.
• A Terms of Service update within the same major version no longer asks you to re-accept. If your organization has accepted v3-0 and Scope3 publishes v3-1, you keep working — no prompt, no interruption. Only a new major version requires an admin to accept again.
• Two pieces of vocabulary now match the protocol and the API, so the docs and your agent use one word each.
• Wholesale product is now defined in the glossary: the product you author on a managed sales-agent source, told apart from a composed product (cf_, built to a brief at discovery) and from a third-party agent’s passthrough products. “Create products from ad-server inventory” opens with that three-way distinction, and clarifies that a component is the raw ad-server material you select from, never something you author.
• Signal replaces “signal component” throughout the documentation. It is the same thing under one name — every API operation has always used signal (create_signal, list_esa_signals), and the prose had drifted. The raw material you author a signal from keeps its own name, ad-server targeting. Some in-product copy still says “signal component” and will follow.

​

4.140.1 — July 29, 2026 at 11:54 AM UTC

• Murph now names and requests every required signal field before creating a component, instead of returning an unnamed “Field required” error after validation.

​

4.140.0 — July 29, 2026 at 9:39 AM UTC

• With a linked storefront account, get_media_buys can now return media buys from each available inventory source the seller has explicitly mapped to that account. Discovered buys use stable storefront IDs and are tracked, read-only records; pass the same linked account and ID to get_media_buy_delivery. Calls without an account are unchanged, and sources without a native-account mapping are not included in account-wide discovery.
• Reviewing one buyer exchange is clearer and more honest. On a phone-width
• screen the allocated money no longer hides behind a sideways scroll — each
• product now lists its price and allocation on its own labelled line. A booked
• amount reads at full precision (£95,000, not £95K), so the number you quote is
• the number that was recorded. A lost exchange reads as history rather than an
• alarm, the pass timeline stays neutral because it is a record of time rather
• than status, and the letter grade now says “Grade” beside it. If the exchange
• fails to load you get a Retry instead of a dead end, and the error text is
• readable in dark mode. Dates, prices and budgets now follow your own locale and
• time zone, and the screen’s labels are translated. Anything that was never
• captured still says so — “Not recorded”, never a blank that could read as zero.
• Compare how your Merchandising Agent would answer the same brief under different configurations on the new Merchandising Simulator page — without changing anything live. A simulation starts from a scenario (a sample brief, one you wrote, or one a buyer sent you) and runs your baseline plus up to three variants — a different negotiation posture, price adjustment, rate card, or bundle rules — through the same engine that answers real briefs. Each card shows the products offered and their CPMs, and every variant states its delta against the baseline: how many products moved, exactly which ones dropped or joined, and the price change. When a variant produces no offer (an acceptance-policy decline, for example), its card says why. Run every variant with one action; results are saved, so you can come back to them any time. A simulation shows what your agent would offer, not how a buyer would respond, and it never changes your live configuration.
• Meta ad platform connections now automatically extend their access token before it expires. Previously, Meta tokens silently expired after 60 days and required a manual reconnect from Settings > Connections; the background credential health sweep now extends them in place, keeping delegated workflows running uninterrupted.
• A create_media_buy call that used to return 200 for a targeting dimension a
• platform doesn’t apply may now return 400 — check your error handling for
• UNSUPPORTED_TARGETING_DIMENSION.
• Each ad platform applies only a handful of AdCP’s 28 targeting dimensions. Until
• now, a dimension a platform didn’t implement was accepted and silently dropped:
• the call succeeded and the campaign delivered without it, with nothing telling
• you the targeting never applied. If you set targeting that a platform didn’t
• support, those campaigns reached a broader audience than you asked for, and the
• spend went with them. Those requests are now rejected before the platform is
• called, so no campaign is created.
• get_adcp_capabilities is also corrected. Some platforms had declared targeting
• they never implemented — Spotify’s audience include/exclude, Amazon’s
• geo_countries, and Google Ads’ geo_countries, geo_regions,
• keyword_targets, and negative_keywords. media_buy.execution.targeting now
• lists only what a platform applies, so a platform you use may list fewer
• dimensions than before, or refuse a request that used to appear to succeed.
• Either way, that targeting was never reaching the platform.
• Changing targeting on an existing buy is separate and still narrower. Snap now
• supports geography changes on update_media_buy — previously it accepted them
• and silently discarded them — joining Meta. TikTok, Reddit, Spotify, Pinterest
• and LinkedIn continue to refuse any targeting change on update; create a new
• media buy instead. See the connect guide for the per-platform table.
• Pause, update, and cancel now keep using the connected ad account’s delegated
• credentials after a buyer creates a campaign through an internal social-adapter
• storefront. This prevents lifecycle actions from incorrectly asking for a new
• OAuth authorization or losing the provider campaign while canceling it.
• Operator-domain verification now accepts owner-registered brand records as ownership evidence. If you registered your brand through the AAO registry API rather than publishing /.well-known/brand.json for the crawler to find, that record previously did not count toward verifying an alias or rebrand operator domain, even though records contributed by third parties did. Registering the record yourself is stronger evidence than a third-party contribution, and it is now treated that way.
• Brandfetch-enriched records are still refused: they describe a brand but assert nothing about who owns or operates a domain.

​

4.139.0 — July 29, 2026 at 2:41 AM UTC

• Product discovery no longer slows down as a storefront accumulates inventory sources. A storefront with hundreds of sources could previously exceed the discovery time limit and fail get_products; its catalog is now read in a fixed number of queries regardless of how many sources it has.
• Fix CANCELED campaigns displaying incorrectly as DRAFT in the Campaigns view.
• The button that adds a modular source now matches the task it opens. Seller Setup still said “Add feed-backed source” while the task it launches is called “Add a modular source” — the same mismatch in Portuguese and Japanese. The docs and Murph now use one name for these surfaces too.
• Several seller widgets now scroll within a fixed height instead of growing unbounded, so long content no longer cuts off or blocks what renders below it: Sales-agent health, Ad server source, Demo storefront, Avails commit, and Get ready to sell setup.
• Nothing changes for accounts that are already live. No existing contract can enter the state below.
• When Scope3 sets up a new organization on standard terms, an admin at that organization now accepts the Terms of Service. Scope3 provisions the account and no longer records acceptance on your behalf.
• Until an admin accepts, get_billing_account reports plan.contractStatus: "awaiting_acceptance" with a nextAction of type ACCEPT_TOS, and endpoints that require an active contract return 403. That action carries the route and tool that resolve it — POST /api/v2/accept-tos and accept_tos — so read it rather than hardcoding either. The endpoint is unchanged. In Interchange, the same acceptance appears as “Accept the platform terms” on Plan & Billing.
• Acceptance claims the contract Scope3 provisioned instead of creating a new one, so a rate card negotiated at setup stays in force once your admin accepts.
• Accounts that inherit their organization’s contract cannot accept for themselves; accept_tos returns 403 for them. One admin on the organization accepts, and its accounts are unblocked, rather than transacting on terms nobody agreed to.
• If someone at your organization is set up but blocked, the person who needs to accept is an admin on the organization itself.
• Turning off review for creative submissions or media buys (setting creativeApproval or mediaBuyApproval to auto) now requires an explicit acknowledgement: pass acknowledgeNoHumanReview: true when calling set_approval_settings or update_storefront, or check the confirmation box on the Selling Terms Page. In auto, nobody reviews the item, and for media buys your Acceptance Policy is not consulted at all. Tightening back to manual, or saving a setting that is already auto, needs no confirmation.
• Buyers can continue creating and managing campaigns through the existing product discovery and media-buy APIs; no action is required for integrations already using those APIs. The never-enabled connected-account create, update, plan, and accept routes are removed and now reject requests, so any integration attempting to use them must move to the buyer APIs. Connected-account subscriptions remain available for read-only campaign mirroring, refresh, and delivery views. Seller storefront presentation and ranking are unchanged.
• Media buys running on a source that reports a day’s delivery as a single total, rather than a day-by-day breakdown, now show that delivery in reporting. Previously it was discarded, so those buys reported no delivery at all even while they were serving.
• Delivery for a day that is still in progress is now included too, and refreshes as the day continues.
• Sellers see the same delivery reflected in their realized cost basis, which previously stayed empty for these sources.
• Storefront readiness now tells you why an operator domain is pending verification, and who has the next action. Previously every cause produced the same “pending verification” message, which listed all the possibilities and often said the blocker was waiting on Scope3 review even when the action was yours.
• You now see one of four specific outcomes: your account domain needs ownership approval before alias evidence is checked at all; your account has no registered domain yet; published AAO or brand.json evidence does not link your operator domain to your account domain; or Scope3’s evidence check did not complete, in which case Scope3 owns the retry and no action is needed from you. Murph reports the same cause and owner as the readiness check rather than defaulting to “waiting on Scope3 review”.
• A check that fails to complete is no longer reported as missing or invalid evidence, so you will not be sent to fix evidence that is already correct.

​

4.138.0 — July 28, 2026 at 9:02 PM UTC

• Buyer agents can keep their existing get_products, create_media_buy, and
• update_media_buy calls. When a request includes a linked storefront account,
• the storefront now routes each inventory source with only the account identifier
• the seller assigned to that source.
• Before an inventory source is contacted, the storefront confirms that the buyer
• grant is active and that the source has one current, unambiguous mapping. An
• inactive grant or a missing, ambiguous, or stale mapping fails closed for that
• source; buyer agents should continue handling standard AdCP errors.
• Sellers must repair an affected mapping before the buyer retries. This release
• does not add a seller setup screen, and it does not change pricing, billing,
• calls without a linked storefront account, or legacy natural-key accounts.
• Account-specific media-buy history, reporting, audiences, and event sources are
• not included in this release.
• Eligible buyers can now create an Interchange organization when buyer admission is open and choose whether to start in the app, build with the API, or connect an assistant. An organization invitation bypasses the public signup waitlist and joins the recipient to that specific organization; it is not a reusable or storefront-scoped admission link.
• Buyer admission remains controlled by the alpha-opt-in rollout. When admission is closed, brand-new advertiser signups continue to see the waitlist.
• The buyer-agent activation contract now also defines staged benchmark evidence and measurement for evaluation, customer claim, storefront-neutral transaction readiness, and the first governed buy.

• ​

  Who notices what

• SMB and first-time buyers: an admitted signup continues into organization creation and then shows one plain-language choice for where to begin. A closed signup still ends at the waitlist; no technical action is required.
• Enterprise brand and agency buyers: an organization-scoped invitation remains the governed way to join the intended organization without entering the public waitlist. It grants no access to any other organization or seller.
• Builders and power buyers: the starting choice names the app, API, and connected-assistant paths explicitly. Choosing one does not remove the other two.
• Sellers: not applicable. This changes buyer admission and the buyer’s starting surface; it does not change seller ranking, storefront presentation, inventory labels, or seller setup.

• ​

  Monetization

• None in this slice. Creating a buyer organization and choosing a starting path does not select a paid plan, activate a billable feature, or change media settlement. Existing route-specific billing and any later account-activation pricing remain unchanged.

• ​

  Measurement and acceptance

• The four Chromium scenarios are the release acceptance gate: closed signup reaches the waitlist, open signup reaches verification, an organization invitation bypasses only the public waitlist, and an admitted buyer reaches the three-path starting choice. The UI emits activation:choice_shown, activation:door_chosen, and activation:choice_deferred as product-analytics projections.
• The server-owned KPI contract names activation_started, buyer_signup_completed, activation_door_chosen, first_authenticated_call, customer_claimed, storefront_ready, and first_governed_buy. Zero-touch activation requires first_authenticated_call with no scope3_operator intervention between it and activation_started; time-to-first-call is measured from activation_started for agent-first journeys or buyer_signup_completed for human-first journeys. These KPIs are not claimed from browser analytics alone: they become reportable only from the durable activation stream defined in AI-2900.
• You can run each saved Simulator alternative against the seller settings captured with the scenario, then compare the resulting decisions without affecting buyers or live analytics. Every attempt remains available for review, with up to 25 attempts per alternative and 100 per scenario. No action is required in your live setup.
• Fix multi-size image package format IDs sending as display_image:None×None on creative update and re-sync paths. The update path now resolves the correct sized format ID (e.g. display_970x250_image) using manifest asset dimensions, matching the behavior on initial execution.
• Setting or rotating a sales-agent source’s credentials is clearer and safer:
• credential fields stay masked and no longer trigger browser autofill or
• password-manager save prompts, replacing an existing credential says so up front
• (and never shows the old value), and the “credentials saved” confirmation is now
• legible in dark mode. Nothing to change on your side.
• Managing your storefront’s buyers is clearer and safer. Disabling an invite
• link now asks you to confirm and tells you exactly what happens — buyers who
• already joined keep their access, and anyone still holding the old link can no
• longer use it. Minting, copying, and disabling a link show progress while they
• run and confirm when they’re done, so you always see the result. Buyer statuses
• read in plain traffic-light color (a suspended buyer is no longer flagged like
• an error), and when you have no buyers yet the screen coaches you to share your
• invite link instead of showing an empty table.
• agentPersonality on your business profile is deprecated. An agent does not have a personality of its own — the voice buyers hear is your brand’s voice, read from your brand manifest’s tone alongside your logo, colours and tagline. Nothing ever consumed the field, so nothing changes in how your storefront sounds; it stays writable only so you can clear an old value, and we have stopped showing it in examples.
• Your pricing facts now accept the AdCP pricing models — cpm, vcpm, cpc, cpcv, cpv, cpp, cpa, flat_rate, time — and nothing else, and the Selling Terms page offers them as a list instead of a free-text box. Previously it took any text: you could type a shape we cannot transact, it looked saved, and everything downstream quietly ignored it. If your price list has a shape that isn’t in that set — share of voice, a day-part premium — that is worth telling us rather than working around, because it means we cannot yet model something you sell. Nothing you have already saved is affected, and cpm remains the default when you don’t say.
• There is also a new page explaining merchandising end to end: the four surfaces that steer how your storefront sells — selling terms, approval settings, acceptance policy, and merchandising rules — which fact each one owns, why a rules version that restates a price is rejected, and what actually changes the moment you save. It spells out the two things sellers most often conflate: your acceptance policy says what is acceptable, your approval setting says whether a human reviews, and in auto mode the policy is not consulted at all.
• A modular inventory source now shows its pipeline: every lifecycle stage in the order a booking moves through them, whether each one runs automatically or waits for a person, how many tasks are open on it, and when the module behind it was last checked. Stages nothing on your source handles are listed too, saying which gap they are — a stage with no module of the right kind reads differently from one whose module doesn’t cover it, because the fix is different. This replaces the separate readiness and modules panels, which between them said the same thing twice and never said how a stage actually works.
• Webhook URLs must now be directly reachable public HTTPS endpoints. Sellers
• registering partner-agent URLs and buyers configuring storefront callbacks
• should update any URL that uses HTTP, resolves privately, or redirects.
• Sellers receive a validation error when registering an incompatible URL, and
• unsafe buyer callback destinations are not called. Nothing changes for existing
• public HTTPS endpoints.

​

4.137.0 — July 28, 2026 at 6:30 PM UTC

• You can save a buyer brief and up to three private merchandising alternatives without changing how your live agent sells. Simulator work stays out of live brief history, analytics, learning, and commercial results. Nothing changes on your side until you choose to create a scenario.
• Your Property Roster now holds every property your publishers declare, and answers at the level you ask at.
• Large networks were silently capped at 5,000 properties per domain. A domain declaring 6,843 sites kept 5,000, the rest were never recorded, and asking your agent whether a site was covered could come back “no” for a site you do sell. Every declared property and collection is now stored, however many there are. Each domain also carries propertyCount and collectionCount — how many it actually has, which can exceed what a single response returns — and the response carries a truncated object naming any part it left out. totals describes your storefront rather than the response, so if you compared the resolved-property count on your publisher list against your roster and the numbers disagreed, they now agree.
• Every property carries its own authorization. Read grain alongside status: a negative is definite, because a publisher domain that does not authorize your agent authorizes nothing beneath it; a positive is inherited from the domain rather than proven against the exact selector the publisher bound your agent to. A property you declared yourself, or one under a domain whose last check did not complete, reads unknown rather than claiming to be sellable.
• A domain that serves something unreadable at /.well-known/adagents.json now says so instead of reporting that no file exists. adagentsStatus gains invalid — a document is published there and is not a usable adagents.json, commonly an HTML page or a redirect. no_adagents now means only what it says. The remediation differs: fix the file you have, rather than publish a second one.
• Property key-values are reachable from your agent. get_property_mappings returns the current bindings and replace_property_mappings replaces them; preview first with params: { dry_run: "true" } and a body of just { mappings }, and the preview reports which rows mapped, which did not and why, and whether each key-value and ad-server selector exists in your ad server.
• Finally, a storefront that sells through a platform account connection is no longer told to publish an adagents.json. Those storefronts get selling rights from the connection, no adagents.json will ever resolve, and the roster, readiness checklist and your agent now all say the authorization verdict does not apply rather than showing a permanent failure.
• Audience-targeted buys forwarded to a Scope3-hosted sales agent now carry the package-ID key-value on the ad server line item. Previously the key-value was omitted for these sources, so the line item was less restrictive than the campaign’s audience targeting intended and could serve on ad requests carrying no identity-match signal.
• Buyers: audience-targeted campaigns on these sources now deliver only against the audience you specified.
• Sellers: for products you declare as identity-matching, line items created on your ad server now carry the package key-value and target more selectively than before. Expect tighter, better-qualified delivery on those line items.
• Your saved Simulator scenario now uses the same selling logic as live demand while keeping the captured brief, inventory, rules, and pricing frozen. Existing scenarios need no action and still cannot change live seller settings.
• The three source surfaces now use the name the documentation already uses: a modular inventory source. They previously said “feed-backed source,” which named a source after one of its modules — a modular source can just as easily carry an ad-server or human module, and every one already has a booking ledger alongside its avails feed. Nothing about how a source works has changed: the workspace, the add-source task, and the avails upload all behave exactly as before.
• Managed ad-server inventory now preserves canonical creative format details through order creation, preventing valid fixed-size image packages from being rejected by a lossy legacy ID. Scope3’s buyer path is already migrated, so sellers do not need to change their ad-server setup and buyers do not need to change how they create media buys. FreeWheel capability checks also resume automatically after vendor permissions recover, including before the first media buy.
• Approving a wholesale pricing upload now actually commits it. Previously, if you attached your pricing file and then approved the upload on a later message — the normal way an approval works — the commit could not read the attached file back and stored nothing, while the retry reported the upload as complete. Sellers who uploaded the same feed repeatedly were told each time that it was live when no rows had been saved. Approved uploads now read the file from where it was stored when you attached it, so the commit lands regardless of how many messages passed between attaching and approving. If the file genuinely cannot be read, the upload now says so and asks you to re-attach it rather than reporting success.
• More generally, any action that needs your approval no longer claims to have happened when it failed. An approved action that errors is now reported as not done, so you are asked to review and approve it again instead of being told a change was saved that never was. A successful approved action is still applied only once.

​

4.136.0 — July 28, 2026 at 2:39 PM UTC

• EUR buyers can now add products from USD-priced adapter storefronts (Meta Ads, Google Ads) to campaigns without a CURRENCY_MISMATCH error. FX conversion is applied at execution time when the buyer-to-seller currency pair is supported by marketplace FX.
• Inventory source tests now run against the exact product you selected during planning. Previously a test could fail to build a campaign when the selected product fell outside the top slice of discovery results, even though the source could sell it.
• Buying accounts are now identified consistently to sellers. Every step of a campaign (product discovery, account setup, booking, updates, cancellations, and delivery reporting) now sends the same buying organization for a given advertiser, so a seller opens and bills one account per buyer instead of several. Previously the identity varied by step, and on updates and cancellations it was taken from whoever was signed in, which could present the same buy under two different buyers.
• Buyers who have not recorded their own company domain are identified as operating through Interchange. Record your company domain in account settings to be identified under your own organization instead.
• If you have not recorded a company domain, the name your sellers see for you changes with this release. Sellers who create accounts on first contact will open a new one for you on your next request, and campaigns you have already booked stay on the account they were booked under. Nothing stops delivering and no reporting is lost, but for a short period the same seller may show you two accounts. Recording your company domain later has the same effect once more, so it is worth doing before your next campaign rather than during one.
• The Creative Assets dashboard now shows platform-specific ad formats (such as Meta image and video feed formats) in the format selector when creating or uploading a creative for campaigns that include Meta products.
• Opening a feed-backed source in Murph now tells you whether it can sell before anything else: live or in setup, how many avails it holds, and the single next step. Lifecycle stages, the modules behind them, and the work waiting on a person sit below that. Adding a source is now its own task with three fields — a name, where its avails come from, and how often they arrive — replacing eight more that had no effect on how the source ran. Uploading avails is a separate task that still previews before it commits, and the result now names the rows that were rejected alongside the ones that landed, so you can fix the export and upload again. Nothing is offered to buyers until you commit avails rows. Sources you already created keep working, and half-finished setup resumes where you left it.
• When you call add_discovery_products after a prior execution, execute_campaign now warns you that the pending media buys no longer reflect your current discovery selection. Previously, the tool retried the stale state silently. The warning returns the affected media buy IDs and a hint field with the recovery path.
• To apply the current selection and execute in one step, call create_media_buys with replace: true and mode: "execute".
• Sellers: not applicable — this change is buyer-side only and does not affect seller-visible storefront ranking, rendering, or labeling.
• Fixed a bug where running a test campaign against an inventory source that requires authentication would silently return zero products instead of testing the source correctly.
• Flight dates now read the same wherever you are. A campaign or media-buy flight was formatted in the reader’s own timezone, so a window that starts on 1 January showed as “Dec 31” for anyone west of UTC — whether the date arrived as a calendar date or as the instant that day begins. A flight bound names a day, and is now shown as that day.
• Fixed an issue where a media buy package containing multiple image creatives of different sizes (e.g. 970×250 and 728×90) sent a generic display_image format ID to the sales agent instead of the correct sized format ID for each creative. The sales agent can now route each creative to the correct sized placement.
• Fixed Murph telling you a report had not been filed after it was successfully filed. Asking for help through the Scope3 team now confirms the filing correctly, with its reference, instead of offering to file it a second time.
• The IU plan selection surface now formats prices, discounts, and dates for your
• account’s language and time zone, and the “pricing changed while you were
• reviewing it” notice reads as a calm heads-up that stays legible in dark mode —
• never a red alarm. Your confirmation is still bound to the exact offer you saw:
• a superseded price is refused cleanly and shown again for a fresh confirmation.
• Read the brief your Merchandising Agent answered as a business document. A proposal pass opens on the advertiser, who it came through, and the buyer’s ask in their own words — then budget, flight, markets, channels, how they want to transact, and how long you have to respond. Their requirements read as sentences: placements, exclusivity, policies, the metrics they expect back, performance standards, and approved property lists and catalogs by name. Anything the buyer did not send is simply absent. The exact request, its identity, and its capture evidence sit under Technical details.
• See the proposal your Merchandising Agent sent, as the pitch it is. A pass leads with the plan’s name, its scale, and its argument for the brief, then one line per product with its price and its share of the plan. Expand a product for why it is in the plan, every pricing option offered and where your selection sat against market guidance, where it runs, who it reaches, and what it reports. When the buyer committed a single exact budget, each share also reads as money. The exact response and its capture evidence sit under Technical details.
• Fixed storefront inventory-source callbacks rejecting RFC 9421 signatures. The sales-agent and storefront-catalog callbacks already accepted them; the inventory-source rail did not, so a source signing to current AdCP defaults had every delivery rejected with a 401 even though its signature was valid.
• All three inbound rails now verify RFC 9421 HTTP Message Signatures as well as HMAC-SHA256, which AdCP deprecates and removes in 4.0.
• If your source was already signing with RFC 9421 and getting 401s, it should start being accepted with no change on your side. If you want to move a source off HMAC, publish a jwks_uri in the agents[] entry of your brand.json and send Signature and Signature-Input on each delivery; HMAC keeps working until you do.
• Two details to check when you switch: sign the @target-uri as the callback URL we registered with you (we verify against that, not the inbound Host header), and always send both RFC 9421 headers, since a lone Signature is rejected rather than quietly falling back to HMAC.

​

4.135.0 — July 28, 2026 at 11:10 AM UTC

• Creative requests for AudioStack now use the standard audio_hosted format and duration parameters, with no agent URL or separate AudioStack catalog. Meta, Pinterest, and Snapchat validate publisher format options against their registry declarations, while Figma frame names remain tenant-local build settings. Retailers using CitrusAd or Criteo own their catalog entries under their retailer domains. Buyers sending legacy agent-URL selectors to AudioStack or Figma must switch to these canonical fields.
• Authoring buyer discounts is clearer end to end. When you add, edit, or remove a rate-card discount, the Save button now shows an in-flight state and the widget confirms exactly what applies afterward (“Added a 15% brand discount on nike.com, off wholesale”). If the server rejects a save, you get a plain notice that the change did not take and nothing changed — never a silent no-op. Percentages format for your locale, and a failed initial load now offers an in-place retry. Discount pricing rules are unchanged: brand and operator, the larger discount wins, always floored at your wholesale cost.
• Source health no longer reports missing advertisers for ad servers that do not run an advertiser sync. Only Google Ad Manager syncs an advertiser roster; on FreeWheel, SpringServe, and AdsWizz sources that check now stays quiet instead of asking you to grant advertiser access your ad server never uses.

​

4.134.0 — July 28, 2026 at 8:04 AM UTC

• Meta product discovery now surfaces exactly one product per Meta campaign objective. “Meta Conversions Campaign” is renamed to “Meta Sales Campaign” to match Meta Ads Manager’s current UI. The “Meta Video Views Campaign” and “Meta Reels Campaign” options are removed — briefs mentioning video views or reels now route to the Engagement and Awareness objectives respectively.
• Source health no longer tells you your ad server has withheld reporting or forecasting access when we have never actually been able to check. The diagnosis now reports what Interchange observes, and names the date of the last completed check, so a result from days ago is not presented as today’s status.
• Advertiser-visibility warnings now name your own ad server. A FreeWheel, SpringServe, or AdsWizz source no longer tells you to go check a Google Ad Manager service account.
• Embedded storefront offers now appear as sellers configured them: full creative requirements are preserved, and guaranteed and non-guaranteed fixed-price offers no longer look identical. Buyers get the intended format and price without changing how they discover or select products.
• No seller or current buyer-integration changes are required. Existing package and pricing configuration remains valid. If an older buyer retries a previously cached price identifier that matched more than one offer, the request now returns an error instead of risking the wrong price; refresh the product list and retry with the returned identifier. Older identifiers that match one offer continue to work. Storefront lifecycle, previews, and status behavior are unchanged.
• Buyers enrolled in the directed-campaigns alpha can now read the platform-reported audiences and event sources tracked on a connected seller account with GET /storefront-connections/{connectionId}/accounts/{accountId}/presences (or the list_storefront_connection_account_presences operation). The response is read-only and reference-only: identity, sync status, and row/event counts for each object — never member lists or event payloads. Objects the seller discovered on its own have no buyer-level master until explicitly adopted; objects already pushed from your account carry their audience or event source ID.

​

4.133.0 — July 28, 2026 at 1:18 AM UTC

• You can now book Meta Lead Generation campaigns through the API, MCP tools, and the Murph assistant. When a respondent taps your ad, they complete a Meta Instant Form — pre-populated from their Facebook profile — without leaving Facebook or Instagram.
• To book a Leads campaign, provide the lead_form_id of an Instant Form authorized on your Meta ad account. If you omit the field, the API returns the authorized list so you can select the correct form. Leads campaigns use LOWEST_COST_WITHOUT_CAP bid strategy, so no bid price is needed. Spend is billed directly through your connected Meta ad account at Meta’s standard delivery rates — no additional platform fee applies beyond your existing Meta connection.
• App Installs (Meta App Promotion) are not yet supported; this release covers Leads only.
• The Demo Storefront now reads honestly across its whole life. A live demo shows
• a green status with the days remaining; one that is close to expiring turns
• yellow; and an expired demo shows a calm gray “Expired” state that explains the
• seven-day demo ended on its own and coaches the next step — connect a real
• inventory source or ask an admin to provision a fresh demo. Resetting or
• deleting a demo now confirms exactly what is affected (synthetic demo data only,
• never your account or real members), shows a progress label while it runs, and
• leaves a visible result. Dates follow your workspace locale and time zone.
• When you create a signal component from your ad server’s targeting, the Signal
• components workspace now tells you where the component went — it appears under
• Signal components — and how to change course (rename, reprice, or remove it),
• instead of just saying “created.” Your ad server’s own segment, key, and value
• names and ids always display exactly as your ad server reports them.
• Seller dashboards now load for active and paused storefronts. The dashboard had continued validating retired storefront lifecycle labels after the API moved to the canonical pause-state contract, so it rejected otherwise successful analytics responses and showed a generic loading error.
• Storefront test-campaign plans no longer show source-catalog pricing option IDs that execution cannot accept. Pricing summaries still show the option name, rate, and currency; omit pricingOptionId to let execution select the buyer-facing option.
• The standard plan sizes, the break-even points, the calculator and the worked examples are now all on one page — How IU billing works — instead of the table being repeated on the Organization IU Rate Card page. That page now points to it and stays on its own subject: the Effective Rate Card that binds your organization.
• Two protections moved with the table, onto the page that carries the numbers: the standard list is not everyone’s price, and prices are published per currency rather than converted from USD. Nothing about the figures themselves changed.
• Buyer account requests to a hosted storefront now wait for the seller’s decision when no approved relationship exists. sync_accounts returns a submitted task and an account with pending_approval status instead of presenting an unreviewed account as active; buyers can poll that task or call list_accounts to see the current result. The account can then be linked to an existing billing relationship, routed through Interchange, sent through onboarding, or rejected. This release adds the account lifecycle and audit history, but not the seller management page, CRM import, or ad-server account-mapping feed.

​

4.132.0 — July 28, 2026 at 12:13 AM UTC

• The activities under calibration now read the same way on the Rate Card page and in Plan & Billing. Two the page listed — proposal evaluation pass and comparative proposal ranking pass — were missing from the product’s list, and multi-seller product ranking was in the product’s list but missing from the page. All three now appear in both.
• One correction worth naming: Plan & Billing described a Murph working session as priced “per five working sessions” while showing its rate as 1 IU. The rate was right and the description was stale. A Murph working session is 1 IU, and the description now says so.
• Nothing about what you are charged changes. These activities are shown for planning, are not part of an accepted Rate Card, and cannot draw down your IU balance.
• Documented the signing contract for async task webhooks that sales agents and inventory sources push back to Interchange. Signing the webhooks you send us covers where the signing key comes from (the authentication.credentials value in the push_notification_config we send on each call), the exact signed message, the sha256= prefix, the timestamp format and skew window, reference implementations in Node, Python, and Go, and a troubleshooting guide for a rejected delivery.
• This contract was previously unpublished, and the only webhook signing scheme in our docs was the buyer subscription scheme, which is different and incompatible. Both pages now cross-reference each other so the two cannot be confused.
• Action may be required if you hand-rolled your signer. Signature validation is now stricter and rejects three malformed shapes that could previously slip through: a duplicated X-ADCP-Signature or X-ADCP-Timestamp header (send each exactly once), a signature that is not exactly sha256= followed by 64 lowercase hex characters, and a timestamp containing anything other than digits. If you sign with the official @adcp/sdk webhook emitter you are unaffected. If you built your own, check it against the reference implementations on the new page before this release reaches you.
• fee_rate_percent in the media buy budget breakdown now consistently reports the fee as a percentage of the media budget (fee / media × 100), regardless of how the rate was stored. Previously, some buys showed the gross-basis rate (fee / all-in total) and others showed the net-basis rate depending on when and how the terms were set, producing different numbers for the same underlying fee on the same advertiser.
• LinkedIn seller-managed campaigns can now target states and regions: pass ISO 3166-2 codes such as AU-NSW in geo_regions, and Interchange resolves each code to its matching LinkedIn location before the campaign is created. Country-only targeting behaves exactly as it did, campaigns you already created keep their targeting, and only new creates use the new behavior. Geo targeting is state the campaign declares: if a package requests both a region and its parent country (geo_countries: ["AU"] with geo_regions: ["AU-NSW"]), New South Wales delivers — Australia as a whole does not. Any other countries requested in that package still deliver. If LinkedIn can’t resolve exactly one match for a requested region, the request fails before a campaign is created. Nothing else to change on your side. Region targeting is set when the campaign is created and can’t be changed afterward — targeting a different region means creating a new campaign.
• Meta media buys can now change or remove region targeting on update, not just at creation. The geo_countries/geo_regions you send on an update become the complete targeting for that package, replacing what was there rather than merging with it. Clear a region (or leave geo_regions off the update) and the package reverts to full-country delivery; add one and it takes effect on that same update — no need to recreate the media buy. Other countries in the same package keep delivering as before. An unresolvable or ambiguous region is rejected before anything changes, so a bad update never leaves a media buy partially retargeted.
• Sellers whose managed ad-server connection was created before the sandbox test account carried an ad-server advertiser can now run a sandbox test campaign.
• Preparing the sandbox account reported the account as not ready and stopped there, because it only ever set up an account that did not exist yet. Connections made before the sales agent started creating the sandbox advertiser therefore stayed blocked at test-campaign validation, and the storefront could not be opened for transactions. Preparing the account now completes the setup of the existing one instead of reporting it as unusable.
• Connections made since then were already set up correctly and are unchanged.
• Snap media buys placed through Interchange can now target specific states, provinces, and other ISO 3166-2 regions (for example AU-NSW or AU-VIC), not just whole countries. Set targeting_overlay.geo_regions on a Snap package the same way you already do for Meta: Interchange matches each region code against Snap’s region list and attaches the matching native region ID before creating the campaign. Region and postal-code targeting can’t be combined on one package — send one or the other. If a region code can’t be matched (missing, ambiguous, or duplicated), the request fails before Snap creates anything, so you see the error immediately instead of an under-targeted campaign. Existing country-only Snap campaigns are unaffected; nothing changes on your side unless you start setting region-level targeting. You set region targeting when you create the media buy; to target a different region, create a new one.
• Hand your Merchandising Agent a brief without leaving chat. When a brief reaches you as a document (an RFP, a spreadsheet, a forwarded agency email), drop it into the composer. Your agent reads it, shows you the brief it recognized, and waits for you to confirm — nothing is saved or run until you do. If you drop a media kit, your agent also tells you in chat which of its claims your storefront can and can’t back yet. On confirmation, your agent works the brief the same way it works a live buyer’s brief, finding matching products and composing a proposal, then lands it in your Demand inbox marked as uploaded so it never reads as live buyer demand. Review it the way you would any incoming brief. Available once the Demand inbox is on for your storefront.

​

4.131.0 — July 27, 2026 at 6:18 PM UTC

• Activating a connected social account now draws IUs from your organization’s wallet for each account-month, at the price on your accepted Rate Card — 4 IUs per account-month on the standard card. Your balance goes down, and the usage appears on Settings → Plan & Billing → Usage & credits. No money is charged for it: charging is switched on per organization, never silently, and it is still off. Connecting and mapping accounts stay free, and there is nothing to change on your side.
• While charging is off, account-months past your included allowance accrue as overage you can see but are not billed for. If usage billing is later switched on, overage still accruing in the open period becomes chargeable.
• Each metered account-month records the accepted Rate Card version that priced it. A change to the standard count cannot reprice a month already metered, and it reaches you only through a successor Rate Card you accept.
• Marketplace and buyer storefront responses now distinguish whether a seller is
• available to buy from from whether buyer credentials are connected. Buyers get
• an accurate availability label and a readiness field for integrations; sellers
• using a pass-through sales agent are presented as buyable without an
• Interchange wholesale catalog. No setup or buying-workflow change is required.
• A failing MCP tool now reports its actual error. Tools that declare an output schema returned their ADCP error envelope — code, message, suggestion — in structuredContent, but that schema described only the success shape. Because an MCP client validates structuredContent against it on every call, the client rejected the error envelope and raised Structured content does not match the tool's output schema, hiding the real reason the call failed and the guidance for recovering from it. Each tool’s output schema now declares both outcomes, so the error reaches you intact. Affects get_products, create_media_buys, update_media_buy, api_call, list_buyer_activity, and the storefront and operator tools that declare output schemas.
• Spotify media buys now resolve ISO region and state targeting to provider-native geographic identifiers and reject unsupported targeting before creating provider entities. Region targeting is set when the media buy is created and can’t be changed afterward — targeting different regions means creating a new media buy.
• search on /mcp/v3 now covers the documentation as well as your own objects, and searches all three sources by default: objects, docs, and specs.
• Asking “which of my sources are failing” and asking “what does authorization actually mean” are the same question at two altitudes, so they are the same tool. An agent doesn’t have to guess whether the answer is a record in your account or a paragraph in the docs. It asks, and gets whichever it is. Every documentation result carries a link, so an answer can be checked rather than taken on trust.
• docs is the Interchange documentation for what this platform does; specs is the AdCP protocol spec for what the protocol defines. They are reported separately, because “the protocol allows this” and “we support this” are not the same claim.
• The object half is storefront-scoped and today covers inventory sources; a buyer account gets the documentation results and an explicit note that objects were not searched. /mcp/v3 is behind a feature flag with nobody enrolled yet. Nothing on /mcp/v2 changes.

​

4.130.0 — July 27, 2026 at 5:09 PM UTC

• When a storefront returns no products and says why, buyers now see the reason. Storefronts hosted on Interchange are dispatched in-process, and that path rebuilt the response envelope from products and proposals alone — discarding the storefront’s own message. A storefront that declined to sell (“This storefront is blocked and cannot transact”) reached the buyer as status: completed, product_count: 0 with no explanation, indistinguishable from a storefront that simply had nothing to offer. The message now travels with the response and appears on the matching ext.interchange.storefront_results[] entry, as it always has for storefronts reached over the network.
• Setting up a feed-backed inventory source now reads more clearly. Readiness and setup steps stay neutral while a source is still being set up — in-progress work is no longer shown in an alarm color — and the Create, Preview, Commit, and Complete buttons show progress and can’t be triggered twice while a change is running. A partially set-up source stays in a recoverable state you can resume or remove, and dates follow your locale and time zone.
• You can now pause and reactivate a single media buy without touching the rest of its campaign. Before this, pausing a campaign paused every media buy inside it; there was no way to bring back just one.
• Call pause_media_buy or reactivate_media_buy (or POST /api/v2/buyer/media-buys/:id/pause and .../reactivate) with a media buy ID, and only that buy changes state — its campaign and sibling media buys keep running exactly as they were.
• A paused media buy still accepts budget, date, and package updates the same way an active one does, and those updates still reach the seller. Approving an update never resumes a paused buy — reactivating is the only way to bring it back to ACTIVE.

​

4.129.0 — July 27, 2026 at 3:33 PM UTC

• Fixed a bug where re-authenticating a Snap account caused the next discover_products call to fail with “Buyer has not connected snap for this storefront”. The error appeared immediately after re-auth and resolved on retry. TikTok and Meta were not affected.
• Your merchandising rules stay between you and your Merchandising Agent. Until now, a brief your storefront could not fill sent the agent’s internal notes to the buyer’s agent: your rule text quoted word for word, the ids of the components it ruled out, and which of your signal sources were not live. Buyers now get copy written for them — no products matched this brief, and how to broaden it. Nothing to change on your side.
• For buyers’ agents the contract is unchanged: a brief a storefront cannot fill still comes back as INVALID_REQUEST with reason: no_compositions, carrying either the neutral line or the seller’s own wording. Nothing to change there either.
• Whether a buyer hears the reason is now your call. Write the rule into your merchandising rules in your own words: “when we decline because the budget is below our floor, tell the buyer their CPM is short of what we can sell this inventory for and invite a higher bid, without naming the floor.” Your Merchandising Agent makes that case in your voice, in a couple of sentences and within what you authorized; a decline that quotes your rulebook, names an internal id, or runs long is replaced with the neutral line. Say nothing about declines and nothing is disclosed. Your own candid account is unchanged on the intelligence run and its decision record, and running a brief past Murph now tells you which of the two a buyer would get.
• The Retry Forward task now shows its chrome in your own language, keeps buy ids and source error messages verbatim, and reads clearly in both its retry and re-send shapes.
• Meta Sales (OUTCOME_SALES) campaigns can now be created via the Scope3 API. To create a Sales campaign, provide a pixel_id (a Meta Pixel or Dataset authorized on the ad account), a bid_price (target cost per conversion in the account currency), and optionally a conversion_event (defaults to PURCHASE; supported values: PURCHASE, ADD_TO_CART, INITIATE_CHECKOUT, COMPLETE_REGISTRATION). The campaign is created with COST_CAP bid strategy and OFFSITE_CONVERSIONS optimization. Meta Sales campaigns also surface during product discovery when the brief mentions sales, conversions, or purchase objectives. No changes to existing campaign creation calls or other Meta campaign types.
• The Property Roster now leads with the answer you came for — how many of your
• publisher domains need attention — and shows each domain’s authorization state
• in plain color: green when a domain is authorized to sell, amber when a
• published adagents.json needs a fix, and gray while a domain is still being
• checked or has no adagents.json yet (setup in progress is not a failure). Dates,
• counts, and every label now follow your workspace language and time zone, and
• long rosters keep that headline pinned while the list scrolls.
• The property roster now renders correctly in dark mode: labels, chips, and the attention banner keep readable contrast instead of falling back to light-theme colors.

​

4.127.0 — July 27, 2026 at 12:56 PM UTC

• When POST /media-buy-approvals/{mediaBuyId}/retry-forward refuses a forced retry, the error now says which refusal it is in details.reason. Two of them share 400 VALIDATION_ERROR and field: "forceTerminal" but call for opposite responses, and until now the only way to tell them apart was to read the English message:
• upstream_buy_exists — a source already has this buy. It reached the ad server; reconcile or cancel it there, and never force. details.sentLegCount says how many legs.
• no_failed_route — no leg was ever recorded, so there is no evidence the forward went unsent. Usually a storefront-level precondition (paused storefront, unconfigured settlement currency, expired FX quote); fix that and have the buyer resubmit.
• not_approved — the entry is not approved, so there is nothing to re-send. details.status carries the actual state.
• The status code, error code, field, and messages are unchanged, so nothing you have written breaks. If you branch on this error, switch from matching the message to reading details.reason.
• If your storefront’s status ever moves off green — live with an issue worth attention, or stopped because a promise to buyers broke — you now get a notification the moment it happens, with the reason and a link to fix it. You’ll hear about it getting worse too (attention escalating to stopped), and you’ll hear when it’s back to fully live. A storefront still in setup never triggers this — that’s expected, not a problem.
• Nothing to set up on your side. This is an operational alert: it always lands in your in-app notification feed and by email, and can’t be muted. Slack is the one exception — it posts there only if you’ve enabled this event type in your Slack configuration. Nothing changes for buyers.

​

4.126.0 — July 27, 2026 at 10:47 AM UTC

• Discovery now keeps products and proposals attached to the correct storefront when sellers expose the same upstream ID. Buyer teams get more reliable seller attribution across discovery, refinement, and media-buy setup, with no workflow change for chat or UI users. API and MCP integrations that already pass the top-level product_id and proposal_id returned by discovery back unchanged need no action. Integrations that reconstruct IDs from source_product_id or source_proposal_id should instead preserve the returned sf1: or sfp1: ID; when a source ID is ambiguous, the API now returns a validation error so the client can re-run discovery and use the returned qualified ID. Sellers need no action: their inventory and proposals now remain labeled with their own storefront instead of being attributed to another seller when IDs collide.
• Pending operations now offers a Re-send action on a media buy a source refused, instead of routing every terminalized buy to escalation. Re-sending keeps the buy’s ID and your approval — the buyer does not resubmit.
• The action appears only on buys that can actually be re-sent: a source has to have refused the buy after receiving no part of it. A buy that failed before any source was contacted — a paused storefront, an unconfigured settlement currency, an expired FX quote — still shows escalation, because there is nothing to re-send. Groups of failures offer the action only when every buy in the group qualifies.
• Failed-forward rows on GET /pending-operations carry a new action value, force_retry, alongside the existing retry, fix_and_resubmit, and escalate. If you branch on action, treat an unrecognized value the way you treat escalate.
• Re-sending replays the original payload with only the end date refreshed, so check the flight window first: a buy re-sent days later carries its original start date and full budget over a shorter window.
• Open any Demand inbox row to see the whole exchange: the proposal pass. It shows the brief facts exactly as your buyer sent them, the products your agent proposed with each one’s plan allocation and price, a timeline of proposal versions, and the commercial result. Allocation money appears only when the buyer committed a definite budget, never computed against an open range, and prices come from the pricing option the plan actually selected. A won exchange shows its recorded value or says “not recorded” — never a guess — and a lost exchange shows the buyer’s stated budget as the demand you didn’t close. When a proposal was too old or too large to have been captured in full, the pass says so instead of guessing. Expand any product to inspect the exact recorded snapshot. Nothing to set up; it opens from the Demand inbox once that’s on for your storefront.
• POST /media-buy-approvals/{mediaBuyId}/retry-forward now takes an optional reason (up to 500 characters) recording why you re-sent a buy. It is worth supplying whenever you set forceTerminal, which overrides a terminal state in front of your ad server — the reason is recorded against the attempt, so whoever reviews it later can tell a considered recovery from a reflexive one.
• Nothing is required and no existing call changes. A retry without a reason behaves exactly as before.
• Agents connected to /mcp/v3 get a new tool, save_ask, for the two things an account cannot resolve on its own: something is broken, or something does not exist.
• A support ask reaches the Scope3 team the same way a problem reported in Murph chat does, and returns a reference id to quote when you follow up. A product ask records a capability we do not have; if someone already asked for it, yours joins that entry instead of creating a duplicate. Only the title is recorded on a product ask, so make the title carry the request. Tracking an ask is not a commitment to build it.
• save_ask works from any account, buyer or seller, and needs only read permission. Whoever runs into a wall is usually not whoever has permission to fix it.
• Also on /mcp/v3: structured responses over 200KB are now truncated. That is a backstop against pathological payloads, not a size to design against.
• /mcp/v3 is behind a feature flag with nobody enrolled, so there is nothing to call yet. Nothing on /mcp/v2 changes.

​

4.125.0 — July 27, 2026 at 7:51 AM UTC

• Buyers can now create TikTok carousel ads with 2–35 distinct square images in a chosen order. Interchange verifies that every image is available in the selected advertiser’s TikTok account, and the ad stays paused until TikTok returns every image in that same order.
• Your storefront has a new Demand inbox: one front-of-house ledger of every buyer brief your agent answered, the proposal it produced, the buyer’s feedback, and whether you won — with the money attached. Each row carries the buyer’s stated budget range from the brief, won rows show the booked or delivered value in its own currency, and a Booked YTD tile totals this year’s wins per currency. The metrics strip also shows briefs this year, how many you answered, your win rate (first responses only — the widget explains the count), your average grade, and how many briefs the agent led versus a human; filter the ledger by buyer from the header. Every number is drawn only from what actually happened — a metric with nothing recorded yet reads as unavailable rather than a misleading zero, and a brief captured before we started keeping canonical records shows “artifact unavailable” instead of a reconstruction. Nothing to set up; open it from the Demand row in your rail once it’s turned on for your storefront.
• Buyer MCP clients can fetch the tool list again. get_products declared an output schema that was not a JSON Schema object at the root, and because an MCP client validates the whole tools/list page at once, that one tool made every tool on /mcp/v2/buyer disappear — claude.ai reported “tools fetch failed”, Claude Code indexed no tools, and the TypeScript SDK threw before returning. The schema now describes both a complete and a field-projected response as one object, so the page parses. /mcp/v2/storefront, /mcp/v2/murph, and /mcp/v3 were never affected.
• get_products also now returns name on every product even when your fields selection leaves it out, matching AdCP: product_id and name are always included regardless of selection. Previously a narrow fields list could return products you had no way to label.
• Snap discover_products and get_products calls that fail due to a missing or
• mismatched ad account selection now return a descriptive INVALID_REQUEST error
• instead of the generic “Upstream request failed”. This applies to all synthesized
• correctable errors from the Snap adapter (account required, invalid account,
• account mismatch, incompatible product selection, etc.).
• Buttons that open a second workspace from a seller widget work again. “Open sync & diagnostics”, “View details”, “Open full diagnostics”, and “Add another ad server” on the Ad server source page — plus the equivalent launches from Pending operations, Sync diagnostics, Release notes, and Test runs — were failing with “Couldn’t open that workspace. Try again.” These launches were being resolved against the buyer tool set, which does not contain the seller tools they open; they now resolve against the seller tool set.
• Delivery reads for TikTok campaigns that cover multiple days now succeed instead of failing with a “delivery is not authoritative” error. The daily report returns one row per day for a campaign, and the completeness check was mistakenly comparing that day-row count against the provider’s per-campaign count. Spend now uses base-10, currency-aware minor-unit rounding; the package breakdown lists every ad group in the campaign (including those with zero delivery); and package totals are cross-checked against the campaign report within a bounded tolerance for provider reporting lag. When pagination cannot be corroborated, report spend diverges beyond that tolerance, or a spend value cannot be represented safely in the account currency, the request still fails closed rather than returning partial numbers. Nothing to change on your side.
• TikTok delivery reads now accept the integrated report’s documented live response shape when page_size reports the number of returned daily rows instead of echoing the requested capacity. Arbitrary page-size mismatches, incomplete pages, duplicate rows, and unstable terminal pages still fail closed.
• Budget and end-date changes that a publisher accepts for later processing now apply to the live buy on their own.
• When you submit a change, the publisher may apply it immediately or accept it as a task to complete later. The second case only ever resolved if the publisher called us back, and for publishers that do not, the change could sit until it timed out a week later without applying. It is now also resolved by asking the publisher directly, so a change lands as soon as they confirm it.
• Two related corrections:
• A change that has been submitted is no longer announced as though it were already live. You are told it was submitted and is awaiting confirmation.
• Submitting a budget or date change while an earlier one is still with the publisher is now rejected, with an explanation of what is already in flight. Previously the second submission merged into the first, leaving a combination neither one asked for. Other updates to the same buy, such as creative changes, are unaffected.
• How you submit a change has not altered.
• You can now see at a glance whether each storefront is live and healthy. Every storefront gets one status, computed once and shown the same way everywhere it appears.
• The readiness response (GET /api/v2/storefront/readiness and the get_storefront_readiness tool) carries a new liveness verdict with four values: setup (gray — not live yet, as expected while you set up), live (green — buyers can discover and buy), live_attention (yellow — live, with something worth acting on), and live_critical (red — live, but something is broken that affects buyers). Every verdict comes with a one-line reason; during setup it also counts the go-live steps remaining.
• The same status shows on the seller setup screen and as a per-storefront dot in the account switcher. Clicking a storefront with a yellow or red dot takes you straight to the screen where you can fix it.
• Two guardrails keep the status honest: a disconnected source that isn’t behind any buyer-visible product won’t turn your status red, and storefronts that pass buys through to an external platform or your own sales agent aren’t held to merchandising steps that don’t apply to them.
• Nothing to set up on your side. Nothing changes for buyers — no new fields, and discovery, media buys, and settlement behave exactly as before.
• A media buy that an inventory source refused does not need to be rebuilt under a new ID. The seller can re-send the original — same media buy ID, their approval intact — once the cause is fixed.
• Sellers do this with POST /media-buy-approvals/{mediaBuyId}/retry-forward and {"forceTerminal": true}, or retry_forward_media_buy_approval over MCP. It is an API control today: the retry action in Pending operations still covers transient failures only and routes a refused buy to escalation. Buyers cannot re-send a buy themselves; ask the seller.
• This corrects the v4.118.0 note, which told buyers that terminalized buys could not be retried in place and to resubmit under a fresh media buy ID. That was wrong. The control has always existed; it was missing from the API reference, and the reference described terminal failures as unrecoverable.
• Three limits. A buy that failed before any source was contacted — a paused storefront, an unconfigured settlement currency, an expired FX quote — records no forwarding leg and cannot be recovered this way; it needs a fresh submission. The original payload is replayed with only the end date refreshed, so a buy re-sent days later carries its original start date and its full budget over a shorter window. And it applies only to a create approval the seller already approved: a rejected buy has nothing to re-send, and an update approval ignores the flag. Before forcing a retry, check the flight window and check the ad server for an order a partial write may have left behind.
• forceTerminal is now published in the API reference, and a new Retry forwarding page covers how to tell a delivered buy from a refused one, what to check before forcing one, and how to read the result. Platform behavior is unchanged — existing calls do exactly what they did before.

​

4.124.1 — July 26, 2026 at 5:49 PM UTC

• Adapter connections now report classified account-discovery failures and hide expired, abandoned OAuth attempts instead of rendering duplicate storefront rows.
• Adapter OAuth expiry checks now support the PostgreSQL version used by deployed environments while preserving safe handling of malformed legacy timestamps.

​

4.124.0 — July 26, 2026 at 3:24 PM UTC

• Storefront Activity now shows dates and times in your own locale and timezone, and its “couldn’t load” messages are easier to read.
• You can now update a media buy directly by its ID: PATCH /api/v2/buyer/media-buys/{mediaBuyId} on the buyer REST API, and the matching update_media_buy tool on the buyer MCP server. Send only the fields you want to change — name, flight dates, package budgets and pacing, product budgets, optimization goals, or creative assignments — without routing the edit through the campaign update, which still works unchanged. An update that would break a campaign invariant fails with a specific error instead of being silently adjusted — for example a pricing option that settles in a different currency than the buy, a budget increase past the campaign’s remaining budget, an edit to a buy on a tracked (seller-mirrored) campaign, or a buy or campaign that has already ended. Flight dates outside the campaign window are the one exception — they apply, the campaign flight widens to cover them, and the response includes a warning saying so.
• Separately, creating media buys (create_media_buys on REST and MCP) now rejects manual product selections against a performance campaign — the platform selects and allocates the product mix on those toward your objective. If your integration hand-picks products for a performance campaign, those requests now fail with a validation error; drop the manual selection and let the campaign allocate, or make the selection on a discovery campaign instead.
• Sellers: nothing changes on the seller side — updates reach sellers through the same execution and approval path as campaign-routed edits, and a rejected buyer request never contacts the seller. Monetization: none — no billable surface or metering change; the verb is covered by existing buyer API terms. Exposure: ungated (gate: none) — an atomic, additive verb on the existing authenticated buyer surface; rollback is a code revert with no data migration. Adoption: update_media_buy call volume and per-failure-mode error mix via workload-attributed buyer activity; the success signal is direct mutations on multi-buy campaigns, which previously had no verb (baseline zero). Full launch record: the commercialization brief on AI-4576.
• Nothing to change on your side, and nothing starts charging in this release.
• A seller organization accepting an IU plan for the first time now receives a one-time 100-IU credit on better terms. You no longer have to be a new customer to qualify, and the credit spends on any IU-priced activity rather than storefront setup work only. One credit per billing organization, valid 60 days from the day you accept — counted in days, not billing cycles — with the exact expiry date shown on Settings → Plan & Billing → Usage & credits. One plan covers an organization’s selling and buying work, so setup and buying draw on the same 100 IUs.
• How IU billing works is a new page that follows one charge end to end: what an IU is, what consumes one and what is always free, the seven steps from a published price to an invoice, worked examples for a light month and a heavy one, and a calculator for which plan is cheapest at your volume. Two numbers worth taking away: above 200 IUs a month the 250 plan costs less than pay-as-you-go, and above 650 the 1,000 plan costs less than the 250. If you reconcile invoices, Checking our numbers lists the exact reads each charge was built from. If you would rather not read a rate card at all, ask Murph what something costs or why a charge appeared — it answers from the same page.
• The Organization IU Rate Card page now shows the standard plan sizes and prices as the agreed standard model rather than provisional figures. They are not published in production, so nothing on that page is an offer you can accept today, and the per-activity IU counts we are still calibrating stay marked as such.
• Separately, on Plan & Billing: accepting terms and saving billing details now update the page immediately instead of needing a reload, and an account with setup still outstanding now shows that outstanding step instead of reporting good standing.
• Managed evaluation in get_products is more reliable: the evaluation model is now shown the exact output shape (including enrichment and refine variants) and explicit field limits, so evaluations no longer fail open when the model formats its verdicts with invented field names or oversized reason lists. Fewer executions report status: degraded with evaluated: false pass-throughs.
• Directed-campaign mirrors of a connected TikTok account now keep syncing when the provider’s advertiser details omit an unrelated presentation or financial field (such as balance, language, role, or account creation time). Media-buy reads only need the account’s identity, ownership, and currency, so those reads no longer fail — and disable every mirror — over a field they never use. Account identity, ownership/scope, and currency are still checked strictly and still fail closed. If a periodic sync does fail, the subscription now keeps the machine-readable diagnosis (errorCode, errorField, errorReason, upstreamCode) so a later read can tell a provider-shape error apart from a credential or configuration problem; a successful sync clears it. Nothing to change on your side.
• Murph now checks the source-specific publisher authorization guidance before advising modular sellers, and keeps documented API field names intact in its replies. Nothing to change on your side.
• Product discovery now honors the requested product fields. Murph carries ordinary product results up to 32K characters and explicitly pages or narrows anything larger instead of treating the visible products as the complete catalog. Existing requests need no changes.
• The published plan sizes and prices are the standard USD list, and the billing docs now say so where the numbers are. Two clarifications: your Effective Rate Card is the authority — an authorized discount, a negotiated package, or an enterprise offer replaces the list figures, and Plan & Billing shows list and effective price side by side before you confirm. And prices are set per currency rather than converted: a plan in EUR, GBP, or AUD is its own published number, not the USD figure at an exchange rate, and the currency on the revision you accept is the one your invoice, charge, and wallet use. The plan calculator now states that it computes the standard USD list rather than a quote.
• The pages also now say what happens when standard prices change: a change arrives as a new published revision, never as an edit to a revision anyone accepted. Your binding pins the version, term, and prices you agreed to, so a change to the published table does not change what you pay — you would see a successor offer and decide whether to accept it.
• Sellers: the same three clarifications now appear on the storefront billing page, which carried the identical table. One plan covers an organization’s selling and buying work, so the list, the currency rule, and the revision behaviour are the same on both sides — and the storefront page no longer describes the plan values as “not final” when they were agreed on 2026-07-22.
• When you open a media buy’s timeline to trace where it’s stuck, stage times and
• budgets now read in your own language and time zone, and the surface is
• localized in Portuguese and Japanese. A forward that failed once but then
• recovered on retry no longer shows as a red alarm — only a buy that is actually
• stuck is flagged. Nothing to change on your side.
• Pinterest media buys now validate region and state targeting against Pinterest before creating a campaign, and send canonical provider geo identifiers instead of treating subdivisions as metro locations. Region targeting is set when the media buy is created and can’t be changed afterward — targeting different regions means creating a new media buy.
• Murph now keeps its full tool catalog on escalated questions. When a question
• was escalated for extra precision, Murph was reducing its own tool surface to
• fit a model that could not hold it, then answering on a different model that
• could — but without the tools it had just put down. Escalated questions could
• therefore be discussed but not acted on. Murph now picks up the full set again
• once it has the room, so an escalated question gets the same actions available
• as any other.
• When your seller analytics dashboard has no negotiations yet in the selected
• window, it now opens to a clear “no runs yet” line instead of a screen of
• empty zero charts — and the run-window date range no longer shows a blank
• ”- to -”. Once buyers start negotiating with your agent, the full dashboard
• (win rate, booked budget, delivery, posture conversion, and recommendations)
• is unchanged.
• The seller setup widget now shows one clear storefront status: gray while you set up, green when your storefront is live, yellow when something needs attention, and red only when a live storefront can’t sell. Setup steps stay neutral — remaining work shows as progress counts and a single next action, never an alarm — so red means stop, not “still setting up.”
• Buyer surfaces are unchanged: this reworks how sellers see their own storefront status, not what buyers see in discovery or transactions.
• Agents connecting to the storefront MCP server now receive full operating guidance at connect time, instead of a single reminder about notifications. The server tells your agent to orient with get_storefront_readiness, confirm operation names through ask_about_capability before calling api_call, route “how do I” and “why is this stuck” questions to Murph, make one verified mutation per turn, and look up publisher authorization rules rather than answering them from memory.
• This closes a gap for anyone driving their storefront from their own agent — ChatGPT, a custom client, or any MCP host — where that guidance previously reached only our own assistant. The storefront skill also now states Murph’s real capabilities: it searches the published docs and inspects your live storefront state.
• The full contract is documented in Built for agents.
• TikTok media buys can now set a package’s geo_regions field for region-level targeting alongside geo_countries — any ISO 3166-2 subdivision TikTok itself supports is resolved live against TikTok’s own location inventory, and a subdivision TikTok can’t confirm is rejected before the campaign is created, rather than silently dropped to country-level. Region targeting is set when the media buy is created and can’t be changed afterward — targeting a different region means creating a new media buy.

​

4.123.0 — July 26, 2026 at 12:24 AM UTC

• You can now list a media buy’s packages in one call and tell them apart. GET /api/v2/buyer/media-buys/{mediaBuyId}/packages (MCP operation get_media_buy_packages) returns each package with its product, its own flight window, and the pacing period it covers. Going from “the display package ending 2026-08-11” to the right package id no longer means reading the whole campaign or asking your seller for an export. The response leaves out targeting, creative, and format detail on purpose, keeping it small enough for an agent to read in full.
• Package ids are opaque. The trailing number on a storefront-minted id like sf_pkg_..._3 is the order the package was dispatched in, not the period it covers, so read the new pacingPeriod field instead of parsing the id.
• Interchange now also keeps the flight window it asked for when a seller’s response leaves it out, so newly created paced packages carry their own start and end dates. No package created before this change has a pacing period recorded, and roughly 9 in 10 have no flight window either. Neither gap can be filled in later. Product name plus budget will sometimes narrow those packages to one, but not when the pacing schedule gave those periods the same budget, in which case the package can’t be addressed individually through the API and your seller is the way to reach it.
• If you manage your buys in chat, nothing changes for you.
• Campaign lists now default to your live working set: every campaign that could still spend — active, draft, and paused — across both platform-managed campaigns and tracked mirrors from connected seller accounts. Connect a seller account and your live spend there appears in GET /api/v2/buyer/campaigns and list_campaigns immediately — while the account’s finished history (completed and canceled campaigns) stays out of the ambient list. Pass explicit statuses or the new status=ALL to reach it, and use management=managed|tracked to narrow by who operates the campaign. This revises the earlier managed-only default before its flag retires: flood control now lives on the status axis, so nothing you could still run is ever hidden.
• Nothing changes for sellers, and no new seller data is exposed: the campaigns involved are the buyer’s own campaigns in their own connected account, mirrored under the subscription the buyer already authorized — this change only adjusts which of those already-visible mirrors appear without a filter.
• Connected ad-platform accounts now show their campaign footprint at a glance. Each account card on the Connections page carries a rollup: how many campaigns are tracked and how many are active, tracked and managed spend over the trailing year, always in the account’s own currency (never converted or totaled across currencies), and a managed-share bar showing how much of that activity runs through the platform. For brand teams, that answers “how much of our TikTok activity runs as managed campaigns?” without opening a report; for agency teams, it makes connected accounts comparable across clients. A “View tracked campaigns” link drills into the tracked campaign list for accounts mapped to a single advertiser. In the campaigns widget, a new Managed / Tracked / All switch narrows the list by who operates each campaign. The default list still shows what you’re working on: active and draft campaigns, both managed and tracked; completed or paused history stays out unless you ask for it.
• New TikTok campaigns created through Interchange no longer expand into delivery destinations Interchange cannot verify, and automatic delivery in TikTok search is off. Existing campaigns with other delivery settings remain visible but read-only; make any changes to them in TikTok Ads Manager. The public tiktok_for_you_feed placement ID remains unchanged; Interchange maps it to TikTok’s provider enum internally.
• Your storefront now keeps the canonical record of its exchanges: the exact AdCP get_products request it received (content-addressed, secrets redacted) and, for every brief it answered with a proposal, the exact response it returned with immutable product snapshots. (Wholesale catalog pulls record the request only — a catalog listing is not a proposal.) Retrieve them with GET /brief-artifacts and GET /proposal-artifacts (REST or api_call); each demand-inbox row links the brief artifact that produced it. Records from before capture began report the artifact as unavailable — nothing is ever reconstructed after the fact.
• Pausing a Snap campaign in Interchange now remains in effect when you add or
• replace creative later. The campaign and its ad groups stay paused until you
• explicitly resume it, so routine creative work cannot restart spend. Resuming
• checks that every active package has a creative and that Snap accepted the
• change; if Snap’s state cannot be confirmed, the campaign stays paused.
• For an existing Snap campaign, your first budget, schedule, or creative change
• may ask you to pause or resume it once so Interchange can record your choice.
• Enterprise teams can apply this safeguard across automated or high-volume
• campaign operations. Lean teams get the same protection with no setup or
• reconnect. Seller workflows, pricing, billing, entitlements, and planned media
• spend do not change.
• Reddit media buys now normalize country and region targeting to provider-native ISO identifiers and reject invalid regions before creating provider resources.

​

4.121.0 — July 25, 2026 at 9:41 AM UTC

• Your TikTok product catalog is now read and updated only through the TikTok business account that owns the connected advertiser. Currency, region, and item-status totals come directly from TikTok. Seller storefronts and published inventory are unchanged, and no action is needed unless a sync now stops because the advertiser and catalog are not owned by the same TikTok business account; correct that connection and retry.
• Media buy reads now tell you when a change you submitted has not taken effect yet. Every field on a media buy describes what is currently delivering, and a submitted-but-not-yet-applied change appears separately as pendingChange, whose differences map spells out the live and proposed value for each field it would change.
• Previously a buy with a queued change could report PENDING_APPROVAL in mediaBuyRefs while get_media_buy and the delivery poll reported the live values, with nothing anywhere saying a change was waiting. A buyer polling status could reasonably conclude an update had gone live when the buy was still delivering the old budget and end date.
• Corrected behaviour, worth checking your integration: mediaBuyRefs[].status now always reports the live status of each buy. A buy that is delivering with a change awaiting approval reads ACTIVE and carries pendingChange; it previously reported PENDING_APPROVAL, which described a version that was not delivering. That value was never documented as a pending-change signal, so this is a correction rather than a contract change, but if you inferred queued changes from it, read pendingChange instead.
• A buy awaiting its first approval is unaffected: status still reads PENDING_APPROVAL with no pendingChange, because nothing is live behind it yet.
• Sellers see no change. This affects the buyer read surfaces only; storefront approval queues, seller media-buy lists, and the approval flow are untouched.
• Treat a change as applied only once pendingChange is absent. See Media buy lifecycle → Pending changes.

​

4.120.1 — July 25, 2026 at 1:40 AM UTC

• get_campaign_products now returns the package IDs for every media buy that has packages. Some buys came back with an empty packageIds array even though the packages existed, which forced buyers to source package IDs from their seller instead of from the API.
• No action is required for existing Snap connections. Creative assignments now
• recover one exact Snap Ad after retries or lost responses, and creative
• inventory preserves the buyer’s source creative and original assets. Missing,
• duplicate, substituted, or cross-account provider objects fail closed. The
• ordinary assignment path retains its existing activation behavior; the
• future-dated readiness fixture is the path forced to stay paused. There is no
• pricing, billing, entitlement, or media-spend change; the capability remains
• included with existing Snap adapter connections.
• The protected readiness check can now verify a future-dated paused Snap
• campaign from creative upload through complete inventory, package assignment,
• provider review state, exact Ad materialization, zero delivery, and terminal
• cleanup. It remains disabled unless an operator enables an identity-free image
• or video fixture in the protected staging overlay.
• Per-package delivery figures (spend, impressions, clicks, completions) are now correct. Each delivery report’s per-package daily breakdown is accumulated into a per-day ledger, so a package’s lifetime delivered totals are the sum across days rather than the most recent window. This fixes an undercount in the per-package delivery shown on media-buy lists and detail, and it strengthens the budget floor that stops a package budget being reduced below what it has already delivered.
• TikTok catalog sync now safely resumes after a timeout or interrupted create without creating a duplicate catalog or feed. If TikTok cannot identify exactly one matching result, the sync stops and asks you to retry after provider inventory converges instead of repeating the write.

​

4.120.0 — July 25, 2026 at 1:00 AM UTC

• Your TikTok catalog sync now stops before changing anything when TikTok returns an incomplete feed or inventory from another account, preventing the wrong catalog from being used. If a catalog that previously synced now fails, verify that the connected TikTok advertiser owns the catalog and that its feed inventory is complete, then retry. This buyer-side change does not alter seller storefront setup, ranking, inventory labels, or any other buyer-visible seller attribute.
• Meta creative-format discovery now honors exact supported filters and bounded pagination instead of silently returning the full catalog.
• TikTok account discovery now honors status and sandbox filters after fully enumerating the provider inventory. Opaque continuation cursors preserve stable, once-only account coverage and reject tampering or tenant, filter, expiry, offset, and inventory drift.
• Snap account operations now keep cached Public Profile and targeting lookups isolated by connection, tenant, selected account, and provider parent. OAuth token rotation forces a fresh provider read; no changes are required on your side.
• Storefront readiness now requires every seller to declare what publisher domains it sells without treating adagents.json authorization as a transaction blocker or guessing that the operator domain is inventory. It warns separately about products that lack a declared-domain mapping while legacy catalogs are backfilled. One successful sandbox or live media-buy transaction permanently satisfies transaction validation, and seller-owned no-spend tests can exercise a pre-live storefront without exposing it to ordinary buyers. Narrow operational exceptions use an append-only audited service-override ledger and remain distinct from transaction evidence. Multi-storefront product discovery also preserves a seller’s explanation when readiness produces an empty result, so buyers can distinguish an unavailable storefront from one with no matching inventory.
• No action is required for existing Snap connections. Conversion writes now
• report events as processed only after Snap returns its exact valid CAPI
• receipt; matching, attribution, and reporting finalization remain asynchronous
• and are not claimed by that receipt. There is no pricing, billing, or media
• spend change. This capability remains included with existing Snap adapter
• connections; it is not a separate entitlement or paid add-on.
• The protected readiness check also verifies complete Pixel inventory, rejects
• a Pixel outside the selected account, and exercises a synthetic Customer List
• audience through create, replay, update, delete, and final absence without
• customer data or spend. It remains disabled unless an operator enables the
• protected GSM overlay for a dedicated staging connection.

​

4.119.0 — July 25, 2026 at 12:05 AM UTC

• Campaign lists now default to your managed working set. GET /api/v2/buyer/campaigns and the list_campaigns operation return management: "managed" campaigns unless you ask for more: pass management=tracked to list read-only campaigns mirrored from a connected seller account, or the new management=all to include both states. A subscribed account can mirror thousands of historical campaigns — their scale now lives in the connected-account rollup (campaignsTracked, spend rollups, managedShare), not in your ambient campaign list. If you relied on the previous default returning mirrored campaigns, add management=all to those calls.
• Connected seller accounts now carry a campaign rollup, so each connection shows everything the platform tracks without flooding your campaign list.
• Each account on GET /api/v2/buyer/storefront-connections/{connectionId}/accounts returns an optional campaignRollup: campaignsTracked (campaigns the platform did not set up, mirrored read-only from your connected seller account), campaignsActive, trackedSpend and managedSpend over the trailing 365 days, and managedShare — managedSpend / (trackedSpend + managedSpend), the share of reported spend running through platform-managed campaigns, null until spend is recorded. Spend is seller-reported net in the account currency (for campaigns managed through the platform, your full media budget goes to the seller with no platform fee, so net equals your budget), and rollups are never summed across currencies. Connection rows on GET /api/v2/buyer/storefront-connections add campaignsTracked and campaignsActive counts. Nothing changes in billing — the rollup reads what your subscribed accounts already mirror.
• The Media Buys page now leads each row with the buyer instead of the internal buy id, formats flight dates in your locale and timezone, and offers an in-place retry when the list fails to load.
• Metadata separators on Media Buys rows now render with proper spacing; the previous join used a Tailwind utility this package never emits, leaving the dots glued to the text.

​

4.118.0 — July 24, 2026 at 9:12 PM UTC

• If a canonical-image buy was previously rejected and terminalized, resubmit it with a fresh media buy ID after this release; terminalized buys cannot be retried in place. Newly executed and resubmitted buys with one unambiguous fixed image size now send the resolved width and height in their package selectors, so GAM-backed sellers can traffic them. No action is required for other buyers or sellers.
• Fixed-price products authored through managed sales agents now stay buyable after composition, and accepted product changes reach buyer and readiness catalogs without a manual refresh. Managed proposal evaluation now exits a hung provider attempt with enough time to try a fallback before the request deadline. No changes are required on your side.
• Managed evaluation results in get_products now say explicitly when a candidate was NOT actually evaluated. When evaluation degrades (deadline elapsed, pass budget exhausted, or the evaluation model was unavailable), candidates fail open as accepts — previously those pass-throughs were indistinguishable from judged accepts unless you read the reasons text, so an agent could buy on an accept that never saw its instructions. Each candidate’s ext.interchange.evaluation (and the deprecated screening block) now carries evaluated: boolean: false means your evaluation instructions were not applied to that candidate, so re-check it before spending against it. The response guidance also calls out degraded executions so agents that only read dispositions do not mistake pass-throughs for judgments. Nothing changes for sellers: this labels the buyer-side evaluation verdict, not the seller’s candidate, and sellers do not see buyer evaluation results.
• Products returned from embedded sales agent storefronts now retain their canonical creative format declarations in get_products.
• Every campaign in buyer reporting now carries its management state: managed (authored or adopted through the platform) or tracked (mirrored read-only from a connected seller account). The label appears on every campaign block in the summary view, on every timeseries row, and as a new Management column in the CSV export, after Campaign Name. Today every label reads managed — tracked mirror delivery is not reported on this surface yet.
• If you generate strict validators from the reporting response schema, regenerate them: management is a new required property on campaign blocks and timeseries rows. If you parse the CSV export by column position, account for the new Management column. Metric values and formulas are unchanged.
• This surface reports managed delivery only — tracked mirror delivery is excluded — so managed totals never silently include tracked spend, and when mirrored spend is admitted it will arrive labeled. The field ships ungated to all buyers (it is additive and constant until then); tracked labels appear only for accounts enrolled in the connected-seller-accounts alpha, once mirror delivery is integrated. No seller-facing behavior changes. There is no billing change. Adoption signal: presence of the management field in consumed reporting responses and CSV exports.
• The seller analytics dashboard now answers the headline question above the fold and keeps detail on a single in-widget scroll, so it fits the chat window on first load.
• Chat widgets now follow the chat-surface expanded/collapsed model. An expanded widget takes its content height capped at the chat window, so a dense surface like the seller analytics dashboard no longer scrolls far past the screen on open. Opening a widget holds your view on it: new chat lands below in conversation order and the jump-to-latest pill appears instead of the view being pulled away. Open Pages and Glances gain an explicit Collapse control that tucks them to their named stub in place; sending a message or jumping to latest resumes normal conversation follow.

​

4.117.0 — July 24, 2026 at 6:48 PM UTC

• Campaigns now carry a management state alongside mode. tracked means a campaign you did not set up through the platform: it is mirrored read-only from a connected seller account and updates automatically as the seller changes things. managed means a campaign authored or adopted through the platform. Campaign list and get responses include the new field, and GET /api/v2/buyer/campaigns accepts a management=tracked|managed filter — for example, management=managed excludes mirrored read-only shells from your working set.
• If you generate strict validators from the campaign response schema, regenerate them: management is a new required response property. Nothing else about existing calls changes — the mode: "directed" wire value remains for compatibility, and the word “directed” is retired from campaign vocabulary. Read management to know whether the platform acts on a campaign.
• No seller-facing behavior changes: the management state describes the buyer’s own relationship to a campaign, and nothing new about a seller is exposed. Outside the connected-seller-accounts alpha, every campaign reports management: "managed"; tracked campaigns appear once a connected seller account is enrolled. There is no billing change — the field and filter add no billed usage, and connected-account subscription pricing is unchanged. Adoption signal: use of the management filter on campaign list calls.
• Action required for sellers: confirm every storefront settlement currency is supported, fix any readiness blockers, and clear Pause when you want to accept buys. Storefronts now stop accepting new buys whenever required setup is missing or failing, and readiness names the exact issue. Buyers should rerun product discovery if a seller no longer supports the advertiser’s currency. Storefronts where the connected platform clears payment directly are unchanged.
• Meta account discovery now honors client pagination after fully enumerating the provider account inventory. Opaque continuation cursors preserve stable, once-only account coverage and reject tampering or tenant, filter, and snapshot drift.
• Retrying a failed campaign execution now submits the same DRAFT media buy, preserving its creative selection, flight dates, pacing, and optimization goals. The get_products purchase shortcut also prepares new selections exactly once: stage when you want to review or customize the DRAFT first, or execute when it can be submitted immediately. No changes are needed on your side.
• The seller rail can now be organized around the selling journey — Connect (your sources), Teach (your agent), Pitch (for business), and Execute (what you’ve won) — so the rail reads as the ingredients of your next proposal instead of a settings menu. Same rows, same permissions; only the grouping changes.
• Meta, Snap, and TikTok storefronts now return account financials consistently through the SDK using the authenticated selected account, while preserving provider-reported currency, balances, spend, and reporting periods.

​

4.116.0 — July 24, 2026 at 4:59 PM UTC

• Snap measurement now validates the complete account Pixel inventory before campaign or conversion writes. Accounts with multiple Pixels require an explicit selection, setup code comes only from Snap, test-event codes reach Snap, and accepted conversion batches no longer overstate asynchronous processing.
• AudioStack and ElevenLabs audio generation now uses the provider account mapped to each advertiser under Settings → Connections. Existing advertiser-specific assignments carry over; no action is needed if those mappings are correct. If you relied on an organization-wide default, map each advertiser before its next generation. Generation pauses when a mapping is missing or a key changes instead of charging another account. Voice defaults do not change, and you can still choose a different voice for one generation.
• For Meta seller-managed campaigns, you can now target states and regions by passing ISO 3166-2 codes in geo_regions. Existing country targeting is unchanged. If Meta cannot resolve exactly one region in the requested country, the request fails before a campaign is created.

​

4.115.0 — July 24, 2026 at 3:27 PM UTC

• get_products now accepts numeric-string advertiser IDs and normalizes them before processing the request.
• Ad-server-backed inventory sources now surface missing Google Ad Manager team access instead of reporting a successful advertiser sync with no results. FreeWheel delivery reporting, Google Ad Manager inventory filtering, product refinements, and creative matching also behave correctly. If an advertiser sync reports a permissions error, assign the connected Google Ad Manager user to an active team with advertiser access; otherwise there is nothing to change.
• Multi-storefront get_products is now the taught front door for buyer agents. Murph recommends the canonical surface first for new product exploration — with progressive polling, optional proposal evaluation, and direct continuation into create_media_buys — and reserves Discover Products for existing discoveryId workflows and the grouped session view. The buyer documentation hierarchy leads with the same guidance.
• The typed get_products and create_media_buys MCP tool definitions now share repeated AdCP shapes through standard JSON Schema $defs references, reducing their combined tools/list payload from roughly 370KB to 169KB so buyer agents spend less context on tool discovery.

​

4.114.0 — July 24, 2026 at 9:02 AM UTC

• Failed social-adapter account syncs now expose stable diagnostic fields to readiness tooling while keeping untrusted provider details out of signed evidence. Nothing changes for successful syncs.
• Snap conversion reporting now verifies that the selected ad account owns the Pixel and counts events only after Snap confirms the batch.
• Approvals now escalate by default. When no approval routing rule is saved, approvals route to your organization admins — admins receive approval reminder and escalation emails (plus in-app notifications) without any setup, and saving a routing rule still overrides the default. If your organization has no active admin at all, approval emails fall back to every active user so blocking work is never silent — and the missing admin is flagged. All four approval kinds are covered (media buys, creative reviews, ad-server approvals, and inventory shortfall reviews — the latter two always route to admins). The Approvals widget’s Overdue view is now age-based, so an item with no owner still surfaces once it has waited too long, oldest first. Blocking source problems you own re-nudge you at 24 hours and 7 days if still unresolved, then go quiet.
• Snap account discovery now rejects malformed, duplicate, or cross-organization account data instead of presenting it as an active selectable account.
• Snap account readiness now verifies that the selected account belongs to its exact active, readable OAuth credential. Existing Snap connections require one reconnect after this deployment because pre-deployment account snapshots do not carry the new credential proof and are intentionally not trusted or backfilled. Until that reconnect succeeds, adapter calls fail closed; reachable account and advertiser mappings are then preserved.
• Fixed Meta discover_products failing for performance-mode campaigns when the brief does not specify a creative format (image or video). The request now correctly includes the product’s supported format IDs rather than an empty list.
• Before your next Snap creative sync, refresh product and format discovery and add a headline of up to 34 characters to every full-screen image or video creative. New setup now offers Snap Awareness, Traffic, and Web Conversions with snap_ad_image_9x16 and snap_ad_video_9x16; Catalog Traffic, App Installs, Story Ads, Collection, Lead Generation, Sponsored Snaps, Commercials, generated, and promoted-offering options are no longer returned or accepted for new syncs.
• Existing Snap campaigns and creatives are not edited, paused, or deleted by this release and can keep delivering in Snap. If an account contains another creative format, Interchange leaves that object in Snap and stops creative inventory with UNSUPPORTED_CREATIVE_FORMAT instead of showing an incomplete list. Brands and agencies should update shared creative templates and trafficking playbooks; API and MCP integrations should refresh discovery and supply brand_name, headline, and the advertised image or video asset. Buyers working in chat will see only the two supported full-screen choices, and a missing headline stops before any media upload.
• Pricing, plans, and entitlements are unchanged; this adds no billable surface and does not change seller products, inventory, ranking, or storefront presentation.
• Snap connected-account delivery reports now keep spend in the selected ad account’s currency and include every ad squad in the requested window. Shifted, partial, or inconsistent provider reports return an error instead of exposing incomplete billing totals. Nothing changes in your request.
• Snap campaign, ad-squad, ad, creative, media-upload, bid-estimate, Public
• Profile, Pixel, and catalog client methods covered by this release now stop when
• Snap declares an error inside an HTTP success response. Global-ID mutations and
• creative assignments confirm the selected-account parent chain before writing,
• and later-page inventory failures return a bounded host diagnostic instead of a
• successful prefix. This is not a universal Snap-envelope claim: audience batch
• and polling calls and Conversions API HTTP-success envelope semantics remain
• tracked separately.
• Native catalog writes use the selected account’s organization and currency,
• stage local mapping changes behind an atomic revision check, and keep durable
• tenant/account/catalog journals for both catalog and product-feed creation.
• Retries after an ambiguous catalog or feed response never repeat the uncertain
• POST. They reconcile only exact complete provider readback, while delayed
• visibility, drift, foreign identities, unselected catalog_ids, and concurrent
• stale writers fail closed with no hidden provider or local mutation. No action
• is required.
• Social adapter campaigns now use the Interchange campaign name when creating platform campaigns. Previously, adapters such as Snap, Reddit, LinkedIn, and Pinterest ignored the campaign name and defaulted to a date-based fallback (e.g. “Campaign 2026-07-23”). Google and Amazon used an internal correlation reference instead of the campaign name. The standard ADCP buyer flow also failed to forward the campaign name to adapters even when a name was provided at campaign creation time. All adapters now use the Interchange campaign name, falling back to a date-based name only if no name is available. Ad groups, ad squads, and ads now consistently include the campaign name as a prefix (e.g. “My Campaign - Ad Group 1”), matching the naming convention used by Meta and TikTok.
• Storefront connections now show as connected immediately after mapping a provider account to an advertiser. Previously, the connection stayed in needs_account_selection state after a successful mapping, blocking product discovery and capabilities for the advertiser.
• Murph escalation status now treats Linear duplicate tickets as closed, preventing reconciliations from reopening consolidated reports.
• Meta’s product catalog now returns results for open or conversational briefs (“What ad products can I buy from Meta?”), matching the behavior of TikTok and Snap. Previously, briefs that lacked explicit campaign language caused Meta to return zero products. Products requiring platform setup (conversions, app installs, lead gen) continue to be excluded from controlled-planning results; the returned catalog reflects what can be booked today. The scope3_brief_strategy object in the response still signals any clarification needs so the buyer agent can guide next steps.
• If you’re setting up Meta buys through Interchange, only Auction buying type is available today; Reservation (Reach & Frequency) campaigns are not supported.
• Sandbox inventory-source tests for pass-through sources now select real products end to end. When you plan a sandbox test, the product candidates come from the same sandbox catalog the test actually uses, so a product shown in planning no longer comes back as “no matching products” at execution. And re-running a sandbox test for a brand you’ve already tested reuses the existing test advertiser instead of failing when it tries to create a duplicate.
• Three guardrails now protect live storefronts from silent degradation.
• Currency changes confirm their impact. Changing the settlement currency on a live storefront now tells you how many buyer-visible products the change would hide (prices you set directly are only shown in the settlement currency) and rejects the update until you confirm with confirmCurrencyCatalogImpact: true. Non-live storefronts and zero-impact changes are unaffected.
• Stale buy statuses are flagged. Media buys routed through an ad-platform connection now surface a staleness marker when the platform stops confirming status — the media-buys list carries a statusFreshness note (“status last confirmed Nh ago — source unreachable”) and a matching media_buy_status_stale diagnosis, instead of showing a dead connection’s last-known status forever. If the marker doesn’t clear, check that your ad-platform connection is still authorized.
• Stale reporting prices come off the market. Ad-server-reporting-derived pricing now has a 60-day freshness ceiling: a product whose cached reporting price hasn’t refreshed in 60 days is hidden from buyers with a “check your ad-server connection” readiness state, rather than served on a stale price. A fresh sync restores it automatically.
• Buyer note: products hidden by the currency or freshness guardrails drop out of buyer discovery — buyers see a smaller catalog, not an error.
• Platform campaigns created by adapter storefronts (Meta, Snap, TikTok, LinkedIn, Reddit, Pinterest, Google, Amazon) now use the Interchange campaign name chosen by the buyer instead of a system-derived name.
• Existing get_products calls require no changes and keep their current behavior unless proposal evaluation is enabled. discover_products again applies its established enrichment, relevance, ordering, and refinement behavior when evaluation is omitted.
• Add plain-language instructions under ext.interchange.evaluation to evaluate proposals before your buyer agent processes them. Interchange can accept or reject each proposal, attach buyer-owned enrichment, request a bounded AdCP refinement from the originating seller, and reevaluate the revision. An optional comparative pass ranks accepted proposals across storefronts.
• Progressive polls return replacement snapshots. Rankings remain provisional while sellers are pending; an unchanged revision poll is cached, while a changed accepted cohort is ranked again. Unchanged candidate versions do not repeat absolute evaluation. ext.interchange.screening remains available as a deprecated compatibility alias for accept, reject, and refine; it does not enable enrichment or comparative ranking.
• One Proposal Evaluation Pass processes up to 10 candidates. One Comparative Proposal Ranking Pass ranks up to 100 accepted candidates. Both meters are calibrating and report charged_ius: 0; provider tokens, retries, cached polls, protocol validation, and seller network calls are not separate passes.
• Reconnect Snap in Settings > Connections if Customer List audience sync says the connection cannot prove its identity. Audience create, update, member add/remove, status, and delete now retry without duplicating a list, stay isolated to the selected account, and return only Snap-confirmed outcomes. Incomplete or unfamiliar provider responses stop with an error instead of exposing or changing the wrong audience.
• Snap campaign discovery on selected USD accounts now asks for clarification instead of selecting a product when a brief is ambiguous, unsafe, or missing a supported objective or geography. Non-USD planning remains fail-closed until account-currency pricing is supported.
• Reconnect an existing Snap connection in Settings > Connections before using conversion measurement. New and reconnected Snap connections now request offline-conversions access in both hosted and delegated OAuth flows; Public Profile access remains excluded pending Snap allowlisting.
• Existing Snap campaign calls require no request changes. Campaign creation now confirms that Snap accepted the selected product and targeting before reporting success. Campaign reads show the requested settings, the current settings in Snap, and whether they match, without exposing private audience identifiers.
• If Snap omits or changes required settings, Interchange returns a clear error or reports the difference instead of presenting unverified targeting. Pricing, plans, and entitlements are unchanged; this adds no billable surface.
• Your Snap campaigns now use the selected ad account’s currency for prices,
• forecasts, and budgets. Non-USD accounts no longer inherit US-dollar minimums
• or guidance, and inconsistent amounts stop before a campaign is created.
• Nothing to change on your side.
• TikTok directed campaign creation now verifies selected-account ownership, paused materialization, activation response identities, and enabled readback at every hierarchy level. It activates the campaign only after its children. On ambiguous activation, cleanup verifies the exact campaign is paused before requesting deletion, distinguishes confirmed paused containment from a possibly active campaign, and reports rollback only after terminal provider readback. Offering-based packages remain paused until TikTok offering assets can be materialized as runnable ads.
• TikTok product discovery now asks for one campaign outcome instead of returning runnable recommendations from a vague, negated, or competing brief. If prompted, reply with an explicit choice such as Objective: traffic and retry; supported outcomes are reach, video views, traffic, conversions, app installs, and lead generation. Otherwise no action is needed.
• No action is needed unless a TikTok creative sync asks you to reconnect. If it does, reconnect TikTok in Settings > Connections and retry.
• TikTok image, video, and promoted-post creatives now keep their names and assets through retries, replacements, and service restarts. Campaign setup stays paused until TikTok confirms the intended creative was attached, and incomplete or conflicting TikTok responses stop safely instead of reporting the wrong status. Older saved TikTok channel selections also continue to work when the channel is still authorized.
• This improvement is for buyers who sync or run TikTok creatives. Seller storefronts and seller workflows are unchanged.
• Existing TikTok campaign calls require no request changes. Campaign creation now confirms that TikTok accepted the selected product and targeting before reporting success. Campaign reads show the requested settings, the current settings in TikTok, and whether they match, without exposing private audience identifiers.
• If TikTok omits or changes required settings, Interchange returns a clear error instead of presenting unverified targeting. Pricing, plans, and entitlements are unchanged; this adds no billable surface.

​

4.113.0 — July 23, 2026 at 11:39 PM UTC

• Delivery reporting now accumulates every counter (impressions, clicks, completed views, views, conversions, leads) into a lifetime total for sellers who report one day at a time, matching how delivered spend already behaves. Previously these counts showed only the most recent report for per-day-reporting sellers, so a campaign’s totals could look far smaller than what actually delivered. Cumulative and full-window reports are unchanged.
• When a campaign execution fails because a seller’s platform timed out, the error now explains that the media buy may still complete asynchronously and tells you to check its status — rather than surfacing a raw technical message with no direction. A new documentation section on the media buy lifecycle page shows how to receive completion webhooks instead of polling when working directly over AdCP, and the buyer agent now includes guidance on handling timeout errors and the async-acceptance path.
• create_media_buy and execute_campaign no longer return a misleading “sales agent not found” (404) when the sales agent actually exists but is not active. A pending, disabled, or failed sales agent now returns a specific, actionable error (409 SALES_AGENT_NOT_ACTIVE) that names the real reason — for example, that the storefront has not completed go-live and is not transacting yet, so complete billing/payout to activate it. An ID that resolves to a non-sales agent now returns a validation error naming the actual agent type rather than a 404.
• Three settlement and catalog-pricing correctness fixes:
• Settlement no longer guesses on an unrecorded media buy. When a media buy’s clearing method (Interchange-cleared vs. seller-direct) wasn’t recorded at booking time, the ledger now falls back to the storefront’s own declared clearing method before defaulting — the same fallback the seller-facing Media Buys list already used to fill in “not recorded” rows. The rare case where neither is known still books safely and is now flagged internally for follow-up, instead of silently assuming Interchange-cleared.
• **A $0 price is never treated as a real price.** A product option carrying a $0 fixed or floor price — the platform’s internal “not yet priced” placeholder — is now excluded from composed and pass-through catalog listings instead of reaching buyers as a bookable zero-dollar rate.
• Unpriced products stay visible to you, hidden from buyers. A legacy product your pricing feed couldn’t price (e.g. a currency mismatch, or an option shape the feed can’t match) used to disappear from your catalog entirely with no explanation. It now stays in your catalog — visibly marked as unpriced with the reason — while remaining correctly hidden from buyer discovery until it’s priced. A product you priced yourself with a fixed rate in your settlement currency is unaffected: it stays buyable on that price even when the feed can’t price it.
• Seller Setup now keeps every inventory source visible and opens the exact ad-server, feed-backed, or external-agent flow when you add another source, without asking for storefront-wide settings again. Uploaded media kits and policy documents now produce separate business-profile, acceptance-policy, and canonical creative-format drafts for review, and the Acceptance Policy page provides a conservative starter policy when no document is available.
• Creative tool connections now show only the relevant Audiences control. Buy and Events no longer appear because those settings do not apply to creative generation. No action is required.
• If Merchandising Rules shows Needs cleanup, remove the listed pricing, discount, market, or eligibility statements when you create your next version. The active version remains active in the meantime, but Selling Terms, Buyer Discounts and Buyer Instructions, Business Profile, and Acceptance Policy take precedence. Buyers do not need to change anything: storefront discovery and qualification now use each seller’s Business Profile markets consistently.
• Several surfaces now report their true state instead of a misleading default:
• Go-live catalog check (sellers): if opening for transactions is blocked by a failed catalog check, the error now names which inventory sources failed (up to three, plus a count) and a coarse reason (timed out, unreachable, errored) instead of a generic “try again in a moment.”
• Publisher domain roster (sellers): a domain whose adagents.json check hit a transient failure (timeout, DNS, 5xx) now shows “couldn’t check yet — retrying” instead of “Unknown,” so it’s clear we’re still trying rather than that we’ve never looked.
• Analytics win rate (sellers): a brand-new storefront with no run history yet shows ”–” for win rate instead of a false “0%.”
• Terms of Service (buyers and sellers): an account whose organization has no valid parent to accept Terms of Service on behalf of now sees a clear “contact support” message instead of the generic “must be a direct admin” error.
• Assistant render honesty (buyers and sellers): any tool result that opens a screen — on every MCP surface, buyer and seller alike — now reminds the assistant that it only requested the screen and cannot claim to see it rendered. This previously covered only a subset of seller-side tools.

​

4.112.0 — July 23, 2026 at 9:15 PM UTC

• You can now continue directly from multi-storefront get_products into one Interchange cart request. Select storefront-qualified proposals and/or proposal-less products, then choose whether to stage or execute the resulting media buys. Interchange keeps the search and refinement history on the product query and uses a DRAFT campaign as the shopping cart and parent of every media buy.
• Pass an existing campaign or include the fields for a new discovery campaign. If you create one inline, the response returns its campaign ID; media buys are never left without a campaign parent. A proposal selection applies that proposal’s product allocations to the cart—the proposal object itself is not sent back for exact execution. mode: stage contacts no sellers. mode: execute sends ordinary bilateral AdCP create_media_buy calls for the resulting buys and reports partial failures per media buy. The seller calls are not atomic, and an unchanged retry does not repeat completed work.
• The new v2 surface is available as POST /api/v2/buyer/media-buys/batch, MCP create_media_buys, and the buyer api_call operation create_media_buys. Existing discovery selection and execute_campaign workflows remain available and need no changes.
• Commercial model: There is no incremental charge for create_media_buys at launch, and existing media-buy pricing is unchanged. Retrieval remains included. Optional proposal screening remains a separately measured Intelligence Unit activity, with charged_ius: 0 while screening is calibrating.
• Rollout and rollback: This additive v2 surface launches ungated (multi-storefront-products remains gate: none). Existing callers enter it only when they invoke the new route or tool, so current workflows do not change. Rollback removes the additive route and tool; discovery selection and execute_campaign remain available.
• Measurement: multi-storefront-products defines active use as returning a multi-storefront get_products page or staging or executing qualified selections with create_media_buys. Batch audit events distinguish stage from execute and record selection count, inline campaign creation, and whether selections replace or merge. We will monitor successful staged and executed batches, retry/no-op rate, and per-media-buy errors. Healthy expansion means buyers complete multi-storefront carts without duplicate buys after an unchanged retry.
• Persona pass
• Enterprise brand buyer: Stage a reviewed cross-storefront plan on an existing campaign, inspect the resulting DRAFT buys, and execute only when approved.
• Large agency / hold-co buyer: Apply accepted proposal allocations from several storefronts in one cart request while retaining per-buy execution outcomes and retry safety.
• Scrappy builder / power buyer: Feed storefront-qualified IDs from get_products straight into create_media_buys; create the campaign inline when you do not already have one.
• SMB buyer (novice, chat): Save selected inventory in a draft campaign cart and review the prepared media buys before any seller is contacted.
• Seller: You continue to receive an ordinary one-to-one AdCP create_media_buy request. Other storefront selections and the buyer’s Interchange cart metadata are not shared with you.
• Existing storefront API calls keep their behavior. Integrations can now clear the first-go-live test-campaign gate without switching to Murph: plan a sandbox inventory-source test to inspect readiness and products, then redeem its short-lived, single-use token to execute the exact no-spend campaign through the real buyer path. The current validation covers product discovery and media-buy execution; it does not create or validate a creative. The existing test-runs API reports the result and its failing step. Seller-scoped test execution provisions a missing storefront wrapper before buyer discovery, while media-buy creation resolves stale selections from authoritative storefront provenance.
• Buyers are unaffected: the canary is confined to the seller’s sandbox-capable source and mock product provenance, creates no spend, and does not appear as a live offer or campaign to real buyers. This adds no billable surface, pricing change, plan gate, or packaging differentiation; it makes an existing go-live validation available to authenticated storefront API integrations.
• Exposure plan: gate: none. The API ships atomically because authentication, seller ownership, sandbox capability, mock-product provenance, a five-minute token, and single-use execution constrain exposure. There is no cohort expansion: all eligible authenticated storefront integrations receive the same contract. The kill switch is deployment rollback of these additive routes; there is no migration or persisted entitlement to unwind.
• Measurement: named usage signals are authenticated requests to storefront_test_campaign_plan and storefront_test_campaign_execute, plus terminal success and failure rows in the durable storefront test-run history. Launch acceptance is at least one seller completing the API plan-to-execute path with no real-spend or cross-tenant event, while 4xx/5xx and failing-step rates identify validation or runtime regressions.
• Actions inside interactive chat widgets now finish where you click them instead of posting the same choice back as a new chat request. Product selections save in place; creative campaign assignments and library saves execute directly; event sources and signal components finish in their forms; inventory and creative-reference choices record a quiet completion for the next step. Controls that could not actually complete a task are no longer presented as working actions.
• Persona pass
• Seller: Inventory, signal, and event-source work stays in the surface that collected the configuration, with an explicit saved or created result.
• Enterprise brand buyer: Creative assignments and library roles commit through the governed typed operation, without an extra model interpretation step.
• Large agency / hold-co buyer: Repeated product and creative work no longer creates duplicate conversational instructions across accounts and campaigns.
• Scrappy builder / power buyer: The same named operations and MCP completion channel work in Murph, Claude, ChatGPT, and other compliant hosts.
• SMB buyer (novice, chat): Clicking Save or Attach produces the result shown on the card instead of asking the buyer to explain the click again.
• Launch plan: This is an atomic ungated correction to existing GA widget surfaces (gate: none). Deploy to every host with the release. Roll back this change if direct operation completion or non-prompting context writeback regresses; rollback restores the former controls without changing any saved campaign, creative, product, signal, or event-source data.
• Measurement: Track successful add_discovery_products, attach_creatives_to_campaign, save_creatives_to_library, sync_event_sources, and create_signal operations alongside mcp_widget_context_updated completion events. Watch operation error rate, repeated identical user turns immediately after a widget action, and widget-to-operation completion. Acceptance is zero sendMessage calls in API Call, no increase in operation failures, and no confirmed duplicate-composer regressions across five buyer and five seller accounts.
• Monetization: None. Entitlements, pricing, settlement, and Intelligence Unit treatment do not change.
• Media-buy updates now leave existing creative assignments unchanged unless you include creative_ids. Send the full list to replace assignments, or [] to clear them. You can update campaign details or packages without revalidating attached creatives or sending them to the seller again.
• If your integration reads droppedCreatives from update_campaign, remove that handling: the field is no longer returned.
• For a package without stored flight dates, a date update now returns CAPABILITY_NOT_SUPPORTED until the seller advertises supported actions. Retry after the seller has provided that capability information.
• Persona pass
• Scrappy builder / power buyer and large agency / hold-co buyer: Send creative_ids only for an intentional assignment change; ordinary campaign and package updates now leave existing assignments alone.
• Seller: No storefront presentation or setup changes are required. Storefronts receive only the requested package update rather than re-forwarded creative assignments. Sellers supporting package date changes should continue exposing their supported actions.
• Three fixes to the storefront operate surfaces. Approvals: routing settings load reliably instead of showing a persistent “Unavailable” error — nothing to change on your side. Media buys: each buy now shows its real settlement method (Interchange-cleared or seller-cleared) wherever it is determinable; buys whose method genuinely isn’t recorded say so explicitly — nothing to change on your side. Payouts: banking details no longer block going live. You can activate your storefront first; funds accrue but cannot be disbursed until you add payout details, and the Payouts tab tells you exactly that with an add-details button.
• Active external sources now receive an automatic initial health check instead
• of remaining unclassified until buyer traffic reaches them.

​

4.111.0 — July 23, 2026 at 6:57 PM UTC

• Integrations must send format_kind when they create a creative from only a brief or when its legacy format reference conflicts with its asset type or dimensions. Existing canonical requests and supported legacy references continue unchanged when the evidence identifies one canonical kind. Saved creatives now match campaigns and products by that canonical format instead of an imported label. Sellers do not need to change their products or integrations.
• You can now turn reviewed ad-server inventory into a draft product without leaving Inventory Components or Inventory Selector. Name the product, choose the buyer creative formats, review validation results, and confirm creation in the same surface. Nothing is created until you select Create draft product.
• If you ask Murph with an exact product configuration, Murph can validate and create the draft through the same product operations. No existing products or publishing settings change.
• Draft products are not visible to buyers until you activate them. This release changes seller authoring only; buyer discovery and active catalog presentation are unchanged.
• Persona pass
• Seller: Review synced inventory and create a validated draft without repeating the selection in chat. Existing products are unchanged, and the new draft remains buyer-invisible until activation.
• Enterprise brand buyer: No workflow or governance change. Drafts created by sellers do not enter discovery until the seller activates them.
• Large agency / hold-co buyer: No workflow change and no new catalog rows until a seller activates a draft.
• Scrappy builder / power buyer: No buyer API or MCP contract changes; the new operations are storefront-authoring operations.
• SMB buyer (novice, chat): No visible change. Murph does not present seller drafts to buyers.
• Launch plan: This is an atomic ungated launch within the existing GA Product Authoring feature (gate: none). Inventory Components and Inventory Selector are already available to eligible storefront operators; the release replaces their composer handoff with the typed workflow. Expand immediately with the deployment. If validation or create completion regresses, revert this change to restore the prior Murph product-authoring path while preserving all existing products and underlying product APIs.
• Measurement: Use API operation telemetry for validate_esa_product and create_esa_product. Adoption is a storefront completing at least one successful validation; completion is a successful create with status: draft. Watch aggregate validation-to-create conversion, field-level validation failures, and create failure rate by storefront. The current REST telemetry does not carry MCP-app resource provenance, so do not attribute aggregate calls to a specific widget until that dimension exists. Acceptance is at least 20 successful draft creations across five storefronts, no confirmed composer-handoff regression, and a create failure rate below 5%.
• Monetization: None. Product authoring entitlements, pricing, and Intelligence Unit treatment do not change.
• Delivered-spend on media buys is now accumulated per reporting day instead of being overwritten by the latest delivery report. Buyers and sellers previously saw understated “delivered so far” figures on buys whose sellers report daily (or in overlapping windows), which could let a budget reduction slip below what had already been delivered. Delivery now sums correctly across days and is robust to re-sent, corrected, and overlapping reports.
• Spotify package-budget and end-time updates now use the provider’s documented account-scoped PATCH method instead of failing with 405 under PUT.
• Sales-agent connections whose OAuth refresh grant is rejected now show as degraded and reconnect-required instead of being reported as a source outage. Interchange no longer retries discovery with a known-expired access token, so the actionable credential issue is not overwritten by a misleading endpoint failure or timeout.
• Live storefronts now notify you when your buyable catalog empties — for example, when manual pricing expires — naming the cause and the fix. Going live is now blocked while your catalog can’t be verified yet, or when nothing in your synced catalog can actually be trafficked (e.g. video with no duration, or display formats with no width/height); a partial issue still warns without blocking. Readiness also flags active products that reference a publisher domain you haven’t declared or authorized.
• Buyer agents can now retrieve every package ID for a media buy and poll or cancel a pending update by its exact proposal ID. Updates that name an unknown package or media buy are rejected before the seller is contacted. Existing integrations do not need to change. Sellers do not need to act; a cancelled proposal becomes terminal, and a late seller callback cannot change the live media buy.
• Widget load failures in chat now name the widget that failed and offer a Retry button instead of a dead-end “MCP app failed to load.” strip, collapsed widget bars carry the widget’s name, a diagnostics request for an ad-server source opens its sync & diagnostics surface instead of an unrelated “connect a sales agent” form, and the assistant no longer claims a panel is visible when it failed to render.

​

4.110.0 — July 23, 2026 at 4:49 PM UTC

• You can now send one get_products request to selected storefronts—or every storefront connected to an advertiser—and receive products and proposals as sellers respond. Each product and proposal ID identifies its originating storefront and can be passed unchanged to later refine and media-buy calls.
• Screening is optional and currently in beta. Add plain-language instructions to have Interchange evaluate each valid proposal against your criteria, then return it unchanged, exclude it from the result, or ask the originating seller to refine it. If screening is unavailable, valid proposals pass through instead of being rejected. Existing unscreened calls are unchanged and remain included at no additional charge. During calibration, screening pass counts and estimated IUs may appear, but charged_ius remains 0.
• Discover Products accepts the same optional screening instructions. When you refine a discovery with screening enabled, Interchange sends the refinement to the seller, then screens the seller’s revised proposals before returning them.
• Persona pass
• Enterprise brand buyer: Compare proposals from connected sellers under buyer-controlled screening criteria. Existing workflows stay the same unless your media team enables screening.
• Large agency / hold-co buyer: Collect products from connected sellers in one progressive request. Optional screening removes proposals that miss your first-pass criteria and asks sellers to refine others before your team compares them.
• Scrappy builder / power buyer: Use the v2 REST endpoint or MCP tool. Select storefronts, poll results, and add screening through ext.interchange; pass storefront-qualified IDs unchanged into refine and media-buy calls.
• SMB buyer (novice, chat): When screening is enabled in Discover Products, proposals that do not meet your criteria stay out of the results, and sellers may be asked to revise others before you see them. There is no API setup.
• Seller: Buyers can now compare your proposal with responses from other connected storefronts and may ask you to refine it before review. You receive the bilateral AdCP request only; buyer screening instructions and Interchange coordination fields are not shared. No setup change is required. Complete proposals pass protocol validation, and prompt refine responses can return before the buyer’s deadline.
• Registering a sales-agent source with a malformed credential payload now fails at registration instead of succeeding silently. Previously, an API-key credential sent under the wrong field name (for example key instead of token) passed validation, showed as configured, and left the agent permanently unreachable with no pointer to the cause. Registration now rejects the wrong shape with a validation error, and credentials already stored under the legacy field name are read correctly.
• Source diagnostics now measure inventory discovery from get_products only, so failures in account sync, campaign updates, creative operations, or delivery reporting no longer falsely label a source as unable to return inventory. Those failures remain on their own operational axes. The same correction stops unchanged ESA health conditions from being presented as new Agentic Ops incidents while preserving the underlying health state and recovery re-alerting.
• A2A async discovery polling now recovers the seller’s returned server task ID from the paired response before calling tasks_get, preventing a failed immediate pre-seed race from polling Scope3’s client operation ID instead.
• Read-only source rechecks no longer turn an accepted asynchronous task or an account-required public probe into a critical outage. Pending tasks remain degraded until their correctly addressed background poll records the terminal result, and terminal success clears the health cell.
• Fixed an issue where the storefront setup assistant could stop taking actions (such as re-checking an ad server, inventory source, or compliance status) and reply in text only. These re-check actions now run reliably during setup.
• Spotify campaign creation and readback now preserve the buyer-authored campaign name across provider synchronization.
• TikTok media buys now use the selected ad account’s currency consistently from product discovery through campaign creation, monetary updates, and reporting. Conflicting or malformed account details—including unknown account statuses or roles—stop before a campaign budget or bid mutation, while recognized non-approved accounts remain discoverable with a suspended or closed status.
• You can now connect a hosted feed or upload and replace CSV, TSV, Excel, and JSON files directly in Catalogs. Approval counts, rejected rows, and field-level issues stay beside the advertiser feed so you can review and retry the exact change in one place.
• Persona pass
• Enterprise brand buyer: Review feed changes and rejected items in one governed advertiser workspace; no partner instruction or seller presentation changes.
• Large agency / hold-co buyer: Add and maintain feeds across advertiser accounts without moving configuration into a separate chat workflow.
• Scrappy builder / power buyer: Supply a feed URL or row-based file directly and inspect the sync result immediately.
• SMB buyer (novice, chat): Murph opens the guided Catalogs Page for setup; no API payload or technical prompt is required.
• Seller: Not applicable. This changes buyer-owned advertiser feed setup and does not change what buyers see about a seller or what sellers must configure.
• Launch plan: This remains behind the existing Buyer widgets v2 customer flag. Expand after at least 20 successful URL/file syncs across five enrolled buyers with a sync failure rate below 5% and no confirmed return-to-chat regressions. Disable buyer-widgets-v2 to remove the Page entry while retaining the existing API and Murph catalog paths.
• Measurement: Use successful and failed sync_catalogs activity records for enrolled buyers, split by URL and inline-file requests. Adoption is a buyer completing either path; acceptance is the expansion threshold above.
• Monetization: None. Catalog sync pricing and entitlements do not change.
• If your storefront is in the Trusted Match pilot, you can now declare trusted_match on a product directly through the wholesale authoring API. Send the field on POST, PUT, or PATCH /tenants/{tenant_id}/wholesale-products and get_products returns it on the next call. PATCH is coverage-preserving: omit or send null to keep the stored value, send an explicit body to replace it. Declare which runtimes the product supports (context match, identity match), the provider agent URL, and the uid types and countries the declaration covers. The SQL workaround is retired; existing declarations keep working. Storefronts not in the pilot see no change: sending trusted_match returns 403 tmp-not-enabled. Pilot enrollment is managed by Scope3 operations through a new PUT /tenants/{tenant_id}/adapter-config/tmp-enabled endpoint.
• Buyers: no behavior change. Buyer agents calling get_products continue to receive trusted_match on any product where a seller has declared it, exactly as they did before — the field itself and its shape are unchanged; the only change is that sellers can now populate it themselves.
• Monetization: none. Trusted Match itself is priced through the existing sales-agent runtime and identity-match provider contracts; this endpoint does not introduce a new billable surface or entitlement.
• Rollout: gated per-tenant behind AdapterConfig.tmp_enabled (ops-provisioned, fail-closed). Expansion: pilot storefronts move to beta once a declared product surfaces on the setup checklist and flows through a forwarded media buy end-to-end; beta moves to GA once the legacy match-flag reader is retired. Kill switch: ops flip tmp_enabled: false and writes immediately return 403 tmp-not-enabled; stored declarations are preserved but no longer emitted on get_products from that tenant.
• Storefront Briefs now runs starter discovery tests directly and keeps progress, matched products, errors, retry, and decision review beside the selected brief instead of creating a generated chat prompt.

​

4.109.0 — July 23, 2026 at 2:57 PM UTC

• Seller Setup and ad server source diagnostics now run reporting, forecasting, refresh, and discovery re-check actions through their canonical typed operations. This fixes valid FreeWheel re-check buttons being blocked by a stale host allow-list and prevents the same operation-map drift across other source adapters.
• Answering the first setup question with “sell through Scope3” no longer fails on brand-new storefronts. The intent’s capability preset previously tripped a validation that requires an approval reviewer to be configured — a step new sellers had not reached yet. The reviewer requirement still holds where it matters: the approval-routing item on your readiness checklist must be resolved before going live, and explicitly enabling manual review workflows still requires a reviewer up front.
• Discovery tests against an external sales-agent inventory source now return the actual matching products, each with its product id, alongside the match count. For pass-through sources that compose inventory live rather than from a staged catalog, this gives you concrete, addressable products to select when setting up a sandbox test, instead of only a number.
• Test Runs now diagnoses and repairs a failed or stalled sandbox run directly from its detail. The result and retry state stay beside the exact run instead of creating a synthetic chat message.

​

4.108.1 — July 23, 2026 at 8:59 AM UTC

• Campaign re-execution now uses the current FX quote without colliding with the original media buy’s locked rate. Existing booked media buys keep their original rates; no buyer action is required.
• Pacing period overrides on pre-execution media buys now apply correctly instead of returning “Media buy not found.”
• Campaigns can now use existing static display creatives whose legacy format labels differ from a product’s current image-format name when the asset type and dimensions match. This prevents valid campaign creatives from being excluded during media-buy creation without changing the saved creative or weakening video and other format checks.
• Wholesale pricing uploads now close the feedback loop instead of going silent on success. Every preview and commit reports which of your feed’s selectors matched a product and which didn’t, so a feed that priced nothing because of a selector typo or the wrong selector type is no longer a bare success. Readiness no longer reports pricing as current when a fresh, in-window feed doesn’t actually match any product, and it never blocks a source you’ve priced entirely with operator fixed prices in your settlement currency. A new advance warning shows “pricing feed expires in N days” starting a week before the 35-day staleness cliff, instead of the first sign being products disappearing. Countries suppressed by your minimum line-item spend are now named on the product and in readiness details instead of just vanishing, and a feed row mixing a GLOBAL selector with per-country rows for the same selector is rejected rather than silently double-counting avails.

​

4.108.0 — July 23, 2026 at 4:59 AM UTC

• Account admins can now add, view, and remove browser origins for custom agents right from Interchange — no raw API call needed. Find the setting under API Keys → Browser origins.
• Scope3 platform administrators can create a separate seven-day Demo Storefront with clearly labeled synthetic Display, CTV, and Retail Media inventory. Each demo includes a sample buyer brief and outcome, plus controls to reset, extend, or delete it. Ordinary seller accounts do not show demo-creation controls. Deletion or expiration removes only the Demo Storefront and its synthetic data. No action is required.
• Go-live checklist buttons now open the right surface. “Add payout details” opens your own storefront’s billing setup instead of a different account, and “Fix publisher authorization” opens your property roster instead of the ad-server source page.
• Currency mismatches in your pricing now surface before go-live instead of silently hiding products. A wholesale pricing feed must be single-currency and match your storefront’s settlement currency — off-currency rows are rejected row-by-row at preview with a clear reason. A fixed product price in a different currency than your settlement currency no longer counts as a complete price (there is no FX), and setting one warns you immediately at authoring time. When every hidden product’s only problem is a wrong-currency price, the Products available readiness check names the currency mismatch directly instead of reporting a generic “pricing unresolved”.
• Ad-server source actions now open their connection and diagnostics workspaces directly instead of turning button clicks into Murph chat prompts.
• Buyer Activity now analyzes a selected API call directly inside the Activity page. The answer and retry state stay with the call, and the action no longer creates a synthetic chat message.
• The Campaigns workspace now opens a campaign’s editable creative-to-placement mapping task directly instead of turning the button click into a Murph prompt.
• Release Notes now explains account-specific updates directly inside the selected card. Answers and retry states stay in the Page, and the action no longer creates a synthetic chat message.
• Re-declaring a publisher domain — or resending it in a full publisher-set update — now re-checks its adagents.json after a short cooldown, instead of only ever checking it once. A domain that already resolved successfully no longer gets reset to “Checking” when you re-declare it, and a temporary network hiccup while fetching your adagents.json is now retried automatically instead of being reported as “no adagents.json found.”
• Storefront adapter credential health status (expired, revoked, or errored connections) now persists correctly and triggers the expected seller notifications. A parameter-typing bug in the underlying database write had silently dropped every credential health update and its notification since the health-tracking loop shipped.
• Product discovery now labels result groups as storefronts instead of sales agents. The selector, the summary count, and the results footer all read “storefront(s),” matching how discovered inventory is actually grouped (by storefront).
• Sales agents that answer get_products with input-required — for example, sellers that need campaign or brief context before they can return inventory — are no longer incorrectly marked unhealthy or sent false “source unreachable” notifications. An input-required (or auth-required) response is now treated as a healthy, reachable reply: the live discovery leg records the source as healthy and serves any warmed catalog, and the wholesale catalog probe records the capability as unsupported rather than as an outage.
• When a Meta storefront has multiple Facebook Pages authorized for the selected ad account and no page_id is provided in the execute_campaign request, the error now surfaces the list of authorized Page IDs and names so the buyer’s agent can select one and retry. Previously the error was stripped to “Upstream request failed” before reaching the buyer.
• Snap campaign creation now stops safely when Snap returns inconsistent account or status data. It verifies that the campaign is paused before launch, cleans up confirmed partial creations, and clearly reports when cleanup needs operator attention. No action is required.
• Snap media buys now verify countries against Snap’s current targeting inventory, reject incompatible products and unsupported targeting before campaign creation, emit provider-valid frequency and audience shapes, and disable provider audience expansion for accepted targets.
• Spotify campaign writes and readbacks now use the account-scoped v3 endpoint as their ownership boundary when the provider omits its retired campaign account field.
• Spotify campaign reads now trust the authenticated account-scoped v3 resource when the provider emits a contradictory legacy campaign account field.
• Spotify media-buy readback now projects its top-level flight from authoritative package schedules so paused creates can reconcile exactly.
• Spotify media-buy readback now accepts the v3 PENDING_APPROVAL ad-set state returned immediately after a successful paused campaign create.
• TikTok campaigns now reject targeting that cannot be applied exactly, and Snap campaigns requested as paused stay paused through creative setup. Wholesale catalog reads also return complete, stable inventory metadata.
• TikTok campaigns now use current provider demographic fields, disable native targeting expansion, and verify the paused ad group’s targeting and ownership before continuing setup.
• Meta now returns products on open briefs. Geography defaults to US when no country is specified, and creative format no longer needs to be stated explicitly — both gates previously blocked discovery on any brief that didn’t name a country and a format keyword. LinkedIn matched-audience products no longer have US targeting silently baked in when the brief contains no geography.
• Fixed four small onboarding friction points: pre-provisioned accounts now get their invite email sent (not just the invitation record), the ad-server connection status now tells you to grant Google Ad Manager access once your service account exists instead of repeating “connect your ad server,” a Google Ad Manager credential problem now names the actual fix (granting the service account access) instead of a generic “reconnect,” and asking to change approval routing without admin access now tells you to ask an admin instead of a bare rejection.
• Planning a test campaign against a pass-through inventory source now surfaces real, selectable products. Previously, for storefronts that pass inventory straight through from an outside sales agent (product composition off), the planner skipped catalog discovery and returned no product candidates, leaving no way to pick a product for a sandbox test even when the source clearly had matching inventory. The planner now runs a live discovery against the source (falling back to the most recently cached pass-through catalog if the source is momentarily unreachable) so it hands back concrete product ids that a later test execution will actually find.
• Pending Operations now takes sellers directly to the approval, retry, timeline, or source-diagnostics view for each task. When a Google Ad Manager order needs cleanup, the Page offers a confirmed safe archive or a documented manual resolution. No setup change is required.
• Before your storefront activates for the first time, one end-to-end test campaign — product discovery, media buy, and creative against your own storefront — must pass. The new publish_validation readiness check runs the same path a buyer would, so a buyer never hits a failure you could have caught yourself. A failing run names the failing step and its root cause right in the readiness checklist, so you fix the exact problem instead of guessing. A pass older than 30 days downgrades to an advisory nudge to re-run, and storefronts that are already live are never retroactively blocked. Run it by asking your agent to run a test campaign, or with execute_inventory_source_test_campaign.
• Every readiness checklist item now tells you what it actually demands: requirement is hard (must be resolved before going live), soft (advisory — never blocks), or platform_default (the platform applied a sensible default, named in appliedDefault, that you can change any time). The checklist is path-aware and now starts with the question everything else depends on — how you sell. A new selling_intent check leads the list: complete once you declare it (or automatically inferred from your configuration, so existing storefronts are never blocked retroactively), and a new approval_settings item shows the approval posture the platform applied for you.
• Embedded sales agents now wait for trafficking acknowledgement before marking creatives active, and delivery responses serialize scheduled polling times as ISO 8601 strings while omitting the field when no further update is expected. No seller action is required.
• Sandbox inventory-source tests now explain why a test found nothing to buy instead of always reporting an empty catalog. When your source returns inventory but none of it matches the test brief’s format or targeting, the failure now says the source returned products that did not match this brief (and how many), rather than claiming the source has no catalog. If the source was skipped or returned an error during discovery, that reason is surfaced too.
• Setup now asks one question first: are you connecting a sales agent you already use, or selling through Scope3? Your answer (setupIntent on the storefront) sets the right starting configuration automatically — pass-through storefronts are no longer offered ad-server connection steps they don’t need, and sell-through storefronts start with merchandising on. The choice is reversible at any time: updating the storefront with the other intent (or flipping capability flags) switches paths, and the matching setup surfaces appear immediately.
• Connected TikTok advertisers can retry audience creates, updates, and deletes without creating duplicate provider audiences. Pixel and audience ownership is checked against the selected advertiser before a write. Nothing to change on your side.
• Buyers can now set packages[].startTime/packages[].endTime on update_campaign to move an individual package’s flight window in place — alongside the existing budget, pacing, and bidPrice fields — instead of canceling the package and adding a new one to shift its dates. The new dates must fall within the media buy’s own date range; every other package on the buy keeps its own window untouched.

​

4.107.0 — July 22, 2026 at 5:07 PM UTC

• If your API integration creates creatives, send the documented format_kind field. Buyer-created creatives now stay attached to their campaigns and reach sales agents reliably, while campaign format coverage and buyer discovery remain canonical and URL-free. Media-buy responses identify older or incompatible creatives that could not be delivered. Exact format references supplied by third-party systems remain supported at the adapter boundary.
• Sellers do not need to take action. They receive the same creative payload contract, with unsupported creatives rejected before delivery instead of arriving incomplete.
• Spotify account reads now preserve v3 account resources with tax identifiers and use the provider’s current currency field, restoring directed campaign synchronization and media-buy readback.

​

4.106.0 — July 22, 2026 at 2:52 PM UTC

• Approval review is now self-contained: inspect the submitted details and
• pre-screen, decide in place, and retry a failed media-buy forward without
• leaving the Approvals Page. A retry requires confirmation and cannot create a
• duplicate booking at a source that already received the approval.
• Video hosted creatives now include a separate clickthrough asset when synced to third-party sales agents. VAST creatives are unaffected — click tracking is embedded inside the VAST XML and no separate clickthrough asset is sent.

​

4.105.0 — July 22, 2026 at 1:43 PM UTC

• You can now manage trusted-buyer auto-approve carve-outs directly in a portable
• Buyer Trust Page. Eligible buyers are shown by name with recent media-buy
• activity, every enable or revoke explains its exact effect, and no setting
• changes until you explicitly save it.
• You can now edit pricing rules and creative or media-buy review settings directly
• in the portable Selling Terms Page. The same configuration also works through
• confirmed assistant prompts in any compatible MCP client. Existing settings do
• not change until you save or confirm an exact update.

​

4.104.0 — July 22, 2026 at 11:31 AM UTC

• Seller Analytics and Brief History now show one consistent record for every buyer brief, from fit and posture through response, approval, outcome, and learning. You can search by buyer, brand, brief, date, or outcome, and no setup changes are required.
• You can now edit and activate your Merchandising Rules wherever you open them, review every previous version, and restore an earlier version without leaving the page. You can also ask your assistant to apply exact rules after you confirm them.
• Seller Analytics now identifies the storefront being measured, keeps catalog probes out of recent-run totals, and shows each run’s posture and attribution. No setup changes are required.

​

4.103.0 — July 22, 2026 at 9:30 AM UTC

• Fixed advertiser mapping for connected ad-platform accounts while the adapter storefront is still configuring. Buyers can now finish account setup before the storefront begins transacting.
• Account admins can now preview, reactivate, or reuse saved acceptance-policy versions when no version is active. Starter policy templates also match the Page language, while other storefront members remain read-only. No action is required.

​

4.102.0 — July 22, 2026 at 6:53 AM UTC

• Meta media buys now keep exact AdCP targeting by explicitly disabling Advantage Audience expansion and verifying that setting on provider readback.
• Fixed an issue where discover_products returned 0 results with no error for Meta adapter storefronts when the buyer had mapped an advertiser to a Meta ad account but had not globally selected a default account on their connection.
• MCP tools that declare nullable fields (for example update_business_profile) no longer reject valid values with a false “wrong type” validation error. The tool input validator now understands JSON Schema type unions such as ["string", "null"].
• Organizations with an accepted Intelligence Unit plan can now be billed on a monthly cycle. The plan commitment is charged at the start of each calendar month, and accrued usage overage is charged automatically when it crosses a threshold during the month. Each month closes with a numbered fee invoice — plan commitment, overage (IUs × rate), and payments applied. Invoice numbers are sequential with no gaps. Invoices appear on Plan & Billing → Payment & invoices and via GET /api/v2/billing/fee-invoices (list) and GET /api/v2/billing/fee-invoices/:invoiceNumber (line-level detail).
• Organizations with a saved card are charged automatically; invoiced organizations receive the invoice and pay on their existing terms. A failed charge enters the standard payment retry process, with self-serve pay-now recovery on Plan & Billing.
• No organization is charged as a result of this release. Cycle billing is switched on per organization — it requires an accepted Intelligence Unit plan, and you will know before it applies to yours. Nothing changes in how storefronts appear to buyers; this is billing between your organization and Scope3 only.
• Meta connections now recognize the current versioned webhook-field response and automatically maintain their configured ad-account event topics. No action is required.
• Seller-managed campaign readback now retains the selected product and currency when a provider omits those fields from its create response. No action is required.
• Seller-managed campaign refreshes now retain accepted product and pricing identity when the provider omits those fields. No action is required.
• Canceled Meta campaigns now reach terminal readback when Meta removes their ad sets before retained targeting records are retired. No action is required.
• Seller-managed campaign writes no longer remain pending when a provider returns the same flight dates without milliseconds. No action is required.
• Meta campaign package details now consistently include the selected product’s currency and product identifiers. No action is required.
• You can now declare properties on your Property Roster before a publisher’s adagents.json does — tell your agent about a site, app, or CTV channel you sell (or call declare_roster_property / POST /api/v2/storefront/property-roster/properties) and it appears on the roster marked “Declared by you”. When the publisher’s own adagents.json later declares the same property, the publisher’s record takes over automatically. If the publisher’s file later drops the property, your declaration stays; publisher-origin entries follow the file. You can remove a declared entry at any time. Nothing changes for buyers: the roster is a seller-only surface, and declared entries are never served to buyer tools or buyer-facing property lists.

​

4.101.0 — July 21, 2026 at 11:45 PM UTC

• You can now edit and activate your Acceptance Policy wherever you open it, review every previous version, and restore an earlier version without leaving the page. You can also ask your assistant to apply exact policy text after you confirm it.

​

4.100.0 — July 21, 2026 at 11:27 PM UTC

• Fixed an issue where a user added to an admin or approver role after an approval work item was created could not act on it, even when the routing policy was configured for that role. The authorization check now treats current role membership as sufficient qualification when the routing policy includes a role-based audience.
• Organization invitations can now be accepted or declined while Terms of Service are pending, so invited admins can join the organization and complete its agreement setup.
• Include account IDs and names in the model-visible list_accounts summary so MCP hosts can select a connected advertising account.
• Murph now consistently presents buyer budgets and delivered spend in gross (fee-inclusive) terms and no longer asks buyers whether to work in net or gross. When you need the working-media (net-of-fee) figure to reconcile against an IO line, ask Murph for the media buy’s budget breakdown and it will show the media, fee, and fee-rate split.
• Meta media buys now preserve the platform’s standard audience and location-presence metadata without rejecting an otherwise exact targeting match, while unknown controls and audience expansion that changes delivery remain blocked.
• Require Murph to triage customer issues before preparing a support escalation, while preserving that triage through approval and filing.

​

4.99.0 — July 21, 2026 at 9:47 PM UTC

• Fix package-level delivery breakdown missing from reporting for single-day reports whose reporting period ends at 23:59:59 (end-inclusive) rather than the next day’s midnight. These reports were misread as multi-day, which dropped by_package metrics that carried period totals without a nested daily breakdown. Package-level impressions, spend, and rate now record correctly for these single-day reports.
• Fixed Murph approval controls disappearing when you reopened or reloaded a chat. The Approve and Reject buttons for a pending action now reliably reappear, so you can approve what you asked Murph to do instead of getting stuck repeating the request.
• RFC 9421-signed webhook deliveries from sales agents are now verified by matching the agent’s brand.json entry to the endpoint URL we call, rather than an internal identifier. Previously, when the id an agent published in its brand.json differed from the identifier stored on our side, valid signatures were rejected with a generic “invalid signature” error and catalog, delivery, creative, and reporting webhooks silently failed to apply. Verification now resolves the agent by URL, caches the agent’s declared id, and re-resolves automatically if it later changes, so signed webhooks keep working without manual intervention.
• The pricing-coverage warning no longer counts products that already have a fixed price. A product made buyable by a fixed price set directly on it was still counted as “unresolved” in the source’s pricing sync status, so the “upload pricing” warning could ask for uploads nothing needed. The effective coverage summary now counts fixed-priced products as seller-priced.
• Murph’s inventory-source sandbox test now checks up front whether an inventory source’s sales agent supports sandbox (no-spend) testing, and stops with a clear explanation when it doesn’t, instead of creating a test advertiser and campaign and then failing with a confusing “couldn’t find the selected inventory” message. When a sandbox test does run and the source returns no inventory, the failure now says the source returned an empty catalog rather than blaming the product you picked.
• Your storefront now has a Property Roster: one place to see every publisher domain you have declared, the properties and collections that publisher’s adagents.json actually resolves to, and whether your sales agent is authorized to sell each one. Ask your agent to “open my property roster”, or call the open_property_roster tool / GET /api/v2/storefront/property-roster. Declared properties and collections are now persisted from each adagents.json resolution, so the roster stays accurate as publishers update their files. Nothing changes about how you sell today — this is a read-only view, and unauthorized domains show exactly what to fix. Not applicable to buyers: the roster describes a seller’s own publisher relationships and is not exposed on any buyer surface.
• Storefront status now consistently recognizes that ad servers other than Google Ad Manager (SpringServe, FreeWheel, AdsWizz) price through a manual wholesale-pricing upload rather than an automatic ad-server sync. Previously these sources were reported as having unresolved pricing that needed support — and an uploaded pricing feed was ignored until an admin changed a setting — across the readiness view, the ad-server status your agent reports, and admin refreshes. Now every one of those surfaces reads the uploaded feed directly and, when none exists, prompts you to upload wholesale pricing.
• Murph now reconciles a stuck media buy against your ad server. When an order was approved or rejected directly in your ad server (for example, a GAM order handled outside the storefront approval flow), refreshing the source re-checks every non-terminal media buy (pending_approval, pending_start, paused) and corrects any status that drifted, so a buy that is really live no longer sits at pending_approval. Ask Murph to refresh the source and it reconciles the status instead of only filing an escalation.
• When Meta rejects and rolls back a media buy, the connected account no longer remains stuck, so you can retry without changing your setup.
• Fix creative sync to routed sales agents when no explicit placement assignments are provided. Syncing a campaign’s creatives to a media buy now binds each creative to the buy’s package(s) automatically, so sales agents that require a creative→package assignment (e.g. via AdCP assignments[]) receive the binding instead of rejecting the sync with INVALID_REQUEST. Buyers who send explicit assignments are unaffected.

​

4.98.2 — July 21, 2026 at 1:38 PM UTC

• Meta product discovery no longer mistakes ISO campaign flight dates for unsupported audience age ranges.

​

4.98.1 — July 21, 2026 at 1:18 PM UTC

• TikTok campaign execution now checks the verified USD and AUD campaign minimum against the net media budget before any provider write. USD package and offering-expanded ad-group minimums are also checked. Budget failures return bounded numeric details and an actionable gross-budget correction while other provider messages remain masked.

​

4.98.0 — July 21, 2026 at 12:33 PM UTC

• Claude can now discover the correct sign-in endpoints for a direct adapter storefront instead of failing while registering the connector.
• If Scope3 has issued your storefront organization a private offer, review and accept it in Plan & Billing before your current term ends. Plan & Billing keeps the current and upcoming plans visible, and starts the accepted plan when the current term ends. Your current price and allowance do not change mid-term.

​

4.97.0 — July 21, 2026 at 11:43 AM UTC

• Official ad-platform connections now expose one canonical provider source ID, such as meta, across capabilities, connection summaries, account mappings, and directed subscriptions. Account mapping no longer requires callers to copy a redundant source ID; historical adapter and storefront IDs remain accepted as compatibility inputs.
• When you ask Murph to buy through a named platform such as TikTok, it now distinguishes a direct platform-authored campaign from brief-led product discovery. If your intent is unclear, Murph asks before choosing a campaign mode; direct campaigns no longer get an unnecessary discovery or execution step.
• Plan & Billing now identifies private Effective Rate Cards from the accepted offer and clearly separates IU package terms from existing media pricing.
• Claude and ChatGPT can now finish signing in to a direct Meta storefront. Interchange validates the Meta credential and selected ad account before allowing account-bound operations; no setup changes are required.
• Meta product discovery now understands explicit country names or ISO codes and exactly representable composite age ranges even when the optional brief interpreter is unavailable. Fully specified briefs return reviewable products instead of incorrectly asking for geography or age clarification.

​

4.96.0 — July 21, 2026 at 10:33 AM UTC

• Sellers can now review, create, and update their business profile in a portable Business Profile page. MCP-compatible assistants can also show that page or apply only the profile changes a seller confirms, without erasing saved details they did not mention.
• Fixed brought creatives with generated tracking URLs being removed from media buys as if they lacked required assets. Campaign assignment, package execution, and creative sync now use the same complete manifest asset projection for managed and external sales agents.
• Plan & Billing now shows the exact included IUs, monthly commitment, overage rate, and rollover terms from your accepted Effective Rate Card, including private packages.

​

4.95.0 — July 21, 2026 at 9:54 AM UTC

• Fixed get_storefront_capabilities returning probeStatus: unreachable for official adapter storefronts (Meta, TikTok, Snap, and others). Adapter storefronts dispatch in-process and always synthesize capabilities without an HTTP probe, so they now correctly report as reachable when the adapter is active.
• Clear product ideas shared with Murph are now added directly to **Your
• requests** for product review. Murph avoids duplicate asks and confirms that an
• idea is tracked without implying that it has been promised or scheduled. If
• product tracking is unavailable for the account, Murph says the ask was not
• confirmed instead of claiming success.

​

4.94.0 — July 21, 2026 at 8:54 AM UTC

• Repair existing saved creatives that were attached to campaigns but remained invisible to media buys and sales agents.
• Murph now shows support, product, and supply asks in one customer-safe request
• tracker. Product asks are explicitly tracked for review rather than promised,
• and support asks show recovery status such as the next update and whether the
• customer is still blocked.

​

4.93.0 — July 21, 2026 at 7:47 AM UTC

• If Seller Setup shows Add payout details, complete that step before transacting. Interchange pays you for transactions from external Sales Agent sources, so these storefronts need payout details; storefront adapters with a separate settlement agreement do not. You can now set your operator domain and settlement currencies directly in the checklist, then open the correct secure page for payout details and other required tasks. If your storefront already shows as ready, nothing changes.
• Whether you’re buying or selling, requests you bring to Murph now keep their type, urgency, and blocked action together for follow-up. Product ideas stay distinct from urgent support problems, and there is nothing to change on your side.
• Buyers with a selected Meta ad account can now inspect recent processing,
• review-issue, recommendation, creative-fatigue, and product-set signals in
• ext.scope3_provider_signals. Existing API calls and polling behavior do not
• change when no signals are present, and there is nothing to configure. Scope3
• confirms webhook updates against Meta before they affect campaign state;
• polling remains the authoritative fallback.
• You can review your complete storefront plan terms before accepting them and find the same terms later in Plan & Billing. Existing accepted terms do not change; if a private offer requires review at renewal, it stops at the end of its term until new terms are accepted.

​

4.92.0 — July 21, 2026 at 6:22 AM UTC

• Fixed uploaded video (and other data-URL) creatives silently failing to attach. When a creative was brought into a campaign through the assistant, its media file could fail to link — leaving a creative that showed as “attached” but had no usable asset and could never be trafficked. Brought media is now uploaded to hosted storage with the storage service’s canonical asset identity, the same way a direct file upload is, so it attaches reliably and can be sent to the seller for review. If an upload does fail, the incomplete manifest is removed; an existing asset-less upload is rejected with a clear instruction to delete and re-upload it instead of pretending the creative is deliverable.
• Creatives attached from an earlier conversation, a creative library, a collection, or a copy now reach new and existing media buys with their files intact. Previously, a buy could reach a seller without a reviewable creative and appear to be waiting for approval forever. Buyer and seller views now say that no creatives are attached, so the buyer knows to attach or re-upload one and the seller does not need to investigate an approval queue.
• New organizations now get oriented on the Plan & billing Overview before accepting terms: a “What stays free vs. what needs payment” explainer shows that connecting, browsing, discovery, and reading docs and pricing stay free, while media spend and intelligence-metered activities are paid — with every metered activity priced on your published price list before you run it. The plan summary also states plainly that your plan starts once the platform terms are accepted, instead of implying a plan that doesn’t exist yet.
• TARS now recognizes punctuated leading Slack mentions as human-to-human
• handoffs and stays silent without running an answer-model turn. Murph follows
• the same leading-addressee rule. Direct mentions now route once and reach both
• assistants without addressee punctuation in the model prompt.

​

4.89.0 — July 20, 2026 at 11:42 PM UTC

• GET /api/v2/billing/account now returns your recent prepay deposits in payment.deposits (previously always empty): each row carries the amount, currency, effective date, reversal status, and the payment provider and reference recorded with it, projected read-only from the platform ledger. The Plan & billing page’s Deposits history card populates from the same field. No action is needed — existing consumers pick the rows up with no API changes, and nothing about how deposits are made, invoiced, or billed changes.
• Monetization: none — this is read-only visibility into deposits that already exist on the ledger; it does not change invoicing, credit terms, packaging, or pricing. Persona: buyer-side (org admins and the builders integrating the billing document); sellers have no deposit surface and are not implicated.
• Cross-currency media buys now keep the exchange rate shown at booking through approval, retries, delivery reporting, and settlement. Buyers can plan against one stable converted price, and sellers receive settlement based on that same rate across every package. We audited current production buys before rollout; no existing buy needs customer action. If a future retry sends different currency terms, Interchange rejects it before spend starts—the buyer should resubmit with the original terms or a new media-buy ID.
• Rotate a generative creative provider key without disconnecting it or rebuilding its setup. Its label, advertiser assignments, and default status stay in place.
• A fixed price set directly on a product now makes it buyable on its own. A pricing option with is_fixed: true, a positive rate, and a currency counts as complete pricing — the product is visible to buyers without waiting for ad-server pricing history or uploading a wholesale feed (auction-priced products still need one of those two paths for their percentile guidance and availability). The readiness checklist also stops double-reporting one unresolved-pricing problem: when the “Products available” check already blocks with the upload remediation, the wholesale feed-freshness row no longer appears as a second red row for the same fix.
• The Plan & billing page now shows more of your account’s history at a glance. The Overview tab lists recent commercial activity — agreement acceptances (including who accepted and when) and credit application milestones (submitted, approved with the granted limit, declined, or withdrawn) — instead of a permanent empty state. On the Usage & credits tab, day-by-day intelligence spend renders as a time-series chart with per-day amounts on hover.
• The Plan & billing chat widget now matches the web page’s balance treatment: an untouched credit line (nothing funded or owed) renders as quiet credit headroom instead of a hero number, so the big figure appears only when it carries news. The usage summary also names your top intelligence-usage feature and its share of spend instead of a generic note.
• pause_campaign now returns the full cascade result including totalMediaBuys, successCount, failureCount, and per-buy mediaBuyResults. Previously the response always reported success: true even when all ADCP calls to the seller agents failed — callers had no way to distinguish a clean pause from a total cascade failure. The always-true success field is removed; callers should check failureCount to determine whether the pause reached sellers. Sellers are not affected: this change is to the buyer API response shape only; the ADCP calls to seller agents were already occurring before this change.

​

4.88.0 — July 20, 2026 at 7:44 PM UTC

• People who sign up with an organization’s verified primary email domain now join that organization as members by default when the domain identifies only one organization.
• Organization settings → Members now shows members, admins, pending invitations, pending access requests, and the accounts each active member can access.
• No action is needed to keep this default. Admins who want to review every new member can turn off Domain auto-join in Organization settings. Joining the organization does not grant access to child accounts.
• Added ad_unit_node as a supported FreeWheel selector type for browsing ad-server selectors, matching FreeWheel’s real inventory taxonomy. Previously it was missing from the selector-type list, so sellers could not browse or search FreeWheel ad unit nodes through this capability.

​

4.87.0 — July 20, 2026 at 6:29 PM UTC

• Every Plan & billing tab now shares the redesigned look. No action needed.
• Plan & pricing: your effective terms, rate provenance, and IU plan render in the same clear card-and-stat layout as the rest of the page, with plan selection and renewal management working exactly as before.
• Payment & invoices, Contracts & orders, and Media billing: same content and actions, cleaner presentation.
• Setup answers now preserve every complete command in documented CLI sequences and omit unrelated internal work from customer and prospect guidance.
• New publishers no longer dead-end on pricing or domain authorization. Readiness now measures what buyers can actually purchase: when products exist but none are visible to buyers because pricing is unresolved, the “Products available” check blocks going live and says so directly (e.g. “3 products created, 0 visible to buyers — pricing unresolved”) with a link to fix it. A new GET /api/v2/storefront/inventory-sources/{sourceId}/wholesale-pricing/template endpoint returns a pre-filled CSV — one row per ad-server selector your products reference, with ids, names, settlement currency, and dates already filled in — so you only add CPM percentiles and monthly available impressions, and your first committed upload now enables the wholesale pricing module automatically. Declaring a publisher domain now resolves its adagents.json immediately instead of waiting for a background sweep, and every domain carries a machine-readable authorizationReason (no_file, file_invalid, agent_not_listed, agent_untyped, agent_not_property_bound, authorized) on the publishers API and readiness checklist, so an unauthorized domain tells you exactly what to fix — including pre-3.x adagents.json files that need upgrading to typed authorizations.

​

4.86.3 — July 20, 2026 at 5:17 PM UTC

• Buyer agents now get the exact public AdCP endpoint when asking how to connect to a storefront. Storefront operators now get the exact management MCP and Codex setup details plus independent GAM advertiser-access diagnostics.

​

4.86.0 — July 20, 2026 at 3:04 PM UTC

• Adding, managing, and diagnosing an ad-server source now happen in three focused views instead of one crowded screen. Existing connections, settings, and sync schedules are unchanged; there is nothing to migrate. Use the Connect view the next time you add a source, the source page for day-to-day settings, and Sync & diagnostics for health and run history.

​

4.85.1 — July 20, 2026 at 1:48 PM UTC

• Connected social account campaign lists are now more reliable. Incomplete platform
• responses are rejected instead of being shown as complete, reducing the chance that
• campaigns are missing from buying and reporting workflows. No action is required.
• Murph and TARS now preserve exact storefront connector commands, buyer-facing endpoints, and independent GAM advertiser diagnostics in multi-part setup answers.
• Account administrators can again see older customer-scoped scope3_ API keys while
• migrating integrations to account API keys. The API Access page had incorrectly hidden
• legacy keys that were not attached to an individual user, even though they remained
• active.

​

4.85.0 — July 20, 2026 at 1:21 PM UTC

• Report the correct unique-publisher count when redeeming seller proposals and improve multi-seller ranking measurement.
• The Payouts tab on Plan & billing has a clearer layout. Payout activity now reads as a proper list with status chips and amounts, payout entities show as structured cards with their currencies and masked account details, and empty states explain what will appear instead of leaving blank space. Setup itself is unchanged — no action needed.
• The Plan & billing Overview is easier to read and more informative. No action needed for any of it.
• Text and spacing across the page now render at the intended size — they were previously ~40% too small next to the rest of the app.
• Sellers: the Payouts card now shows your payout entity count and setup status, with a “Set up payouts” shortcut if you haven’t added one yet.
• Buyers on a credit line: until money actually moves, the balance card shows your credit headroom quietly instead of a large number restating your credit limit. The prominent balance returns whenever funds or owed amounts are real.
• The Usage & credits and Accounts tabs on Plan & billing match the rest of the redesigned page. No action needed.
• Usage & credits: your intelligence balance leads with four clear stats (used, remaining, overage, projected), bucket balances render as labeled meters, and the price list and calibration catalog read as proper tables.
• Accounts: the money view of your accounts is a cleaner table with the same delegation, fees, and usage columns as before.
• Existing connections keep working, so no action is required. Settings and Murph
• now use Connections and Connected platforms consistently.
• For buyers setting up a new Meta connection: use an Ad Account owned by a
• Business Portfolio and add the Scope3 Business Portfolio (Business ID:
• 1091793362240769) as a partner. Seller storefronts and how buyers see them are
• unchanged.

​

4.84.0 — July 20, 2026 at 9:55 AM UTC

• Plan & Billing now separates your immutable published activity prices from the broader Intelligence Unit catalog still being calibrated. Starting rates for merchandising, Murph, generation, analysis, optimization, document understanding, BigQuery, and managed media are clearly labeled as non-billing estimates that cannot change your accepted Rate Card or debit your IU balance.

​

4.83.0 — July 19, 2026 at 10:53 PM UTC

• Meta audience syncs now reuse the same Meta audience on retries and report a
• failure when Meta does not accept every requested member change or deletion.
• Estimated audience sizes are no longer presented as exact counts, and conversion
• totals include only events Meta confirms. Existing requests do not need to
• change. A sync that previously appeared successful may now return an error;
• investigate that error and retry after the provider issue is resolved.
• The Inventory Components workspace now leads with what to do: a plain-language header explains the job (turn synced ad-server inventory into products buyers can discover), one promoted “Do this next” line replaces the static five-step banner, and mapping statuses speak seller language (“Needs a choice”, “Not matched”, “Suggested match”). Your accept/hide decisions now survive data refreshes instead of silently resetting — they only clear when you switch sources. The workspace also uses the correct term everywhere: it builds Products (the “Packages” tab and drafting actions were mislabeled — a package is part of a media buy, not what you author here).
• Meta connectors now turn a non-empty advertiser brief into a reviewable campaign
• strategy by default. If the objective, geography, creative format, or another
• required decision is ambiguous, the connector asks for clarification instead of
• returning an actionable product based on a guess. API callers that explicitly
• want raw catalogue discovery can continue to use buying_mode: "wholesale".
• Account API keys managed by WorkOS are now the primary credential in API Access.
• Legacy personal keys appear only for accounts that still have them, with guidance to
• replace and revoke them; customers can no longer create, edit, or reveal a legacy key
• from the Interchange UI.
• Spotify connections now return only advertiser-authorized audiences, Pixels,
• and Conversions API integrations. They no longer substitute demo audiences,
• claim ignored customer-list changes succeeded, expose approximate audience size
• as an exact match count, or hide partial audience deletion.
• Buyers may see fewer audience or measurement objects because unverified and
• synthetic results are no longer returned. Server-side conversion ingestion is
• shown as unavailable instead of accepting events without a provider-confirmed
• outcome.
• No migration is required. Re-run Spotify audience or event-source discovery
• before relying on an existing object; use only the returned advertiser-owned
• identities. Customer-list replacement and conversion event ingestion remain
• unavailable until Spotify can provide safely reconcilable write receipts.
• Reddit-connected buyers now get provider-issued Pixel IDs, account-authorized server events, and retry-safe customer-list updates. Buyer and provider audience aliases share one tenant-owned operation identity, so another connection’s same-account audience cannot be changed by raw Reddit ID. Failed or ambiguous Pixel, audience, and conversion operations now stop with an explicit error instead of reporting success. No credential change is required; existing unowned lists remain readable but fail closed for writes. Dedicated live verification remains in progress.
• Google Ads media-buy updates now use provider-derived revisions and exact
• readback for supported Search, Display, Performance Max, and Demand Gen
• campaigns. Pause/resume, seller-package budget, supported ad-group bid, and
• advertiser-timezone schedule changes validate account and package ownership,
• reject stale revisions before writing, and roll back or pause the campaign if a
• multi-entity update cannot be completed safely.
• Cancellation now makes an active campaign non-serving before removal and waits
• for Google to return terminal removed-campaign history. Accepted but
• unconfirmed removal is returned as a reconciliation error, not a completed
• cancellation. Reporting-only Google campaign surfaces advertise no write
• actions. These capabilities remain pending signed staging evidence and are not
• yet marked Green.
• Seller persona: not applicable. This changes only buyer-directed writes to
• connected Google advertiser accounts; it does not alter a seller storefront or
• anything buyers see about a seller.
• Fixed an existing Meta server-side conversion workflow that could stop when a
• request named a tracking source but not an ad account. Scope3 now uses the
• ownership learned by the existing tracking-source sync, rechecks access before
• every send, and stops safely when that access cannot be proven.
• If you use event-source-only conversion requests, continue to sync the Meta
• tracking sources for that ad account once first. Existing requests that already
• name an account are unchanged. This buyer-side fix does not change seller
• storefronts, ranking, or reporting.
• Existing Meta creative calls are unchanged. Buyers enrolled in seller-managed campaign writes can now attach one image-feed creative to one existing paused package with sync_creatives.assignments; Scope3 durably records the provider ad, reconciles retries without creating another ad, and confirms the paused provider assignment before reporting success. This is a separate post-create operation: the current assisted decision plan does not choose or bind creative and actor fields. Multiple assignments, assignment weights, placement-specific assignments, carousel, and generated formats remain unavailable.
• Buyers enrolled in directed campaign writes can now compare the targeting
• requested for a Meta media buy with Meta’s current normalized targeting on
• every read. Invalid or ambiguous geography stops before any provider write,
• and missing audit data fails clearly instead of hiding what changed. The new
• read fields are additive and optional, so existing clients need no changes.
• No setup changes are required. Organization SSO sign-in now keeps each user in the correct account and gives administrators clear guidance when WorkOS membership or organization setup needs attention.
• The Plan & billing Overview tab has a clearer layout. The page now leads with a next-action card that shows where you are in billing setup (accept terms, add billing details, fund your account — whichever applies to your organization) instead of a warning banner, and a new Quick links card puts API keys and the billing docs one click away. Nothing changes about your plan, balances, or billing itself — no action needed.
• Meta campaign plans now show product pricing and budgets in the connected ad
• account’s currency. Accounts that use another currency no longer see
• dollar-based minimum prices or forecasts presented as local guidance.
• Interchange checks that the plan and budget use the same currency before
• creating a campaign. Nothing changes for existing campaigns or raw campaign
• creation. If your integration uses assisted plans, send the connected
• account’s three-letter currency code in both the request and its total budget.
• Storefront administrators can now manage shared API keys using their existing
• Interchange access without requiring a second WorkOS administrator role. API
• Access also labels personal-key creation explicitly and describes shared keys
• without using “programmatic access.”
• Meta, Snap, TikTok, Pinterest, Reddit, and LinkedIn connectors no longer return active
• demo audiences when provider inventory is empty or unavailable. Empty accounts
• return an empty signal list, while provider and pagination failures return an
• error so agents cannot target fabricated identity. Reddit, TikTok, and LinkedIn
• now exhaust bounded, identity-validated audience pagination before returning a
• successful signal inventory. LinkedIn validates paging.total when supplied
• and otherwise proves completion through bounded short-page exhaustion.
• Plan & Billing now presents IU terms as one coherent experience: a concise plan comparison on Plan & pricing, including the effective included-IU rate separately from the overage rate, and a unified balance, forecast, setup-credit, and published activity-price view on Usage & credits.
• Meta connectors now discover Pixels and Datasets from the selected ad account
• instead of substituting the ad account ID. Empty accounts return an empty list,
• and installation guidance and Event Match Quality are shown only for sources
• Meta confirms on that account. Conversion events are not sent when ownership or
• complete inventory cannot be verified. Request/context account mismatches and
• pagination that changes API version, account, or resource also fail before any
• Meta write.

​

4.82.0 — July 19, 2026 at 9:22 AM UTC

• The ad-server product setup path got a substantial clarity pass. Connecting an ad server: the create button now stays disabled until required fields are filled, jargon fields (network code, agency id, namespace, floor price) carry plain-language hints, and the Google Ad Manager steps say how access is verified. Inventory Components: a misleading “Synced” badge is gone, every Ask-Murph hand-off now confirms success or reports failure, load errors are retryable in place, and partial data loads show a notice instead of looking complete. Inventory Selector: “Selection sent to Murph” now appears only when the send actually succeeded (failures show a retry), the selection task closes itself on success, failed branch loads are recoverable per row, and the tree is fully screen-reader navigable. Error text and links meet contrast standards in both themes.
• Meta-connected buyers can keep one JPEG or PNG creative upload inside compatible
• agent hosts instead of leaving the campaign workflow to finish the asset in Ads
• Manager. The Task checks the image in the browser, uploads it to private
• storage, and returns a stable creative reference without exposing image bytes
• or temporary storage URLs to the model. Availability remains gated on private
• ingress setup and successful Claude and ChatGPT validation.
• Approvals and Source Diagnostics got a round of reliability and clarity fixes. Approvals: decisions now write an activity line to the chat, the approve confirmation says the real reason when a pre-screen is still running, failed history or pre-screen lookups no longer masquerade as “nothing here”, Ask-Murph failures are surfaced, and screen readers get proper expand/collapse and severity cues. Source Diagnostics: a failed load now retries in place, partially loaded evidence shows a notice instead of looking empty, recommended next steps appear above the evidence tables, and copy buttons report when a copy fails. Error text in both widgets now meets contrast standards in light and dark themes.
• Buyers enrolled in Meta seller-managed campaign writes can now turn a brief
• into a reviewable decision plan, accept it together with the exact future
• create intent, and bind that one-time authorization to campaign creation.
• Pass-through creates remain backward compatible and are recorded as raw, so
• they cannot be mistaken for Scope3-assisted targeting or creative decisions.
• This first assisted contract stays paused and intentionally leaves inline
• creative execution to a future separate creative assignment workflow.
• The accepted Meta plan also binds an immutable product, pricing, objective,
• targeting, and campaign-name execution snapshot. Missing or mutated stored
• products fail before Meta mutation, pre-feature raw idempotency hashes still
• replay, and plan cleanup cannot cascade-delete the durable write journal. Plan
• audit rows remain available for at least 30 days and are then eligible for
• bounded best-effort cleanup on later planning traffic.
• Buyers can now list a campaign’s saved creatives from the canonical plural REST
• route and compare each one with the creative created by a connected platform or
• sales agent. Existing creative reads and the legacy singular route keep working;
• no client migration or setup change is required. The optional platform_links
• field exposes the agent, provider creative identifier, sync state, approval
• state, and latest sync time when those values are available.
• Claude, ChatGPT, and other generic MCP clients can now inspect the exact AdCP
• request fields for a connected ad-platform storefront before they create or
• update a campaign. Clients should call get_adcp_tool_schema and follow its
• bounded nested paths instead of guessing targeting, creative, budget, or
• lifecycle shapes.
• Ad-server refreshes now reliably use the connected source’s correct internal identifier after access or permissions are updated.
• Buyers enrolled in directed campaigns can now retrieve their complete LinkedIn
• campaign inventory through Interchange. Campaign status, currency, budgets,
• schedules, revision, available actions, and creative review state come from the
• connected LinkedIn account. If LinkedIn cannot prove the account snapshot is
• complete, Interchange returns an error instead of incomplete campaign data. No
• setup change is required.
• Connected Pinterest accounts now return complete campaign, package, and creative inventory with the account’s actual currency. If Pinterest cannot provide a complete, account-safe read, the request reports an error instead of returning partial data. No action is needed.
• Pinterest media-buy updates now verify the selected account and current provider
• state before writing, mutate package budgets and flights at the owning ad-group
• or campaign CBO boundary, and reconcile every success from a fresh provider
• readback. Stale, unsupported, cross-account, partial, or unconfirmed terminal
• updates return a clear error instead of reporting unverified success. No action
• is required.
• Reddit campaigns pulled through your connected account now include the full
• account inventory and its actual currency. When Reddit cannot return a
• complete, account-safe campaign or performance view, the request reports an
• error instead of showing partial data as complete. No action is needed.
• Reddit-connected campaigns now preserve exact bounded budget changes, reject
• stale updates, and confirm cancellation from provider state before reporting
• completion. Existing campaigns and seller workflows are unchanged. No action is
• needed.
• Snap connected-account reads now return complete campaign, creative, media, audience, account, and catalog inventory with the actual account currency, campaign status, package budgets, and requested delivery snapshots. If Snap cannot provide a complete or safe read, the request returns a clear error instead of partial data. No action is required.
• Snap media-buy updates now verify account ownership and current provider state before writing, update the selected package budget, attach creatives atomically, and confirm campaign cancellation from deleted-entity readback. Stale or partial updates return a clear error instead of reporting an unverified success. No action is required.
• Spotify account and creative reads now include every paginated campaign, ad set, and ad instead of silently stopping after the first 50 results. Incomplete provider responses fail safely rather than appearing to be a complete account snapshot.
• Fixed two issues where a media buy’s delivered flight dates and reported status could drift from reality: shortening a campaign’s end date after it was submitted for storefront approval, but before it was delivered, could be silently dropped so the ad server kept running the original, longer end date; and a media buy that failed once and then succeeded on a later retry could be stuck showing a rejected status even though it was actually running.
• TikTok account reads now return complete campaign, ad-group, ad, creative, and requested reporting inventories or fail clearly instead of silently returning a partial result when provider pagination is incomplete.
• Buyers enrolled in directed campaign writes can now pause or resume TikTok
• campaigns and change package budgets, bids, and end dates through Interchange.
• Cancellation appears complete only after TikTok confirms it. If TikTok applies
• only part of a change, Interchange either restores the prior settings or reports
• clearly that manual review is needed. No setup change is required.
• WorkOS organization API keys now authenticate correctly as Bearer credentials,
• carry the customer context required by buyer and seller route guards, and return
• non-cacheable credential responses. M2M applications return and verify credentials
• through the environment’s AuthKit domain.
• Social adapter readiness checks can now verify the same paused, future-start,
• no-spend campaign lifecycle across Meta, TikTok, Pinterest, Reddit, Snap, and
• Spotify. This adds a validation path only; an adapter is not considered live-ready
• until its signed provider canary passes. Seller storefronts and seller workflows are
• not affected. No action is needed.
• Buyers enrolled in directed campaigns can now retrieve their complete current
• Google Ads campaign inventory through Interchange, including active, paused,
• completed, and removed campaigns. Campaign currency, budget, dates, status, and
• package details come from the connected advertiser account. If Google cannot
• prove that the account view is complete and belongs to the selected advertiser,
• Interchange reports the problem instead of showing partial campaign data.
• New Google campaigns also keep the package, product, pricing option, and budget
• selected by the buyer when they are read back. They remain paused until their
• creative is created and Google confirms that the campaign is ready to run. No
• setup or client change is required.
• Buyers enrolled in directed campaign writes can manage LinkedIn campaigns with
• provider-backed conflict detection and readback. LinkedIn media buys now retain
• one stable campaign/package identity, honor paused creation, use account
• currency, and support pause/resume, total-budget, bid, end-date, and terminal
• deletion transitions. Interrupted changes are restored or paused for
• containment instead of being reported as successful.
• Existing read behavior and setup remain unchanged; writes stay limited to
• enrolled accounts.
• Invited staging organizations can now review the exact Intelligence Unit Rate Card available to them, choose a plan, keep an eligible storefront on pass-through at no cost, or decide later. Interchange records the version shown and the administrator’s response so pricing can be evaluated before a production rollout. This pilot does not publish production pricing or enable metering, invoicing, or payment collection.
• The storefront Setup checklist now recovers in place when it fails to load: a Try again button retries without reopening the widget, and a failed background refresh keeps your checklist visible instead of replacing it with an error screen. The publisher-domain detail appears only while a domain still needs authorization, the go-live progress bar is announced correctly by screen readers, and error text meets contrast standards in light and dark themes.
• Buyers enrolled in directed campaign writes can now safely pause or resume
• Spotify campaigns and update package budgets, bids, end dates, and delivery
• state through Interchange. Each change checks the current Spotify revision and
• is confirmed by a complete provider readback that rejects unrequested state
• drift. Exact currency micros, strict schedules, provider identities/statuses,
• and a bounded account-operation deadline fail closed. Spotify does not offer a
• true campaign cancellation operation, so cancellation now returns a clear
• unsupported response instead of presenting a reversible pause as canceled.

​

4.81.0 — July 18, 2026 at 8:09 PM UTC

• Storefront marketplace cards and hosted AdCP capability responses now state who bills you for media, using AdCP billing-party vocabulary at the protocol-native slot (account.supported_billing): agent means Interchange clears the transaction and bills you; operator/advertiser mean the seller or your connected platform account bills you directly.

​

4.80.0 — July 18, 2026 at 7:39 PM UTC

• Anonymous Agent Registration identities can now verify read-only, zero-spend sandbox access before they are claimed by a customer organization. Claimed agents still require the organization to accept the Terms of Service before customer-bound access.
• Anonymous Agent Registration identities can now use the canonical buyer advertiser read endpoint during their zero-spend sandbox trial. Mutations, nested advertiser routes, MCP, and money-moving endpoints remain denied until claim.
• Storefront Activity now opens reliably from the Operate rail, notification
• polling no longer produces repeated request errors, and the Media Buys, Pending
• Operations, payout-currency, and source-diagnostics states stay coherent in
• Portuguese and Japanese.
• This restores the existing Activity rail action to its already-shipped typed
• Storefront tool; it does not add a new seller capability. Buyers are unaffected,
• and no action is required.
• Murph now returns portable widget launch directives directly and stages report requests as real approval controls instead of making text-only offers.
• Agent Registration requests now carry their database-backed customer role and account type through normal buyer authorization guards, allowing zero-spend advertiser reads while continuing to reject seller-bound and deleted customer identities.
• You can now see your Intelligence Unit (IU) plan, balance, and usage in one place. Plan & Billing shows your plan — pay-as-you-go or committed — plus your signup credit, any IUs carried over from last month, and your included IUs. It also shows how many you’ve used this cycle, a projection for the rest of the month, and any overage building up. Overage shown here isn’t charged yet. There’s nothing to change on your side.
• Storefront Activity now follows the seller’s selected language when Calls are
• available and when the account uses the Changes fallback. No action is required.
• IU plan selection now presents prices, savings, rollover, and acceptance terms
• in a calmer two-step rate card. Plan & Billing also gives account standing,
• available funds, current intelligence spend, and any required action a clearer
• visual hierarchy without changing prices or billing behavior.
• Today’s standard IU Rate Card draft is unpublished. Its displayed 4-IU activated-social-account rate is only the current coarse-denomination planning value: the final denomination and IU count are not set, and the activity is not charged. Once a finalized Rate Card is published for your organization, Plan & Billing will show one organization-wide IU plan for buyer, storefront, Murph, and other IU-rated activity, including exact plan prices, your corporate discount, rollover terms, and activity prices before an authorized administrator accepts it. When the offer becomes available, an eligible new seller billing account can receive one 100-IU credit for storefront setup, valid for 60 days and limited to one per billing organization. No action is required until an effective Rate Card is shown to your organization.

​

4.79.0 — July 18, 2026 at 4:31 PM UTC

• Storefront sellers can now run setup and day-to-day operations in the display
• language selected in Interchange. Portuguese and Japanese sessions keep widget
• labels, dates, numbers, currency, and post-action confirmations consistent with
• the surrounding interface.
• Publisher signup now keeps Storefront intent through account creation and
• leaves optional marketing consent off by default. No action is required.

​

4.77.0 — July 18, 2026 at 11:00 AM UTC

• Meta creative sync now rejects native-localization requests before uploading media instead of silently creating an untranslated ad.

​

4.76.0 — July 18, 2026 at 9:20 AM UTC

• Enrolled buyers can turn an advertiser brief into a read-only Meta campaign plan with explicit objective, audience, creative, measurement, and setup decisions. Ambiguous, excluded, or unsupported targeting returns questions instead of guessed inclusions. This capability remains gated pending signed live evidence; existing product listing and campaign creation calls do not change.
• Meta directed-campaign mirrors now fail safely instead of omitting native exclusions, audiences, locales, behaviors, or placement constraints. When a complete account sync cannot represent an ad set’s targeting, the prior complete mirror is retained and the subscription reports an error.
• Meta directed-campaign delivery now returns every ad-set package, including zero-delivery packages, account-currency spend, and the provider’s effective campaign status even when optional catalog attribution is unavailable. Invalid package totals, currency precision, or requested device reports fail closed. Provider-suppressed geography attribution remains visibly truncated instead of failing the authoritative campaign total or appearing complete.
• Buyers enrolled in Meta directed campaign writes can now keep one creative ID from upload through paused campaign creation, then read back its assigned ad set and Meta review status. Before syncing an image, provide an authorized Facebook Page ID (and an Instagram account ID when needed) and host the JPEG or PNG at a public HTTPS URL. Campaigns remain paused while Meta reviews the creative.
• Meta account connections now keep the last complete account list when a refresh fails, and buyers can select only active advertiser accounts. Account status, hierarchy, labels, and currency remain consistent across refreshes, including correct financial values for currencies such as JPY and KWD. No setup change is required.
• Managed Google Ad Manager orders now stay pending while forecasting finishes and count as approved only after GAM confirms approval.
• Meta creative sync and inline offering creation now discover Facebook Pages authorized for the selected ad account. When exactly one Page is available it is selected automatically; ambiguous selection returns paged ID-and-name choices, and unauthorized Facebook Page or Instagram identities fail before any provider or ledger write.
• Meta directed campaign creation now verifies the provider campaign, ad set, ad, creative, source media, and configured status before reporting success. Malformed, substituted, cross-account, or partially activated provider hierarchies fail closed and are cleaned up safely.

​

4.75.0 — July 18, 2026 at 12:26 AM UTC

• Buyer teams can now set up credentials for agents, scripts, and backend integrations without contacting Scope3. Organization admins can manage API keys in API Access settings, while existing scope3_ keys keep working. Test a replacement with a successful request before retiring a working key.
• Campaigns can no longer commit more spend than your available Scope3 credit. When you activate a campaign — or raise its budget — in a way that would push your committed spend past what your funding and credit line cover, the API now returns HTTP 402 CREDIT_LIMIT_EXCEEDED, with the shortfall and your current balances in error.details. Creating a campaign is never blocked: if its budget already exceeds your available credit, the create response carries a non-blocking warning instead. Free up committed budget by pausing or archiving other campaigns, or add funds, to clear the block.
• This is gated by a feature flag and off by default, so nothing changes for your account until it is enabled.
• Before creating a Meta campaign, include an explicit country for every package and every postal-code target. Campaign creation now stops if Meta applies different geography, protecting brand and agency teams from approving spend against the wrong market. Existing campaigns and requests that already include valid geography need no changes.
• Fixed PayloadTooLargeError (413) on update_media_buy webhook callbacks. Seller-returned affected_packages payloads for multi-package updates can exceed the previous 64KB body-size cap; the limit is now 15MB (matching get_products) for update_media_buy and remains 64KB for all other task types.
• Also fixed async update_media_buy requests not being tracked correctly: the task ID a sales agent returns for a still-processing update is now persisted, and the webhook that later confirms completion is now matched against that task ID (in addition to our own buyer reference) when correlating it back to the right media buy.
• Fix stale source health for external sales-agent inventory sources. Source-health diagnoses now offer a read-only discovery recheck that records the actual get_products result before returning, and an hourly background recheck clears recovered sources without waiting for buyer traffic.
• Catalog-driven social buys now preserve item-level delivery attribution when
• packages use the canonical AdCP catalogs array. No action is required.
• Seller-managed TikTok campaign writes now accept canonical offering and job catalogs while continuing to reject catalog types the provider cannot apply.
• You can now update a media-buy package’s pacing to front_loaded (previously rejected only for packages, though products already supported it), sync a catalog feed with feedFormat: "tiktok_shop", "pinterest_catalog", or "openai_product_feed", and set a catalog’s type to "app" — all previously rejected due to hand-maintained enum lists that had silently drifted from the underlying protocol.
• Improves managed-storefront buying by applying channel, market, and format filters consistently; presenting canonical creative formats without legacy media-type leakage; surfacing per-source rejection reasons when a buy fails; and accepting clear natural-language approvals for the exact pending action while failing closed on ambiguous replies.
• Fixed the buyer creative library tool (list_advertiser_creatives) so it shows every creative saved on an advertiser by default, matching what buyers already see on the web platform. Previously it only showed creatives explicitly promoted to the reusable library, so a creative uploaded on the web but not yet promoted could be invisible to an agent over MCP and fail to attach to a campaign.
• Fixed a bug where an uploaded creative (for example, an audio ad) could be saved as the wrong media type and left unplayable when its upload reference never resolved to the actual file — most commonly a same-session file reference reused on a later turn. The upload is now rejected with a clear “please re-attach it” notice instead of being silently guessed as an image.
• Storefront delivery polling now retries within the hour when a source returns no usable per-day delivery for the day yet (e.g. its numbers finalize a few hours after midnight), instead of waiting for the next scheduled read. Retries are bounded per slot: after several hourly attempts without data the route defers to its next fixed read and records a diagnostic, so a source that reports no daily breakdown can’t be polled indefinitely. Each scheduled read starts a fresh retry cycle, so a day’s failures never carry into the next.

​

4.74.0 — July 17, 2026 at 6:39 PM UTC

• Fixed the storefront catalog-change webhook for sellers connected as a direct agent (not a managed/ESA connection): it previously accepted the request but never actually refreshed the cached product or signal catalog, so proactive change notifications were silently ignored.
• execute_campaign now returns an error instead of a false success when a campaign has never launched and has no media buys to execute (for example, no product was ever selected). Previously this case reported success: true with mediaBuysExecuted: 0, leaving the campaign silently stuck in draft while telling the buyer it was activating. Re-executing an already-active or paused campaign with nothing new to dispatch still reports a successful no-op, unchanged.
• Fixed two issues with media buy budget updates on multi-format buys. Budget changes could be applied to the wrong ad format when a seller confirmed packages back in a different order than they were sent, and a budget change for a format without an approved creative yet could be silently dropped instead of reaching the seller.
• Fixed a bug where Murph could show raw placeholder text like “(that field, that field, that field)” in a reply instead of a clean sentence, when it needed to redact more than one internal detail at once.
• You can now target reach as a campaign optimization goal (previously rejected due to a stale internal list). Validation errors for an unsupported optimization-goal value now name the specific field and list the accepted values, instead of a bare “Invalid input” message.
• Social delivery reporting now retains catalog-item attribution in durable,
• provider-isolated storage. Aggregate delivery remains available if optional catalog
• enrichment is temporarily unavailable. No action is required.
• Plan & billing tightens up from design review: internal platform usage no longer appears in your intelligence usage, unknown renewal data is hidden instead of labeled “not available”, rate rows explain decisioned vs routed in plain language, the payer-of-record card states its scope, and placeholder cards for unshipped features are gone.
• Murph now stays silent when an ordinary human-to-human Slack message is mistaken for an account-specific request, instead of interrupting with a prompt to tag Murph.
• The storefront catalog-change webhook now returns the underlying reason (e.g. “brand.json fetch returned HTTP 404”) in the error body when RFC 9421 signature verification fails because your agent’s brand.json couldn’t be fetched, instead of a generic “verification unavailable” message.

​

4.73.0 — July 17, 2026 at 2:01 PM UTC

• If you sync event sources without a mapping object, nothing changes. If you do send mapping, you must switch its field names to camelCase — the retired snake_case keys are now rejected with a validation error instead of being silently dropped, so integrators wiring event-source sync should update before their next call. The mapping object (a Scope3 extension on sync_event_sources) now uses eventIdField, eventTypeField, eventTimeField, userMatchFields, valueField, currencyField, orderIdField, contentIdsField, consentField, and dedupeStrategy, matching the shape event-source reads already return — this fixes the opaque “Invalid input” a caller hit when mirroring a read back into a write. The ADCP sync_event_sources fields themselves (event_source_id, event_types, allowed_domains, integration_platform, test_event_code) are unchanged, and there is no seller-facing change.
• Wholesale optimization now rejects unsupported pricing models before pacing or
• profitability calculations instead of silently treating them as CPM, zero, or
• missing revenue.

​

4.72.0 — July 17, 2026 at 12:17 PM UTC

• Agents can now request a payment method: the add_payment_authority task returns a single-use secure link the cardholder opens to enter the card directly with the payment processor (no sign-in needed), and the task reports verified once the card is saved. Card details never pass through the agent or the API.
• If a card payment fails, you don’t lose access. We retry automatically at 3 and 7 days and email you at each step. If the charge still hasn’t gone through after 10 days, we pause new paid actions only — new credit spend, media commitments, and upgrades — while reporting, data export, campaigns already delivering, and your Plan & Billing page keep working. Update your card and pay, and everything resumes the moment the charge succeeds. We’ll also email you about 30 days before a saved card expires.
• Creating another account under an existing organization no longer treats the
• organization container as a storefront, and newly created buyer or storefront
• accounts now stay attached to the same canonical organization record.
• Fix routed media buys failing to forward to sales agents that require an explicit buyer confirmation. A storefront-approved routed buy is now forwarded with buyer_confirmed: true, so sales agents that gate create_media_buy on buyer confirmation accept the buy instead of rejecting it (previously surfaced to the seller as “Forward failed”). The flag is set only on the create forward — the buyer’s storefront submission plus the seller’s approval are the confirmation — and never on subsequent update_media_buy calls.
• Creative-format documentation and API descriptions now consistently label
• {agent_url, id} references as legacy-v1 compatibility data. Canonical AdCP
• 3.1 product formats remain URL-free format_kind plus params declarations.
• Media billing polish from a design review: currency renders as a chip everywhere, loading placeholders reserve the right space, the resolution chain marks the matched step with a check (not color alone), the target picker is screen-reader labeled, and the country field shows its help and errors inline like every other field.
• On phones, the address rows in the billing-entity and payout forms now stack instead of crushing; radio choices and dropdown errors render through the standard controls.
• Embedded sales agents now use URL-free AdCP 3.1 creative declarations, pass
• inline HTML tags and their dimensions through to Google Ad Manager, return
• wire-valid pending statuses, and preserve seller approval tasks when a recovered
• media-buy request is replayed.

​

4.71.2 — July 17, 2026 at 11:58 AM UTC

• Cross-currency storefront buys now convert both package budget and bid price
• back to the seller’s settlement currency before forwarding to an inventory
• source. This keeps the CPM and resulting delivery goal consistent with the
• booked FX budget.

• ​

  slack

• Cross-currency storefront forwarding now keeps source CPM bids and budgets in
• the same settlement currency, preventing incorrect delivery goals.

​

4.71.0 — July 17, 2026 at 9:46 AM UTC

• Upload CSV, XLS, or XLSX modular avails files directly through the storefront API and receive the same normalized, row-level preview used by structured feed inputs before confirming a commit.
• Storefront media-buy delivery reporting now refreshes reliably instead of being skippable for a full day. When an upstream source hasn’t finalized a day’s delivery at read time, the route is now retried within the hour until the data lands, rather than waiting until the next day. Every delivering media buy is also read twice daily instead of once, so late-finalizing delivery is picked up the same day.
• Meta campaigns created through directed buying now stay paused until they are deliberately activated. Budget changes use the selected Meta account’s currency, unsafe increases are blocked during testing, and canceled campaigns return a complete final state. Nothing to change on your side.
• Connected-platform campaign mirrors now preserve campaigns that a provider omits from broad account listings. Interchange verifies omitted campaigns through bounded, resumable reads before treating absence as authoritative, so provider-canceled campaigns and their package history remain available while incomplete reads retain the last valid mirror. Nothing to change on your side.

​

4.70.1 — July 17, 2026 at 6:00 AM UTC

• Ad-server-backed product updates now preserve canonical AdCP 3.1 format options as URL-free format_kind and params declarations. Full product updates no longer drop these options or reintroduce legacy creative-agent URLs.

• ​

  slack

• Canonical product format options now survive the ESA full-update flow without
• agent URLs. Legacy creative-format references remain available only for
• explicit v1 compatibility.

​

4.70.0 — July 17, 2026 at 4:03 AM UTC

• Talk to Murph with an MP3, WAV, or M4A attachment. Murph can understand the spoken content for the current conversation while keeping the original file available to creative tools. Nothing to change on your side.
• Buyer integrations now receive canonical creative formats without agent URLs. Existing legacy format IDs remain available in their compatibility field, so no buyer changes are required.
• Storefront operators can now retry an approval that was incorrectly marked as forwarded. The recovery option is available only when every source attempt failed before creating an upstream media buy or task.

​

4.69.0 — July 17, 2026 at 3:08 AM UTC

• Buyers can now discover live, account-specific products in their own currency when a seller prices them in another marketplace-supported currency. Nothing needs to change on either side.

​

4.68.0 — July 17, 2026 at 2:18 AM UTC

• Clarified Intelligence Units (IUs) in the glossary and linked the term to current
• plan and billing details.
• The seller-managed campaigns alpha is now available to an expanded social-adapter test cohort. Enrollment exposes account mirroring and delivery reads; it does not subscribe accounts automatically or authorize upstream writes.
• Meta campaign mirrors now use provider-supported account filters and ad review fields, allowing account-wide reconciliation runs to succeed. Nothing changes in existing requests.
• Fixed wholesale pricing CSV uploads in Murph chat that silently failed to resolve when a seller attached the file without narrating it, and fixed the ad-server source id Murph could pick when pointing a wholesale pricing upload at the wrong source.
• Generating creative from an attached image now grounds the draft directly on your upload — no reference-picker detour — and generation on a bring-your-own provider key no longer requires a connected seller storefront. The reference picker opens only when you ask to pull in more library references.
• Customer release messages now preserve every approved update, use clearer customer-facing language, and state whether action is required. Recipient selection remains based on declared audience and feature relationships rather than generated copy.
• Code examples and tables in Murph answers are now easier to scan. Fenced code shows its language and can be copied in one click, while wide tables stay contained within the conversation. Nothing to change on your side.
• Media billing entities can now be managed end-to-end from the tab: set any entity as the org default, or delete one — with the routing consequences stated before you confirm. Also fixes two labels: the entity form’s currency field now reads “Invoice currency” (it previously showed a payout label), and usage cards now show readable feature names instead of raw meter keys.
• Plan & billing no longer shows a “Storefront pricing is unavailable — retry” warning when the viewer simply doesn’t have permission to see plan terms; the retry could never succeed for a permission outcome.
• Reject invalid execution types, source and agent statuses, and protocols in v2 storefront source diagnostics responses.
• Fixed the extra line spacing in your sent chat messages so multi-line inputs read at the same comfortable leading as Murph’s replies.

​

4.67.0 — July 17, 2026 at 12:02 AM UTC

• Murph now completes long multi-part storefront setup answers and uses the exact documented storefront management connector and authentication steps.
• Campaign creatives now include storefrontReviewStatus showing whether a storefront operator has approved, rejected, or is reviewing a creative (pending, approved, rejected, revoked). Null when the storefront uses automatic approval or the creative hasn’t been synced yet.

​

4.66.1 — July 16, 2026 at 10:07 PM UTC

• Media buys routed to a third-party sales agent no longer fail with a false “source unavailable” when the agent is simply slow to respond — the forward timeout now matches the allowance already given to managed sales-agent sources.

​

4.66.0 — July 16, 2026 at 8:57 PM UTC

• Data Delivery documentation now accurately lists GCS, S3, and Azure Blob as the
• supported destinations. Snowflake and Databricks remain unsupported reserved values.
• Buyers can now use seller-managed campaigns with any active storefront. A campaign appears as soon as the seller accepts a create, while account history, delivery reporting, creates, and updates each report their own support and health.

​

4.65.0 — July 16, 2026 at 7:38 PM UTC

• Tightened the buyer navigation rail so section headers sit flush with their rows and the groups share the same even spacing, and made the “add to chat” affordance appear consistently on Catalogs, Conversions, and Activity alongside Campaigns and Creatives. Also fixed assistant chat messages where a standalone year (e.g. “2026.”) was misrendered as a numbered list and where dates could break across lines.
• Buyer and seller account admins now get a diagnostic ID when SSO setup fails,
• and replay-safe setup checks stop after 15 seconds. Retry once if this occurs;
• include the diagnostic ID if you contact support.
• Managed GAM sources now warn when a successful advertiser sync returns zero
• visible advertisers, with guidance to verify the service account’s GAM role and
• team access before refreshing. A successful inventory sync no longer masks
• this separate advertiser-access problem.
• Storefront operators can now see whether each recorded booking is
• Interchange-cleared or seller-cleared on the existing Media Buys page.
• Historical bookings remain clearly marked when their method was not recorded;
• buyers do not see a new seller attribute and cannot choose the method per buy.

​

4.64.0 — July 16, 2026 at 7:15 PM UTC

• Fixed duplicated impressions and spend in reporting metrics for media buys whose delivery was ingested both before and after source attribution was added. Such a buy could have two copies of the same day’s delivery — one unattributed, one source-attributed — and both survived deduplication and were summed, doubling the totals. Reporting now prefers the source-attributed rows for each media buy and day, and keeps the unattributed copy only when no source-attributed row exists. Applies to both buyer and storefront reporting, in summary and daily timeseries views.
• Organization administrators can schedule a paid storefront plan to end at its
• term boundary and see the exact timestamp the storefront becomes Free. They
• can reinstate automatic renewal before the governing cutoff if the plan can
• renew on the same terms. Every decision remains in renewal history.
• Buyer impact is not applicable to this launch. Buyer pricing and workflows,
• storefront ranking and rendering, and inventory availability do not change. At
• term end, only the seller’s commercial plan state becomes Free; this release
• does not add or change Free-plan entitlement or pass-through enforcement.

​

4.62.0 — July 16, 2026 at 5:14 PM UTC

• Fix delivery reporting dropping metrics on single-day reports. When a delivery report covers a single day, its reporting rows now read from the report’s root totals and per-package totals (which carry the full metric set, e.g. completed views) instead of the daily-breakdown entry, which a source may leave sparse. Multi-day reports are unchanged. Single-day rows are still stamped at the real delivery day, so this does not affect deduplication.
• The “Add a card” option now appears for organizations that already have a credit line or funded balance — a card can be added alongside existing funding.
• Campaign media-buy status now continues to show completed and other terminal buys after background polling finishes, instead of incorrectly reporting that the campaign has no media buys.
• Settings danger zone now shows buyer-appropriate content. Previously, buyers in the Settings modal saw a seller-scoped archive control; they now see a correctly labeled disabled archive option with buyer-specific copy across all supported locales.
• get_media_buy_status now reports source_rejected_creatives as a pendingReason when all assigned creatives have been rejected by the source. Buyers can see this in one call instead of investigating separately why a buy is stuck. Not applicable to sellers — this surfaces seller-originated rejection verdicts to buyers; no seller behavior changes.
• Campaign creatives now include a sourceSyncStatus field showing whether each creative was approved, rejected, or is pending review at each source, with the verbatim rejection reason when rejected.
• Nav avatar now shows two initials (first + last) instead of a single letter. Settings rail groups user-scoped settings (Murph preferences, Notifications) under “Your preferences” separate from account-scoped settings. Murph room share is now a single popover that keeps visibility toggling and link copying as separate, non-entangled actions. Both buyers and sellers see these improvements across the shared navigation and settings surfaces.

​

4.61.0 — July 16, 2026 at 2:55 PM UTC

• The buyer navigation rail now groups sections into two categories: Discover (Marketplace, Activity) and Manage (Campaigns, Creatives, Catalogs, Conversions, Reporting). The advertiser selector is always visible at the top of the rail. When no advertiser is selected, Manage sections show a prompt to select one.
• Campaigns list widget now uses a chip-filter and card-stack layout instead of a data table, matching the 360px chat surface target. Status filter chips (All, Active, Paused, Draft, Completed, Archived) narrow the list in place. Each campaign card shows the campaign name, status, flight dates, budget, spend, and a pacing bar.
• Adds the reversible operating contract for one-storefront modular inventory
• source pilots and clarifies that removing pilot access preserves held and
• booked capacity, open human work, and pending reporting until their normal
• lifecycle actions resolve them.
• Correct storefront approval webhooks to use the canonical AdCP media-buy task protocol and validate every task payload against the SDK wire schema before delivery.
• Fixed a bug where background polling for async get_products responses sent the wrong task ID to the seller. When a seller wraps a get_products call as an async task, the background poller was using an internal SDK correlation UUID instead of the seller’s actual task ID (e.g. tsk_get_products_...), causing all poll attempts to fail with the seller reporting unknown task IDs.
• Fixed update_campaign rejecting media-buy bid-price changes with an opaque “Invalid input” error. The per-package and per-product update fields now use camelCase — bidPrice, productId, pricingOptionId — matching the casing campaign reads return and the rest of the buyer API, instead of the snake_case (bid_price, product_id, pricing_option_id) the update schema previously required. This removes the read/write casing mismatch that let a budget-only update succeed while an otherwise-identical bid-price update failed. Callers sending the old snake_case names on mediaBuys[].packages[] or mediaBuys[].products[] must switch to the camelCase field names.
• Feed-backed modular campaigns now preserve their booked package rate when discovery supplies the catalog’s camelCase pricing shape or omits an unambiguous single-option pricing ID, so final delivery can enter reporting without a pricing error.
• Modular storefront reports now include the booked package pricing required by report processing, and completed route status reaches the buyer media buy promptly instead of waiting for the hourly reconciliation sweep. Nothing to change on your side.
• Plan & billing gains a Media billing tab: define the legal entities Scope3 invoices for media spend, attach them to advertisers or accounts, and ask “who gets this invoice?” for any advertiser — the resolution chain shows exactly why.
• Modular avails previews now keep valid rows visible while reporting rejected rows and normalization warnings with stable row-level diagnostic codes.
• Sellers can now use Activity to inspect their storefront’s tenant-scoped API calls, open safe call detail, and compare those calls with storefront Changes. Buyers keep the same Calls workflow with buyer-specific Changes, now on the shared Activity contract used by portable MCP hosts.
• API Activity remains included in the beta at no incremental charge.
• Murph now uses conversation and connected-room context to resolve informal company and product names before concluding they are unknown, and asks with concrete candidates when the meaning remains ambiguous. Scope3 internal admin and staff operations also stay out of customer-visible Activity history.
• Explain how to choose the supply setup behind a storefront and what sellers need to prepare for a modular source.

​

4.60.0 — July 16, 2026 at 10:13 AM UTC

• Help and support links are now in the ”?” header menu (no longer buried in the sidebar footer), the Activity tab is always visible in the sidebar without needing to select an advertiser first, and AI usage and Danger zone sections are now available in buyer settings.
• Fixed several visual bugs in buyer and seller widgets found during the 360px parity audit: campaigns widget is now readable in dark mode (hardcoded white backgrounds replaced with theme tokens); media-buy and creative names in the campaign detail wrap to two lines instead of truncating; buyer widgets (reporting metrics, creative intent, reference picker, catalog mapping, event sources) no longer overflow the 360px width target; stat label acronyms (CTR, CPM, etc.) now render in correct uppercase; meta-line items in the seller media-buys list are separated by visible dots.
• Fixed ESA storefronts rejecting HTML creative format IDs. HTML creatives with detected dimensions (e.g. 728x90 banners) were assigned legacy fixed-size format IDs that the ESA validator rejects. Canonical parameterized refs are now produced at creative creation time and translated at the forward boundary.
• Media buys with inline creatives that don’t match a product’s format now forward to pending_creatives instead of failing with an error. Assign a compatible creative to complete the buy.
• Generative creative now grounds on the references you pick in the reference picker. Library assets and past creatives you select are passed to the model as style references — matching their look, color, and treatment — instead of being noted but ignored. A locked product you add alongside is preserved as a product reference, and references you add mid-session while refining are picked up too. Previously these selections reached the session but never the generator, so output could come back off-brand.
• Organizations can now define media billing entities — the legal entities Scope3 invoices for media spend. Most specific wins: an advertiser’s entity beats its account’s, which beats the organization default. The /resolve endpoint answers “who gets this invoice” for any advertiser or account. No entity is created automatically — add your organization’s first one to start routing.

​

4.59.0 — July 16, 2026 at 1:21 AM UTC

• Ask Murph to put your logo on a generated creative and it now sources the logo straight from your brand — no more being asked for a logo URL you don’t have. If your brand has no logo on file, the creative is generated without one rather than stalling.
• Generative creative sessions now flag when the number of concepts you get back
• doesn’t match the number you asked for. If the generator returns fewer (a draft
• failed) or more directions than requested, the session carries a clear notice
• alongside the drafts instead of silently dropping or adding them — and the
• plan’s reported concept count reflects what was actually requested.
• Buyer Activity links now stay on Activity instead of reloading into an empty Murph conversation. Calls and their debugging details remain available in place, with nothing to change for API integrations.
• Buyer reporting now labels spend, eCPM, and CPC with their actual currency across the dashboard, in-chat reporting, time-series responses, and CSV exports. Mixed-currency time-series totals leave money blank instead of adding unlike currencies, and summary requests fail rather than relabel unconverted spend when no FX rate exists. Modular storefront final reports also enter buyer reporting when they include reconciled per-day delivery and an explicit currency. The new CSV currency field is appended so existing column positions do not move. Nothing to change on your side.
• External AdCP buyers can now update or cancel an endpoint-directed campaign through
• the addressed storefront while Interchange preserves governance caps, durable
• idempotency evidence, SCD2 budget lineage, dual-key identity, dark usage metering, and
• campaign commitment reconciliation.
• After you pick a creative direction and it builds across your placements, you can now go back to the directions and switch to a different one without starting over. A ”← Back to directions” control returns you to the picker with your current direction highlighted and the other already-generated directions still one click away — no re-running a fresh set of generations.
• You can now pick a draft creative direction just by naming it in chat — “let’s use the zine/DIY one”, “go with the surreal option”, or “direction 3” all fan out that direction’s placements. Previously only the “Use this direction” button worked; typing the choice made Murph ask you to copy a session ID and variant ID off the card.
• When you tune a generated creative across placements, each preview now shows at its real shape — a leaderboard reads wide-and-short, a half-page tall-and-narrow — instead of every placement rendering as the same uniform box. The tiles pack into a masonry grid and keep their pixel-dimension label, so a 728×90 is instantly distinguishable from a 300×600 while you decide which ones to keep.
• The reference picker now always shows all three source tabs — Sourced materials, Past creatives, and Catalog — even when a source is empty. Previously the tab bar disappeared whenever only one source had items, collapsing the picker to a single flat list and hiding the fact that references can come from any of the three. Empty tabs now carry a proper empty state (attach assets, connect catalog) so you always see every source and how to fill it. The item list is also capped and scrolls, so the picker no longer grows unbounded on large libraries.
• Wide and tall placements now generate at their real shape. When a required placement has an extreme aspect ratio — a leaderboard banner or a skyscraper — and your OpenAI-connected session would otherwise crop it to fit, the render is routed to a connected generator that composes that shape natively (Gemini or FAL). It runs on your own connected key for that provider and is billed to that vendor account, the same as any generation on it. If you haven’t connected a native-ratio generator, the placement still renders on your session provider with a heads-up that it may crop — nothing changes for you until you connect one.
• Starting a generative creative session without naming a concept count now generates three draft directions by default, instead of a single draft. Give a number to get exactly that many; ask for one and you still get one. Behind the buyer-creative-v2 + buyer-generative-creative flags.

​

4.58.0 — July 15, 2026 at 11:13 PM UTC

• Generated creative now reflects your brand — colors, tone, and tagline from your brand profile reach the image generator on every render, including after you pick a direction and fan out to placements. Previously the brand reference was dropped when a creative session was saved, so reloaded refine and placement renders generated from the brief alone and ignored the brand.

​

4.57.0 — July 15, 2026 at 10:35 PM UTC

• No action is needed: this release does not publish a paid storefront Rate Card,
• move any storefront to a paid plan, start storefront-plan charges, or change
• buyer pricing. A new-storefront signup can review Free or paid choices once an
• effective Rate Card is separately published. An authorized administrator of an
• existing storefront instead uses Plan & Billing to review the exact version,
• corporate discount, prices, setup grant, committed-IU rollover policy, and term
• before accepting; the page also shows current Free or paid status and immutable
• plan history.
• Buyer Catalogs widget: uploaded (file-based) feeds now show a Reupload action instead of a disabled “Sync now” — syncing only applies to hosted URL feeds — and their status reads “Uploaded” rather than “Synced”. The activation action is now “Save plan” (it persists the activation plan; live execution across campaigns, syndication, and creative is not yet available), and the plan preview no longer advertises a creative-asset count — catalog-driven creative generation stays gated until brand identity and per-format output are in place.
• Storefront operators can now upload their wholesale pricing feed for ad-server-backed inventory sources directly in Murph chat, with a full preview of accepted and rejected rows before anything is committed.
• Managed ad-server sources on adapters without an automatic pricing sync (today, everything except Google Ad Manager) no longer show a false “degraded / contact support” pricing status or retry a sync that cannot run. Instead the source stays healthy and surfaces an actionable prompt to upload wholesale pricing, which is how these sources are priced today.
• Fixed the Campaigns widget lingering in a chat it wasn’t opened in. Opening a recent chat now clears any Campaigns widget from the previous view, so widgets only appear where they belong.
• Creative library and reference-picker widgets now show each image creative’s thumbnail. Uploaded and generated image creatives previously fell back to a generic format-type icon because a preview was only derived from a processed-HTML asset; the creative’s own image is now used when no HTML preview exists.
• Fix: when you upload creative into chat and Murph asks which campaign to attach it to, answering in a later message now attaches the files you already uploaded — instead of Murph saying it can’t see any files and asking you to re-attach them.
• Fix duplicate Slack approval callbacks so one click cannot both file a request and ask for approval again, and give request-tracking guidance that matches the current chat host.
• Generative creative now grounds on your actual inputs and lets you choose a direction before it builds. When you generate creative, Murph presents a few on-brief concept directions to pick from (instead of auto-selecting one), and the direction you pick is rendered across every placement — carrying that concept, your brief, and your uploaded reference images through to each render. Uploaded references now also carry across turns, and placement renders generate in parallel so results come back faster.
• Buyers enrolled in directed campaigns can now send a buy to any active storefront
• while Interchange keeps the campaign, contract, billing context, and delivery
• reporting around that seller-managed buy. Campaign responses identify whether
• execution uses a connected account or the storefront endpoint.
• Fixed under-booking of realized media spend on storefront buys fulfilled by more than one seller. Each seller’s delivery is now recorded as its own ledger entry, so a buy’s booked spend is the sum of every seller’s realized media instead of collapsing to a single seller’s figure. Buys served by a single seller and buyer-direct buys are unaffected. In-flight multi-seller buys are corrected automatically as their deliveries next report.
• When you tell Murph which references to ground a generated creative on (“use the ones I just uploaded”, or name specific creatives), the reference picker now opens with those already checked. Murph passes the named creative ids to the picker, which pre-selects them on the matching tab — you confirm or adjust instead of re-finding and re-selecting them, which matters as your library grows.
• Slack Product Updates now include an Unsubscribe button. Use it to stop future Product Updates in that channel without changing your account’s release history or other connected channels.
• Campaigns created by an external AdCP buyer through one storefront now report
• mode: directed, matching the storefront-managed execution model. Inbound direction
• remains provenance and does not create a separate campaign mode.
• Re-adding an event source that was previously removed via sync_event_sources with delete_missing now restores it instead of failing with a duplicate-identifier error. The revived source keeps its identity and any sales-agent syndication links; its configuration comes from the re-add payload, and its ingestion health resets to not_seen until new events arrive.
• Choose whether source outage alerts appear in your primary Slack channel and how long an outage must last before an alert is sent: 10, 30, or 60 minutes. Use the buttons on an alert or ask Murph to change the setting. Immediate in-app and email health notifications remain on.

​

4.56.0 — July 15, 2026 at 3:55 PM UTC

• When adding your first child account triggers an automatic account structure change, you now see a notification explaining that your billing and contracts have moved to the new parent account.
• Sales Agent Diagnostics can now run its no-spend discovery test, refresh capabilities, and reload durable test results from the in-product widget. Run discovery test now reaches the selected external sales agent instead of returning “MCP app tool call denied,” while capability refresh and prior diagnostic results use the same tightly scoped widget bridge.
• Registering event sources now returns setup guidance in the sync response. Each live source (created, updated, or unchanged) includes a setup object with snippet_type and instructions, so the same call that registers a source also tells you where to send its events. Interchange ingests events server-to-server via log_event, so snippet_type is server_only and no client-side tag is returned; instructions names the ingestion endpoint and links the setup guide. Failed and deleted results omit setup.
• Generated creative renders now crop toward the most visually salient part of the image when a placement’s shape forces a crop (for example a wide leaderboard or tall skyscraper). Previously the render was cropped to the dead center, which could cut the subject in half; it now keeps the region most likely to hold your subject.
• Media buys no longer fail to forward when assigned creatives are format-incompatible with the selected products. The buy forwards with the compatible subset (or an empty set when none match), and every dropped creative is reported with its creative ID, format ID, and the reason it was excluded.
• Buyers can now ask Murph a plain question such as “Is OptOut available?” from
• any Slack channel. Murph answers from the public listing without requiring a
• connected account or an exact domain. When signed in, buyers can also search by
• the seller or company name they already know.
• For agency teams working in a buyer–seller deal room, a Scope3-declared shared
• channel now keeps that seller visible automatically in the buyer’s **Supply I
• would buy** view.
• For sellers, a clear marketplace-listed brand, storefront name, and domain now
• make the storefront easier for buyers to find and track. Keep that public
• identity current; buyer identity remains private, and no seller action is
• needed unless the listing itself needs an update.
• Only human-reviewed listed storefronts can appear in public answers, and
• relationship tracking begins only after a Scope3 admin declares the
• buyer–seller channel shared.

​

4.55.0 — July 15, 2026 at 1:24 PM UTC

• You can now declare, update, and remove the publisher domains your storefront covers directly from your agent using storefront_api_call. The four operations — list_publisher_domains, add_publisher_domain, replace_publisher_domains, and delete_publisher_domain — were previously unreachable through the agentic dispatch layer. Declared domains go through adagents.json verification; authorized domains appear on your buyer-visible storefront profile and count toward the verified domain total buyers see when evaluating reach.
• The organization admin page no longer shows its own Billing tab — billing lives on Plan & billing, and old links to the admin billing tab forward there automatically.
• External agents can now self-register with Interchange using WorkOS credentials. A new endpoint — POST /api/v2/agent-registrations — lets any agent discover, register, and obtain a credential without Scope3 involvement. Registered agents are provisioned into an UNBOUND sandbox environment with endpoint and spend limits until they are verified and promoted.
• Save a card once on Plan & Billing and paid features turn on right away, with nothing charged until your first billing cycle — no invoicing setup required.
• Sellers can now test a connected sales agent’s product discovery directly, see exactly which operations passed or failed, and open the supporting request, response, and trace evidence. The test creates no media buy and spends nothing. Diagnostics also distinguishes a source failure from a storefront composition attempt that stopped before the source was called.
• Third-party sales agents start in finished-product pass-through, so they do not need ingredients. Interchange composition remains a separately provisioned paid add-on and uses only wholesale products the source advertises through AdCP 3.1 or later. Active managed ad-server sources continue to require composition.
• Buyer impact: none. This release does not change buyer protocol behavior or existing product results; it makes the seller’s operating mode and failure evidence explicit.
• Packaging: source diagnostics and the no-spend discovery test are included for sellers at no additional charge. Product composition remains separately packaged.
• Rollout: this is an ungated atomic launch for authenticated storefront operators. Rollback removes the diagnostics launcher and direct-test route without changing buying or selling configuration; disabling the registered launcher is the kill switch.
• Measurement: adoption is the first successful open_source_diagnostics call per storefront. Usage is a run_inventory_source_discovery_test result, segmented by passed, empty, failed, and not reached. Initial acceptance is that every direct test records one durable result and exposes available trace identifiers.
• Existing v2 campaign calls keep their current behavior. Enrolled alpha buyers can connect and subscribe an account with a registered AdCP sales agent, then see its seller-managed campaigns in the same campaign list as their other activity. The mirror is read-only by default; separately approved accounts can create and update those media buys through the same campaign API.
• Embedded sales agents are on v1.25.1. The ESA now strict-validates every inbound creative-format reference at the request boundary: legacy string ids, fixed-size ids like display_300x250, and malformed references are rejected with a descriptive error that names the offending reference and suggests the canonical replacement — completing the canonical format contract’s enforcement half, so a bad reference can no longer slip in and surface later as a mismatched creative. Also included: GAM order-approval permission errors now correctly mark the order pending approval instead of failing the buy, guaranteed impression goals in size auctions are sized off the buyer’s bid rather than the list rate, embedded principals no longer receive fabricated placeholder GAM advertiser ids, and HTML/JS tag creatives now sync without requiring a preview URL. Buyer-visible surfaces are unaffected: buyers see the same product format references and media-buy responses as before; only the seller-side validation and GAM trafficking internals changed.
• Asking Murph to open billing now lands on the Plan & billing page — the same billing home as everywhere else — instead of the retired settings view.
• Murph now gives Slack users a secure, source-focused link to Sales Agent Diagnostics instead of implying that Slack opened an unsupported inline app.
• Failed Murph sandbox tests now open diagnostics on the exact recorded run, with an Open diagnostics handoff in Slack.
• Buyer teams enrolled in the Activity Console beta can now review Calls and Changes inside MCP clients that support MCP Apps. They can filter captured API calls, inspect redacted request fields and available response or error details, and send a selected activity ID to Murph for debugging without leaving the conversation. Existing integrations do not need to change.
• Navigating in a tab opened before a deploy no longer breaks with “Something went wrong” — the app reloads itself once to pick up the new version.
• Failed GAM order cleanup now appears in seller Pending Operations. Sellers get guided permission, reconnect, safe-archive, and manual-cleanup paths when GAM creates an order but trafficking fails; buyers do not get a new action or status change from this release.
• Choosing Billing in settings now takes you straight to Plan & billing — the intermediate summary page with its extra “Manage billing” hop is gone.

​

4.54.1 — July 15, 2026 at 10:02 AM UTC

• Murph now completes sandbox campaign checks reliably, keeps package CPMs separate from campaign-budget currency, and uses the connected account’s buyer or storefront role in Slack.

​

4.54.0 — July 15, 2026 at 8:58 AM UTC

• Org API keys for automation: create scoped API keys for your organization to authenticate programmatic workflows against the Buyer API. Keys carry exactly the permissions you choose at creation (buyer:read, buyer:write, buyer:admin, or account:admin) and work anywhere a bearer token is accepted.
• Manage keys via GET/POST/DELETE /api/v2/org-api-keys, or embed the WorkOS API Keys widget in your own UI using GET /api/v2/org-api-keys/widget-token. Org API key management requires buyer:admin. Included in existing Buyer API access, no separate entitlement needed.
• Seller impact: none. Org API keys are a buyer authentication mechanism only. An automated workflow using an org API key carries the same buyer permissions (buyer:read/write/admin, account:admin) as the human who created the key — no new access to seller surfaces is granted, and sellers see no change in how buyer requests arrive or what they can request.
• Monetization: included in existing Buyer API access. No new billing surface.
• Adoption metric: org API key creation rate (POST /api/v2/org-api-keys calls) tracked via API metrics within 30 days of release.
• Kill switch: revoke individual keys via DELETE /api/v2/org-api-keys/:id or bulk-revoke via the WorkOS dashboard. WorkOS D4 permission registration also gates feature availability at the infrastructure level.
• Expansion: GA at merge for all buyers. Requires WorkOS D4 permissions (buyer:read/write/admin, account:admin) registered in the WorkOS dashboard before creation calls succeed in production. Staged rollout not needed — the feature is additive and does not change existing auth flows.
• Buyer Activity now captures authenticated MCP calls durably before execution.
• Failed tool results, including isError: true responses transported over HTTP
• 200, include schema-declared redacted arguments, typed result detail, workload
• identity, and copyable activity correlation for debugging in Activity or with
• Murph. MCP protocol traffic remains separately classified and does not inflate
• customer activity.
• External AdCP buyers can create a governed Interchange campaign through an enrolled storefront while the seller remains behind the standard AdCP interface.
• The alpha pins zero-fee buyer-edge entitlement terms, enforces buyer/storefront budget caps, journals idempotent writes, preserves buyer and seller media-buy identities, records campaign commitments and delivery usage, and reads delivery through to managed seller agents.

​

4.53.0 — July 15, 2026 at 4:20 AM UTC

• The V2 billing API now provides a version-locked contract for storefront plan
• selection. Once pricing is published, administrators will see the exact Rate
• Card revision, eligible plans, corporate discount, governing agreement, and
• final price before accepting. Any term change requires a fresh review.
• No storefront Rate Card is published yet. Storefront operators do not need to
• act, no account can move to a paid plan or incur a new charge, and buyer pricing
• and behavior are unchanged.

​

4.52.0 — July 15, 2026 at 3:32 AM UTC

• Buyer teams enrolled in the Activity Console beta can now inspect safe,
• schema-validated request JSON, public error responses, selected non-secret
• headers, and validation steps for an API call. Call detail also links directly
• to Murph for evidence-based troubleshooting without exposing credentials, raw
• headers, invalid raw fields, or internal stack traces.
• Diagnostic detail expires after 90 days while slim call metadata remains
• available for 13 months.
• Scope3 support receives the same retained safe REST detail in the cross-tenant
• admin console, plus customer-visible call volume, problem-rate, latency
• percentiles, incomplete-call counts, and top operation/error metadata. Internal,
• protocol, and diagnostic reads are excluded from customer-activity engagement
• rollups so opening Activity or asking Murph does not manufacture API usage.
• Refining a generated creative by typing feedback in chat now works right after the session renders — Murph no longer asks for the session or variant id. The active session carries forward automatically, the same way the widget’s own refine button already did.
• Parent organizations whose storefronts live in child accounts now see the Payouts tab on Plan & billing — capability is derived from the whole organization, not just the parent’s own roles.
• Refining generated creative is now per-placement isolated: add a note to a placement to regenerate only that one from the hero, and leave a placement alone to keep it exactly as-is (never regenerated, never dropped). “Add to campaign” is always available and commits whatever is currently shown. The per-placement “Looks good” toggle and the approve-all gate are gone. Behind the buyer-creative-v2 + buyer-generative-creative flags.
• Generated creative is now produced per campaign placement: the chosen direction is rendered at each required size — grounded on one hero image for a consistent look — so the generation-refine grid shows a tile per placement instead of a single format. Behind the buyer-creative-v2 + buyer-generative-creative flags.

​

4.51.0 — July 14, 2026 at 10:52 PM UTC

• Customer backend services can now authenticate to the Interchange API using WorkOS M2M tokens (client_credentials grant) instead of long-lived API keys. Tokens are short-lived, automatically expire, and support rotation and immediate revocation without service downtime or redeployment.
• Fix a bug where a seller feed reporting a fractional delivery metric (e.g. impressions: 1346.5) caused the whole package/media-buy delivery-metrics batch update to fail with a Postgres bigint syntax error, silently blocking delivery-metric updates for unrelated healthy packages in the same batch. Fractional counts are now rounded to the nearest integer before being written.
• Seller accounts now receive their storefront reliably across signup and admin provisioning, while automatic reconciliation repairs older accounts that were created without one. The Business profile page also provides an onboarding action instead of a load error while recovery completes.
• Murph’s generative creative flow is more reliable and more conversational. Opting into references now consistently opens the reference picker to choose from — Murph no longer sometimes grounds silently and narrates it in prose instead. And Murph’s messages through the flow stay short and chat-first, letting the widgets carry the session, variants, and next steps rather than restating them as a numbered status report. Behind the buyer-creative-v2 + buyer-generative-creative flags.
• Plan & billing is now the one home for your organization’s money. Plan & pricing gains a “How you’re charged” card that states your pricing model plainly — % of media rates, plan terms, or both. Payment & invoices separates what you pay us from what you pay for media: Interchange fees (your plan) and media billing (the media itself). The old billing locations in organization settings and account settings redirect here.
• Payout activity now shows setup history: when payout details were changed and by whom, so finance teams can verify bank-detail changes without contacting support.
• Payouts now live inside Plan & billing as their own tab — payout entities, the setup wizard, and payout activity in the same place as the rest of your billing, no more jumping to a separate settings page.
• You can now navigate back from the Plan & billing page, and the Payouts setup card states when payout runs happen (monthly, at month-end close).
• Explicit storefront refreshes now sync every enabled catalog stream, including pricing availability and signal coverage, while routine inventory polling stays lightweight. Existing in-progress syncs are reused safely, and no force-recovery credentials are needed.
• Reporting for a storefront media buy that fans out to multiple upstream sellers now sums delivery across every seller instead of showing only one. Each seller’s leg is tracked by its source, so GET /api/v2/buyer/reporting/metrics and GET /api/v2/storefront/reporting/metrics report the full buy total (and correct per-package figures) rather than collapsing to a single leg. Single-seller buys are unaffected.

​

4.50.0 — July 14, 2026 at 5:12 PM UTC

• Catalogs now has its own place in the buyer chat rail: open it to see your catalog feeds — health, sync status, and item counts — right in the conversation, drill into a feed for its detail, and sync, preview, or run its activation plan without leaving chat. Data sources is now Conversions only, so connecting event sources gets its own focused view too. You can also just ask Murph to open your catalogs.
• The creative confirmation card now flags any brought creative whose format no product on the campaign accepts — the mismatch shows directly on that creative with the accepted formats, instead of the creative looking mapped and being silently dropped at execute. The check re-derives as products and placements change, so it appears or clears on its own. An incompatible creative offers only Remove (no “map it anyway” placement picker, since nothing would take it), and Remove now takes the creative off the campaign in place, without a chat round-trip.
• The deprecated brand_agent_id response field on creative manifests and creative collections has been removed. Integrations should read advertiser_id, which carries the same advertiser identifier. The field was deprecated and announced in the prior release; the affected surface is flag-gated to pilot customers. Targets API-integrating buyer personas (scrappy builder, large agency); no seller-visible surface changes, so the seller pass is explicitly not applicable.
• Fixed a crash that could occur when attaching a creative asset supplied as an inline (data URL) value without an explicit content type. Very large values could previously fail the request; they are now processed reliably.
• Seller agents now receive a time_budget in real-time discovery requests that accurately reflects how long they have to respond. Previously the budget was stamped before an internal account synchronization step (up to 5 seconds) and did not subtract the 2-second fallback reserve, so the advertised budget was up to 7 seconds larger than the actual timeout. Agents that responded near the stated deadline would be cut off early.
• Murph now keeps creative uploads in the in-chat creative flow instead of sending you out to the Creative Assets dashboard. Bringing, attaching, mapping, or reviewing creatives happens on the in-chat card, which owns advertiser, campaign, and placement selection. A dashboard link is only offered when you explicitly ask for it, or for files larger than 50 MB where VAST/webhook or a public CDN link is the right path.
• The “Needs attention” card in the seller dashboard now explains how to use the trace ID to investigate failing calls: it is sent as the x-scope3-debug-id HTTP header on every request to your agent, so you can search your own logs for it. The card also includes a copy button for the trace ID and clearer next-step guidance for timeout and failure cases.
• When grounding a Murph creative generation on references, an advertiser with no references yet now sees the reference picker in an empty state — with an “Attach assets” affordance and a generate-without-references action — instead of a plain-text “library is empty” fallback. Buyers can add references from zero. Behind the buyer-creative-v2 + buyer-generative-creative flags.
• Ad-server-backed storefronts now preserve eligible ad-server pricing and use uploaded wholesale pricing only for individual products that still need a price. Products without usable pricing stay out of buyer catalogs until separate pricing is provided.

​

4.49.0 — July 14, 2026 at 2:31 PM UTC

• Realized delivered spend now books correctly even when its campaign was archived after the delivery occurred. Previously, archiving a campaign while a media buy still had delivery reports in flight left that spend unbooked, understating buyer balances, seller payables, and fee revenue until it was manually reconciled. The spend-booking resolver now treats an archived campaign as a valid provenance and advertiser source (preferring a live campaign when one exists) instead of refusing to book.
• Buyer teams enrolled in the Activity Console beta can now inspect authenticated
• API calls by workload, operation, outcome, latency, and public correlation ID.
• The Calls view and activity endpoints make agent behavior and failures traceable
• without exposing request payloads or credentials.
• Creative update responses now include a warnings field when the assigned format_id does not match any format accepted by the campaign’s products. Executing a media buy now returns a clear error if no assigned creatives match the product’s accepted formats, or if no video creative satisfies the product’s required duration. Previously these mismatches were silent or surfaced only at the publisher side.
• Google Drive file imports now open directly from Murph and creative uploads. Choose files each time without managing a separate Google Drive connection.
• AAO compliance tracks that have some passing scenarios alongside coverage gaps now correctly display as partial or passing instead of “no coverage”. This fixes storefront compliance checks showing “no coverage” for tracks where the agent did respond and some scenarios ran, matching what AAO’s own compliance summary reports.
• TikTok directed campaigns now validate package geography before dispatch and create ad groups with explicit TikTok placement, avoiding provider-side cleanup after an invalid automatic-placement request.
• FX-terminated media buys now surface a specific error code (fx_snapshot_missing or fx_quote_expired) in the pending-operations view instead of unknown_failure.
• When helping sellers fix their adagents.json, Murph now recommends the correct agent URL for their connection type and accurately describes a missing authorization as an advisory warning (not a blocker), including its effect on buyer-visible coverage disclosure.
• Account admins can now set an org-level default for Murph conversation sharing. New conversations inherit the default when no explicit value is provided. Individual users can still override the default per conversation using the existing sharing toggle.
• Per-route browser tab titles in the buyer app so multiple open tabs are distinguishable.
• Adding a creative labeled video_vast whose asset is a raw video file (for example an .mp4) instead of a real VAST tag now fails immediately, at the point you add it to a media buy, with a clear reason — instead of being accepted and then rejected downstream by the publisher. The message tells you how to fix it: relabel the creative to video_hosted for raw hosted video, or attach a real VAST tag. This closes a gap where such creatives passed our format check and only failed when the buy reached the publisher.
• Canceled directed campaign shells now report CANCELED instead of falling back to DRAFT.
• TikTok directed campaign cancellation now reconciles deletion from either native campaign status field instead of leaving an accepted cancel operation pending.
• TikTok Reach directed campaigns now validate and apply an explicit buyer-selected frequency cap before creating native campaign objects.
• Settings → Plan & Billing now shows your plan, pricing, usage, funded balance, credit line, agreements, and the single next action to stay in good standing — one page, for every organization. Agents get the same data through get_billing_account and open_plan_and_billing.
• Fix media buys failing to forward when the creative uses a base video format (video_standard) but the product only declares a duration-specific variant (video_standard_15s/30s). The correct variant is now matched and sent to the source.
• Directed campaign cancellations now settle when a connected platform omits the deleted campaign from its next complete account snapshot.
• When generating creative in Murph, buyers are now asked whether to ground generation on references from their library — choosing “yes” surfaces the reference picker (which previously could not render inside Murph at all). Also fixes a generation crash on a fresh session with no prior assets. Behind the buyer-creative-v2 + buyer-generative-creative flags.
• Structural media-buy forward failures (for example, a source that cannot traffic the requested creative format) now fail fast with an actionable reason instead of silently retrying for hours. Sellers get a “forward failed — needs correction” signal immediately, pointing at the creative-format or product-catalog mismatch to correct, instead of a buy that quietly never delivers. Buyers see a “needs correction” pending reason rather than an indefinite “retrying” state.
• Added the TMP prebid setup runbook: step-by-step install for the Scope3 module in Prebid.js or Prebid Server (config, credentials, and the auction-timing requirement), the Google Ad Manager half (segment targeting keys, automated line items, the tracker-domain authorization), and how to verify TMP is serving end-to-end — plus a troubleshooting table for the most common silent failures. The TMP overview now links directly to it.

​

4.48.1 — July 13, 2026 at 8:55 PM UTC

• The Approvals widget now keeps approval routing visible when its settings cannot load. Admins can retry the read, while other operators see that a customer admin must manage routing instead of an unexplained blank section.

​

4.48.0 — July 13, 2026 at 6:25 PM UTC

• Buyer API responses now distinguish a stable agent workload from the credential used to authenticate it, giving audit and governance systems a durable identity without changing existing integrations. Seller behavior and seller presentation are unaffected.
• Storefronts now expose their publisher domain lists. Sellers can declare which publisher domains their storefront covers via the REST API; buyers can query the full list, filter storefronts by publisher domain, and see a verified/declared breakdown on storefront detail.
• Buyers can open an in-chat Activity log showing who changed what on their advertisers and campaigns — whether it was a person, the agent, or automation, and whether each action succeeded, was denied, or failed.
• Buyer agents can now call list_storefront_publishers by operation name via api_call to retrieve the full paginated publisher domain list for a storefront. Previously the endpoint was only reachable via raw HTTP; this completes the api_call operation surface for the publisher coverage feature shipped in AI-2796.
• Buyers can now edit an existing campaign creative’s placement mapping directly from the campaign view, and each creative row shows the placements it maps to.
• Creative manifests and collections now return advertiser_id identifying the owning advertiser. The brand_agent_id response field is deprecated — it now only appears on rows created before the advertiser re-key and will be removed after a migration window; switch integrations to advertiser_id.
• The ad-server connection flow now consistently uses Epsilon’s current product name, Epsilon Retail Media, while existing CitrusAd connections and API identifiers remain unchanged.
• Keep the ad server source setup form open after sellers click “Add another ad server,” even when source data refreshes in the background.
• Google Drive file selection now opens in a Google-owned window, so importing creatives and Murph attachments works in browsers that block third-party cookies. Access remains limited to files you explicitly select.
• Buyer agents can connect through MCP 2026-07-28 hosts without changing their
• setup, while existing agent connections continue working unchanged. Storefront
• agents get the same compatibility on the standard storefront MCP endpoint, with
• no change to inventory, media-buy, or authorization behavior. No OAuth
• reconnection or customer action is required.
• You can now rename a Murph chat thread directly from the sidebar. Click the ... menu on any conversation row and choose Rename to give it a name you’ll recognize.
• Optimization suggestions returned by get_optimization_suggestion now include a pacing_recommendation field describing whether a media buy is under- or over-spending and the recommended daily spend to stay on pace. Purely informational — no change to how suggestions are computed or applied.

​

4.47.0 — July 13, 2026 at 2:02 PM UTC

• CitrusAd can now back sponsored-product inventory in seller storefronts. Buyer agents keep using the existing storefront product and media-buy contracts; product metadata identifies CitrusAd as the backing ad server, without requiring a CitrusAd adapter or credentials.
• Buyer-persona applicability: buyer agents encounter CitrusAd inventory through the existing MCP and REST discovery and media-buy operations. Their request shape, authentication, and workflow do not change; only additive product metadata identifies the seller’s backing ad server.
• Monetization: this alpha adds no new buyer fee, seller fee, take rate, or billable usage unit because CitrusAd is another implementation of the existing ad-server-backed storefront capability. Packaging and provider-specific operating costs must be evaluated before any broader paid-tier or GA decision.
• Billing now has a home for payout and invoice activity — new sections at the top of the Payouts and Invoices tabs on your org Billing page, and matching GET /api/v2/billing/payout-activity / GET /api/v2/billing/invoice-activity endpoints (agents: get_payout_activity, get_invoice_activity). The sections are empty until your first payout run or billing period, then populate automatically — no setup needed.
• Murph now correctly scopes campaign reads to the selected advertiser when the chat is opened from an advertiser context. Previously, asking “how are my campaigns performing?” while scoped to a specific advertiser returned campaigns across the entire account.
• Murph now treats ordinary human-to-human Slack replies as ambient channel conversation, even when they include account-specific troubleshooting details, instead of nudging the author to tag Murph.
• Fixed a visual glitch in the Murph sidebar where clicking an existing conversation would jump it to the top of the recents list instead of keeping it in place.
• Buyers can attach selected Google Drive files directly in Murph and request support for OneDrive, Dropbox, or Box from Connections.
• You can now rename a Murph chat thread at any time — the new title replaces the auto-generated one everywhere it appears. If you’re calling the API directly, send PATCH /v2/murph/conversations/:conversationUid/title with { "title": "..." }.
• Automated release notifications to shared customer Slack channels now fail closed: routine release tier or authored Slack copy no longer creates a message, existing machine approvals cannot send, and unresolved targeting is skipped rather than widened. A targeted affected follow-up sends only when its exact message has human approval and a source-backed resolver proves reachable recipients at execute time.
• Optimization suggestions now include campaignExternalId, campaignName, mediaBuyExternalId, and mediaBuyName in the response, enabling downstream enrichment to resolve campaign and media buy details without an extra lookup.
• Your primary payout entity can now receive different currencies into different accounts, like any other entity.

​

4.46.0 — July 13, 2026 at 11:14 AM UTC

• Keep the buyer assistant available when an operation has an unusually large request definition. Large operations remain accessible through the named-operation fallback instead of disabling every assistant action.
• ask_murph responses now include confirmationToken on the pendingConfirmation structured field when an action requires approval. Previously the token was only present in the text answer, requiring clients to parse it from prose. MCP clients can now read structuredContent.pendingConfirmation.confirmationToken directly to get the exact phrase the user must reply with.
• FreeWheel sources now stop retrying unprovisioned reporting or forecasting access and offer a direct re-check after FreeWheel enables the permission.

​

4.45.0 — July 13, 2026 at 9:49 AM UTC

• Separately enrolled directed-campaign customers can list provider products and create or update one seller-managed media buy through the existing campaign API, with durable idempotency, currency-specific budget caps, and upstream reconciliation.
• The AXE setup doc and Murph now teach what the GAM keys are actually for and the required publisher-side install. After Murph clears the “AXE Segment Keys” setup task, it prompts you to confirm the scope3RtdProvider module is installed in your Prebid.js — without it, the GAM keys stay inert and every Scope3-signalled buy misses. The mintlify/v2/storefront/esa/axe-keys doc gains a new “How the keys connect to your ad stack” section (publisher-side RTD writes, ad-server-side reads) plus concrete scope3RtdProvider install guidance and an explicit note that Prebid Server support isn’t complete yet (naming disagreement + missing exclude signal, tracked internally). Two new troubleshooting entries cover “task cleared but no Scope3 targeting is happening” and “I run Prebid Server.”
• Source diagnostics now open from the source you are looking at instead of a standing Diagnostics entry in the seller navigation rail. The ad-server and sales-agent source view gains an “Open full diagnostics” button that opens diagnostics scoped to the selected connection, asking Murph about a named source opens diagnostics focused on that source, and the pending-operations view (GET /api/v2/storefront/pending-operations) gains a sourceDegradations group listing seller-owned degraded sources with severity and a one-line summary — issues Scope3 or a vendor must fix never appear as your task.
• TikTok directed campaigns now validate package geography before dispatch and create ad groups with explicit TikTok placement, avoiding provider-side cleanup after an invalid automatic-placement request.
• The api_call MCP tool (buyer and storefront) now requires a named operation. Raw method + endpoint calls are rejected with a self-healing error that points agents at the operation catalog. Named operations carry validated schemas — the tool derives the HTTP method and endpoint for you and rejects misplaced path params up front — so agents stop guessing URLs and request shapes. Every raw call we observed was either a read that already has a named operation or a hallucinated URL; if you were still sending method+endpoint, switch to the matching operation (use ask_about_capability to find it by intent).
• Murph shared links now open in a new browser tab so customers can keep the chat visible while reviewing linked content.
• Fix the Plan & Billing page failing to open in Murph chat with “MCP app failed to load.” The plan-billing widget was registered everywhere server-side but was missing from the chat client’s widget registry, so the widget directive couldn’t resolve to its resource. Registering it lets the Plan & Billing widget mount and hydrate in chat.
• FreeWheel sources now remember missing reporting or forecasting permissions, stop retrying that capability, and resume it after an explicit permission re-check.

​

4.44.0 — July 12, 2026 at 6:46 PM UTC

• Enrolled buyers can subscribe a connected ad-platform account and see its campaigns in Interchange as read-only directed-campaign mirrors, with up to a year of campaign metadata and delivery read through live from the source.
• Managed storefronts can assign one approval owner, choose an optional escalation audience, and use Murph’s guided setup without broadcasting approval work account-wide.
• Inventory source health is now diagnosed per-capability instead of as one
• combined status. A missing ad-server reporting permission (for example a
• FreeWheel reporting-scope denial) now shows as its own “reporting access
• missing” item — with the exact permission to grant — instead of a generic
• “reconnect your ad server” and no longer blocks selling or setup while
• inventory keeps syncing fine.
• Setup surfaces now tell you when your ad server has no products published yet, instead of showing a confusing cache warning. A connected ad server whose syncs succeed but return zero products gets a clear, actionable diagnosis — “No products are published for your ad server yet, so buyers can’t transact — build products to go live” — with a Build products action and a troubleshooting guide, and you’re notified when it appears. Stale-catalog warnings now appear only when a refresh can actually fix them.
• Media-buy version history now rejects any write that would leave a non-empty buy lineage without a current version, preventing buys from silently disappearing after an incomplete transition or direct database edit.
• You can now go from a feature announcement straight to its guide, product surface, or an authored guided lesson.
• Storefront source health now recognizes current manually uploaded wholesale pricing without asking sellers to reconnect an unused ad-server pricing integration. Sandbox source tests can create their canonical no-spend account even when other sandbox accounts already exist, and storefront readiness now recommends assigning a dedicated sandbox advertiser or granting Interchange permission to create one before smoke testing.
• Media-buy version reads now preserve async-accepted buys, mutations target exact version rows, transitions serialize by tenant lineage, and integrity ambiguity is monitored and handled safely.
• Agents can now read your plan, usage, balance, and agreements — and open a Plan & Billing view in chat — via two new MCP tools, open_plan_and_billing and get_billing_account.
• Media-buy updates now keep the correct current version through approvals, cancellations, and archive transitions, preventing buys from disappearing or selecting an in-flight update.
• The storefront API reference now documents PATCH /api/v2/storefront (updateStorefrontCapabilities), which patches individual storefront capability flags. The endpoint was live and served correctly, but a code-generation path collision left it out of the published OpenAPI spec.
• Creating or updating a performance campaign now rejects an optimization goal whose eventSources[].eventSourceId does not resolve to a live event source on the advertiser, and the error names the offending id. Previously a dangling reference was stored as-is and the goal silently received no conversions. The check is advertiser-scoped, so a source from another account can never satisfy a reference. On update it is delta-validated: only references you add or change are checked, so edits to campaigns that already carry a legacy reference are not blocked.

​

4.43.2 — July 12, 2026 at 3:49 AM UTC

• Hide unpriced source products from buyer discovery instead of returning an invalid wholesale catalog.

​

4.43.1 — July 12, 2026 at 2:57 AM UTC

• Refresh storefront products automatically after wholesale pricing is uploaded.

​

4.43.0 — July 12, 2026 at 1:45 AM UTC

• Sellers can now change their storefront’s merchandising mode. The creative-review, campaign-approval, and product-composition toggles returned an error whenever you tried to save them, because the update they called had no matching endpoint — so the setting never actually changed. That endpoint now exists, and toggling merchandising mode saves correctly. Ad-server-backed storefronts continue to keep all three capabilities on, as before.
• GAM-connected storefronts now include descendant ad-unit delivery in pricing
• guidance and expose a usable CPM floor for wholesale products.
• Storefront admins can now assign primary and fallback role or user audiences separately for media buys and creative review, choose email and Slack delivery for each stage, set reminder and escalation timing, and reassign open work. Approval work moves to the fallback audience if its owner leaves or misses the deadline; it never auto-approves on expiry.

​

4.42.0 — July 11, 2026 at 11:59 PM UTC

• Diagnose any media buy end to end. Every media buy on Scope3 now explains itself: a buyer’s agent answers “why isn’t my buy live?” in one call — what it’s waiting on, whose side owns the wait, and what to do next — instead of polling for a black-box status. Sellers work every buy from chat: Media buys shows what’s pending and urgency-sorted, Timeline shows the exact payload sent to a source for any single buy, and Pending operations groups everything waiting on someone with a retry action only where retrying can work. Existing calls are unchanged. Guide: https://docs.scope3.com/v2/guides/diagnosing-stuck-media-buys
• Organizations now have one Plan & Billing page at Settings → Plan & Billing: plan and rate card, funded balance and credit line, intelligence usage, agreements, and the one next step (if any) to stay in good standing. It’s rolling out to a first group of customers now.
• Your storefront now carries a publisher domain as its identity key — the domain buyers and demand requests look you up by. You can supply publisherDomain when creating a storefront (recommended), and managed ad-server storefronts must have their publisher domains configured and authorized before setup can complete and the storefront goes live. Third-party sales agents are unaffected: your domains keep arriving through the product pass-through as usual. Nothing is required at creation time and no existing integration changes behavior.

​

4.40.0 — July 11, 2026 at 7:56 PM UTC

• Sellers can inspect and author source-scoped property and property-tag mappings to key-value, ad-unit, and placement targets through the v2 API or Murph, with validated dry-run coverage, provenance, audit evidence, and explicit confirmation before bulk replacement.
• Fixed the media-buy policy evaluator’s Gemini second-opinion check, which was still 404ing in production after an earlier fix attempt — the code-level model default had been corrected, but the production Helm configuration still pinned the unprovisioned model and took precedence over it, so buys kept silently escalating to manual review instead of getting an automated verdict. The evaluator, its underlying default, and Murph’s (currently inactive) Gemini fallback now all consistently resolve to gemini-2.5-flash, the model actually provisioned in the production Vertex AI project.
• Network storefronts can now synchronize publisher authorization from large, multi-thousand-property adagents.json documents.

​

4.39.0 — July 11, 2026 at 6:51 PM UTC

• Reduce noisy managed ad-server setup diagnostics. Soft-expired catalog caches now refresh automatically without creating seller action items, default naming conventions no longer appear as setup warnings, and AXE segment-key setup routes to a guided create-or-map flow instead of a generic checklist warning.
• The organization Billing page is now one clear page for how your organization gets paid and pays. Sellers set up payouts entity-first on a Payouts tab: each legal entity appears as a card with its country, per-currency bank accounts (masked to the last 4 digits), and a Primary tag, and adding or editing an entity walks through a 2-step wizard that adapts the bank fields to the entity’s country (US routing number, UK sort code, SWIFT/BIC elsewhere) and prefills the legal name from your business profile. Buyers manage billing details on an Invoices tab. Orgs with both a storefront and a buyer account see both tabs.
• Managed GAM setup diagnostics now treat default naming templates as already configured, so sellers are not prompted to customize naming just to clear setup health.

​

4.38.0 — July 11, 2026 at 5:09 PM UTC

• You can now catch up on product changes without leaving Interchange. Ask “What changed since I was last here?” for a summary tailored to your account, or open Help → Release notes to browse changes for your setup and features worth exploring. No setup is required.
• Signal components now distinguish targeting already present in a connected ad server from the components a seller creates and offers through their storefront.
• Enrolled buyers can connect or disconnect a personal Google Drive account from Connections, then select Drive files from campaign creative bulk upload. Scope3 can only use files the user selects and cannot browse the rest of Drive or write files back.
• Ask and supply-action statuses are now served from a single disclosure-aware read model: the same facts power the internal customer monitor and what Murph shares with you, with customer-visible fields formally annotated and enforced server-side.
• People invited into an eligible single-account Slack channel can now ask Murph general product questions and request access from the account’s admins without re-entering their email. Murph also keeps nearby channel context when a follow-up starts a new thread.
• Corrects the July 11 release note for embedded sales agents: the current pinned release is v1.22.4, not v1.22.1. No customer action is required; the release-safety checks now block stale version announcements and backwards version deploys.
• Storefront setup now shows every configured publisher domain with its authorization status and resolved property count. Managed storefronts remain incomplete until they configure at least one publisher domain and every configured domain is authorized, helping sellers present verified property coverage that buyers can trust.

​

4.37.0 — July 11, 2026 at 1:32 PM UTC

• Managed ad-server source status can now include recent sync runs on request, making failed sync diagnostics available from the existing status call.
• A new endpoint, GET /api/v2/billing/account, returns one consolidated view of your account’s plan, usage, credit/prepay balance, and agreements — plus the single next step, if any, needed to become or remain paid.
• Embedded sales agents roll to v1.22.1. Sellers’ persisted creative-format references are canonicalized in one migration (fixed-size ids like display_300x250 become canonical ids with explicit width/height), completing the canonical format contract’s seller-side data half — media buys and creative assignments now match on one format identity end to end. Also included: GAM custom-targeting and AXE key management endpoints for tenant setup, authoritative publisher-domain sync, delivery reports carrying per-day clicks and completed views, and a publisher-property discovery throttle that keeps busy tenants responsive. Buyer-visible surfaces are unaffected: buyers see the same product format references and delivery reporting fields as before; only the seller-side representation and matching internals changed.

​

4.36.0 — July 11, 2026 at 12:14 PM UTC

• Murph no longer sends an invocation prompt when you upload a file without a caption in a connected Slack channel. Captionless ambient files stay silent; tag @Murph or send the file in a direct message when you want it reviewed.
• Saving publisher domains during storefront setup now automatically registers the full current domain set with the managed sales agent, clears removed domains from its authorization projection, and syncs current domains without a separate manual step.
• Storefronts with managed ad-server inventory now recover stuck pricing and availability syncs even if an earlier recovery attempt already closed. Products no longer stay blocked by the “pricing/availability sync has never run” readiness issue, with nothing for sellers to change.
• Sellers using the embedded sales agent now see pricing and availability sync status for wholesale products that are backed by standalone inventory profiles, so readiness no longer reports those successful GAM syncs as never run.

​

4.35.1 — July 11, 2026 at 1:59 AM UTC

• Managed sales agent storefronts can recover GAM pricing and availability syncs that never started, so wholesale product pricing guidance no longer stays blocked behind a stuck “never run” sync.
• Managed sales agent sync recovery now carries the protected force-recovery key, so GAM pricing and availability syncs that never started can be auto-started after deployment.

​

4.35.0 — July 10, 2026 at 11:30 PM UTC

• Force-start never-run ad-server pricing availability syncs through the ESA recovery endpoint instead of the generic refresh fan-out.
• GET /api/v2/storefront/media-buys now filters, urgency-sorts, and paginates in the database, so large storefronts get fast, consistent pages instead of an in-memory scan of every buy — and page boundaries are stable under the default urgency sort. The Media Buys widget gained a “Load more” pager, so buys past the first 50 are now reachable in chat.

​

4.34.0 — July 10, 2026 at 8:27 PM UTC

• When generating a creative from a brief, you can now ground the look in what you already have. Before Murph builds concepts, it can open a reference picker over your creative library — pick from sourced materials (anything you’ve saved as a generation reference, in any media type) or browse every past creative you’ve made, filterable by campaign — and Murph carries your picks into the draft directions it generates.

​

4.33.0 — July 10, 2026 at 5:56 PM UTC

• Murph can now create the three GAM custom-targeting keys (axei / axex / axem) for you when they’re missing. Previously, if the keys didn’t exist in your GAM network yet, Murph would tell you to open GAM Admin → Custom Targeting and create them yourself before it could save the mapping. Now Murph offers to mint them with Scope3’s recommended names and display names — you confirm in chat, Murph calls a new POST /api/v2/storefront/esa/:esaId/gam-custom-targeting-keys/ensure endpoint, and finishes the setup on the same turn. Endpoint is idempotent (names already in your GAM come back in alreadyExisted, no duplicate creation), and shaped generically so the next signal protocol we ship (TMP) reuses the same call with different key names. The manual GAM path stays as a fallback for storefronts whose Scope3 service account lacks the CustomTargetingKey.write scope on the network — Murph explains that clearly when it happens.
• Bring your own creative straight from chat. Upload an image, video, audio file, or tag in a Murph conversation, and Murph asks the one question that matters: which campaign is this for? It then routes the creative to an existing campaign, a brand-new campaign you describe in plain language, or the advertiser itself to hold until you’re ready. You can drop a file before you’ve named an advertiser; Murph stashes it and picks it back up once you do. Once the creative lands on a campaign, Murph maps it to the campaign’s placements and lets you remap any that landed wrong. Full walkthrough: Buyer → Creatives → Bring your own creative.
• Embedded sales-agent storefronts now keep publisher-domain mappings authoritative. Adding a publisher domain still publishes it into ESA, and removing or clearing publisher domains now removes the stale ESA authorized-property projection instead of leaving old domains available.

​

4.32.1 — July 10, 2026 at 12:37 PM UTC

• Fix canceling a storefront buy that was never forwarded to the source. Previously, canceling a buy that was approved but not yet forwarded (e.g. stuck in forward_failed_needs_correction) would fail because the ESA would return “not found” and cancel.ts would treat that as an error. Now MEDIA_BUY_NOT_FOUND is treated as idempotent success. Also stops the forward worker from retrying a canceled buy by stamping forwarded_at on the storefront_pending_media_buys and storefront_pending_media_buy_updates rows.
• Fixed a display issue where storefronts using manual wholesale pricing upload showed a persistent “pricing availability: failed critical” health indicator even after pricing had been successfully uploaded.
• Fixed HTML5 creatives failing to be created in GAM after syncing. HTML5 creatives use click-beacon injection for click tracking, which meant the outbound payload had no destination URL. GAM requires a destination URL on all HTML5 creative objects, so affected creatives were silently rejected by the ad server. They will now sync and create correctly in GAM.
• Fixed the media-buy policy evaluator’s Gemini second-opinion check. The model path was resolving to a retired Vertex AI alias, causing every auto-approve candidate to silently escalate to manual review instead of receiving an automated verdict. The evaluator now uses gemini-2.5-flash by default, matching what the production Vertex AI project provisions. A startup probe was also added so a misconfigured model path surfaces as an error immediately rather than silently degrading per request.

​

4.32.0 — July 10, 2026 at 10:11 AM UTC

• Treat ad-server pricing availability syncs with zero run evidence as never-run even when the upstream status defaults to success.

​

4.31.0 — July 10, 2026 at 8:53 AM UTC

• Managed ad-server sources now automatically start a pricing/availability refresh when the health sweep finds an ad-server-sync source whose pricing sync has never run.
• Fixed the wholesale avails and pricing guide so sellers can copy the CSV template directly from the page instead of following a static download link that was not served in production.
• The storefront create-account dialog no longer implies your domain is fully verified just because we found it in the AAO registry — the badge now reads as a neutral “found” signal, and a new note tells sellers upfront that domain-ownership verification happens after the account is created, so a “Pending verification” status on the setup checklist isn’t a surprise.
• Buyers with Marketplace access can add sellers and channels they want to buy from directly in the Marketplace widget. The request stays buyer-side, so sellers do not need to do anything and campaigns do not change.
• Sellers with multiple legal entities can now register a payout bank account per entity and currency. Each payout entity carries its own beneficiary name and address, account number (masked to the last 4 characters on every read), and bank identifier, keyed by entity name and payout currency. Manage them via PUT/GET /api/v2/storefront/billing/payees, the set_payout_payee / list_payout_payees agent operations, or Settings → Billing → Payout entities. Existing payout details keep working unchanged as the default payee.
• Wholesale avails & pricing uploads now reject fake currency codes and obvious CPM or monthly-impression outliers during preview, so sellers catch unit mistakes before committing a feed.

​

4.30.0 — July 10, 2026 at 1:08 AM UTC

• Views and Completion rate are now columns in the campaign performance table, letting you compare video metrics directly across advertisers, campaigns, and media buys.
• Storefronts on Google Ad Manager can now finish AXE segment key setup directly in chat. Murph reads the include, exclude, and emissions custom-targeting keys from your GAM network, presents the three candidates for you to confirm, and saves the mapping — no more trip to the embedded sales agent admin. One rule the save enforces: the emissions macro key must be named literally axem in GAM, because the creative macro that carries the emissions token only resolves against that exact name. Full setup guide: Storefront → Embedded sales agents → AXE key setup.
• Fixed the creative picker labeling a placement with its bare media kind (e.g. “Image”) instead of its format. When a format agent returns a generic media-kind name, the picker now shows the canonical format id (e.g. display_300x250) so every placement stays distinct and identifiable.
• Discovery no longer silently drops storefronts whose channel capabilities are stored in legacy alias form (audio, video). Channel normalization is now applied to both the request and the capability side at compare time, so a storefront declaring audio is correctly matched against a channels: ["audio"] request.
• When creative sync fails for a sync-capable seller and your assigned creatives don’t match the required product format, execute now returns a clear error naming the mismatched product(s) and required formats — instead of a cryptic per-package rejection from the seller.

​

4.29.0 — July 9, 2026 at 5:08 PM UTC

• Cancelling a committed, guaranteed media buy now routes to a dedicated seller
• cancellation approval instead of stopping immediately. The buy keeps delivering
• until the operator approves the cancellation (approving terminates the buy;
• rejecting keeps it active). Cancelling a non-guaranteed buy, or a buy that has
• not yet been reserved with the source, still cancels directly with no approval.
• Delivery spend in cross-currency media buys is now correctly denominated in the advertiser’s primary currency. Previously, buyers transacting in ZAR (or any non-USD currency) against USD-settling storefronts would see spend labeled in their currency but showing the raw USD amount. The API now converts source-reported spend using the FX rate booked at buy time, with a historical-snapshot fallback for older buys. The response includes a deliveryFxConversion field on each affected media buy disclosing the rate applied.
• Fixed an error causing the reporting metrics endpoint to return HTTP 500 in certain environments. Buyer reporting data was inaccessible when BigQuery did not support the ANY_VALUE(IGNORE NULLS) syntax. The endpoint now returns correctly.
• Buyers and sellers are now notified when an approved media buy’s forward retry window lapses. Previously the platform stopped retrying after 6 hours without telling anyone — the forward_failed_needs_correction state was only visible by checking media-buy status or Pending operations. Buyers receive the existing media_buy.forward_failed notification carrying pendingReason: forward_failed_needs_correction and the buyer-safe error code; sellers receive the storefront forward-failed alert marked terminal, pointing at Pending operations. Fires exactly once per media buy, at the moment retries stop.
• Every budget you set — campaign budget.total, media buy product budgets, package budgets — is now gross: the all-in amount you pay, fees included, in one consistent denomination, with delivered spend on buyer surfaces reported the same way. Existing budgets were restated in place at the fee terms locked when each media buy was created, so their financial meaning is unchanged; the values you read back are now the numbers you’re billed. Media buy reads gain a budget_breakdown (media budget, fee amount, fee rate, effective gross CPM) and a budget_denomination marker so the split stays visible. One behavior change: campaign budget ceilings now count the fee on ended buys’ delivered spend, so a campaign that was silently over-allocated may ask for more budget before accepting new buys. Legacy media buys created before fee terms were locked are exempt: their spend stays net as the seller reports it, and they carry neither new field. Sellers continue to receive net media demand exactly as before.
• The storefront Dashboard rail item now opens the current seller analytics widget, so sellers return to the same analytics home Murph opens by default instead of the retired storefront dashboard view. The old in-page seller dashboard implementation and unused UI data wrappers were removed.
• Embedded sales agent 1.20.0: adds a tenant-management endpoint (PUT /api/v1/tenant-management/tenants/{tenant_id}/adapter-config/axe-keys) for declaring a GAM tenant’s AXE include, exclude, and macro key names, and unblocks the axe_segment_keys setup-checklist task so it can be cleared once the three keys are confirmed against the tenant’s synced GAM custom-targeting catalog. The macro key stays pinned to axem (the value the GAM creative macro %%PATTERN:axem%% resolves against); include/exclude names are configurable.
• Removed the raw AdCP wire-format payload from the GET /api/v2/buyer/storefronts/:storefrontId/capabilities response. All fields from the raw payload were already surfaced as normalized fields (sandboxSupported, requireOperatorAuth, supportedBillings, etc.) — the raw blob served no additional purpose for buyers and could be misread by agents.

​

4.27.0 — July 9, 2026 at 10:22 AM UTC

• Source-health alerts now come from one pipeline. An unreachable inventory source raises a single action-required notification (and a single all-clear when it recovers) instead of overlapping legacy and diagnosis alerts, Storefront Brain routes source problems by the same typed diagnosis every surface shows, admin views carry the identical owner/severity/action, and Murph can run a diagnosis’s recheck for you on request.
• Interchange no longer sends wholesale product or signal catalog requests to third-party sales agents unless product composition is on and the agent reports AdCP 3.1+ support. Pass-through agents keep using normal live buyer requests.
• Fix creative sync not being reachable via the api_call MCP tool: register the sync_creatives operation in the buyer service route table and coverage allowlist.
• Scope3 now pays sellers by direct bank transfer and invoices buyers directly; billing no longer goes through Stripe. Sellers enter payout bank details once — beneficiary name and address, account number or IBAN, one bank identifier, and payout currency — in Settings → Billing or via set_payout_details (PUT /api/v2/storefront/billing/payout-details), and Scope3 pays by bank transfer in that currency. If you previously connected Stripe, re-enter your bank details once: Stripe-held data cannot be migrated, and until your details are on file your media buys settle on direct billing (you invoice the buyer yourself). Buyers are invoiced by Scope3 directly, with the bank remittance details to pay against printed on each invoice; keep your billing contact and address current in Settings → Billing or via PUT /api/v2/billing/info.
• See and work every media buy on your storefront. GET /media-buys lists every buy — routed and ESA-managed — urgency-sorted (buys still waiting on someone whose flight starts within 48h first), each carrying the shared pendingReason vocabulary, the structured error code of the latest failed exchange, and the forward outcome. GET /media-buys/{mediaBuyId}/timeline traces one buy end to end — received → decided → forwarded / forward-failed → submitted → source moderation → accepted / rejected → delivering — with the exact payload sent to each source (platform-internal webhook and signing fields removed), a trafficker-grade summary, and the references to quote per state: the source’s own media-buy/task ids as their reference, and the sf: idempotency key paired with the request timestamp as the platform reference. GET /pending-operations unions everything waiting on someone — approvals, creative reviews, failed forwards grouped by error code with a recovery-class-gated action (retry for transient failures, fix-and-resubmit for correctable ones, escalate-to-Scope3 for structural or terminalized ones — those never get a retry button), and buys waiting on source moderation since a timestamp. The same surfaces open in chat (Media buys, Media buy timeline, Pending operations, and a one-decision Retry task) from the rail’s Operate section or by asking Murph. Forward failures and aged-out moderation waits now push a transition notification to your storefront’s notification stream.

​

4.26.0 — July 9, 2026 at 7:58 AM UTC

• The approvals widget now shows eligible products and GAM ad units for each pending media buy. When an operator expands a buy, a new “Eligible products” section lists the matched storefront products by name, description, and ad unit — replacing the previous raw package IDs. The Ask Murph prompt also includes inferred creative format hints so Murph can answer inventory eligibility questions without extra round-trips.
• Fix: human-approved optimization-suggestion budget reallocations now correctly apply the new per-product allocation. Previously the apply-suggestion flow read a scaling_factor field that was never present in real suggestion payloads, so approved budget changes silently no-op’d (only bid-price changes took effect). The apply path now uses to_allocation directly, matching the auto-apply worker.
• Source-health Murph alerts now include a direct link to the affected inventory source’s diagnostics in Interchange, so sellers can open the exact evidence for the outage from the alert.

​

4.25.0 — July 8, 2026 at 10:42 PM UTC

• Added a modular inventory source setup app and guide for creating feed-backed sources, previewing and committing avails feeds, inspecting readiness, completing source-side setup tasks, and preparing pilot sellers with row-level avails requirements.
• Video and audio creatives now auto-map to their campaign placements even when the publisher’s spec service is temporarily unreachable. The fallback matcher now understands resolution-style placement ids (video_1080p, ctv_720p), duration ids (ctv_15s, audio_30s), and aspect-ratio ids (video_vertical_9x16) — previously only WxH ids like display_300x250 could be matched without a live spec, so a perfectly matching video or audio file would sit unmapped whenever the sales agent was slow or down.
• Buyers can now supply a tag’s size as a file instead of typing it. Drop a CSV where each row is a creative — tag markup in one column, size in another (Google Ads Editor shape) — and each row becomes its own mapped creative. Or drop a CSV/manifest alongside your tag files (or inside a zip) that references them by filename; it fills each file’s missing size and then dissolves. A CSV dropped on a “needs input” tag row also re-runs mapping for tags already on the campaign. Headers are matched case- and space-insensitively, and sizes read from a WxH cell, a comma-separated list, or split width/height columns. A plain data CSV with no tag or filename column is still read as a document, not a creative.
• Fixed the buyer storefront list and detail endpoints returning the storefront id as a string instead of the documented integer, which caused the marketplace browse surface to fail to load storefronts.
• Delivery reports for non-video inventory (display, audio-only, DOOH-without-video) now ingest correctly. Sellers on these formats legitimately report null for the video-only metrics completion_rate and quartile_data; the reporting webhook previously rejected these payloads, so the affected delivery data never reached buyer reporting. Bumping @adcp/sdk to 11.1.0 (AdCP spec 3.1.2) loosens these fields to accept null as the “not applicable” signal, while still enforcing the [0,1] bound on any non-null completion_rate.
• Murph plain product discovery now uses progressive quick discovery by default, so storefront results can appear as sellers answer instead of waiting for the slowest seller. Explicit progressive, waitMode, and waitSeconds choices are still honored, refine calls still wait for the final answer, and elevated support responses include trace diagnostics for auditing slow runs.
• Sizes supplied via a CSV/manifest sidecar now survive to a later turn. Previously, if you dropped a sizeless tag with its sidecar CSV before picking a campaign, the declared size was lost — the tag landed on the campaign unmapped and asked for its size again. The declared sizes are now stored on the saved creative (a dedicated declared_sizes field on its asset, distinct from probed dimensions) and used when the creative is assigned to a campaign in a later turn, so the tag auto-maps to every placement its declared sizes fill — same as a same-turn upload.
• Agents now receive the exact request format for every buyer and storefront operation that takes a request body, instead of only some of them. Previously an agent calling an operation whose shape wasn’t published had to guess the request body and often failed several times before succeeding. Every body-taking operation that has a defined request shape now exposes it up front.
• Adding products to a discovery session no longer requires salesAgentId, groupId, and groupName on every selection. When omitted, the server resolves them from the session’s saved selections or the discovery result cache, and a budget-only re-add of an already-selected product preserves its stored seller/group provenance. This removes the visible first-turn delay where chat agents had to run product discovery twice — once for products, and again just to reconstruct group metadata before selections could be saved.
• Tidied the storefront left rail: your chat history now takes only the room it needs — and scrolls once it gets long — instead of leaving a large empty block, so the rest of the navigation stays in view.

​

4.24.0 — July 8, 2026 at 12:22 PM UTC

• Approvals widget now surfaces flight dates (including end-only and ASAP starts), CPM bid price, and product names from package payloads on media-buy approvals. Creative reviews show explicit brand and size fields parsed from the submitted payload, so operators don’t have to query Murph for basic metadata. Advertiser/brand name resolution also handles BrandReference objects and nested account paths.
• Answer “why isn’t my media buy live?” in one call. Media buys now carry a pendingReason (e.g. awaiting_storefront_approval, awaiting_source_moderation, scheduled_not_started) that says what the buy is waiting on and whose side owns the wait, a buyer-safe errorCode with ownership (buyer_input / platform / seller) plus the source’s sanitized rejection or moderation message when forwarding fails, forwardedAt, and a buyerReference support handle to quote to the seller or Scope3. The fields appear on the nested media buys in GET /campaigns/:id, on the media-buy status poll, and on the new GET /media-buys/:mediaBuyId (get_media_buy) single-buy lookup. Transition events (media_buy.forward_failed, media_buy.awaiting_source_moderation, media_buy.source_rejected, media_buy.stuck) now ride the buyer notification stream, fired once per state change with the same fields in the payload. Existing calls are unchanged — the new fields are optional and appear only on storefront-routed buys.
• Fixes a bug where creatives added across turns did not auto-map to the correct ad format, causing format_id to remain unset and blocking campaign assignment.
• Fixed a false “AAO compliance pending” status on the storefront readiness panel for agents whose endpoint URL includes a transport suffix (e.g. /mcp, /a2a). The compliance check now queries the verbatim stored URL first; it falls back to the bare-root URL only when the verbatim lookup returns unknown.
• Fixed: updating the budget on a media buy created before the July 2026 pricing-terms migration no longer fails with “pricing terms could not be determined.” The system now resolves and pins fresh pricing terms for those buys at update time, so the campaign ceiling check can proceed.
• Fixed: creatives synced to storefront sources now correctly complete the acknowledgment flow. Previously, the webhook callback used the storefront’s customer ID to look up buyer-owned creatives, causing a silent mismatch that left creative syncs permanently in-progress on the buyer’s side.
• Added status_refresh_source to media-buy status responses so buyers and agents can distinguish direct status polls from storefront route rollups. This prevents agents_queried: 0 or updated: false from being mistaken for stale delivery state when a storefront-routed buy is already current.
• Storefront approval-requested email alerts now use the configured notification address as the explicit recipient instead of also emailing every active user on the storefront account; when that address is missing, they temporarily fall back to active users and raise an internal setup alert.
• Fixed storefront agent debug call traces so transport payloads are scoped to the matching ADCP task instead of occasionally showing an adjacent call.
• Storefronts now tell you when they need something from you. When a source problem only you can fix appears — expired ad-server credentials, a source that stopped responding, a stale pricing feed — you get a notification in the app and by email naming the problem and the fix, and a follow-up when it’s resolved. To receive these in Slack too, add the new source-action alert types to your Slack notification settings. Problems on our side never become your tasks.
• Storefront media buys delivered by poll-based or source-push sources now populate their media-buy summary metrics (impressions, spend, clicks, and last-updated) from the storefront delivery feed, so GET /media-buys/:id reflects real delivery instead of zeros.

​

4.23.0 — July 7, 2026 at 8:35 PM UTC

• Brought video and audio creatives now auto-map to their campaign placements, not just images. Murph matches a video by the placement’s size (fixed, multi-size, or responsive range) and its duration window (e.g. pre-roll :15/:30), and an audio spot by its duration — plus bitrate/codec where the placement declares them. On a match the creative lands mapped, credits format coverage, and the confirmation card shows “Maps to: …”; anything that fits no placement stays recognized. This also repairs cross-turn auto-map (attaching creatives saved in an earlier turn), which previously left every creative — including images — recognized because the saved creatives were looked up under the wrong advertiser id.
• Product format_ids now carry the inline params the seller’s format definition pins (width, height, duration_ms) instead of being stripped to bare {agent_url, id} references. Buyers see fully-parameterized format references in get_products and media-buy responses, and echoing them back on create_media_buy no longer risks rejection by duration-pinned seller products. Existing composed catalog products are backfilled from the seller’s own product definitions; other stored products pick the params up on their next catalog re-sync.

​

4.22.0 — July 7, 2026 at 6:50 PM UTC

• A fluid or multi-size ad tag now maps to every campaign placement its declared sizes can serve, not just one. When a buyer brings a tag that declares multiple sizes (e.g. 300×250 and 728×90), Murph auto-maps it to each matching required placement and the confirmation card shows all of them (“Serves N placements”). Tags with no declared size still ask which placements they run on.
• The buyer rail’s Campaigns and Creatives items now match the storefront rail: once a conversation is underway they drop their selected highlight and show a ”+” on hover, and clicking one opens its widget into the current chat. On a fresh chat, opening one is a clean start point that replaces the other; once chatting, opening another keeps the prior widget and both stay in the conversation. Rail-launched widgets — on both the buyer and storefront rails — now render in chronological order at the point they were opened, so the transcript reads top to bottom as it happened.
• Connecting an ad platform now tells you whether it’s actually buyable. When a
• connect surfaces ad accounts but none of your advertisers are mapped to them,
• Interchange sends a “connected, but 0 advertisers mapped” notification with a
• path to the Advertiser mapping tab — before the first buy fails. Murph
• narrates completed connects (what was linked — a Business Manager, MCC, or a
• single ad account — how many accounts it surfaced, and the mapping state) and
• answers agency-access questions from the new per-platform agency runbooks in
• the connecting guide, which cover how a client grants your agency access on
• Meta, Google Ads, TikTok, Snap, LinkedIn, Pinterest, Reddit, and Amazon Ads.
• Fixed: updating the budget on an active media buy now works even when other buys on the same campaign were created before per-buy pricing terms were required. Previously, any campaign with legacy (unpriced) sibling buys would block all budget changes on any buy in the campaign. The validation now uses the available raw-media allocation as a conservative lower bound and still enforces the campaign ceiling.
• Budget headroom (unallocatedBudget) now reflects pending budget-reduction requests immediately, before storefront acceptance. Buyers who submit a budget cut will see the freed amount available for other buys right away.
• The creative upgrade endpoint (POST /campaigns/:campaignId/creatives/:creativeId/upgrade) is now reachable via the api_call MCP tool, allowing agents to set format_kind on a creative that has requires_upgrade: true.
• Fix Murph in-chat Approve control not completing durable writes. Clicking Approve now correctly executes the pending action instead of issuing a fresh confirmation request.
• Agent-driven catalog sync, event-source sync, and signal updates are more reliable. Some endpoints require the same identifier in both the URL path and the request body; an agent that supplied it in only one place previously got a “missing path parameter” or validation error. The API now backfills the missing side from the one you provided, so the id need only be stated once. A genuine mismatch between the two is still rejected, and the request contract is otherwise unchanged.
• Sellers now have public docs for publisher coverage, network adagents.json, GAM key-value site lists, and buyer property-list briefs.
• The “storefront adapter connection — mapping required” alert is now delivered always-on, alongside its credential-action sibling, instead of appearing as a mutable notification preference. Like the other storefront readiness signals (“your storefront is offline / not traffickable”), an operator can’t mute a buys-are-blocked-until-mapped alert, so it no longer shows as an opt-in category for sellers.

​

4.21.1 — July 7, 2026 at 1:47 PM UTC

• Fix Murph approval flow so attaching a chat-uploaded creative (create_creative_manifest) executes when you click Approve. Previously the pending record kept the upload as a placeholder, so by the time the click landed on a later turn the buyer API rejected the write and Murph looped on a fresh approval instead.

​

4.21.0 — July 7, 2026 at 12:57 PM UTC

• Property lists now apply to active media buys automatically. Creating a new property list pushes it to all active media buys for that advertiser. You can also push an existing list to a specific campaign at any time — no need to recreate media buys that were already running when the list was created.
• Fixed an issue where product discovery returned zero results against AdCP 3.0 sellers (e.g. Ozone) when a currency filter was active. The pricing_currencies field is only supported in AdCP 3.1; 3.0 sellers responded with UNSUPPORTED_FEATURE and no products. The SDK adapter now strips this field before the request reaches 3.0 sellers.
• Fixed two channel-filtering bugs in storefront discovery:
• 1. Audio storefronts (e.g. Talpa Media / Triton) were excluded from product discovery when buyers filtered by channel: audio. Agents advertising primary_channels: ['audio'] now have that alias normalized to the canonical streaming_audio value before storage, matching how buyer-requested channels are normalized.
• 2. Storefronts with no declared channels or regions (most storefronts) were invisible in the marketplace browser when a channel or region filter was active. The filter now treats undeclared metadata as unknown and includes those storefronts, consistent with how product discovery handles agents with unknown capabilities.
• Show the buyer account name for requested supply when an internal customer link is missing, instead of showing an internal account identifier.
• Fixed a bug where deleting the last inventory source left the products_available readiness check showing complete instead of missing. The storefront now correctly reports zero products available after all sources are removed.
• Manual wholesale pricing issues now surface as pricing-upload tasks instead of generic ad-server sync failures.
• Murph: surface every pending confirmation from a multi-write turn so all Approve widgets render, not just the first. When Murph queues N writes in one turn (e.g. six delete_campaign calls), the orchestrator previously collapsed the pending_confirmations to a single artifact via .find(...) — matched by the client hydration/state model which stored only one artifact per messageId, silently dropping N-1. The buyer chat surface promised “N Approve controls below” and rendered one. MurphChatResponse now carries a plural pendingConfirmations: T[] alongside the singular pendingConfirmation (retained for back-compat with older clients and the Slack handler), and the buyer runner renders one panel per element.
• The progressive discovery experience is now complete end to end. The opt-in
• API (progressive: true on discover_products, with revision,
• resultsComplete, pendingAgents, and a guidance field naming the exact
• next call), the server-sent event stream
• (GET /api/v2/buyer/discovery/:id/events), and progressive rendering in the
• buyer chat — results populate as sellers answer, with a waiting affordance
• naming who is still working — are all live. Calls without the flag behave
• exactly as before.
• Progressive product discovery now serializes first-wave cache snapshots behind earlier seller revision writes so sinceRevision polling cannot observe a lower revision than the initial response.
• Creatives that pin a format_option_ref with scope: "product" are now validated at assignment time — the referenced format_option_id must appear in at least one product’s declared format_options. At execute time, the pinned option’s canonical params (e.g. duration_ms_exact) are forwarded to the seller instead of the full option set.

​

4.20.0 — July 7, 2026 at 3:33 AM UTC

• Local MCP clients that use loopback OAuth callbacks, such as Codex, can now complete browser authorization instead of being blocked by hosted-client origin approval checks.
• Buyer agents can now inspect storefront capability diagnostics per active source. Managed ad-server-backed sources are counted as probeable: false instead of disappearing from the response, and external AdCP rows report credential requirements from the latest non-synthetic capability payload when available.
• For buyers and agent builders, this makes product-discovery troubleshooting clearer: a storefront with managed inventory no longer looks empty, and agents can tell when a buyer-owned credential is required. Sellers do not get new setup controls or need to take action; their managed storefront rows may now be shown to buyers as managed and not probeable rather than omitted. No pricing, packaging, billing, or margin changes.

​

4.19.0 — July 7, 2026 at 2:54 AM UTC

• Fixed cancel and delete failing for storefront media buys where the source accepted the buy asynchronously (returning a pending task instead of a confirmed upstream ID). The error “No media buy on this storefront” no longer occurs when cancelling or deleting a buy that is still awaiting source confirmation.
• The API now says advertiser_id everywhere it previously said seat_id, completing the seat→advertiser naming migration. The published buyer and storefront OpenAPI specs already used advertiser naming — this change renames the remaining internal request/response fields (the internal signal provider mapping API and unused input schemas) so no seat_id field name survives anywhere. No action needed: v2 buyer and storefront requests that send a stray seat_id key are automatically corrected to the advertiser field, so existing integrations keep working. Use advertiser_id in new integrations.

​

4.18.0 — July 6, 2026 at 11:07 PM UTC

• Creative manifest validation now accepts format_kind-only creatives (AdCP 3.1 canonical path). Creatives that carry format_kind without a format_id are now validated against the format kind catalog instead of failing with a format-not-found error.
• Bring-your-own-creative now handles ad tags. When a buyer pastes or uploads a display, rich-media, or VAST tag (standalone, or inside a zip bundle), Murph recognizes the tag type and its declared size and shows it on the confirmation card (e.g. “300×250 display tag”, “VAST 4.0”). Tags with no declared size are flagged so Murph can ask which placements they run on, and tags mangled on paste (HTML-escaped, curly quotes, truncated, or garbled encoding) are flagged as malformed with a prompt to re-paste or upload the tag as a file.
• Activate a buyer catalog directly from the UI. The Data sources → Catalogs view now has three distinct actions — Refresh, Preview, and Activate — instead of a combined “Refresh and activate”. Activation no longer depends on a feed refresh, so you can activate an inline/uploaded catalog (not just URL-backed feeds) and re-run activation on an unchanged feed on demand. Refresh now applies only to URL feeds.
• Fixed the buyer left rail rendering the “Recents” heading twice.
• get_campaign now returns packages[] (and its packageId values) before products[] and creatives[] in each media buy, so it survives LLM context truncation on large responses. Previously, packages appeared last in the object and was silently dropped when the response was too large, blocking budget edits on active buys with many creatives.
• Also fixes a silent no-op bug where submitting a package budget update with an unrecognized packageId returned success without changing anything. An unrecognized packageId now returns a validation error with an actionable message.
• Fix Approve button not rendering in Murph when the model made multiple failing tool calls in the same turn before proposing a gated action.
• Fixed an issue where spec-compliant external sales agents declaring media_buy.portfolio.primary_channels were stored with empty channel lists. The SDK reads the wrong key (portfolio.channels), so channels are now extracted directly from the raw capabilities response with fallback to the SDK-parsed value.
• Fixed a bug where browse_discovery always bypassed the discovery result cache on the first page of results (offset 0), causing every browse call to trigger a new live query to the seller. This produced non-deterministic product counts across consecutive calls to the same discoveryId and made the discovery cache effectively useless for initial page loads.
• One campaign can now mix routed and decisioned media buys. Routing (ROUTED vs DECISIONED) and pricing terms are now properties of the media buy, not the campaign: each buy takes its routing type from its storefront at create — derived server-side, never a client input — and locks its own pricing terms for that routing type. Each buy’s fee is calculated at its own rate, so a campaign’s fee is the sum of its buys’ fees, and the campaign carries a single all-in budget_total that caps every buy’s media plus its fee.
• Breaking: campaignType is now ignored on create_campaign/update_campaign and no longer returned on campaign responses (detail or summary) — routing and pricing are determined per media buy. On storefront and discovery responses (list_storefronts/get_storefront, product and proposal discovery), supportedCampaignTypes is renamed supportedRoutingTypes (same DECISIONED/ROUTED values).
• Pricing is unchanged: each buy still prices from the same contract rate card, now selected per buy’s routing type instead of once per campaign. Nothing changes on seller-facing surfaces, and sellers still never see buyer margins.
• Murph: fix the “click Approve below but nothing renders” failure mode observed in the buyer chat surface. Root cause traced in the transcript: on a “re-offer” / “retry” request, Murph was text-narrating the corrected proposal (“This will set the budget to $X…”) without actually invoking the write tool — so no pending_confirmation was issued server-side and no widget could ever render, no matter how many times she said “click the Approve control below”. The prompt now:
• 1. Requires a tool call on re-offer/retry. New section makes explicit that any retry request MUST invoke the write tool in that turn; a text-only reply describing the offer produces zero widgets. Called out as the single most common failure mode.
• 2. Softens the “widget will render” language. Previous fix (#5749) said “A fresh Approve control now sits under THIS turn” — reworded to “SHOULD render, tell me if it doesn’t”, with an explicit ban on asserting the widget WILL appear.
• 3. Handles the “no widget rendered” report. On first report — after a real tool invocation — Murph offers report_issue with the pending confirmationUid instead of looping back to “click the Approve control below”.
• Storefront left-rail nav items now read as “add to chat” once a conversation is underway: they drop their selected highlight and reveal a ”+” on hover, signaling that clicking them drops the widget into the current chat rather than navigating away. New chat and Dashboard keep their normal navigation behavior.
• Ad-server source setup now shows the real credential or vendor error when a create or credential update fails, warns about copied credential characters that can be mistaken for ASCII, and makes source creation and disabling available from the secure setup form.
• This is a seller setup change only; buyers do not see new controls or different catalog copy.
• Fixed creative assignment silently dropping all creatives when a product declares its accepted formats only via format_kind in format_options (no v1 format_option_id). Creatives whose format ID resolves to the declared canonical kind are now correctly assigned on both create and update paths.

​

4.17.0 — July 6, 2026 at 6:59 PM UTC

• You can now register a webhook to receive push events instead of polling. This is opt-in — nothing changes if you don’t register one. Register a URL and secret once, and we’ll POST matching events to it as they happen — starting with discovery.revision, which fires the moment a new seller result lands in a progressive discovery session, the same event the discovery event stream already pushes over a live connection. Deliveries are HMAC-signed so you can verify they came from us. See Webhooks for setup and the full event catalog.
• Fixed: HTML/CM360 tag creatives (display_300x250_html) now pass format validation for products that declare image-only format IDs (display_300x250_image). Many seller product catalogs list only _image variants for display banner slots even though their ad servers accept HTML tags. Display banner slots of the same size now accept both HTML and image creative formats.
• Storefront operator-domain verification now recognizes trusted brand.json house portfolio website properties as alias evidence, so approved sellers are not left pending when their account and operator domains are linked through brands[].properties.
• Fix media buy failure when a MANAGED_SALES_AGENT product’s internal inventory source identifier was mistaken for the sales agent ID, causing “agent reference broken” errors on product execution.
• MCP authorization failures now show the specific reason (for example, “An account admin must add this browser origin before authorizing this MCP client”) instead of a generic “Failed to complete MCP authorization” message, and internal server errors on this route are now captured in Sentry.
• Murph: when a confirm-gated write’s post-approval retry returns pending_confirmation again (the approval didn’t propagate — writeExecuted: false, plainAffirmativeAccepted: false), Murph no longer points at the already-spent Approve widget. She now tells the user plainly that the approval didn’t land and asks them to click the fresh Approve control that renders under the new turn. Also spells out concrete past-tense openers that are forbidden while a write is unconfirmed ("Set — …", "Updated — …", "Bumped — …", "Your budget is now …", etc.) so the specific narrative violation seen on the buyer chat surface can’t slip past the generic “no past tense” rule.

​

4.16.0 — July 6, 2026 at 4:46 PM UTC

• Wholesale catalog products now carry a pricingScope field ("public" or "account") so your agent can tell whether a cached price is the seller’s public rate card or specific to your account. No action needed — the field is additive.
• Setup surfaces now show only the tasks you can actually do, each with a one-click recheck where the platform can verify the fix for you. The ad-server setup surface has a clear binary posture — “Connected and syncing, nothing needed from you” or a short list of exactly what we need — with our own background work shown as a passive status line instead of alarms. GET /api/v2/storefront/esa/{esaId}/status now returns the same typed diagnoses as readiness, scoped to the ad-server failure modes, and every seller-owned diagnosis links its troubleshooting guide.
• Supply requests you tracked before this week’s update are visible again in list_requested_supply. Asks recorded under the previous storage model are now automatically carried into the new demand store on a recurring sweep, so nothing you requested is lost — and new asks continue to appear immediately.
• Finalizing a proposal on a storefront now returns a structured expiration timestamp, so buyer agents can tell exactly when they need to complete the purchase without parsing a text note.
• Storefronts with product composition now support the full AdCP proposal
• lifecycle with third-party buyer agents. A draft proposal returned by
• get_products can be finalized via
• refine[{scope: "proposal", action: "finalize"}] — the storefront
• re-validates that every product in the plan is still available at current
• pricing and commits the proposal with an expires_at deadline — and a
• committed proposal can be executed in one step by passing its proposal_id
• and a total_budget to create_media_buy, which expands the proposal’s
• allocations into packages server-side. Each committed proposal executes at
• most once; unknown, expired, still-draft, and already-used proposals are
• rejected with specific ADCP errors. A committed proposal is a price and
• composition commitment bounded by its expiry, not an inventory reservation.
• Scope3 buyers are unaffected — their agents already execute composed plans
• directly; this closes the loop for third-party AdCP buyers.
• Settings → Connections is now two purpose-driven screens. The Connections tab
• is the accounts you’ve linked — each row is one grant showing who authorized
• it, credential health, and how many advertisers it maps — with link and unlink
• as the only actions. The new Advertiser mapping tab groups platform ad
• accounts under their manager container (Business Manager, MCC), maps or
• unmaps each to your advertisers, filters to unmapped or unreachable, and
• shows preserved unreachable mappings with a relink-to-restore path. A
• “connected, but 0 advertisers mapped” banner links straight to the unmapped
• view before a buy can fail.

​

4.15.0 — July 6, 2026 at 2:35 PM UTC

• MCP OAuth now accepts dynamically registered loopback callback subpaths, allowing local clients like Codex to complete authentication.
• Ad-server source status now shows manual wholesale pricing uploads as the required fix when a source is configured for uploaded pricing, instead of telling sellers to reconnect pricing access to their ad server.
• Murph no longer tells you to click Approve again when a confirm-gated write fails after you’ve already approved it. Instead, Murph now surfaces the underlying error (e.g. “your campaign’s remaining budget is short”) and proposes a concrete fix — the previously-approved control has been consumed and can’t be clicked twice.
• Reporting polls to sales agents now carry the same account reference the seller received on create_media_buy. Previously, if the buyer had no linked account for the seller (the common shape for implicit-auth sellers like pubx), the poll worker dropped the account field entirely — even when create_media_buy had sent a natural-key {brand, operator} account and the seller had accepted the buy on that basis. The asymmetry caused strict seller handlers to null-deref on ctx.account.id, which surfaced as INGESTION_FAILED on every daily poll with no observable data ever landing in reporting.
• In deliberately shared Slack channels, the data owner can now approve sharing a specific campaign with the counterparty: Murph asks for explicit confirmation, only owner-side users can approve or revoke, the approval covers settings-level details only and lasts until revoked, and every grant and revocation is audit-logged.
• Allow multiple publisher organizations to connect the same third-party sales-agent endpoint with separate inventory-source credentials.
• Storefront readiness now returns typed source-health diagnoses. GET /api/v2/storefront/readiness includes a diagnoses array with one entry per source problem, each carrying who owns the fix (seller, scope3, or vendor), an impact-based severity (blocking, attention, or advisory), plain-language copy, and an inline typed action — including a ready-to-call recheck endpoint where the platform can re-verify on demand. Setup surfaces and agents can now show sellers only the tasks they can actually complete: problems Scope3 owns (like a stale catalog cache) no longer appear as seller to-dos or block readiness, and a stale signal catalog that nothing depends on yet is advisory instead of critical.
• Slack confirmation prompts now include Approve and Cancel buttons, so pending write actions can be completed without copying a confirmation code back into the chat.

​

4.14.0 — July 6, 2026 at 9:44 AM UTC

• Interchange now posts release notes to your shared Slack channel after production releases — a few bullets covering only the changes relevant to your role and setup, with the assistant on hand to explain any of them.
• Notification settings now include browser notification controls for shared Murph mentions, so users can explicitly enable live desktop alerts from the app.
• Wholesale product and signal catalogs for managed ad-server sources now refresh automatically when their cache goes stale, so newly created or edited products reach buyer discovery even if a catalog-change notification is missed. Previously a missed notification could leave a source’s catalog stale indefinitely.
• Added GET /api/v2/buyer/discovery/{discoveryId}/events, a Server-Sent Events
• stream for progressive discovery. Instead of polling browse_discovery with
• sinceRevision, callers can open this stream to have each newly landed
• seller group pushed as it lands, with a terminal event once every seller has
• settled. Same continuation contract as polling, delivered as a stream.
• Managed ad-server sources can now distinguish ad-server-synced wholesale pricing from manually uploaded wholesale pricing, so pricing health prompts sellers to upload current pricing instead of reconnecting pricing access when the source is intentionally manual.
• Shared Murph room mentions now refresh faster in the app and can surface browser notifications when users have already granted notification permission.
• The provider account mapping list now carries the platform hierarchy
• (accountType, parentExternalId, parentName) for grouping accounts under
• their manager container, includes preserved unreachable mappings (accounts
• whose connection was unlinked) with a mappingStatus=unreachable filter, and
• each mapping entry exposes linkId and unreachableAt. A new
• DELETE /advertisers/{advertiserId}/accounts/{linkId} endpoint unmaps an
• account from an advertiser.
• discover_products over MCP now emits notifications/progress messages as sellers answer during the discovery fan-out. Pass the MCP protocol’s _meta.progressToken on the api_call tool call and your client receives one progress notification per settled seller — e.g. “Magnite answered — 11 products (3 of 14)” — before the tool result returns. Works on both progressive and non-progressive discovery calls; clients that don’t send a progress token are unaffected.
• Resolve typed Murph room @mentions server-side so valid same-customer handles still invite and notify teammates when the client omits mention IDs.
• Add same-customer @user mention suggestions and durable room invite events for shared Murph conversations.
• Activate OAuth-backed storefront agents after a successful credential callback, backfill already-authorized pending sources, capture the customer action blocked by each escalation, count customer-blocking storefront escalations in health, and auto-verify storefront operator-domain aliases when an approved account domain has trusted AAO/brand linkage evidence.
• Polish shared Murph room participant avatars with clearer initials, image-ready rendering, and consistent room presence stacks.
• The product discovery widget now renders progressive discovery results as
• sellers answer instead of waiting for every seller to respond. It shows a
• “Waiting for X, Y… (N of M sellers)” banner while sellers are still
• answering, accretes newly-landed seller groups into the view as they arrive
• (polling automatically), and once results are complete, drops the banner and
• flags any sellers that timed out.
• Rename the buyer “seat” concept to “advertiser” across the entire wire surface (hard cutover, no aliases — the platform is in beta). What changed for integrations:
• MCP tool names: customer_get_seats → customer_get_advertisers, seat_details_list/seat_details_get → advertiser_details_list/advertiser_details_get, seat_create/seat_update/seat_delete → advertiser_create/advertiser_update/advertiser_delete, select_seat/switch_seat → select_advertiser/switch_advertiser. Old names now return unknown-tool errors; MCP clients that cache the tool list must reconnect.
• Tool scope value: seat → advertiser.
• Response keys: seats/seat/seatId → advertisers/advertiser/advertiserId (e.g. GET /api/customers/:id/seats now returns advertisers; syndication, signals, audit-log, media-buy and campaign payloads return advertiserId).
• Request fields: service-token creation scope: "SEAT" → scope: "ADVERTISER", seatName → advertiserName; signals/audit-logs seatId query param → advertiserId (a legacy seatId param is now ignored); UTM source: "seat" enum value → "advertiser".
• Unchanged: the x-scope3-seat-id request header (stable wire contract; carries the advertiser ID), all SQL/DB column names, and the /api/customers/:id/seats path (response keys renamed, path kept).
• This aligns the public API with the terminology used everywhere else in the product.
• Render selected Murph user mentions as recognized people chips in the composer.
• MCP OAuth clients can now self-register callback redirects during dynamic client registration, and account admins can self-serve exact browser origins for non-credentialed MCP/OAuth CORS access.
• Murph now audits who can read each connected Slack channel. When a channel’s members span more than one customer account, Murph pauses account-specific answers there — explaining why and pointing to DMs — until a Scope3 admin reviews the channel, so one company’s data is never shown to another.
• In Slack channels deliberately shared between two customers, Murph now scopes itself to the relationship: it discusses supply tracked for the named counterparty and general product questions, keeps every other account detail out of the channel (redirecting to a DM), and limits supply tracking there to the counterparty’s own domains.
• Shared Murph rooms now create in-app notifications when a teammate mentions you.
• Shared Murph rooms can now be started and linked before the first Murph prompt is sent.
• Shared Murph room lists now update from a live stream instead of repeated browser polling.
• Unlinking an ad-platform connection now preserves your advertiser mappings
• instead of leaving them orphaned. Mappings whose account is still reachable
• through another connection of the same platform keep working; mappings only
• the unlinked connection reached are marked unreachable (unreachableAt on
• the linked-account resource), never resolve at buy time, and recover
• automatically when you reconnect the platform or re-map the account — a
• temporary disconnect/reconnect never loses mapping work.
• Products with an FX-converted price (a rate-of-the-day quote into a currency
• the storefront doesn’t natively price in) now carry an expiresAt timestamp
• through discover_products, browse_discovery, and product details — the
• hold expires at the next UTC midnight. Buyer-side caches (the discovery
• snapshot and the per-query fan-out cache) now treat any cached quote past its
• expiresAt as stale and transparently re-fetch a fresh price instead of
• serving the expired one. Natively-priced products are unaffected and continue
• to cache freely.
• Added a downloadable wholesale avails and pricing CSV template and clarified how sellers should prepare manual wholesale pricing uploads for ad-server-backed sources.

​

4.13.0 — July 5, 2026 at 6:31 AM UTC

• Adapter connections are now keyed by grant identity — who actually authorized
• the platform grant (the authenticating user, and organization for org-scoped
• grants; captured from the platform’s identity endpoint on Meta and Snap, and
• derived from the reachable account set elsewhere). Reconnecting the same
• account updates its existing connection instead of duplicating it, a reconnect
• can no longer attach a fresh credential to a different grant’s connection, and
• intentionally distinct grants (an agency manager account alongside a client’s
• directly-shared account) coexist as separate connections.
• Progressive discovery documentation: end-to-end worked example (request, first-wave response, sinceRevision polling loop, stop conditions) across the discover-products and browse-products task pages and the discovery guide. The guidance field — the human-readable next-step hint returned on progressive responses and campaign-unbound sessions — is now declared in the DiscoverProductsResponse schema and OpenAPI spec.
• Hosted managed ad-server sources no longer receive sustained source-outage Slack or Pylon notices that ask sellers to restore infrastructure operated by Interchange. Reconnect-labeled ESA timeout failures are now treated as Interchange runtime issues instead of seller credential-repair tasks.
• Validate FreeWheel ad-server credentials before accepting the managed source, so invalid credentials are rejected during setup instead of creating a broken source. The source dashboard now also separates first-sync progress from action-required failures.

​

4.12.0 — July 4, 2026 at 10:09 AM UTC

• Murph now treats supply-tracker phrasing as requested-supply intent and gives the correct account-connection path when it cannot record the request from the current channel.
• Product discovery supports progressive responses. Pass progressive: true to discover_products and the first response returns already-answered sellers within seconds — with resultsComplete, a monotonic revision, and pendingAgents naming who is still working — while remaining sellers keep landing in the background. Poll browse_discovery with sinceRevision to receive only newly landed seller groups until resultsComplete is true. Sellers’ answers arrive one at a time, flight-search style, instead of everyone waiting for the slowest storefront.
• Murph conversations can now be feature-flagged into same-customer shared rooms with shareable room links, live room presence, participant-authored room messages, @Murph/@room composer routing, same-customer @mention suggestions, per-person chat avatars, and a room-level stream that refreshes viewers when new messages are persisted.

​

4.11.0 — July 3, 2026 at 7:17 PM UTC

• Clarify how adagents.json hosting modes relate to publisher-origin verification and AAO-hosted records.

​

4.10.0 — July 3, 2026 at 5:17 PM UTC

• Buyer reporting now handles multiple advertiser currencies honestly and can consolidate across them. Each advertiser block names its native currency; cross-advertiser totals carry a totalsCurrency and their money metrics are null (never a mixed-currency sum) when advertisers span currencies. A new displayCurrency parameter — defaulting to your home currency when your advertisers share one — returns a consolidated block: each advertiser’s spend converted at the current rate-of-the-day and then summed, with a per-advertiser audit trail and conversionInfo metadata (rates, as-of day, anything unconverted, estimate: true). Consolidated figures are display estimates only and never affect billing or settlement.
• Adapter connection summaries now report mappedAdvertiserCount — how many of
• your advertisers have an active mapping to one of the connection’s currently
• active accounts. A connected storefront with 0 mapped advertisers is not yet
• buyable (a media buy for an unmapped advertiser fails with
• account_mapping_required), and this field lets buyers and agents surface
• that gap right after connecting instead of at the first failed buy.
• Media buys on ad platform storefronts now resolve their external account
• through the advertiser mapping — the account mapped to the campaign’s
• advertiser under Settings → Connections — instead of the connection-level
• default account. An unmapped advertiser fails fast with a structured
• account_mapping_required blocker carrying the Connections link, rather
• than silently buying on a shared default account. Existing selected
• accounts are backfilled into mappings automatically where exactly one
• advertiser has transacted through the connection; ambiguous connections
• are left unmapped and surface the blocker instead. Buy account resolution
• (connection, credential, and how the account was chosen) is now logged for
• audit.
• Reporting metrics documentation now correctly describes spend as denominated in the advertiser’s primary currency rather than claiming USD (which was only true for USD advertisers).
• Add storefront adapter credential health writeback, a nightly expiry/refresh sweep, and lifecycle docs for reconnecting or rotating unhealthy credentials.
• Fix two defects that could leave a storefront-routed media buy’s package budgets out of sync with what was approved. Approved budget updates now locate the buy under either media-buy id space, so an operator approval actually persists the new budgets instead of failing silently; and package backfill from a resolved source route no longer overwrites newer, locally-staged budgets with the create-time snapshot.
• A creative that fails to sync to a sales agent is no longer reported as successfully synced, and sync failures now carry the agent’s rejection reason instead of a bare agent name — so buyers see when a creative did not reach the sales agent and why.

​

4.9.0 — July 3, 2026 at 12:05 PM UTC

• Brief requests to composition storefronts now return only composed products and proposals — the raw wholesale catalog is no longer merged into brief responses, and a discovery deadline no longer substitutes the catalog for a composed answer. Ask with a brief and every product you get back was composed for it; ask in wholesale mode for the full catalog. Source pass-through still serves as the fallback when composition fails.
• Add an in-chat campaigns widget for buyers. Ask Murph (or use the Campaigns
• rail item) to see an advertiser’s campaigns as a table with status, flight,
• and budget, then drill into a single campaign for its delivery metrics, media
• buys, and creatives. Gated behind the buyer creative v2 rollout.
• Storefronts with product composition can now return ADCP proposals from get_products. When a brief gives a basis for a multi-product plan, the composition engine emits draft proposals — named plans with budget allocations across the composed products, per-allocation rationale, and brief alignment — with deterministic proposal IDs that stay stable across re-discovery. Buyers see these as recommended plans in discovery and can execute them via apply_proposal.
• Murph approval prompts now use clearer wording when an action was suggested after reading external or uploaded content.
• Connecting an adapter account (Reddit, Snap, Meta, TikTok, and other
• provider storefronts) is now one click: the connectionUrl returned by
• connect_storefront sends the buyer straight to the provider’s OAuth
• consent screen instead of the Connections page, and every adapter has a
• permanent shareable link at /connect/{provider} (for example
• /connect/reddit) that works without a pre-minted customer URL.
• External-agent pass-through storefronts now keep Interchange-owned merchandising features off, including Chef composition and Storefront approval queues.
• Product discovery results now refresh immediately after a seller updates their catalog. Seller catalog-change webhooks retire cached discovery fan-out results, so buyers no longer see a pre-change product set for up to 10 minutes after a seller publishes changes.
• Retrying a discovery with a longer wait (waitSeconds / waitMode: long) now actually re-queries the sales agents that missed the shorter window. Previously the retry could return the cached partial result from the quick pass, leaving incompleteAgents unchanged no matter how long you offered to wait.
• Fix two storefront currency setup issues. (1) The setup checklist did not update after saving — the embedded setup widget cached read responses and never refreshed them after a write, so confirming your settlement currency left the step showing as incomplete until a full page reload, even though the change had saved. Writes now invalidate cached reads so the checklist reflects the change immediately. (2) The currency picker in the create-account flow rendered its label on top of the placeholder text; the label now floats correctly so the two no longer overlap.
• Cross-currency buys are no longer blocked by a temporary FX rate-feed outage: the most recent locked rate-of-the-day (up to 7 days) is carried forward as the day’s rate, with operations alerted. When no recent rate exists, cross-currency requests now fail with an explicit FX_RATE_UNAVAILABLE error instead of a generic pricing error, and stale FX quotes are rejected with FX_QUOTE_EXPIRED on every create path.
• Clarify MCP customer-switching errors so agents use the dedicated customer_switch tool, then retry the original API operation without per-call customer scoping.
• Documented response bodies for eleven API operations that previously showed
• no response schema — creative preview, discovery product details,
• optimization suggestions (list/get/approve/reject), notification read and
• acknowledge, advertiser account, storefront connection archive, and the
• adapter-storefront connect handoff (including its connectionUrl browser
• link). Also corrected the ad-server source refresh docs: it returns the sync
• run status and ids with 200, not an empty 204.
• Sellers whose ad server can execute but can’t expose commercial data (e.g. GAM publishers who won’t let us run the pricing query) can now supply wholesale price and availability by uploading a percentile-CPM feed keyed on their ad-server selectors. The platform validates it deterministically, prices the seller’s products from it (floor derived from p25; p50/p75 as guidance), and exposes per-country availability and expected CPM as a product forecast rather than splitting the catalog per country. Inventory too thin to clear the storefront’s minimum line item is held back, and a source that has enabled the module can’t go live until it has a current, non-stale feed.
• Priced wholesale products can now be purchased end-to-end. Previously a wholesale product was shown and priced during discovery but failed at execution, because media-buy pricing was resolved only from the internal products table where wholesale products have no row. Execution now resolves a wholesale product’s price from the wholesale catalog — the same source discovery reads — so a priced wholesale product completes a buy. Wholesale buys are supported in the source’s settlement currency; selecting a converted (FX) currency returns a clear, specific error rather than failing obscurely.
• Wholesale products can now be purchased in a converted (FX) currency, not just the source’s settlement currency. At execution the buyer’s converted-currency selection is priced by re-minting the same buyer-currency option discovery served (converted at the rate quoted when the product was selected); a stale quote or an unavailable rate fails with a clear error rather than a wrong price. Re-reconciling an open wholesale buy now keys it to its native settlement currency, so it matches the existing buy instead of creating a duplicate.

​

4.8.0 — July 2, 2026 at 10:10 PM UTC

• Buyer Creative v2: creative evaluators now run through an extensible registry that declares each evaluator’s default gate posture (blocking vs advisory), and the creative-session evaluate boundary accepts the full buyer-creative workflow stages (generation, selection, refinement, finalization, adaptation, approval, live_learning) alongside the legacy draft/final values. Draft variants are scored 0-100 from their evaluator results and the highest-scoring variant is recommended.
• Discovery responses no longer block on LLM-generated group descriptions and product relevance copy in long-wait mode. waitSeconds/waitMode: long now only extend the time upstream sales agents get to answer; descriptive copy is served deterministically inline and upgraded in the background, cutting up to 15 seconds from long-wait discovery latency.

​

4.7.0 — July 2, 2026 at 9:45 PM UTC

• Flighted media buys no longer fail when part of the pacing schedule has already elapsed. Fully-elapsed pacing periods are skipped across campaign execution, per-buy pacing changes, and campaign pacing cascades — only still-live flights are sent to the seller — and executing a buy whose entire schedule has elapsed now returns a clear, fixable error instead of a seller rejection.
• Documented 21 previously-undocumented storefront API operations in the
• OpenAPI reference — storefront compliance, agent capability refresh, the
• embedded sales agent connection lifecycle (list, get, test, refresh,
• deactivate, reactivate, status, service account), the ESA catalog surfaces
• (products, signals, signal candidates, adapter capabilities, publisher
• properties, ad-server selectors, creative formats), and the storefront
• product catalogue. The refresh_esa MCP operation now returns the refresh
• result body (status + syncRunIds) instead of an empty response,
• matching the REST endpoint.

​

4.6.0 — July 2, 2026 at 8:24 PM UTC

• Managed ad-server source health now reflects the booking write path: a source
• whose last media-buy forward failed at the infrastructure level shows as
• degraded until a booking succeeds or the evidence ages out, and successful
• bookings count as positive health evidence.
• Polished the buyer Marketplace widget so buyers can open and manage supply they would buy, including editing buyer ask details and removing tracked supply from the widget.
• Documented 18 previously-undocumented buyer API operations in the OpenAPI
• reference — advertiser restore, discovery product details, creative
• list/preview/duplicate, creative sessions, optimization suggestions,
• advertiser accounts, storefront connections, notifications, and campaign
• property lists. The notification endpoints (list, read, acknowledge) are
• also documented for the storefront API.

​

4.5.0 — July 2, 2026 at 7:24 PM UTC

• Murph inventory-source test campaigns can now select wholesale buyer products by the source product IDs shown in the test plan.
• Fixed a pair of bugs where a package/budget update to a storefront-routed media buy could either silently self-activate without operator approval and without ever reaching the seller, or (the inverse) have a legitimate, already-approved update wrongly rejected. Both were caused by an internal check that assumed a live media buy always has an activation timestamp recorded, which isn’t true for buys accepted asynchronously.

​

4.4.0 — July 2, 2026 at 6:26 PM UTC

• Brief-based product discovery on ESA-backed storefronts is faster: products
• are served directly from the managed catalog instead of waiting on a live
• sales-agent call. A storefront whose catalog is still being set up now returns
• quickly with no products instead of timing out.
• Storefront operators are now notified (in-app and email always, plus Slack once they’ve enabled that event type in their Slack settings) as soon as a new approval work item — a media buy, creative, ad-server approval, or inventory-shortfall review — is waiting for them, instead of only being discoverable by checking the Approvals page.
• update_campaign now rejects mediaBuys[].products[].budget/pacing/bidPrice on a media buy that already has deployed packages (ACTIVE, PAUSED, COMPLETED, INPUT_REQUIRED, or a PENDING_APPROVAL version staged on top of one of these) instead of silently accepting the request with no effect. Once packages exist, the product-level field is informational only: update packages[].packageId + budget/pacing/bidPrice instead (fetch packageId via get_campaign with includeProductDetails=false to avoid response truncation on buys with many creatives).

​

4.3.0 — July 2, 2026 at 5:58 PM UTC

• Adapter connection accounts now carry account hierarchy: each discovered account
• reports an accountType (advertiser, organization, or a platform subtype such
• as Amazon sponsored_ads/dsp or TikTok publisher_identity) plus
• parentExternalId/parentName for its parent business or manager account. Google
• connections now expand manager (MCC) accounts into their client accounts, so
• agency users whose access flows through an MCC see the buyable child accounts.
• Organization (manager) accounts are listed for context but cannot be selected,
• mapped, or used for buys.
• Clickthrough URLs on media-buy creatives are now automatically wrapped in the Scope3 click tracker across all outbound paths (sync_creatives, create_media_buy, and update_media_buy inline creatives), so per-media-buy click attribution works regardless of which path a creative ships on and without the format having to declare a tracker slot. No action needed: existing tracker URLs and creatives without a clickthrough are left untouched.
• Avoid unnecessary Redis scans during product discovery enrichment cache invalidation.
• The storefront MCP api_call tool can now fetch the seller-analytics rollup
• — as the named operation get_seller_analytics or as raw
• GET /api/v2/storefront/seller-analytics. This fixes the seller dashboard
• widget failing to load its analytics view over MCP.
• Fixed a create_media_buy failure classification bug: a fixable, non-refusal source failure (for example, a stale or invalid product reference) was being reported as a seller rejection. These failures are now categorized separately from a deliberate rejection.
• Detect ADCP sandbox support from raw account capability metadata as well as normalized sandbox extensions.
• The Source Health workbench now shows a source’s TRANSACT axis — the outcome of the last create_media_buy forward to it — as its own cell, distinct from discovery/reachability health. When a storefront forwards a buy, the source’s transact cell records the outcome (succeeded, pending for an async acceptance still awaiting confirmation, business_rejected, not_authorized, invalid_request, source_unavailable, or failed) plus the media-buy reference and a masked flag. This is recording-only: it never changes a source’s health status and raises no work items or alerts — interpretation is deferred to the diagnosis layer, mirroring the conformance-vs-health separation. A curated (linked) source records with masked: true, because its buyer-facing failure category is identity-masked and therefore not yet trustworthy for diagnosis.
• Use warmed managed sales agent products directly when cached wholesale data is sufficient, avoiding unnecessary live upstream discovery calls.
• Managed ad-server source health now reflects the managed pipeline (sync
• status, catalog freshness, connector reachability), refreshed by the platform
• every 15 minutes. Sellers are notified with the specific cause when a failure
• needs their action (for example, reconnecting ad-server credentials);
• platform-side failures alert Scope3 operations instead of asking the seller
• to fix them.
• Realign the signal keyType enum to the AdCP context-match spec: added context signals (country, region, metro, topic, eidr, gracenote, isrc, gtin, rss_guid, isbn, custom) and identity signals (rampid_derived, hashed_email); removed values Scope3 does not resolve end-to-end (coreid, yahoo_connect, property, postal_code, uk_postal_district, lat_long_radius). A new privacy-boundary validator rejects any signal (or custom-signal targeting profile) that mixes context and identity key types.
• Fixed linking or unlinking a creative on a campaign sending a no-op update_media_buy to every media buy in the campaign, including legs whose contracted format has nothing to do with the changed creative.
• Chat composer now tells you when a file can’t be attached instead of silently dropping it. Files that are too large, an unsupported type, or over the per-turn attachment limit surface a dismissible warning naming the file and the reason, so an oversized upload never disappears without a trace.
• Creative uploads that hit a size or file-count limit now tell you exactly which files were skipped and why (e.g. “chime-video.mp4 wasn’t added — the upload went over the 100 MB limit.”) instead of dropping them silently. The creative-intent and creative-confirmation responses carry a skipped_files_notice and the full skipped_files list; the in-chat card shows the ratio (“3 of 4 saved”) and lists every dropped file so you can re-add exactly those without re-uploading the whole batch; and Murph relays it in one line rather than telling you to re-upload everything.
• Storefront onboarding now judges the Walk → Run step by how much of your committed inventory you are actually expressing, rather than a fixed coverage checklist. Once your plan’s target model has enough substance, “Run” means you are fully expressing the inventory you have committed to — channels or properties you have declined lower the bar rather than counting against you; until then the previous coverage heuristic still applies. This makes the phase Murph coaches you toward reflect real expression progress.

​

4.2.0 — July 2, 2026 at 9:52 AM UTC

• Advertise sandbox support on storefront wrapper agents when their active backing inventory sources support sandbox tests, so sandbox advertisers are not skipped during buyer discovery.

​

4.1.0 — July 2, 2026 at 8:36 AM UTC

• Allow buyers to include the exact supply, package, audience, placement, or capability they would buy when tracking requested supply.
• Inventory source diagnostics now include a structured issue breakdown so sellers can see every active source-health signal, not only the top cause.
• External sales-agent storefronts with merchandising off now skip Chef
• composition and answer buyer briefs through live source passthrough, while
• composition ingredient loading reads only cached components and does not
• synchronously warm upstream sources. Public and internal docs now explain
• component-cache success, passthrough behavior, and Murph diagnostics language.
• Sandbox advertiser discovery now force-refreshes seller capabilities before
• checking sandbox eligibility, and storefront sandbox filtering no longer drops
• agents from stale cached capability rows before that refresh can run.
• ADCP account credential registration and rotation also trigger a scoped
• background account-inventory refresh, while unregistering a credential
• immediately cancels its locally cached discovered accounts.
• Storefront readiness now carries a persisted onboarding plan — the durable, shared record of what your storefront could sell. It includes a target model (seeded cheapest-first from your connected agents’ declared capabilities and your business profile), which setup steps are complete, and how your storefront has moved through the Crawl → Walk → Run phases over time. The phase is still derived live from your setup; the plan records the transitions for history so any surface can answer “where is this seller?” from one source of truth.
• Buyer integration account mapping tables are clearer, with less repeated platform/source text and a precise default-account label.
• Connection handoff links now preserve the full destination through login and can resolve provider-style targets before starting adapter OAuth.
• Sellers may now receive a supply nudge notification (storefront.supply_nudge)
• in their notification feed — a human-reviewed heads-up from the Scope3 team when
• something on their storefront needs attention (e.g. a sales agent that’s stopped
• responding, or an unconfirmed settlement currency). It’s delivered like the other
• operational alerts (in-app + email, plus Slack if enabled) and is always-on. The
• value is additive to the notification type enum in the v2 API.
• A storefront media-buy leg that a source never accepts no longer polls forever. A never-resolved route (one that never received an upstream media-buy id — e.g. its source became unreachable) still un-accepted past a 14-day age backstop is now force-terminalized to canceled (an operational terminal, not a seller rejection), so the buy stops showing an indefinite pending status. Buys that DID resolve upstream are never affected — a legitimately future-dated flight sitting pending_start until its start, a buy awaiting creative upload, and live active/paused buys are all exempt. Operationally, a pending update_media_buy that misses its resolution deadline now also alerts on-call, matching the existing acceptance-timeout alert.
• Supply requests now resolve the requesting customer strictly by authenticated account, closing a cross-tenant data exposure where customers sharing a company name or domain could see or modify each other’s requested supply.

​

4.0.0 — July 2, 2026 at 4:39 AM UTC

• Adapter storefront connection links now open the selected provider’s OAuth flow directly instead of only landing on the Connections page.
• get_campaign/list_campaigns responses no longer include mediaBudget or fees — these were derived campaign-level values that no longer reflect how the Scope3 fee is tracked. The Scope3 fee is now recorded per media buy in the platform ledger (previously it was a single campaign-wide figure), so a campaign-level mediaBudget/fees split is no longer meaningful. Use budget.total, feeType, allocatedBudget, and unallocatedBudget (all unchanged) to reason about a campaign’s budget.
• Clarify that creative manifest validation is an optional diagnostic, not a launch prerequisite, send upgraded creative manifests to sync_creatives with canonical format_kind, and return a clear unsupported-capability error when an agent does not support ADCP validate_input.
• Clarify setup documentation around AdCP, AAO, and publisher authorization: external sales-agent sources authorize the external agent URL, ad-server sources using Interchange’s hosted storefront agent authorize https://interchange.io, AAO registration blocks source connection, AAO compliance is advisory for activation, and publisher adagents.json authorization is surfaced as an advisory setup/product signal today.
• Adapter connection deep links now preserve storefront context when launched with tool-style snake_case query parameters.
• Discovery sessions can now hold the same product selected more than once. Each selection carries its own selection_id and becomes an independent media-buy line item (distinct budget, pacing, and flight), matching what create_media_buy / update_media_buy already support. Omit selection_id for a product’s single default selection; supply a distinct value to add a repeat. Re-sending an existing selection_id updates that instance instead of creating a duplicate.
• Breaking: the selected_products field on the start_product_discovery and update_discovery_session_products outputs changed from an object keyed by product id to an array of selection instances (to represent repeats). Consumers that indexed it as selected_products[productId] must iterate the array and read each element’s product_id / selection_id.
• Creatives with target_format_ids set now count toward campaign format coverage and are synced to the sales agents whose formats they cover, so one creative can satisfy multiple publishers’ format IDs instead of needing a separate duplicated creative per publisher.
• Fix discover_products, auto_select_products, and product detail responses (REST and MCP) always prefixing CPM/budget amounts with $ regardless of the product’s or campaign’s actual currency. A non-USD product (e.g. a ZAR-priced Ozone package at 450.23) rendered as $450.23, misrepresenting the price by the FX rate. Prices now carry and display their real currency (e.g. ZAR 450.23), falling back to $ only when currency is genuinely unknown or when a price range mixes multiple currencies.
• Fix storefront discovery under a tight deadline: when the buyer-discovery budget
• is nearly exhausted by the time a source’s live get_products would run, serve the
• source’s warmed catalog instead of issuing a doomed sub-viable live call. Prior
• behavior floored the timeout to ~1ms, which failed instantly (“timed out after
• 1ms”) and wrongly marked the source unhealthy — so a live-only third-party source
• briefly dropped out of discovery. A budget-exhaustion skip is no longer treated
• as a source-health failure.
• Murph sandbox inventory source and buyer-infra test campaigns now execute through the normal buyer campaign, discovery, product-selection, and execute_campaign tools instead of constructing direct upstream ADCP media-buy probes.
• ESA managed ad-server sources now expose explicit sandbox-account readiness and ensure endpoints so no-spend buyer tests can verify or create the tenant-managed sandbox account instead of inferring sandbox setup from the source type.
• Require confirmation before Murph records or removes requested supply, let buyers remove specific seller/channel supply they no longer want to buy, block requested-supply writes during admin simulation dry-runs, and have Murph share the public seller signup link instead of creating seller-outreach workflows when buyers ask what to send sellers.
• Fix Murph confirmation token replies so they continue the original conversation before executing the approved action.
• Murph’s confirmation prompts now explain exactly why a follow-up confirmation was rejected (for example, a dropped conversation thread id) instead of a generic “expired or didn’t match” message, and consistently remind the calling client to keep passing the same conversation thread id when confirming a gated action.
• Normalize embedded sales agent sandbox account domains before provisioning managed storefront sources.
• Adaptive onboarding phase (Crawl → Walk → Run, plus Pass-Through). The storefront readiness response now includes a derived phase, and Murph frames onboarding conversationally by phase — orienting a seller (“you’re in the Crawl phase; your next step is …”) instead of reading a flat checklist. pass_through (a finished-products sales agent) has no rungs; composition storefronts progress Crawl → Walk → Run. Derived live from setup-mode + readiness — no new persistence.
• Open the Marketplace widget for filtered storefront browse questions and keep supply requests focused on named sellers.
• Operational source failures on a storefront media buy no longer surface as a seller rejection. When a source fails to resolve a previously-accepted buy — its task failed/canceled/aborted, or it went silent past the acceptance deadline — the leg now settles as canceled (a terminal fault) rather than rejected (a seller “no, don’t retry”). Only a genuine merits refusal (rejected/governance-denied) settles as rejected, and it now carries the seller’s reason through to get_media_buys.rejection_reason (redacted per source kind). A source that reports rejected on its delivery feed also surfaces a rejection reason.
• Remove the standalone creative validate pre-flight (POST /api/v2/buyer/campaigns//creatives/validate and the validate_creative diagnostic). It provided no value over submitting a creative directly — attach/create the manifest and deliver it through sync_creatives / campaign execution, which runs the necessary manifest checks and surfaces any issues.
• Deleting a media buy that is still awaiting approval is now treated as a retraction: it withdraws the pending request instead of adding a spurious “approve media buy” task to the seller’s operator approval queue. Cancelling a buy the seller has already committed to is unchanged.
• Separate ready supply from waiting supply in the Marketplace widget and return buyer-safe ready dates for supply requests that are now available.

​

3.31.3 — July 1, 2026 at 10:35 PM UTC

• Coerce forwarded ADCP product-discovery time budgets to integer seconds so seller agents reject fewer valid discovery requests.

​

3.31.2 — July 1, 2026 at 7:17 PM UTC

• Polish the Marketplace widget so requested supply uses the public status contract and remains visible from the storefront discovery surface.
• Fix creative upload dropping duplicate-named files: when a zip bundle contained the same filename in different folders (e.g. two versions of a video), only one was saved. Every uploaded file is now kept as its own creative, with folder-qualified names to tell same-named versions apart.
• Direct sales adapter storefronts run by our expert agents no longer require seller settlement currency readiness checks, and adapter media buys preserve the buyer-declared currency without requiring an Interchange payout currency.
• Tighten Marketplace supply-list copy so the widget avoids repeating the same label across the header, rail, and panel.

​

3.31.1 — July 1, 2026 at 6:18 PM UTC

• Clarify the seller readiness nudge for settlement currency setup, including multiple payment currencies and Interchange’s automatic currency conversion.
• update_campaign with mediaBuys[].products[].budget on a pacing buy now propagates the new budget to the corresponding packages proportionally, preserving the existing period split. Previously the write landed only on the informational budget_amount field and left spend authority unchanged.
• update_campaign no longer targets archived media buy versions when a buy with the same ID has both an archived and an active row with valid_to IS NULL, which could cause budget updates to silently write to the wrong version.

​

3.31.0 — July 1, 2026 at 5:30 PM UTC

• Add shelf filters to the advertiser creative library listing (GET /api/v2/buyer/advertisers/:advertiserId/creatives): filter by role (evergreen/reference), source (uploaded/generated/connected), format_kind, asset_type, and dimensions (e.g. 300x250), alongside the existing search and promoted filters.
• Storefront media buys accepted asynchronously by a source (including ESA / managed-sales-agent buys) now create their packages when the hourly status poll activates them, matching the synchronous and push/poll acceptance paths. Previously these buys could go active with no packages, which blocked package-level delivery reporting and optimization.
• Fixed a race condition where adding creatives to a campaign in quick succession could silently fail to sync some media buys, instead of the intended “a pending version already exists” error.
• Fix POST /api/v2/buyer/campaigns/{campaignId}/creatives/validate (and the validate_creative MCP tool) silently dropping VAST/DAAST-specific fields (delivery_type, vast_version, vpaid_enabled, companion_ads) from a creative manifest before validation. A correctly-formed VAST or DAAST asset was matched against an earlier, looser asset schema in the manifest’s asset-type union and had its distinguishing fields stripped, causing the downstream ADCP agent to reject the manifest as missing delivery_type even though the buyer had supplied it.
• Also accept the standard AdCP asset_type discriminator (e.g. asset_type: "image") on every asset shape, including inside image_carousel cards. Previously an asset carrying it would be rejected outright (for carousel card media, which has no lenient fallback) or silently downgraded to unvalidated passthrough (for top-level manifest assets).
• get_media_buys now returns rejection_reason on a storefront media buy whose rolled-up status is rejected, so a buyer can see WHY a source refused the buy without a separate delivery call. The reason is the source’s merits-refusal message (already redacted, carrying no seller identity); operational failures (unreachable source, credential fault) map to a non-rejected status and so never surface a rejection reason. The field is present only when the buy is rejected and a reason was reported — never fabricated.
• Hide internal Linear ticket identifiers from buyer-facing requested supply responses.
• Limit buyer-facing requested supply responses to customer-safe tracking status instead of internal workflow details.
• Make the buyer Marketplace nav item open the storefront discovery widget directly instead of redirecting through Murph, and hide it when supply browsing is not enabled.
• Media buys now support the same product as multiple distinct line items, and multiple media buys per storefront in the same currency. A buyer can add a product more than once to one media buy (each line item carries its own budget, pacing, and flight — e.g. parallel optimization arms or pacing periods) and run several media buys on the same storefront and currency. Each line item has a stable buyer_ref returned on reads; pass it to update_media_buy to update or remove one specific line item when a product appears more than once.

​

3.29.0 — July 1, 2026 at 2:59 PM UTC

• get_campaign now accepts includeProductDetails=false to strip formatOptions from mediaBuys[].products[], exposing packages[] without response truncation for media buys with many creatives. This unblocks callers that need packageId values to submit package-level budget updates via packages[].budget.

​

3.28.0 — July 1, 2026 at 1:55 PM UTC

• Fix buyer-side errors hit when setting up cross-currency campaigns:
• POST /api/v2/buyer/campaigns/{campaignId}/creatives/validate no longer returns a 500. Creative-manifest validation now invokes the ADCP validate_input task through the supported SDK entry point.
• Adding a product to a discovery session now FX-converts the product’s pricing options during validation. A buyer whose advertiser transacts in a marketplace-FX currency (e.g. ZAR) can now select inventory that settles in another currency (e.g. USD) using the cross-currency pricing option they were quoted at discovery, instead of being rejected as a currency mismatch.
• Adding a product that was never in your discovery results (a stale or invalid id) is now rejected at selection with a clear message, instead of being silently accepted and failing later at execution. The execution-time “no pricing options” error is likewise clearer, pointing you to re-run discovery.

​

3.27.2 — July 1, 2026 at 1:08 PM UTC

• Capture A2A server task handles when storefront source forwarding receives async media-buy responses.

​

3.27.1 — July 1, 2026 at 12:02 PM UTC

• Fix Murph sandbox inventory-source test diagnostics so async create_media_buy responses preserve the returned task id for follow-up status checks.
• Clarified that GAM key-value targeting is supported through ESA signals, and labeled key-value-based property targeting as coming soon.

​

3.27.0 — July 1, 2026 at 11:15 AM UTC

• Storefront creation now captures settlement currencies up front, suggests an obvious storefront currency from the entered domain, lets the provided operator domain use normal auto-verification instead of forcing it back to unverified, and shows pending domain approval as an explicit readiness state.

​

3.26.1 — July 1, 2026 at 7:54 AM UTC

• A media-buy leg that fails to forward to a source is now recorded as a terminal route, so it appears in the media-buy status rollup (get_media_buys / status polling) instead of silently vanishing — a partial forward no longer under-represents its failed source(s). The stored leg status reflects the cause: a source that refused the buy on its merits reads as rejected, while an operational failure (unreachable source, credential fault, forward-chain error) reads as an unobservable leg — so an operational blip is never mislabeled to the buyer as a seller refusal and never terminally demotes a still-delivering partial buy. Failed legs carry no delivery and are never re-polled.

​

3.26.0 — July 1, 2026 at 7:07 AM UTC

• Fix managed (embedded sales agent) inventory sources that could strand at PENDING after provisioning — leaving their products and signals invisible to buyer discovery even though the ad server was fully connected and synced. Provisioning no longer ties a source’s active status to a sandbox test account; the ESA sync-health pass now advances a connected managed source to ACTIVE and warms its buyer-discovery catalog; and a connected, inventory-synced source whose product catalog never populated is now surfaced as a critical health alert instead of failing silently.
• Add timeline buckets to inventory source diagnostics so source call failures, rejections, timeouts, and latency movement are visible inside the selected window.
• Reddit and TikTok discovery and community mirror catalogs now avoid advertising creative formats that their current media-buy creation paths cannot fulfill.
• All campaigns now use GROSS budgets: the budget you supply is the all-in total and the Scope3 fee is carved out of it (media budget = budget − fee). The feeType (GROSS/NET) choice has been removed from campaign creation — NET (fee added on top) is no longer selectable. Existing campaigns keep their recorded fee type, and the campaign response still returns feeType.
• The campaignBudgetType field has been removed from advertiser create, update, and detail responses. It was a single-value setting that did not affect behavior.
• Buyers can now select products that settle in different currencies within a single campaign — across storefronts and within a single multi-currency storefront. Previously a discovery session was restricted to one currency. The buyer always transacts and is billed in their own primary currency; products are split into one media buy per storefront and settlement currency, each denominated in the buyer’s primary currency with its own locked FX rate.
• Move storefront marketplace browsing out of Connections into a buyer storefront discovery MCP app widget, keeping Connections focused on provider credentials, accounts, and integration feature policy. The widget now also exposes customer supply-wishlist requests through the existing supply-request API.
• Campaign creative template responses now include V2 product format options alongside legacy format IDs.
• Fix mapping a connected ad-platform account (Reddit, Meta, Snap, and other adapter integrations) to an advertiser — the discovered account now appears in “External account mappings” and can be linked to an advertiser as expected.
• Fix cross-currency product discovery for foreign-currency advertisers. Buyer
• discover_products stamps the advertiser’s primary currency onto the request as
• filters.pricing_currencies, which drives the FX overlay’s convert-to-buyer-
• currency in the storefront get_products handler. The in-process ESA dispatch
• was dropping those filters, so a storefront routed through an in-process sales
• agent returned products in the source currency (e.g. USD) to a foreign-currency
• advertiser (e.g. ZAR) — the FX overlay never fired. The dispatch now threads the
• request filters through, matching the MCP seam, so discovery quotes are converted
• to the advertiser’s currency.
• Keep buyer Connections focused on adapter/provider integrations instead of listing every marketplace storefront.
• Make Marketplace easier to reach and make requested supply statuses read as supply the buyer would buy when it is live.
• Read publisher domains from nested embedded-sales-agent inventory metadata so wholesale products expose their declared publisher properties in discovery and storefront product identity.
• Product discovery API responses now include live storefront timeout retry hints at the top level whenever the discovery service detects incomplete agents.
• Source diagnostics now compare each source’s current lookback window with the prior window, making newly worse, improved, and recovered call-health patterns visible in the diagnostics overview.
• Source diagnostics now show whether a reliability issue is owned by the seller’s source operator or Scope3’s managed runtime, so teams can route call, latency, timeout, and callback problems faster.
• Product discovery responses now surface live storefront timeout signals in incompleteAgents even when the upstream agent reports the timeout as an error reason rather than a structured timeout flag.
• Upgrade Sonnet-tier AI defaults to Claude Sonnet 5, including Murph, chat, cost tracking, and supporting tools.

​

3.25.0 — June 30, 2026 at 7:29 PM UTC

• The advertiser creative library now distinguishes its two durable roles. Creatives can be promoted with a creative_role of evergreen (serve-ready, reusable across campaigns) or reference (a generation input, not served) via POST /advertisers/:id/creatives/save-to-library (identify the creatives by creative_ids or by collection_id; no campaign required).
• Brought creative now persists the instant it’s uploaded, even before an advertiser is chosen: POST /buyer/creatives/stash saves the upload customer-scoped and returns ids, and get_creative_intent accepts those creative_ids to adopt them into an advertiser later — so naming the advertiser in a later turn no longer loses the upload. The creative-intent widget now owns advertiser selection via an in-widget dropdown (defaulted to a named advertiser, switchable) that re-surfaces that advertiser’s campaigns, and the saved creatives route to whichever advertiser is selected on commit. Uploads that are never claimed (no advertiser, no campaign) are automatically reaped after 7 days so abandoned stashes can’t accumulate. Promoting creatives now renders the advertiser’s creative-library shelf with the newly-saved item in it, and the shelf can be opened on demand (GET /advertisers/:id/creatives) — so a buyer can see and confirm their library in chat. The library list (GET /advertisers/:id/creatives) returns each creative’s creative_role, its creative_source (provenance — uploaded/generated/connected), and its reuse_count (campaigns it is actively attached to), and accepts ?promoted=true to return only library creatives — flight-specific creatives stay attached to their campaign.
• Fix media buys placed through a manual-approval storefront getting stuck in PENDING_APPROVAL with a status_refresh_failed error after the operator approved them. The storefront’s submitted-task envelope now returns the storefront-minted media buy id as task_id (the id every routing, status-sync, and settlement rail joins on) instead of the internal operator-queue record id, so the buy’s status reconciles to active once the source accepts.

​

3.24.0 — June 30, 2026 at 7:23 PM UTC

• Cross-currency buys now work end to end from discovery to media-buy creation. When a buyer transacting in a marketplace-FX currency selects a product priced in a storefront’s settlement currency, the buy is created at the FX rate the buyer was quoted at get_products and the buyer-facing budget is recorded in the buyer’s (campaign) currency — instead of being rejected as “not sold in that currency” or stamped in the seller’s currency. The quote is honored for the UTC day it was issued (the rate-of-the-day lock); a selection from a prior day is rejected so the buyer can re-discover at the current rate.
• Storefront media buys accepted asynchronously by a source (e.g. behind manual moderation) now have their packages created when the acceptance resolves, instead of going live with no packages. This restores package-grain delivery, reporting, and optimization for those buys.

​

3.23.0 — June 30, 2026 at 6:00 PM UTC

• Product discovery now surfaces inventory priced in any currency, not just the advertiser’s primary currency. Buyers with a ZAR advertiser can see and select GBP or USD products; FX conversion is handled at booking time.

​

3.22.1 — June 30, 2026 at 4:46 PM UTC

• Improved quick product discovery latency for storefronts with non-guaranteed managed wholesale products by returning warmed storefront products immediately and moving uncached LLM relevance enrichment out of the quick response path.
• Signing up again when you already have access to an organization no longer triggers new-member side effects. Previously, a repeat signup for an existing member (e.g. an OAuth re-auth, a retried request, or a stale signup tab) could send a false “new user signed up” notification to the organization’s admins and overwrite the organization’s recorded email domain. The signup flow now detects that no new access was granted and routes the user to log in instead, leaving the organization untouched.

​

3.22.0 — June 30, 2026 at 3:03 PM UTC

• Use adapter-declared sandbox support and channel metadata when routing discovery through Scope3-hosted adapter storefronts.
• Fixed product discovery so deadline-bound storefront searches can return available storefront products instead of timing out while additional product composition is still running.
• The launchable seller Dashboard now renders the learned default posture and learned auto-approve suggestions, matching what the agent shows inline — the REST analytics path previously omitted them (a shared enrichment helper now backs both). Docs also explain how a held or rejected media buy maps to the seller’s acceptance policy, for both sellers (the pre-screen verdict) and buyers (why a buy was held/rejected).

​

3.21.0 — June 30, 2026 at 2:22 PM UTC

• Advertise sandbox support from v6 storefront adapter capabilities so sandbox advertisers can discover connected adapter inventory.
• Disabled inventory sources no longer affect storefront readiness checks or source diagnostics.
• Route-polled storefront deliveries now record per-package delivery onto the buyer’s packages, so package-grain pacing and optimization reflect real delivery on poll-based sources, not only sources that push the delivery webhook.

​

3.20.0 — June 30, 2026 at 1:21 PM UTC

• Provider account mappings are now recorded in buyer activity so teams can audit when an integration account was mapped to an advertiser.
• Add an in-chat “Per-buyer auto-approve” view. Ask Murph to open it to see which trusted buyers skip your media-buy review queue and how many of each buyer’s buys auto-forwarded that your acceptance policy would have held — the would-have-held count surfaces the carve-outs worth revisiting first. Opt a buyer in or remove one inline (handed to Murph). Read-only and media-buy-only.
• When the bounded discovery setup-phase capabilities probe times out (or fails), product discovery now falls back to the agent’s last-known capabilities instead of treating it as “unknown”. A previously-probed but momentarily slow agent keeps routing correctly rather than being mis-handled on its first cold discovery; only a never-probed agent is treated as unknown. Warm cache hits are unaffected.
• Update @adcp/sdk to 9.4.0 so outbound AdCP requests carrying push notification authentication are signed by the SDK before seller capability-based signing decisions.

​

3.19.0 — June 30, 2026 at 12:25 PM UTC

• Buyer-direct adapter media buys on providers that don’t yet report buy status (those that expose campaign creation but no status read) no longer show a perpetual “status refresh failed”. The status sweep now recognizes a provider that can’t report status as a capability gap rather than a failure, and leaves the buy at its last-known status — no false error, no alert — until status reporting is available for that provider.
• Publishers can now connect an AdsWizz source (streaming audio + podcast) as a managed ad server, alongside Google Ad Manager, FreeWheel, and SpringServe. The connection takes an AdsWizz agency API key; inventory, products, and delivery surface to buyers through the storefront like any other managed source.
• TikTok adapter media buys now support live status polling through get_media_buys, so buyer campaign status refresh can read back TikTok campaigns created through delegated adapter auth.
• Fix the reporting completionRate to be completions per paid impression (completedViews / impressions) instead of completedViews / views. The previous denominator (viewable impressions) was non-standard for a completion rate and could exceed 100%; the corrected rate is bounded at ≤ 1 and is now consistent across buyer, seller, and tactic reporting. For CPM video the paid unit is the served impression; CPV/TrueView buys (billed per view) will track the billed view as the denominator when that inventory is supported.
• Product discovery no longer hangs when a single sales agent’s endpoint accepts the connection but never responds. The per-agent capabilities pre-load is now bounded by a short deadline, so a non-responsive agent is skipped and the remaining agents’ products return quickly instead of stalling the whole discovery up to the client’s request ceiling.
• Add external account mappings from buyer integrations to advertisers.
• Storefront catalogs now recover wholesale products from upstream sales agents that reject the platform’s AdCP version. When a source returns VERSION_UNSUPPORTED for a release it should have accepted within the same major version, the catalog warmer retries once at the highest release that source advertises, so a source on an older build no longer empties its catalog.

​

3.18.0 — June 30, 2026 at 8:18 AM UTC

• Keep seller-authored wholesale products discoverable during quick product discovery when a live storefront product query is slow, without dropping live managed ESA avails.
• Stop reporting successful pending media-buy status polls as status refresh failures.
• Fixed OAuth callback handling so successful logins do not get stuck on the signing-in screen when the callback route restarts mid-exchange.
• Fix Meta adapter media-buy status refresh for buyer-direct adapter buys. Status
• polling now uses the storefront delegated adapter credential for route-less
• adapter buys, so get_adcp_status and background polling can refresh
• get_media_buys status without incorrectly falling back to direct ADCP agent
• auth. Missing delegated credentials now surface a specific
• adapter_credential_unavailable blocker instead of a generic status refresh
• failure.
• Harden seller settlement-currency validation. create_media_buy now re-validates
• the storefront’s resolved settlement currency against the marketplace-supported
• set: a storefront whose defaultCurrency/paymentCurrencies holds an off-list
• code (persisted before the write-side guard) now gets a clear
• settlement_currency_unsupported error instead of an opaque spread-ledger CHECK
• failure deep in booking. The storefront update API also now enforces that
• defaultCurrency is part of paymentCurrencies when both are provided (the
• primary settlement currency is always part of the payout set).
• Internally, seller-settlement validation now runs against a dedicated
• SETTLEMENT_CURRENCIES set (the seller-payout axis), separate from the
• buyer-side MARKETPLACE_FX_CURRENCIES FX-admission set, with the invariant
• MARKETPLACE_FX_CURRENCIES ⊆ SETTLEMENT_CURRENCIES enforced by test — so a future
• change to the FX-admission set can never wrongly reject a legitimate
• direct-settlement currency.
• Storefront media buys now record per-package delivery from source push notifications, so package-grain pacing and optimization reflect each package’s real delivery instead of staying at zero.
• Fix the Buyer Discounts widget, which couldn’t load — the host had no REST allow-list row for it, so every API call it made was denied. A new CI gate keeps each widget’s directory, build list, both resource registries, README index, host REST-policy, and reachability in sync, so this class of drift (dead or unreachable widgets) can’t ship again.

​

3.17.0 — June 30, 2026 at 4:21 AM UTC

• Stop abandoned adapter-connection OAuth attempts from piling up on the
• Connections page. Starting a fresh connect now supersedes prior expired,
• credential-less attempts for the same provider, so you no longer see duplicate
• “saved connection but no usable credential” cards. Completed connections and
• in-flight connects (including a second account being connected) are preserved.
• Fix a 500 when disconnecting an adapter storefront connection (Settings →
• Connections). Disconnecting now succeeds and terminalizes the connection, its
• credentials, and its mirrored accounts.
• Murph now infers catalog purpose from context (feed type, existing setup, conversation) and confirms with the buyer instead of presenting a menu of internal concepts during catalog setup.
• Fixed probe_sales_agent returning a false “unreachable” verdict when called with a numeric database id instead of the agent’s external string slug. The tool now returns an actionable error in that case. Also improved the error message from the capabilities-refresh endpoint to include the failure kind and HTTP status, making it easier to diagnose transport or auth issues.
• Cross-currency (FX) media buys are now supported on storefronts that require operator approval. The quoted rate-of-the-day is snapshotted when the buy is submitted and held for 24h pending review; on approval the held rate is replayed exactly, so the buyer is billed at the rate they were quoted. If approval lands after the hold window expires, the buy is rejected (fx_quote_expired) and the buyer must re-discover and re-buy at the current rate.
• Cross-currency (FX) media buys can now be updated (re-budgeted) on storefronts. An update_media_buy recovers the buy’s already-locked rate-of-the-day from when it was created and re-applies it — the source is billed the settlement-currency budget (buyer budget ÷ the locked rate) and the buyer is never re-quoted, so a later update never drifts the rate. Changing a buy’s currency is rejected (currency_change_not_supported): a buy’s currency is fixed for its whole life.
• Polish the seller Test Runs widget: loading and error states now use a card-bordered treatment consistent with other seller MCP app widgets, and the empty state is replaced with a structured card that explains how to get started with sandbox test runs.
• Sellers can now choose any marketplace-supported settlement currency. The
• self-service currency picker offers the full set the marketplace supports
• end-to-end (21 currencies, including launch markets IDR and ZAR plus KRW, INR,
• MXN, PLN and others) instead of a partial list, so a seller in those markets can
• get paid directly in their own currency. The storefront update API now rejects a
• defaultCurrency or paymentCurrencies entry that is ISO-valid but not
• marketplace-supported (e.g. AED), which would otherwise produce a buy the
• ledger cannot record and the FX overlay cannot price. The setup widget also
• explains that buyers paying in other currencies are converted to your primary at
• the daily rate, so you never need to add a currency just to sell into it.
• Fix storefront media buys from a source that PUSHES delivery (a signed source webhook rather than being polled) showing zero in buyer reporting. The push path only ran the seller spread-ledger accrual, so the delivery never reached GET /reporting/metrics. It now also feeds the same buyer-reporting sink the poll path uses, scoped to each leg’s route under the verified source.

​

3.16.0 — June 29, 2026 at 7:03 PM UTC

• Product budgets can now be updated on active media buys without pausing delivery. Adding or removing products still requires draft status.
• Fix Murph erroring on long Slack answers: the message-splitter used the wrong Slack size limit, so a long answer still posted in one piece and hit msg_too_long. Answers are now split to fit Slack’s limit, and a very long answer is bounded to a few messages instead of a wall.
• Add url_hash to the signal keyType enum. Clients that already hold AdCP-canonical URL hashes (44-char std-base64 of blake3-256 over the canonicalized URL) can register signals against url_hash directly. The pre-existing url keyType keeps working: writers that project URL signals into the AdCP context-agent’s signal:* keyspace translate url → url_hash and canonicalize+hash the value at the wire boundary, so buyers continue to see raw URLs throughout the API while the wire format matches what adcp-go expects.

​

3.15.0 — June 29, 2026 at 5:50 PM UTC

• Sign-in no longer shows an error when an OAuth authorization code is exchanged a
• second time (e.g. a redirect re-entry after the first exchange already
• succeeded). The callback now resolves invalid_grant idempotently: if a session
• already exists it continues to your destination; otherwise it restarts sign-in.
• Per-buyer auto-approve now keeps trust honest: when a trusted buyer’s media buy is auto-forwarded that your acceptance policy would have held, the gate records it (it never holds the buy). Each override exposes a policyBypassCount and lastPolicyBypassAt on GET /api/v2/storefront/buyer-auto-approvals (and via Murph), so you can see whether a buyer you opted in is pushing buys you’d otherwise have flagged and revisit the carve-out. The forward decision is unchanged — this is visibility only.
• Complete the in-chat bring-your-own-creative flow. When a brought creative fits no placement on the campaign it’s flagged as a misfit with the nearest placement suggested (non-blocking — the creative still attaches), and the buyer can map it to a placement of their choice from a menu on the card: rows go green as you pick, and one Save commits the whole batch in a single write (no per-action chat turn) with the card updating in place. Buyers can also reassign a creative to a different placement directly in chat (e.g. “move the 300×250 to the leaderboard”) via the new remap_creative_placement operation. Size→placement matching now falls back to the size encoded in a canonical format id when the format agent’s spec is unavailable, so mapping no longer silently fails; placements that can’t be read at all are surfaced honestly on the card instead of leaving creatives unexplained. Mapped creatives now name the placement they cover (“Maps to: …”) on the card, and each creative shows its detected specs — image dimensions, video dimensions and duration, audio duration — read from the file at upload (including creatives uploaded inline). The in-chat creative widgets show a loading state instead of a blank frame while results load. Buyer-creative-v2 only.
• Clarify storefront lifecycle and health labels so storefronts that accept buyer transactions are shown as transacting instead of generically active or live.
• The storefront media-buy approval pre-screen now reads your written acceptance policy more thoroughly and sorts each buy into three tiers instead of two: clearly on policy (auto-forwarded), needs a look (queued), and clearly against an explicit rule you wrote (surfaced as a strong decision-support signal on the queued item — the buy still queues; nothing is auto-rejected yet). It generalizes past a fixed category list — a rule like “we don’t accept fast-food advertisers” is honored even though it isn’t a built-in category — by reading what you actually wrote, and an AI second-opinion can flag a conflict the keyword pass missed before a buy auto-forwards. The new recommendation value auto_reject and rejectionReason field appear on the evaluation response. The pre-screen errs toward human review whenever it is unsure or the AI layer is unavailable, and the AI layer can only ever route a buy to human review — never approve or reject one on its own.
• Murph no longer leaves a Slack message frozen on “On it…” when the service restarts mid-answer. An interrupted turn is now replaced with a clear “I got interrupted — please re-ask” message instead of a status that never resolves.
• Guaranteed media buys that exceed the ad server’s availability forecast are now held for operator review instead of silently overbooking. The sales agent stamps an inventory-availability signal on the buy; the storefront surfaces it as a “Guaranteed availability review” work item plus a readiness item. This is per-buy (it does not change the storefront’s auto-approve setting) and does NOT auto-clear when the order goes live — the operator confirms or adjusts the goal. Non-guaranteed buys are unaffected. Also fixes the discovery-time bookability signal, which was inert because it read the ad server’s object-shaped forecast availability as a string.
• Murph widget activity lines now persist, so a committed action (e.g. “Approved Acme Motors”) stays in the conversation after a page reload, not just for the current session.
• The Murph chat request accepts an optional modelContext field — the latest widget activity-line writeback — which is sanitized and fed to the model as a <widget_activity> context block on the next turn, so Murph knows what a widget just did without a re-prompt.
• Add customer-scoped requested supply tools backed by Linear customer needs, plus an internal Storefront Brain rollup for requested seller/channel demand.
• Seller analytics now flags buyers whose media buys consistently clear your review and recommends opting them into per-buyer auto-approve. When the buys from one buyer that came to you for review have all cleared and forwarded with no rejections, the agent surfaces a learned_auto_approve suggestion in sellerRecommendations[] that points you at the per-buyer auto-approve control for that buyer. It looks only at media-buy approvals (not creative review or delivery), and it’s suggest-only — the agent recommends and you decide; it never changes an approval gate on its own. Evidence-gated, so a short or mixed approval history yields no suggestion.

​

3.14.0 — June 29, 2026 at 3:31 PM UTC

• The /auth/token endpoint now returns 400 invalid_grant (instead of 500)
• when an OAuth authorization code is expired, already used, or otherwise invalid
• — for example when a single-use code is exchanged twice. Sign-in clients get a
• clear, actionable signal to restart the flow, and these expected client
• conditions no longer page as server errors.
• Fix cross-currency (FX) accounting and discovery for wholesale passthrough inventory. A ZAR (or other marketplace-FX) buy against a USD-settling storefront’s passthrough product now records its FX leg in the spread ledger and currency book — the buyer currency, held rate, settlement amount, and zero break-even spread are captured even when the source’s per-unit rate isn’t exposed (previously the position was dropped, so the currency book under-reported FX exposure). Separately, wholesale products whose source omits channels now pass get_products response validation (the field defaults to an empty array) so they remain discoverable and buyable.
• Sponsored-buyer actions (approve / suspend / reactivate) now post a non-prompting activity line to the chat — e.g. “Approved Lakeside Motors” — so what you did stays visible in the transcript without re-prompting Murph.
• Fix storefront media buys accepted asynchronously (the source returns submitted) never showing as active or in reporting. The storefront-minted routing id arrived as a task id and was not persisted as the buy’s adcp_media_buy_id, so the status-sync job and the buyer reporting feed (both keyed on it) could not resolve the buy. It is now persisted on the storefront-parked acceptance path.

​

3.13.0 — June 29, 2026 at 2:05 PM UTC

• service_token.active_adcp_agent_ids now contains every adcp_agent row in the token’s scope, not just status = 'ACTIVE'. Downstream consumers (rtdp, rt-audience) treat membership as “this token has access to this agent” rather than “ACTIVE-right-now”, so flipping an agent to DISABLED/FAILED/PENDING no longer silently revokes access. The boolean active_adcp_agents flag retains its ACTIVE-only semantics.
• Improve the adapter connection OAuth callback (Settings → Connections). A failed
• or timed-out connection now shows a clear page with a “Back to Connections”
• action instead of a raw error-JSON page, and a successful connection returns you
• to the Connections page with that provider preselected instead of the app
• homepage.
• Storefront/managed (GAM) media-buy delivery now flows into buyer reporting. The route-poll worker feeds the delivering leg’s per-day metrics into the reporting pipeline under the buyer-facing media-buy id, so GET /api/v2/buyer/reporting/metrics shows impressions/spend for managed buys instead of zero. Metrics are attributed to the real delivery day, and only legs carrying a daily breakdown are fed (a breakdown-less snapshot is held back so it can’t double-count against later per-day data). Correct per-day attribution depends on the companion sales-agent change that surfaces the daily breakdown.
• Murph no longer presents an ad-server source and its owning Storefront as two peer agents when sellers test products.

​

3.12.0 — June 29, 2026 at 10:50 AM UTC

• Manage buyer discounts in chat. Sellers can now open a Buyer discounts widget to see, add, edit, and remove their rate-card discounts grouped by axis — the buyer’s advertiser brand and its buying operator. The add form previews where a typed domain keys in its published corporate hierarchy (so you can tell whether a discount covers a whole house or just one subsidiary), and a discount never prices a quote below your wholesale cost.
• Add GET /api/v2/storefront/house-discounts/resolve?domain= — a read-only helper
• that resolves a brand or operator domain up its published corporate hierarchy
• (e.g. converse.com → nike.com) and reports the chain, the house it rolls up to,
• and whether that hierarchy is known. It lets a discount-authoring surface preview
• where a discount will key — and warn when a domain only covers itself — before
• the row is saved. Creates and matches nothing.

​

3.11.0 — June 29, 2026 at 8:56 AM UTC

• Fix media-buy delivery status incorrectly showing pending_start for buys that are actually delivering. When a sales agent’s reporting read is temporarily unavailable, the status poller no longer regresses an in-flight buy to pending_start; it preserves the last-known status and retries.
• Fixed a race condition in Murph conversation creation that caused a duplicate key value violates unique constraint error when two concurrent requests attempted to start the same conversation simultaneously.
• Fix the Signal components MCP app launch so the standalone seller widget is registered, served, and allowed to call its signal authoring endpoints.
• Persist seller analytics chat artifacts as assistant-turn blocks and rehydrate them when a Murph conversation is reopened.
• Murph no longer errors out when its Slack answer is long. A thorough, docs-grounded reply that exceeded Slack’s message-size limit previously failed the whole turn (“I hit an error trying to answer that”); long answers are now split across threaded replies, and Murph keeps Slack answers concise rather than pasting large doc excerpts.
• Cross-currency FX quotes now hold for the day. get_products and create_media_buy resolve the same deterministic rate-of-the-day per currency pair (fixed at first use each UTC day, sourced from the spot feed), so a buyer quoted “ZAR 52” books at “ZAR 52” as long as they transact within the day — no more intraday drift between the quote and the buy. FX-converted products carry a hard expires_at (the next UTC midnight); after it, re-discover to be re-quoted at the new day’s rate. The expiry encodes the marketplace’s FX-risk hold window and is tunable.
• Cross-currency FX now works on wholesale / passthrough products, not just composed ones. A buyer transacting in a marketplace-FX currency is admitted on the wholesale discovery path, the source’s settlement-currency options are converted to the buyer’s currency at the rate-of-the-day (a natively-priced currency is never re-converted), and the passthrough leg books the cross-currency split on the spread ledger — the source is still paid in its own currency. Conversion happens once, at the buyer’s edge: internal storefront-to-storefront (pool/cascade) hops carry the settlement currency through and never re-convert, so a buy is never FX’d twice.
• When a buy matches both a brand discount and an operator discount, the buyer now
• gets the larger of the two (ties resolve to the brand axis) — rather than the
• brand discount always winning. Brand and operator are independent buyer
• identities, so neither hides a better deal from the other, and discount
• composition is now uniformly larger-of across both axes and across the
• house/buyer-instruction rails. Nearest-ancestor-wins still governs within a
• single axis.
• Improve Meta app-install discovery guidance with mobile-first creative, placement, and iOS measurement readiness recommendations.

​

3.10.0 — June 29, 2026 at 4:32 AM UTC

• Added a Components widget for mapping ad-server inventory into products and a bulk signal creation tool so sellers can create many signals after one approval.
• Storefront operators can now opt a specific trusted buyer into automatic approval
• for their media buys while the storefront stays in manual review for everyone else.
• Set it with PUT /api/v2/storefront/buyer-auto-approvals/{buyerCustomerId} (or ask
• Murph), and list current overrides with GET /api/v2/storefront/buyer-auto-approvals.
• It is relax-only and media-buy-only — an enabled buyer’s media buys skip both the
• review queue and the acceptance-policy screen, creative review is unaffected, and it
• only takes effect while mediaBuyApproval is manual. Buyers must have submitted a
• media buy to the storefront (no pre-arming an unknown buyer), and disabling keeps the
• record for audit.
• Removed the standalone validate_signals storefront operation and the POST /esa/{esaId}/signals:validate REST route. Signal validation now runs through the dry-run path — manage_esa_signal with action: "validate" — which returns the same validation result plus a preview of the signal, in one non-persisting call.

​

3.9.0 — June 28, 2026 at 10:28 PM UTC

• Cross-currency buying is now global and automatic. Which currencies the marketplace accepts via FX is a single marketplace-curated set — the major traded currencies plus key emerging markets, including the launch markets Indonesia (IDR) and Brazil (BRL) and the pilot currency ZAR. A buyer in an accepted currency is admitted at every storefront and converted to that storefront’s settlement currency at the platform spot rate; the source is always paid in its own currency. A storefront operator still decides which currencies it settles in directly (paymentCurrencies) — there is no FX on those, and no per-storefront FX configuration.
• Storefront creation now accepts an operator domain, storefront readiness blocks go-live until that domain is set and verified, and account customer-domain updates preserve storefronts that intentionally operate under a different domain.

​

3.8.0 — June 28, 2026 at 9:35 PM UTC

• Murph no longer deflects credential-policy questions to the secure credential form. Questions about bearer-token rotation, replacing compromised credentials, audit logs, or governance now get a real answer. The secret-in-chat backstop still redirects when an answer actually routes a secret into the chat (“paste your token here”), but no longer discards an answer that merely explains how credentials work.
• Storefronts with an FX overlay enabled can now accept and book a media buy in a buyer currency they do not settle in (e.g. a ZAR-locked buyer against a USD-settling storefront). create_media_buy admits the buyer currency, snapshots the operator’s rate, and bills the source in its own currency (buyer budget ÷ rate); the cross-currency edge — the USD cost leg and the buyer-currency sell leg plus the booked rate — is recorded on the storefront’s spread ledger. Default off; same-currency buys are unchanged.
• Not yet covered (follow-ups): FX buys on a storefront that requires media-buy approval are rejected until the approval path carries the rate snapshot; update_media_buy on an FX buy and FX over raw-passthrough inventory are not yet currency-aware; and FX spread rows are recorded but not yet surfaced in margin reports.
• Cross-currency curation now sources FX rates automatically: a storefront with the FX overlay enabled lists the buyer currencies it accepts (allowedBuyerCurrencies) and each is priced at the current platform spot rate — operators no longer have to hand-enter a rate, though they may pin a per-pair override in rates. The rate in effect is locked onto a media buy when it is created, so it bills the source and settles the campaign at the booked rate for the campaign’s whole life. Spot rates only for now (no hedge); a forward rate for the settlement horizon is a later refinement. Default off.
• Murph now opens each conversation aware of the support requests you’ve already filed. On the first turn it sees your open and recently-resolved requests, so it won’t ask you to re-file something already in flight, can pick up an open item when your message relates to it, and will let you know when a related issue looks resolved.

​

3.7.0 — June 28, 2026 at 7:52 PM UTC

• Murph now proactively follows up in your support channel when an issue you reported is resolved — a one-time “we believe this is now fixed, could you retry?” message, so you’re not left guessing whether to try again.
• Creative format specs derived from a canonical format_kind now use the
• asset_type the manifest validator actually detects (vast, daast, html)
• instead of names it never produces (vast_tag, daast_tag, tag, html5). This
• restores per-asset validation (duration, codec, dimensions) for VAST, DAAST, and
• HTML/HTML5 formats, which was previously silently skipped — so a non-conforming
• VAST/DAAST/HTML creative for such a format is now caught at validation instead of
• at the ad server.
• Creatives for adapter/canonical formats (e.g. Snapchat) no longer fail
• validation when the format’s per-platform creative agent is unreachable. The
• format spec is now resolved from the format declarations the storefront adapter
• already provides on the product (format_options) before falling back to the
• agent, so a retired or unavailable creative-agent host can’t block a creative
• whose spec we already hold. Genuinely unknown formats still return a clear
• “format not found” error.
• Refreshed the seller Signals widget with a new header and tabbed layout, plus a collapsible Adapter capabilities panel that surfaces what your connected ad server supports for signals — mapping kinds, source types, value types, and grouped (include/exclude, AND/OR) semantics. The panel is driven by the adapter’s own capability manifest, so it reflects each adapter accurately rather than assuming a single ad server.
• Added a Signal components entry to the seller menu that opens the Signals widget directly. When you have more than one ad server connected, the widget includes an ad-server picker so you can browse and author signals on each one (two ad servers of the same type are distinguished by network code), and switch between them in place.
• Storefront budget updates now retry version activation on transient lock contention before giving up, and report the buyer’s update_media_buy task honestly: the task completes when the new budget is live (including when a prior attempt already applied it) and fails only when the change genuinely never landed. Previously a never-staged update could be falsely reported as completed.
• Buyer product discovery (get_product_details) now surfaces a product’s
• canonical format_options (format_kind / format_option_id) alongside the v1
• product cards, so buyers can reference a format without the per-platform
• creative agent_url. The storefront adapter already provides these; the read
• path now carries them.

​

3.6.0 — June 28, 2026 at 5:44 PM UTC

• Retry the creative asset media probe on transient read failures so uploaded image/video/audio dimensions and specs are reliably detected and persisted. Previously a transient network/timeout/5xx while reading the freshly-uploaded file could silently drop width/height/codec with no backfill.

​

3.5.0 — June 28, 2026 at 4:39 PM UTC

• A posture you pin as the storefront’s learned default now sticks: the Merchandising Agent will not relearn over a pinned default, even as it keeps learning from outcomes, until you change it. Clearing the default returns it to agent-managed so the agent can learn a new one again. This makes the operator override durable once automatic learning is enabled for a storefront.

​

3.4.0 — June 28, 2026 at 2:33 PM UTC

• Ad-server provisioning probe failures now carry their recovery on the tool result. When a storefront_api_call operation fails with a structured upstream code (e.g. ADAPTER_PERMISSION_DENIED, ADAPTER_NETWORK_NOT_FOUND), the error response now surfaces that upstream code and the upstream remediation hint — so a seller’s agent gets precise next steps at the moment of failure instead of a generic validation message. Murph’s storefront-setup guidance no longer hard-codes the per-error-code remedies; it relays the remediation the result carries and keeps the operator out of raw adapter internals.

​

3.3.0 — June 28, 2026 at 2:14 PM UTC

• Storefront adapters now align to the AAO registry’s canonical model: the
• deprecated per-platform creative-agent advertisement (the creative_agent_url
• field in generated adagents.json and the buyer-facing list_creative_formats
• catalog surface) is removed, and each adapter’s publisher domain is aligned to
• the domain the registry publishes (e.g. Snap ads.snap.com → snapchat.com,
• Meta business.facebook.com → facebook.com). Creative formats are discovered
• canonically via get_products format_options; the registry already publishes
• these formats canonically with no creative agent.
• manage_esa_signal gains an update action to edit an existing signal (a full replacement, like create), and its validate dry-run now previews an update when given a signalId (otherwise a create). The update write is confirmation-gated like create/delete.
• ESA ad-server connection errors now carry structured recovery. The test_esa_connection and get_esa_status storefront operations classify adapter-probe failures (permission denied, network-code not found, invalid credentials) as 400 VALIDATION_ERROR with the upstream ADAPTER_* code and remediation hint — matching connection creation — instead of a generic 503 Service Unavailable. Murph’s ESA tools surface that code and remediation in their results, so a seller gets precise next steps when a provisioning probe fails.
• Author buyer discounts conversationally through Murph and the storefront API.
• Discounts are structured rate-card objects keyed to one of a buyer’s two
• identities: a brand discount (the advertiser or its house, e.g. nike.com
• reaching Converse) or an operator discount (the buying agency/DSP or its
• holdco, e.g. wpp.com), set via the required scope field. Each resolves up the
• buyer’s brand hierarchy; the nearest ancestor wins within an axis and a brand
• discount beats an operator one. create_house_discount and
• update_house_discount are typed storefront operations (list/delete reachable
• through the storefront API), and (houseDomain, scope) is unique per storefront
• so the same domain can carry both a brand and an operator discount. New
• documentation frames these as the structured discount rail alongside buyer
• instructions (the tool for operator-and-brand intersections, country terms, and
• freeform notes), including how they compose and the wholesale-cost floor.
• The storefront media-buy forward worker no longer re-attempts a still-undelivered approved buy indefinitely. It now stops retrying a buy whose source forward has not succeeded within 6 hours of approval — on a wholesale forward failure the buyer was already notified on the first attempt, so the further re-attempts only burned upstream calls. Buys keep retrying within the window so a transient source outage still recovers automatically.
• Sellers can now clear or pin the Merchandising Agent’s learned default negotiation posture. Ask your agent to clear the saved default (revert to none) or to pin a specific posture yourself — the saved reason then reads “Pinned by you”. The learned default remains a fallback the agent uses only when it has no fresher read for the buyer in front of it, and your operating instructions always take precedence. The learned-default reason now reads with a friendly posture label (e.g. “Hold value booked 64% over 14 runs”).
• The storefront signal create endpoint (POST /esa/{esaId}/signals) now accepts ?dry_run=true, which validates and previews a signal draft via the sales agent’s dry-run route without persisting it (returns { valid, issues, preview }).
• Seller analytics now surfaces the Merchandising Agent’s learned default negotiation posture — the rule the agent saves for itself once a posture has been converting consistently. The sellerAnalytics.learnedDefault payload (and the “What your agent learned” panel) shows the saved posture, why it was learned, and when. The agent uses it only as a fallback when it has no fresher read for the buyer in front of it — never a forcing override — and your operating instructions always take precedence.
• A media buy budget update that is forwarded to the inventory source but then fails to activate on the storefront side (the new budget version doesn’t flip live) now terminalizes the buyer’s update_media_buy task with a failed webhook instead of leaving it open indefinitely. The failure is reported with a distinct reason so a buyer can tell “the update reached the source but the live budget didn’t change” apart from “the source rejected the update” — and it is never falsely reported as completed, since the live buy is still on the old budget. Previously a push-only or polling buyer was left with no resolution at all on this path.

​

3.2.1 — June 27, 2026 at 9:41 PM UTC

• Creatives can now be assigned to products that declare formats only as canonical
• format_options (no v1 format_ids). Creative↔product format matching now folds
• each product’s format_options[].format_option_id into its accepted format set,
• so a creative whose format_id.id equals a product’s format_option_id matches
• by that exact canonical id — fixing assignment to v2-native catalogs (e.g. Snap)
• that previously reported “no declared formats” or filtered out every creative.

​

3.2.0 — June 27, 2026 at 8:26 PM UTC

• Approved creatives that fail to forward to an inventory source are now retried automatically (bounded) instead of being stranded after a single attempt, and the buyer’s sync_creatives webhook fires on the terminal outcome. A transient source failure is retried in the background for up to 30 minutes; on eventual delivery the buyer gets the approved webhook, and if the forward is structurally impossible or the retry window is exhausted the buyer gets a failed notification (with a generic message — the inventory source is never disclosed) so a push-only buyer is no longer left believing an undelivered creative is live. Previously an approved-but-undelivered creative produced no buyer notification at all.
• manage_esa_signal with action: "validate" now runs through the sales agent’s dry-run route, so it returns a preview of the signal (what buyers would see) alongside the validation result — and surfaces would-be create/update conflicts as issues — all without persisting anything.
• Sellers can now set a discount scoped to a corporate house. A discount keyed at a house (e.g. nike.com) automatically reaches every descendant — so it applies to a converse.com buy that rolls up to it — and a discount can also be keyed at an exact brand or operator domain. It matches on either the buy’s advertiser brand or its buying operator. When more than one applies, the nearest node in the corporate tree wins (a brand-specific discount beats its house’s; a parent never overrides a child), and the brand dimension takes precedence over the operator dimension. Author them through the new /api/v2/storefront/house-discounts endpoints (list, create, update, delete). The discount is applied at product discovery and always floored at the wholesale cost.

​

3.1.0 — June 27, 2026 at 6:01 PM UTC

• Reduce repeated no-op sync_accounts calls to third-party storefront inventory sources by reusing a prior successful account sync for unchanged account payloads.
• dryRun: true on create_esa_product / update_esa_product now runs through the sales agent’s single dry-run pass — the same validation and preview a real create or update would produce, with nothing persisted. An update dry-run also checks the product you’re editing, so it surfaces not-found and inventory-profile conflicts before you commit. A dry-run check no longer asks for write-confirmation (it changes nothing); only the real commit does.
• Fixed ask_murph returning an invalid MCP result (error -32602) whenever a turn surfaced a widget. The embedded UI resource now carries the widget HTML inline, so MCP clients receive a valid tool result instead of a protocol error.
• Fix update_media_buy emitting a wire-invalid format_id (agent_url: "", or a missing agent_url) when falling back to a product’s declared formats. The AdCP format-id schema requires a real agent_url, so a forged empty value produced a reference the sales agent could reject. The update now drops any product format that lacks a usable agent_url/id instead of forging one.
• Fixed a bug where Murph’s write-confirmation prompt (“reply with the confirmation phrase…”) was sometimes replaced with an unrelated “I can’t take credentials in chat — open the secure form” message. The credential-safety check no longer fires on confirmation turns, which carry no secret.
• Validating or previewing a wholesale product now surfaces an advisory warning when a declared publisher property (by id or tag) isn’t found in the registry or on the publisher’s live adagents.json — usually a typo. This is a warning only — it never blocks authoring. It’s lag-aware (a publisher that exposes no property list yet is not flagged) and skips publishers that haven’t authorized the agent, since the authorization advisory already covers those.
• Seller analytics now shows what your Merchandising Agent learned: which negotiation posture is actually converting, and whether following its own history-derived recommendation booked better than diverging from it. This surfaces the postureConversion data in the seller-analytics widget (both the Ask Murph panel and the seller dashboard) and documents it in the seller analytics reference.
• Reduce production Sentry noise from known Slack setup drift and harden several root causes found in prod triage, including catalog cache upserts, Murph conversation creation races, invalid Cloud Function metric values, creative sync source-health diagnostics, and indexes for scheduled health/insights jobs.
• Storefront media buys and updates that a buyer submits with a push_notification_config now fire the buyer’s AdCP task webhook when the inventory source resolves acceptance asynchronously — on final acceptance, terminal rejection, and the pending-acceptance timeout. Previously only the operator-approval path emitted these webhooks, so a buyer that relied on push delivery (rather than polling tasks_get) was never told the outcome of an asynchronously-settled buy or update despite our “await your webhook” promise.
• update_campaign now reports which campaign creatives were dropped from each media buy during auto-link. When a campaign creative’s duration or slot doesn’t satisfy a buy’s product format, the cascade drops it (and proceeds with the compatible ones) — previously that drop was silent. The response now includes a droppedCreatives array ({ mediaBuyId, dropped: [{ creativeId, reason }] }) so the buyer can see exactly what wasn’t applied and fix or resubmit those creatives.

​

3.0.0 — June 27, 2026 at 7:16 AM UTC

• Fix Murph stalling when creating products or signals on an embedded ad-server source. It now validates, previews, and proceeds to call create — the in-chat Approve control is the confirmation step — instead of repeatedly validating and never creating. The ad-server source widget’s draft buttons drive to creation rather than asking to confirm beforehand.
• Prevent duplicate managed FreeWheel ESA connections from bypassing the duplicate check when authenticated with a client ID.
• Remove the managed ad-server source provisioningStatus field. The pending → provisioning → active → failed → deactivated lifecycle was a stored state machine that nothing reliably advanced (sources stranded in provisioning indefinitely) and that misrepresented usability. A source’s enabled/disabled state is now conveyed solely by deactivatedAt (null = enabled), and whether it is live/sellable is derived from upstream facts via the managed-source status (operational.isLive). The provisioningStatus field is gone from the ad-server connection and managed-sales-agent responses under /api/v2/storefront/inventory-sources.
• The managed-sales-agent summary now also exposes lastErrorCode — the machine-readable classification of the most recent provisioning failure (same vocabulary as EsaConnection.lastErrorCode), or null when there has been no failure.

​

2.201.0 — June 27, 2026 at 6:49 AM UTC

• Auto-linking campaign creatives to existing media buys no longer fails all-or-nothing when one campaign creative doesn’t fit a buy. The auto-sync now drops creatives whose duration or slot doesn’t satisfy the buy’s product format and proceeds with the compatible ones (it already dropped format-mismatched creatives this way) — so a single incompatible campaign creative can’t block every other creative from syncing to that buy. Dropped creatives are logged for the operator.
• Media buys now validate the full set of attached creatives against each product’s format requirements (duration, dimensions, slot types) on both create and update. Previously a creative could skip the duration/slot check depending on how it was attached — a campaign creative auto-linked into a new media buy on create, or a creative attached per-package via packages[].creative_ids on update — so a creative whose duration didn’t fit a product’s slot (for example a 15s creative on a 30s-only slot) could slip through to a downstream ad-server rejection instead of being flagged up front. Both paths now run the same gate that top-level creative assignments already did.
• Agent discovery now surfaces a publisher’s self-published creative formats. When a publisher’s adagents.json resolves, the discover-agents response includes publisher.formats (the AdCP 3.1 formats[] inventory-identity catalog), read directly through the publisher’s own canonical document — never assembled or stored by the platform. Absent when only the registry mirror resolves; an empty array for a pre-3.1 file that declares no formats.
• Buyer product discovery now forwards quick/long wait windows through storefront chains and returns structured timeout and upstream incomplete signals so agents can ask before retrying slow storefronts with a longer wait.
• create_esa_product and update_esa_product now accept dryRun: true to check a draft and return validation + preview without persisting — one dry-run step instead of separate validate/preview calls. validate_esa_product / preview_esa_product remain as deprecated aliases.
• Agent discovery now resolves a publisher through a single resolver that reports provenance. The discover-agents response carries the registry’s hosting verdict and a freshness block indicating whether the authorization verdict came from the registry’s crawl (source: "registry") or the publisher’s live adagents.json (source: "live_origin"), along with the registry’s last-crawl time. When the registry’s crawl lags a publisher’s live file, the platform now asks the registry to re-crawl so its mirror converges, instead of silently overriding the stale verdict.
• Validating or previewing a wholesale product now surfaces an advisory warning when the product declares no publisher properties (it hasn’t said which publisher inventory it covers). This is a warning only — it never blocks authoring; declaring publisher properties is recommended, not required. It complements the existing publisher-authorization advisory.
• Validating or previewing a wholesale product now surfaces an advisory warning when a declared publisher’s live adagents.json hasn’t authorized the storefront’s sales agent. This is a warning only — it never blocks authoring (publisher authorization isn’t required at this distribution stage), and it reads the publisher’s live adagents.json (not the lagging registry mirror) so a not-yet-crawled publisher isn’t falsely flagged.

​

2.200.0 — June 26, 2026 at 9:43 PM UTC

• Clarify the AAO check when connecting an inventory source. The connect-time gate verifies the agent’s own AAO registration; its messaging now says so explicitly and distinguishes it from a publisher’s authorization (adagents.json) to sell inventory, which is enforced later when traffic is served. The “agent not registered” rejection (400) is also clearly separated from a “registry temporarily unreachable” outcome (503, retryable), and both are documented on the create-inventory-source reference.
• Learn each GAM inventory source’s approve-capability from real order outcomes and use it to stop stranded buys. When a create is structurally blocked at the ad server’s approval step (the service account lacks Approve + Overbook, or the network mandates manual approval), the source is marked blocked: the storefront then refuses to enable auto media-buy approval — telling the operator to grant Approve + Overbook in Google Ad Manager — instead of accepting an auto setting it can’t honor, and surfaces a readiness remediation. It recovers automatically once a subsequent order is created without an approval block, after the permission is granted. Detection is lazy — there is no synthetic probe order; the first real order is the probe. (This covers the approval axis — Approve/Overbook permission and mandatory-approval networks — not forecast or inventory availability.)
• When a managed inventory source rejects a creative or media-buy request as invalid, the buyer now sees the source’s actual reason (for example, “creative needs a 4:3 640×480 rendition”) instead of a generic “rejected as invalid” message — so the problem is actionable. The storefront operator owns the managed sales agent, so its validation rejection is the seller speaking to the buyer and is passed through. Authorization and transport failures stay generic (they are credential/plumbing problems, not a seller message), and rejections from cross-storefront linked sources remain redacted. Validation rejections are now identified by structured signals only (never a free-text message match), so a transport error can never be mistaken for a validation rejection.
• Murph now gathers a required creative format up front (via list_esa_creative_formats) before validating an embedded sales-agent product, so sellers no longer hit an avoidable “missing creative formats” round-trip when authoring a product.

​

2.199.0 — June 26, 2026 at 8:51 PM UTC

• Storefront inventory-source compliance is now actionable instead of inscrutable: it surfaces AAO’s advisory observations (the observations array was previously always empty), labels skipped/not-run compliance tracks clearly (“not run” / “no coverage”) instead of showing a blank track at 0 ms, and adds an explicit advisory when a registered agent has no scored compliance tracks yet (coverage-gap skips or a pending run). Compliance remains informational and never blocks going live.
• AAO inventory-source compliance is now informational at go-live: a non-passing compliance verdict no longer blocks a storefront from going live and transacting. The verdict is still surfaced prominently as an advisory warning (in storefront readiness and Murph’s health snapshot) so you can see and address it. Connect-time registration and the agent-active readiness check are unchanged, and per-publisher authorization remains enforced.
• Discover-agents now explains a null AAO member instead of collapsing every cause into the same null. Each of operator and publisher carries a lookup_status: member, not_member, scope_limited (looked up without your AAO key, so members-only records may be hidden), or lookup_failed (the registry was unreachable — retry with refresh). Publisher lookups have no visibility tiers, so a null publisher member is always definitive. Transient lookup failures are no longer cached, so a refresh reflects a recovered registry immediately.
• Add AdCP integration docs, split by perspective: “Connect your sales agent” (seller/storefront side — how Interchange uses AdCP to integrate your agent as a storefront source, AAO compliance, and a governance/audit FAQ) and “How Interchange uses AdCP (buy side)” (cross-seller discovery and campaigns). Each pairs Interchange behavior with the AdCP spec.
• Buyer campaign targeting can now list targeting dimension dictionaries, resolve localized or messy Nielsen DMA labels such as “LA DMA” and “Dallas/Ft. Worth” to code candidates, and request geo metro display labels on campaign reads with fields=geo_metro_names.
• Creative attachment now checks a creative’s duration against the format slot’s required duration_ms range before a media buy is created or updated. A creative whose duration falls outside the slot’s range — for example a 15s video on a 30s-only slot — is rejected up front with a clear reason, instead of being synced and then hard-rejected by the publisher’s ad server. Linked creative assets accept an optional duration_ms so a VAST tag’s duration can be declared, and uploaded video duration is measured automatically. Creatives whose duration is unknown are not blocked.
• Creative recognition now probes video and audio specs at upload, not just image dimensions. When a buyer brings a video or audio creative, the upload reads its intrinsic specs and surfaces them in the recognition card alongside the file:
• Video: dimensions, duration, codec, frame rate, overall bitrate, and container (MP4/MOV).
• Audio: duration, codec, sample rate, and bitrate (MP3, AAC/M4A, WAV).
• Detected specs are persisted on the asset and returned on the creative manifest (duration_ms, codec, bitrate_kbps, frame_rate, sample_rate, container), so they’re available to the buyer and to placement auto-mapping without re-reading the file. Probing is best-effort: an unreadable or unsupported file still uploads, just without the extra specs. Dimensions continue to be confirmed against the filename, with disagreements flagged.
• Audio and QuickTime creatives now upload cleanly across both surfaces that feed recognition — the in-chat dropzone and the campaign creative-assets page. The chat dropzone accepts MP3, WAV, M4A, and .mov alongside MP4 (previously only MP4), and the creative upload endpoint now accepts .m4a and the common .wav/.mp3 MIME variants (e.g. audio/x-wav, audio/x-m4a) that some browsers send, normalizing them to a canonical type so they classify and probe correctly instead of being rejected as an unsupported file type.
• Reduce database timeout exposure on the agentic database: replace the per-row LATERAL JOIN in storefront diagnostics with a set-based CTE, eliminate a duplicate COUNT(*) query in agent activity listing, add expression indexes on murph_test_runs task_id paths, and raise the agentic DB connection pool ceiling in production.
• The diagnostics window object now includes activityTruncated: boolean. When true, the 200-row sample cap was reached and recentActivity[] shows only the most recent 200 rows — performance rates and counts are derived from that sample, not the full window.
• Package-level budget updates for media buys backed by ESA storefronts are now correctly forwarded to the upstream source.
• Fix auth failure that blocked cancel (and silent false-ACTIVE on execute) for managed-storefront sales agents. The cancel path now routes in-process for platform-internal storefronts instead of calling their public OAuth-gated URL. Execute no longer marks a campaign ACTIVE when no upstream media_buy_id was returned.
• Fixed an intermittent “MCP app failed to initialize” error that could leave in-chat widgets blank. The widget-to-host handshake now arms when the widget frame mounts instead of waiting for its load event, so a large widget bundle can no longer send its initialization before the host is listening.
• Fix Murph chat attachments getting stuck on a loading spinner and never attaching. A drop cancel-guard was set when the chat unmounted but never re-armed on remount, so after a remount (or React StrictMode in dev) every dropped file silently skipped the attach step and spun forever.
• Fix source-webhook callback URL using wrong customer ID for storefront-routed buys. Async accepts (e.g. Ozone manual moderation) now route to the buyer’s customer context instead of the storefront’s.
• Murph now grounds answers in the AdCP protocol spec alongside the Interchange docs. The docs index is built from both corpora (the AdCP spec is fetched fresh at build time so it tracks the latest), search results are tagged by source and balanced so the larger AdCP corpus can’t crowd out our own docs, and Murph cites the AdCP docs for protocol questions and the Interchange docs for platform behavior.
• The Murph chat composer now surfaces each attaching file as a chip with a spinner in its leading slot while the file is read and encoded, so attaching large files no longer feels unresponsive. Sending is held until encoding finishes so a file can’t be dropped from the turn. The attach-file button is now a plus icon.
• Raise the per-turn chat attachment limit from 4 to 5 files. The 50 MB total-size cap per turn is unchanged.

​

2.198.0 — June 26, 2026 at 2:29 PM UTC

• Bound synchronous buyer product discovery so slow sales agents degrade instead of holding REST discovery responses open past client and deploy-gate timeouts.
• Product discovery now defaults to a 30-second quick wait, exposes opt-in longer waits, and reports storefront response timing so buyers can debug slow or timed-out storefront calls.
• Murph is now added automatically to newly provisioned Slack support channels and those channels are connected to the right customer account. A scheduled customer setup invariant reconciler also keeps existing Slack support channels repaired if Murph membership or the customer binding drifts.
• Make ESA product authoring resilient to stale creative-format catalogs and partial data. A single malformed or partially-authored wholesale product no longer blanks the entire seller product list — valid products are still returned and the bad row is logged. Product validation downgrades a “creative format not found” error to a warning when the format is present in the source’s live creative-format catalog (so a stale validator snapshot no longer blocks authoring a format that is actually available), tolerates variation in the validator’s message phrasing, and logs clearly when it cannot. When saving a product (create or update) is rejected because a creative format is missing from the source’s discovered catalog, the seller now gets an actionable message — distinguishing a stale discovered catalog that needs refreshing (the format is available in the source’s live catalog) from a format the source genuinely doesn’t support — instead of a raw upstream error.
• Fixed storefront async budget-update rail: a source-rejected update no longer leaves a wrong budget live, and the seller spread ledger is now re-booked when an async update confirms. On a multi-source buy, a budget version is no longer promoted live when any leg was rejected, and a failed activation no longer reports the update as succeeded.
• Buyer product discovery now applies the quick/long wait deadline to the full per-storefront agent task, including account sync and in-process storefront dispatch, so wholesale discovery cannot hang beyond the requested wait.
• Legacy non-storefront product discovery has been removed. The product_discover and media_product_list tools on the legacy /tools endpoint no longer return products from standalone sales agents. Product discovery now runs exclusively through storefront-backed discovery (POST /api/v2/discovery/discover-products), which surfaces each storefront once rather than returning both a storefront and its underlying direct agent. Buyers still integrating against the legacy /tools discovery tools should move to the storefront discovery surface.

​

2.197.0 — June 26, 2026 at 11:08 AM UTC

• Add the browse_ad_server_selectors storefront MCP tool. It opens the in-chat inventory browser over an embedded sales agent’s ad-server inventory: call with an esaId to list the adapter’s available selector types, or add a selectorType to browse selectors of that type (narrowed by query/parentId, paginated with cursor). As a standard MCP Apps tool — it declares its widget binding and returns the inventory as structuredContent — any MCP host renders the inventory-selector surface from the tool result, not just the in-app guide.
• ask_murph now surfaces a turn’s primary widget as a conformant MCP-UI tool result — an embedded ui:// resource plus the widget’s render data on structuredContent — so any MCP-UI host (Claude, ChatGPT) renders the widget from the result, not just the in-product drawer. Previously only the seller open_<widget> directive was surfaced as a resource; discovery, creative, inventory, analytics, and escalations widgets were invisible to external hosts. One primary widget is chosen per turn (an MCP-UI result carries one render payload); the in-product experience is unchanged.
• Paced campaigns now correctly split into per-period packages on first execute. A regression caused the first execute of a campaign with pacing periods to ship a single flat package instead of one package per period, so the configured weekly schedule was silently ignored. Executing a paced campaign now produces the expected per-period packages.
• Clarify campaign creation guidance so buyers leave campaignType unset by default and let the first media buy lock the campaign type.
• Expose sanitized ADCP transport request and response diagnostics for source debug calls.

​

2.196.1 — June 26, 2026 at 9:40 AM UTC

• Fix Murph storefront diagnostics so seller-scoped MCP sessions can access their sales-agent debug calls after customer switching, and allow source diagnostics to be filtered by either source slug or source row id.

​

2.196.0 — June 25, 2026 at 7:13 PM UTC

• Buyer creative v2: buyers can bring creative into chat and get it onto a campaign, whether or not they name the campaign up front.
• Drop a zip bundle of creatives and it unpacks into one creative per file, each titled from its filename and auto-mapped to a placement by size (images today). Unsupported files, SVG (active content), manifest/CSV sidecars, and macOS junk are skipped.
• Upload then pick later: uploads are saved as advertiser-level creatives up front (building on the advertiser creative library), so picking a campaign in a later turn — via the picker, a typo’d name, or “a campaign” left vague — still attaches and maps them. No more lost upload or picker loop.
• Name the campaign with the upload and it attaches directly, skipping the picker.
• Flagged behind buyer-creative-v2, off by default.
• Fix 500 error on storefront source webhooks caused by referencing a non-existent customer_id column on storefront_inventory_source — the column belongs to storefront_agent_source.
• Fixed inbound ADCP source webhooks returning 500 INTERNAL_ERROR for every callback. The source resolver scoped the customer filter on the wrong table (the inventory source, which is storefront-scoped and has no customer column) instead of the agent source that actually carries it. As a result, create_media_buy activation callbacks and media_buy_delivery reports from third-party sources were rejected and not ingested; they now resolve and process correctly.
• Fix a media-buy activation edge case: an approved budget-change update could activate a brand-new buy that was still awaiting its initial source acceptance, flipping it live outside the normal create path. Storefront version activation now only promotes a budget change that is staged on top of an already-live version, leaving an unaccepted new buy untouched.
• Fix catalog warm crash when a seller returns the same product_id on multiple pages. The error appeared in Sentry as a duplicate key violation on storefront_catalog_wholesale_products_pkey. Duplicate products are now skipped with a warning log so the rest of the catalog persists correctly.

​

2.195.1 — June 25, 2026 at 3:57 PM UTC

• update_esa_product now surfaces the salesagent’s validation detail when a product update is rejected with a 400. Previously Murph received a generic “salesagent PUT … returned 400” with no indication of which field failed or why. The salesagent returns a {valid: false, issues: [{field, message}]} body on these rejections (e.g. format_missing_duration for video_standard on GAM requiring duration_ms); the error parser now reads issues[] in addition to errors[] so the full field-level message reaches the operator.
• Fixed a bug where the Notifications Settings modal could not be reopened after being closed. Closing the modal now clears the settingsSection query parameter so subsequent clicks correctly reopen it.

​

2.195.0 — June 25, 2026 at 2:32 PM UTC

• Video creative assets now carry a bitrate. The server estimates a hosted video’s bitrate from its file size and duration and forwards it on the creative manifest as video_bitrate_kbps (kilobits per second), so sales agents that require a bitrate on video asset metadata (e.g. Google Ad Manager) can traffic the creative. The video and audio asset bitrate fields are now video_bitrate_kbps / audio_bitrate_kbps (integer kbps), aligning with the canonical AdCP naming.
• Fix creative sync sending raw landing page URL instead of Scope3-wrapped click tracker URL to sellers.
• Fix campaigns to embedded storefronts silently reporting success when the inventory source rejects the forwarded buy on authentication. A forwarded media buy that the source refuses on auth — an auth-required status, an HTTP 401/403, or a failed task naming an identity/permission problem — now fails with a clear not_authorized error instead of being reported as accepted. Buyers are no longer told a campaign is live when it never reached the storefront.
• Creatives assigned to a campaign via the advertiser-library join table now appear correctly on the campaign card and count toward format coverage.
• Campaign type (DECISIONED vs ROUTED) no longer has to be chosen up front. campaignType is now optional on campaign creation: leave it unset and the campaign is created untyped, then locks to the type of its first media buy — a buy through an adapter storefront locks it to ROUTED, every other buy to DECISIONED. Once set, the type is immutable and later media buys of the other type are rejected, so a single campaign still can’t mix the two. Set campaignType explicitly only when you want ROUTED on a non-adapter agent before adding any media buy.
• Fix execute gate using stale product-level budget instead of package budgets. When a storefront accepts a media buy and creates sub-packages with different amounts than originally requested, the execute reconcile check now reads the same packages-aware allocation as the buyer-visible remaining budget, so available budget shown to buyers matches what execute will honor.
• Fix existing-user signup so an invitation join lands on the invited org. When an existing user (typically an OAuth/SSO re-signup) accepts an invitation to an org we cannot resolve by id, domain, or tenant, provisioning now resolves the invited org from the invitation and grants the invited role there — instead of falling back to the user’s oldest membership and reporting them against the wrong org. The oldest-membership fallback is reserved for genuinely idempotent calls with no invitation.
• Source diagnostics now include partner-safe debug IDs, bounded time-window lookup, and copyable redacted request details for recent sales-agent failures and timeouts.
• update_media_buy on a storefront now resolves edits a source accepts asynchronously (e.g. parked for manual moderation) instead of reporting a false failure. When a source takes the update out-of-band, the storefront returns a spec-compliant submitted task envelope with a task_id to poll (or await via webhook); the edit is applied to the buy once the source finishes accepting, and the task resolves to completed (or failed if the source rejects it). Previously such an update returned SERVICE_UNAVAILABLE even though the source had accepted it.
• Fix media-buy budget changes not persisting and SCD2 versions losing child-row history.
• Reducing a package/product budget on a live media buy is now recorded locally as the buyer’s intent (it no longer depends on the sales agent echoing the change back, which adapter/GAM/3rd-party AdCP paths don’t do). The change is staged on a new PENDING_APPROVAL version that owns its own duplicated packages and media_buy_products carrying the new budget, while the still-ACTIVE version keeps running its current budget until approval. On activation the version markers flip without deleting or moving child rows, so the superseded version keeps its history. A migration scopes packages uniqueness to (media_buy_id, package_id) so each version can own its package copy. Reads that aggregate budgets across a media buy are scoped to a single live version to avoid double-counting during the approval window, and the campaign ledger commitment is recomputed/posted when an approved budget change goes live.

​

2.194.0 — June 25, 2026 at 12:52 AM UTC

• Agent widgets in the Murph chat no longer repeat as you work — only the most recent widget stays open, at the latest turn, instead of stacking a new copy each time it’s surfaced. Reopening a conversation now restores a single live widget rather than one per past turn.
• Fix AAO compliance reader URL normalization: strip /mcp and /a2a transport path suffixes before registry lookup so storefront compliance checks correctly find agents registered under their bare root URL.
• Fix Murph in-chat widgets (product discovery, creative, inventory, and seller surfaces) rendering as a black box when the operating system is set to dark mode. The widget canvas is now pinned to the host’s theme so content is always visible.
• Murph can now check a domain’s adagents.json directly and resolves managed/network publishers via the ads.txt managerdomain fallback, so domains that host no file of their own (e.g. Raptive/CafeMedia-managed publishers delegating to cafemedia.com) no longer read as “no adagents.json”. The discover-agents response now also reports how the file was resolved (discovery_method, manager_domain, resolved_url).
• Fixed signup notifications so the admins of the organization you join are notified of your signup, even when you accept several invitations at once. Previously the notification could target the wrong organization and report that no admins were found.
• Media buy products in get_campaign now include a formatOptions field with the publisher’s declared creative format requirements. For video products this shows required duration, dimensions, and aspect ratio: use it to tell buyers what creative spec to provide before executing.
• Creative format references are now reconciled to the product’s advertised format when a media buy is created. When a creative’s stored format agent_url does not match the agent_url the matched product advertises for the same format id (for example a bare host on the creative versus an authoritative path on the product), the buy now uses the product’s agent_url for the format-spec lookup and for the format reference sent to the sales agent. This prevents a mismatched creative agent_url from breaking the buy with a validation error. Formats a product does not advertise are left unchanged, so direct (non-storefront) buys are unaffected.
• Deselecting a product in discovery now removes it from a bound DRAFT media buy and frees its budget. Previously a removed product lingered on the DRAFT (still carrying its budget) and was forwarded to the sales agent on execute, so a buyer who dropped a product could still see it submitted to the source. Reconcile now drops the deselected product from the DRAFT before execution, keyed on the durable selection identity, and only ever touches DRAFT (non-executed) buys.
• Murph chat now redraws in-chat widgets and attachment references when a conversation is reopened or refreshed. Product-discovery and creative-iteration widgets persist their data so they reappear on reload (previously only a text recap showed), and files you attached are surfaced as reference chips showing what was sent (the file contents themselves are still not retained).
• Use the storefront media buy id for the utm_media_buy attribution parameter on synced creative clickthrough URLs, so clicks map to the correct buy for storefront-routed media buys.

​

2.193.1 — June 24, 2026 at 5:46 PM UTC

• Apply campaign UTM attribution to creative clickthrough URLs on media buy execution, not only on media buy update, so initial sync to sellers carries the buy and creative identifiers for attribution.

​

2.193.0 — June 24, 2026 at 5:25 PM UTC

• Creative clickthrough URLs synced to sales agents now carry the campaign’s UTM attribution parameters (source, medium, campaign, content, media buy), so per-media-buy and per-creative click attribution works end to end.
• Product discovery no longer drops a sales agent’s entire catalog when the account-billing handshake (sync_accounts) times out or fails. Discovery now falls back to the natural-key account and still fetches products, so a slow or flaky third-party handshake can’t zero out an otherwise-healthy source. Sources that genuinely require a synced account still surface their error to operators.
• Fixed an issue where accepting an invitation during signup could create a duplicate organization instead of joining the organization you were invited to.
• Media-buy attribution now reaches sellers on creative sync: impression and click tracker URLs (and the embedded HTML pixel) carry the resolved media buy id instead of an unresolved macro.
• Murph now surfaces the interactive product-discovery widget in chat when you discover products. Discovered products render as the same selectable card surface used by external MCP hosts — browse, view details, and select products directly in the conversation — and the widget appears above Murph’s reply. Instead of repeating the full product list in text, Murph gives a short orientation (totals, price range, recommended plans) and steers you to next steps.

​

2.192.0 — June 24, 2026 at 3:09 PM UTC

• Text slot validation now fails with a clear error when format spec is unavailable, instead of silently skipping per-slot length limits.
• create_media_buy and update_media_buy now return ext.source_references — the upstream media buy id (and, for pass-through agents, the source name) that your buy maps to on each inventory source, so you can reconcile against the system that actually serves it. Disclosure is gated: pass-through agents include the source name, the storefront’s own managed agent returns the upstream id under a neutral label, and curated or in-process sources are omitted. The per-source breakdown on these responses now masks the underlying source identity for non-pass-through sources.
• Two ways to manage ad-server products faster. In the ad-server view you can now edit a product’s name and description or delete it inline, without going through a full chat cycle. And for bulk work, drop a product spreadsheet (CSV/XLSX) straight into the chat — the agent reads the rows, validates them, and creates the whole set in one batch, then tells you which landed and which need attention.
• Fixed campaign start_date set to today failing at execution. When a media buy’s start time is today’s midnight, the platform now treats it as “start immediately” (asap) rather than stamping the execution clock as the start time, which ADCP would reject as a past timestamp.
• Fixed duplicate media buys when re-running discovery or execute on a campaign. Composed products are now reconciled by a durable selection identity that stays stable across the targeting variations that previously made the same inventory look like a brand-new product, so re-binding or re-executing a campaign no longer spawns duplicate media buys for the same selection.
• Fixed ESA product validation incorrectly blocking products when a creative format exists in the live catalog but not in the validator’s discovered catalog. The validator’s discovered catalog can become stale after new formats are added to the creative agent. When this mismatch is detected, the creative_format_not_found validation issue is now downgraded from an error to a warning so product authoring can proceed.
• Fixed streamed Murph chat requests preserving selected workspace context, and let watched Slack channel requests reach Murph with supported Slack file attachments.
• Fixed the storefront navigation rail cutting off its menu and reserving empty space for recent chats. The menu now sizes to its content and the recent chats list fills the remaining space, with “New chat” set off from the section navigation by a divider.
• Fixed update_media_buy failing schema validation for sources that require an account field.
• Updated FreeWheel ad-server setup to collect and forward partner-program client ID and client secret credentials.
• Fixed a self-built sales-agent source being falsely reported as “unreachable” and unable to activate. The connectivity probe and capability refresh now reach a PENDING agent’s endpoint to verify it, instead of short-circuiting before the request — so a healthy agent reflects its real connection status and can move to active.
• url_type is now required when supplying a url_asset on the create or update creative manifest endpoints. Previously the field was optional; clients must now explicitly declare the URL classification (clickthrough, tracker_pixel, tracker_script, or vast).

​

2.191.0 — June 24, 2026 at 12:32 AM UTC

• Clearer error when a campaign end date cannot be shortened. The API now lists every media buy that ends after the requested date and explains that active buys have to be shortened first, instead of a generic “update or complete the media buy” message that left buyers unsure what to do.
• Fixed an issue where a campaign’s media buys could show no packages while a pending change was awaiting approval. The campaign endpoint now reports the current packages, products, and budget on each media buy, while still surfacing the pending status on the campaign’s media-buy summary so reviewers can see a change is in flight.

​

2.190.0 — June 23, 2026 at 6:09 PM UTC

• Bulk creative updates can now set format_id and target_format_ids, not just click_url. This lets you retype many creatives to a sales agent’s required format (for example OpenAds display_300x250_nongenerative) in a single call, matched by size, instead of editing each creative one at a time.
• Campaign execution now returns a clear, actionable error naming the affected product when a selected product cannot be funded within the campaign’s remaining media budget, instead of failing later with an internal database error. Raise the campaign budget or reduce other media buys, then re-run execute.

​

2.189.1 — June 23, 2026 at 4:46 PM UTC

• Fixed available account discovery for adapter storefronts after connecting buyer-managed provider accounts.
• Fixed creative approval and assignment handling across the campaign → media buy → storefront flow:
• Creative approval status syncing back from sales agents: operator approvals (delivered as an “updated/approved” review verdict) were being recorded as still-pending and triggering spurious “changes requested” notifications; the per-agent approval status was also written in a different case than the readers expected, so approved creatives could read back as unregistered. Creative status is now derived across every sales agent a creative is synced to, so a creative one routed seller rejected can no longer appear approved.
• Attaching creatives to an active media buy no longer leaves its per-package creative assignments stale (they were silently not updated once a buy went live), so get/list responses now reflect the attached creatives.
• A creative-only change to a routed buy no longer forces an unnecessary seller re-approval.
• Murph now returns a user-friendly “temporarily unavailable” message when the Anthropic API is overloaded (HTTP 529) or encounters a temporary server error (HTTP 500), instead of propagating an unhandled exception.
• Fixed a 500 error when executing or re-syncing a campaign whose draft media buy already exists and the campaign has optimization goals set. The goals are now stored correctly instead of failing with a database serialization error.
• Normalized creative format identifiers during seller sync when a product declares a base format that covers sized variants.

​

2.189.0 — June 23, 2026 at 2:18 PM UTC

• Creating products on an ad-server inventory source from chat now works reliably, and you can create several at once. Ask the agent to build a batch of products (for example from a spreadsheet) and approve the whole set in a single confirmation. Creation continues even if one product fails. You get a clear summary of which products were created and which failed, with the reason, so you can retry just the ones that didn’t land.
• You can now update several ad-server products at once from chat. Ask the agent to change a batch of products and approve the whole set in a single confirmation. Updates continue even if one fails. You get a clear summary of which products changed and which failed, with the reason, so you can retry just the ones that didn’t update.
• Fixed video creatives failing to upload to the ad server (“failed to upload creative”) when a video file was supplied for a VAST slot. The video was forwarded labeled as a VAST tag pointing at a raw MP4, which the ad server’s VAST parser rejected. The video is now correctly sent as a video asset on every upload path — including syncing creatives directly and creating a media buy — not only the format-adapted path.

​

2.188.0 — June 23, 2026 at 1:49 PM UTC

• Murph no longer writes the auto-vs-manual approval mode into the acceptance-policy document. The acceptance policy now covers content rules (which advertisers/creatives are accepted and what needs review); whether creatives and media buys auto-approve is the separate approval setting. This stops the acceptance-policy page from showing a stale “manual review” posture after the approval setting is changed.
• Fixed deleting a media buy leaving the ad-server order live. When a buyer deletes an executed media buy, the platform now cancels it at the sales agent / ad server first (archiving the upstream order, e.g. a GAM order) before archiving locally, instead of stranding an orphaned order.
• Fixed video media buys being rejected by the ad server. When a media buy was forwarded with a video creative, the video asset was sent without its name and pixel dimensions, so the sales agent rejected the buy. The forwarded video asset now carries its name, width, height, and (when available) duration.
• Storefronts can now be paid in more than one currency. A new paymentCurrencies setting lists the ISO-4217 currencies a storefront will be paid in (the primary defaultCurrency is always included). There is no FX — the currency a buyer pays in is exactly the currency the seller is paid in — so a storefront cannot sell a pricing option in a currency outside this set. Product discovery returns products in the buyer’s advertiser currency; if the storefront isn’t paid in that currency it returns no products (rather than ones the buyer could never buy). A media buy is accepted only when denominated in a single one of the storefront’s payment currencies. A storefront that sets no paymentCurrencies keeps its previous single-currency behavior, falling back to its defaultCurrency.
• Murph now shows Approve / Cancel buttons in Slack when an action needs confirmation. Previously a Slack user had to reply with a long confirmation phrase to approve a gated change; now a tap approves it. Only the person who requested the change can approve it.
• Storefront readiness now surfaces the real per-track AAO compliance results (e.g. core, products, audiences) with their pass / fail / partial status and scenario tallies, instead of collapsing every agent to a single track that could report “0 tracks executed”.

​

2.187.0 — June 23, 2026 at 1:12 PM UTC

• Video media buys now carry the product’s exact required duration to the seller. When a product declares a canonical video format with a required duration, the package sent to the sales agent includes that duration (duration_ms_exact / duration_ms_range) alongside the existing format selection, so duration-sensitive video inventory traffics correctly instead of dropping the requirement.
• Product discovery now documents and types the accepted video delivery containers and codecs a seller will accept. For hosted-video formats, formatOptions[].params.containers, params.video_codecs, and params.audio_codecs advertise the allowed values (for example, MP4 with H.264/AAC), so a buyer’s agent can avoid sending a creative that would be rejected downstream. VAST formats intentionally omit these — the codec is carried inside the VAST document. The legacy formats reference array is also now documented on the product response.
• Fixed approval queue action buttons so approving one media-buy approval does not show a busy state on unrelated approvals, and approval decisions now return immediately while source forwarding continues in the background.

​

2.186.0 — June 23, 2026 at 10:36 AM UTC

• Hosted video creatives now carry their duration. The duration is extracted from the video file (including non-faststart MP4s, via a tail read) when a creative is published and when it is adapted to a publisher format, so downstream duration limits — such as a sales agent’s maximum video length — can be checked. A missing duration is non-fatal: the creative still syncs, and only width/height remain required.
• Fixed a crash in the buyer catalogs view that prevented catalog details from rendering when an item count was shown.
• Fixed hosted video creatives failing to sync when they fill a VAST format slot. A hosted video used for a VAST slot is now sent as a video asset carrying its width and height, instead of being relabeled as a VAST tag pointing at the raw video file — which sales agents rejected as invalid (and which dropped the video’s dimensions).

​

2.185.0 — June 23, 2026 at 6:03 AM UTC

• Your business profile now reads as structured cards — the pitch buyers see, plus your channels, regions, verticals, and authorized domains as legible tagged groups — instead of a flat gray list, and “Update profile” is a clear primary action.
• Fixed approved creatives not delivering on approval-gated storefronts. When a seller approved a creative, it was created on the ad server but never associated with the line item, so it could not serve. The storefront approval now forwards the creative’s package assignment to the source, so the ad server creates the line-item creative association.
• Added a manual refresh control to the seller Approvals view, clarified pending media-buy review copy, and surfaced prior approval decisions with reviewer notes in the media-buy detail pane.
• Third-party storefronts can now leave Interchange merchandising tools off without being blocked by storefront-managed approval setup, and sellers can opt those tools back in from the Sales agent widget or Storefront settings.

​

2.184.3 — June 22, 2026 at 10:55 PM UTC

• Fixed an issue where sync_creatives calls could fail with IDEMPOTENCY_CONFLICT when the set of package assignments changed between calls. The upstream idempotency key now includes a content fingerprint covering the creative and assignment payload, so different payloads always produce a distinct key even when the caller reuses its own base key.

​

2.184.2 — June 22, 2026 at 9:48 PM UTC

• Fixed a crash when updating a storefront’s publisher domain and operator domain in the same request.

​

2.184.1 — June 22, 2026 at 9:05 PM UTC

• Fixed creatives being synced to a seller without the media buy id or package assignments for media buys placed through a storefront. The storefront sync dispatch forwarded only the creatives and account, so the storefront fanned them out to every connected source unattached to a buy or package. The media buy id and per-package assignments are now forwarded through the dispatch, so creatives route to the buy’s source(s) and attach to their packages on the seller.

​

2.184.0 — June 22, 2026 at 8:11 PM UTC

• Signing up with an email domain that already has an account but no owner now lets the first verified user from that domain claim the account and become its owner. Previously, only brand-new domains could create an account: if an account already existed for the domain but had no owner, the first user was blocked and routed to request access (which no one could approve). Accounts that already have an owner are unaffected.
• Fixed creatives being synced to a seller without their package assignments for media buys placed through a storefront. The assignment step resolved formats from the wrong product record and produced no assignments, so creatives reached the seller unattached to any package. It now resolves each package’s own product formats and routed sales agent, so creatives are assigned to their packages on the seller for storefront-routed buys.

​

2.183.0 — June 22, 2026 at 8:02 PM UTC

• Fixed delivered spend (and other delivery metrics) being lost when a media buy is edited or re-synced. Delivery metrics are now carried forward to each new version of a media buy, and a one-time backfill restores metrics on existing media buys, so reported spend stays accurate after updates.
• Fixed client-side validation in the credentials form to allow Basic Auth with an empty password.

​

2.182.1 — June 22, 2026 at 6:16 PM UTC

• Fixed standalone creatives (submitted to a storefront without a media buy and held for manual operator review) failing to reach the underlying seller on approval. The forwarded sync_creatives request was missing an account, so it was rejected before delivery. The buyer’s account is now preserved on the review record and reused when the approved creative is forwarded.

​

2.182.0 — June 22, 2026 at 5:33 PM UTC

• Inventory sources that use basic auth or an API key can now be registered without supplying the secret up front. The source is created pending credentials, and the credential is collected afterwards through the secure in-chat form rather than being typed into the conversation. OAuth and no-auth sources are unchanged.
• Fixed two bugs in the storefront creative approval evaluator: the evaluator was incorrectly using the seller’s own brand ID as the expected brand when validating buyer-submitted creatives, and a brand metadata mismatch was treated as a hard block that prevented approval entirely. Brand mismatches now escalate to manual review instead of blocking.
• Fixed creative approval getting stuck in pending when ad-server forwarding fails. Operators can now approve a creative even when the source forward encounters a transient error — the approval decision is recorded immediately, and forwarding is retried separately.
• External sales-agent sources now accept Basic Auth credentials with an empty password.
• Murph now says “Scope3 has been notified” when it files a report and tells users they can track status under the ? menu. The offer to notify Scope3 also uses plain language (“Would you like me to notify the Scope3 team?”) so users know what the action means.
• Action buttons across the seller widgets now name what they do — “Fix this run”, “Build my profile”, “Update profile”, “Get a recommendation” — instead of naming the assistant (”… with Murph” / “Ask Murph”). The agent still does the work; the button just says the outcome.

​

2.181.0 — June 22, 2026 at 3:44 PM UTC

• Fixed a bug where hosted MP4 video creatives could not be forwarded to sales agents. Dimensions for MP4 video assets are now extracted from the file’s ISOBMFF container at upload and execution time, so video creatives proceed through media-buy execution without a “numeric width and height” validation error.
• Fixed service tokens showing no active agents when agents became active after the token was created. A token’s active agent list is now kept current whenever an agent is registered, activated, disabled, or reassigned, and existing tokens have been backfilled.
• Fixed an issue where creatives synced to a media buy placed through a storefront could fail to reach the underlying seller. The forwarded sync_creatives request was missing the account the media buy was created under, so it was rejected before delivery and the buy could stay in pending_creatives. Creative syncs now reuse the correct per-source account.
• Inventory-source health alerts are now owner-aware. When an official Scope3-hosted adapter (e.g. Pinterest, Reddit, Snap) has a runtime outage, Scope3 is alerted internally instead of notifying the seller about infrastructure they don’t operate. When the issue is the seller’s own adapter credentials, they still get a notification telling them to reconnect. Sources the seller operates directly are unchanged.
• Sellers now receive an “all clear” notification when a previously-unhealthy inventory source recovers, closing the loop on the unhealthy alert. It fires only for sources we actually alerted on, exactly once per outage, so it never spams.
• When a sales-agent connection check fails, diagnostics now report the specific failure — the HTTP status, whether it was an authentication/audience rejection, a timeout, or a network/DNS error, plus a redacted response excerpt — instead of a generic “not reachable” message. This makes it possible to tell an OAuth token or audience mismatch apart from an endpoint that is simply down.

​

2.180.0 — June 22, 2026 at 2:30 PM UTC

• Your acceptance policy now reads as a traffic-light — what you Accept (green) vs Decline (red) — instead of one flat gray list, so the two sides of the policy are clear at a glance. “Update policy” is now the clear primary action.
• Murph in-chat approval controls are more reliable. The window to approve a pending action is longer, so a review that takes more than a few minutes no longer lapses mid-decision, and a lapsed approval now shows an explicit “expired — ask again” state instead of a blank step that looked like the controls were missing. A pending approval also survives when the click that approves it is handled by a different server instance or after a restart, so approvals are no longer silently stranded. Approving an action started while signed in as another user (support-assisted setup) no longer fails with a confirmation error.
• Fixed several notification types that were silently failing to deliver — most notably the “your ad-server connection needs action” alert for sellers, plus outcomes-agent registration/update notices. These types were defined in the API but missing from the database’s notification-type list, so the platform dropped them instead of sending them; they now deliver as intended.
• Fixed a managed media buy failing at ad-server line-item creation when a product offered both a sized display format (e.g. 970×250) and the dimensionless display family format. The buy now forwards the sized format so the line item can be trafficked, instead of sending the dimensionless one alongside it and failing.
• Merchandising rules now has one clear primary “Update rules” action instead of a row of look-alike low-contrast buttons, and its actions are named for the task (“Update rules”, “Write merchandising rules”) rather than the tool.

​

2.179.0 — June 22, 2026 at 1:48 PM UTC

• You can now stop an in-flight Murph chat turn. While Murph is working, a Stop control appears in the composer — pressing it ends the turn immediately instead of waiting for it to finish. Stopping does not undo anything Murph already did on that turn (for example, a change it had already applied); the reply makes that clear.
• Storefront readiness now reflects when Stripe later disables, restricts, or disconnects your connected payout account. Previously, once payout onboarding completed it was recorded as done permanently — so if Stripe turned off payouts afterward, your storefront still showed billing as complete and “ready to sell” even though you couldn’t be paid out. Readiness now re-flags payout setup when Stripe reports the account can no longer pay out.
• Signal lifecycle status now shows a color-coded badge (active / draft / archived) instead of a flat gray pill where every state looked the same, reusing the shared seller-widget status badge.
• Fixed approved creatives getting stuck at “0/1 source” when forwarded to an ad server (e.g. Google Ad Manager) that reviews creatives asynchronously. An async-accepted creative is now correctly recorded as forwarded, so the operator’s approval lands instead of bouncing back as pending.
• Murph can now attach URL-backed creatives reliably. The create_creative_manifest operation now publishes its request schema through describe_operation, so the agent uses the correct shape (a URL asset, an object-form format id) instead of guessing and failing.
• Product discovery no longer hangs indefinitely when a single sales agent is slow to respond. Each agent now has a hard per-call ceiling, so one unresponsive seller is skipped (and reported) instead of stalling the whole discovery run.
• Stop Murph from re-issuing the same failing tool call turn after turn. When a request with byte-identical arguments has already failed in multiple previous turns, Murph now tells you the request keeps failing and stops retrying, instead of silently re-sending it. Mutations that are simply awaiting your approval are not affected.
• Fixed a confirmation-loop bug where Murph’s in-chat Approve button could misattribute a banner-attach (or other buyer write) approval to a discovery re-run when multiple pending confirmations were in context. The server-injected approval message now names the specific operation, so Murph cannot confuse which call to replay.
• Murph now presents the complete product discovery results to the user before offering curated recommendations. Previously, Murph could jump directly to a shortlist without giving the buyer a chance to browse the full inventory.
• Fixed the Murph sidebar recents empty state so it no longer creates unnecessary scrolling in compact layouts.
• Fixed Murph chat occasionally failing with a “network blip” error during long-running turns. The chat stream now sends a periodic keep-alive so a multi-minute response (for example a large product discovery) is no longer cut off by an idle-connection timeout.
• Fixed a loop where registering a third-party sales agent with no authentication kept redirecting to the credential form. Murph’s post-registration guidance (“add a bearer token later via /source credentials”) was being misclassified as an in-chat credential solicitation and replaced with a secure-credential redirect, leaving the registration visibly incomplete.
• Fixed the “Confirm currency” control in the seller setup checklist, which silently did nothing when clicked. The settlement-currency update is now applied, and a failed save surfaces an error instead of leaving the step unchanged.
• Storefront readiness now reflects real product availability for storefronts backed by a managed sales agent. Previously these storefronts always showed products as ready regardless of whether any products or signals existed; go-live now blocks only when a storefront genuinely has nothing to sell (no wholesale products and no signals to compose from). A storefront with signals but no pre-built products is correctly treated as sellable.
• The approvals view now shows a clear “you’re all caught up” confirmation when nothing is waiting on your review, instead of a bare line of text that could look like a broken panel. Introduces a shared empty-state used across seller widgets.
• Event source health now shows a color-coded status (Receiving / Needs attention / Not seen) that stays legible in dark mode, instead of a flat gray pill where every state looked the same. Introduces a shared status badge used across seller widgets.
• When a seller-operated inventory source stays unhealthy past a short threshold (default 10 minutes), Interchange now opens a Pylon support issue so the seller is reached in their support channel — and auto-closes it once the source recovers. Sporadic blips that self-heal within the threshold never open a ticket, and Scope3-hosted adapter outages route to Scope3 rather than the seller.

​

2.178.0 — June 22, 2026 at 8:54 AM UTC

• Sellers are now proactively notified when a third-party inventory source they operate goes unhealthy, so they can restore it before it stops serving demand — instead of only finding out by opening diagnostics. The alert is operational (always-on, customer-scoped) and debounced so a flapping source cannot spam. Official Scope3-hosted adapters are excluded for now; their owner-aware alerting is a follow-up.

​

2.177.0 — June 22, 2026 at 6:25 AM UTC

• Removing an inventory source no longer leaves it able to block your storefront. Source removal is a soft delete, so an unresolved trafficking error on a removed source previously kept readiness blocked indefinitely (and the resolved item lingered in your work queue). Readiness and the work queue now exclude items on removed sources.
• Inventory-source diagnostics now identify who owns a failure. The diagnosis block of GET /api/v2/storefront/inventory-sources/{sourceId}/diagnostics includes an owner field: for an official Scope3-hosted adapter (Pinterest, Reddit, Snap, …) a runtime failure is attributed to Scope3 — with guidance that it recovers automatically — instead of asking you to debug infrastructure you don’t operate. Adapter credential issues and your own external sales agents remain yours to fix.

​

2.176.0 — June 22, 2026 at 5:55 AM UTC

• A separate action-required indicator now appears in the top navigation when your storefront is blocked from selling, and opens the “Get ready to sell” readiness view so you can fix the blockers. It’s distinct from the notifications bell (which stays for passive updates) and only shows while there’s something to act on, clearing once your storefront is ready.
• Ad-server connection alerts (“sync action required”) are now always-on like other storefront readiness alerts — delivered to your whole team and shown in the notifications feed regardless of preferences, since a broken ad-server connection stops your storefront from selling. They no longer appear as a toggle in notification settings.
• Storefront readiness alerts — your storefront was paused, or products aren’t ready to traffic — are now delivered to your whole team automatically rather than being something you had to opt into. These operational alerts can’t be muted, so a storefront problem never goes unnoticed, and they no longer appear as toggles in notification settings.
• Fixed the Ad server item in the seller navigation doing nothing when clicked — it now opens your ad-server inventory view (connections, sync status, wholesale products, and signals), the same surface the inventory link already opened.
• Notification settings no longer show a duplicate “Storefront” category, and the list now only includes the categories relevant to your account — buyers see buyer notifications, sellers see storefront notifications. The sales-agent notification category is now labeled “Sales agent.”
• Murph now acts immediately when you approve a change it proposed (for example a campaign start-date edit), instead of repeating the confirmation in a way that left it unclear whether Murph had already made the change or was still waiting on you.
• Fixed Murph confirmation messages to unambiguously use future tense so users can tell whether Murph has acted or is waiting for their approval.
• Murph confirmation and approval summaries now use plain language — no API field names, ISO codes, JSON paths, or internal schema reasoning. Before any gated action (campaign creation, policy write, advertiser setup), Murph describes what will happen in terms of the buyer’s intent, not the underlying API call structure.
• Murph no longer warns that a campaign or flight start date of today is in the past — a start date of today is valid and is accepted without friction. When you ask which inventory covers a channel or region, Murph now leads with the storefronts that match and offers to run discovery for actual products and pricing.
• Fixed duplicate approval prompts appearing for product discovery actions in sessions where discovery had previously been run. Returning buyers no longer see a second confirmation gate when re-running discovery in the same conversation.
• Improved the error message shown when Murph is temporarily unreachable server-side. The message no longer instructs users to check their own connection when the issue is on Scope3’s end.
• Murph no longer infers an advertiser’s primary currency from seller-side storefront data (name, domain, region, pricing, or rate card). Currency is now always sourced from the buyer’s own stated preference or by asking directly.
• Fixed an issue where Murph incorrectly rejected today’s date as a campaign flight start date. The validator now correctly uses UTC midnight for date comparisons, matching how ISO 8601 date strings from clients are parsed.
• A new seller’s menu now keeps the focus on getting set up. Until the storefront
• is live, the Merchandise and Operate sections start collapsed — one click opens
• them — so the rail shows the foundational steps instead of every option at once.
• They expand automatically once the storefront is live, or whenever you’re working
• in one of them.
• The Approvals item in the seller navigation now opens the full approvals view, where you can see every pending creative review and media-buy approval and approve or reject each one inline — instead of a read-only summary of the most recent few.
• The Self-serve buyers item in the seller navigation now opens its full in-chat view, where you can create and share your buyer invite link, copy or disable it, and approve, decline, suspend, or reactivate the buyers who have joined — all in one place.
• The Business profile and Pricing & terms items in the seller navigation now open their full in-chat views — your profile, voice, and pitch; and your rate-card rules and approval settings — instead of a condensed summary panel.
• Once a seller’s storefront is live, the menu now collapses the set-once “Set up”
• section and leads with the ongoing Merchandise and Operate work — mirroring how a
• not-yet-live storefront keeps Set up open and collapses the rest. Collapsed
• sections are one click away, and any section you’re working in stays open.
• Rebuilt the seller “Get ready to sell” surface into a go-live readiness dashboard and extended it to reflect live operational health. It now leads with your go-live progress and one clear next action, lets you confirm simple settings like your settlement currency right in the surface, and offers accept-default / upload-your-own / build-with-help for your acceptance policy. Once you’re live it stays a glanceable health check: if an inventory source goes down or buys fail to traffic, it flags exactly what’s stopping you from selling — with direct “reconnect” and “resolve” actions — in step with the action-required indicator.
• The Test runs item in the seller navigation now opens its full in-chat view: your sandbox test history, and for each run the per-sales-agent breakdown (which agents returned products, came back empty, or failed — with the raw call payload), the run’s context, and a one-click handoff to Murph to fix a failed run.
• When a campaign’s selected products include a sales agent that can’t be used with the campaign’s routing type (for example, a decisioned storefront selected into a routed campaign), that agent is now skipped with a warning instead of failing media-buy creation for the entire campaign. Compatible sales agents in the same campaign still get their media buys.

​

2.175.0 — June 22, 2026 at 1:06 AM UTC

• Advertisers are now unique within a customer by the pair of brand domain and primary currency, instead of by brand domain alone. The same brand domain can back more than one advertiser as long as each uses a different currency (e.g. one in USD and one in EUR). Creating — or updating an advertiser onto — a brand domain + currency pair already taken by a sibling advertiser returns a conflict.
• Murph now coaches sellers all the way through acceptance-policy setup instead of stopping to say the decision “has to come from the operator.” When a step asks which advertisers or creatives to accept, decline, or send for review, Murph asks the questions, drafts the policy, and writes it on your confirmation — rather than handing back a generic template. The in-product recovery after a hiccup also no longer implies a change that already saved cleanly failed.
• Fixed Murph chat scrolling and added clearer debug-call provenance, including timestamps, initiators, and whether calls came from sandbox tests or non-test demand traffic.
• Murph now proactively coaches sellers whose storefront isn’t live yet. On the
• first message of a conversation, Murph leads with where the storefront stands —
• how many steps remain before it can answer its first buyer brief and what the
• immediate next step is — and offers to walk through it one step at a time,
• instead of waiting to be asked. The offer is made once per person, with a
• lighter “pick up where you left off” nudge on a later visit, and it stops
• automatically once the storefront goes live.
• When a seller opens Murph without an active conversation, it now opens directly
• to the right place — the setup checklist while the storefront isn’t live yet,
• the dashboard once it is — instead of a blank screen next to the full menu.
• Starting a new chat still gives a clean chat to type into.
• Sellers can now attach pricing to wholesale signals (CPM or revenue-share), so audience signals can be sold with an incremental price.

​

2.174.0 — June 21, 2026 at 3:47 PM UTC

• Storefronts now flag products synced from a connected sales agent that can’t be trafficked — for example, video formats missing a duration. The issue appears in your storefront health and raises a notification naming how many products are affected, so you can fix them in your sales agent and re-sync. This extends the same not-traffickable detection that managed ad-server products already have.
• Fixed Murph chat consistently failing with “Murph chat stream ended without a result” even though the reply was generated and saved. The streaming response now reliably delivers its final result.
• Product activity entries now record the full set of seller-meaningful fields (delivery type, inventory type, formats, pricing, exclusivity) instead of only name and pricing, so edits to those fields are no longer silently omitted from the activity feed. The audit row no longer stores the raw product payload, keeping unbounded upstream data out of the activity log.
• Murph no longer stops a conversation when an account reaches its daily usage
• budget. During the beta we meter usage and watch instead of blocking, so a
• seller or buyer is never cut off mid-task. A high runaway-safety limit still
• guards against abuse or a stuck loop.
• The seller rail’s “Get ready to sell” now opens the coached go-live checklist (the Setup widget with a highlighted “do this next” step and a walk-me-through option) instead of the older state drawer — so the most important setup row lands a new seller on the guided surface.
• The “connect an inventory source” and “ad-server source” go-live checks now name the actual ad servers (Google Ad Manager, FreeWheel, SpringServe) and the sales-agent option in their guidance. This makes the step clearer for a new seller and routes Murph’s “walk me through it” hand-off to the GAM-access documentation, so the most common setup question is answered at the moment of friction.
• Reorganize the seller agent’s navigation rail into three teaching sections — Set up, Merchandise, and Operate — with plain-language labels, so a new publisher can see the whole journey at a glance. Renames the opaque rows (“Demand inbox” → “Demand”, “Selling terms” → “Pricing & terms”, “Source sales agent” → “Sales agent”, “Source ad server”/“Inventory” → “Ad server”, “Go live” → “Get ready to sell”, and more), splits ad-server vs. sales-agent connection into distinct rows, and surfaces Acceptance policy, Merchandising rules, and a Components coaching entry directly in the rail.
• Added a Setup view to the seller chat experience. Ask Murph “is my storefront set up?” (or use /setup) to see your go-live checklist — the single most important next step is highlighted, required steps come first, and every step can be done with Murph right there. “Walk me through it” hands the whole sequence to your agent.
• Renamed the app support menu status link to “Scope3 service status”.
• The not-traffickable product check now covers every connected source’s synced catalog — not just third-party sales agents — and runs even when a storefront also has a managed ad server, so any source with products that can’t be trafficked (e.g. video missing a duration) is caught and named per source. Managed ad-server sources continue to be covered by their own setup checklist.

​

2.173.0 — June 21, 2026 at 4:58 AM UTC

• Creative changes now appear in your activity feed: creating, updating, archiving, and assigning or removing a creative to/from a campaign — and bulk creative updates — are each recorded with who did it and when. Previously the creative service wrote no activity at all.
• More seller actions now appear in your activity feed: creating a storefront, resetting brand verification, linking an agent as an inventory source, and approving or rejecting an ad-server (ESA) workflow are each recorded with who did it and when. This clears the last of the known audit-coverage gaps.
• Your activity log is now reachable from chat: type /activity in the composer to open it. The log opens on recent account-wide activity instead of requiring you to pick an advertiser and campaign first — those filters now refine the view rather than gate it. The buyer Diagnostics shortcut also now opens the diagnostics view as intended.
• Storefront API calls scoped to your own storefront (listing products, demand signals, the dashboard summary, and responding to a demand signal) no longer require you to pass a storefrontId — the server resolves your storefront from your account. A wrong or guessed id is corrected automatically, and calling before you have a storefront returns a clear “start onboarding first” message instead of a confusing missing-parameter error. Inventory-source executionType and status values are documented as the uppercase enums the API requires (AGENT, PENDING/ACTIVE/DISABLED).
• Added a Dashboard view to the seller chat experience. Ask Murph “how am I doing?” (or use /dashboard) to open your storefront performance at a glance — win rate, booked budget, delivery, how your agent’s negotiation postures convert, and what to improve — without leaving chat.
• Storefronts now flag go-live blockers when a product cannot be trafficked (for example, a video product missing its duration). The blocker is surfaced the moment you ask your storefront agent about capabilities, and it raises a notification (with email for opted-in operators) — naming how many and which products are affected — so you know your storefront is not live and exactly what to fix.

​

2.172.0 — June 20, 2026 at 3:21 PM UTC

• Added an in-chat Acceptance Policy view to the seller Murph experience — see your storefront’s acceptance policy (which advertisers, categories, and creatives your agent accepts or declines) with version history, and ask Murph to summarize, explain, or update it.
• Added an in-chat Activity Log for storefronts. Ask your agent to “show the activity log” (or type /activity) to open a read-only feed of recent changes — each entry shows what changed, whether it was a person, the agent, or automation, and whether the action succeeded, was denied, or was blocked. You can also just ask “who changed this?”, “what changed yesterday?”, or “what got blocked?” and get the answer in chat.
• Added an Approvals view to the seller chat experience. Ask Murph for “Approvals” (or use /approvals) to see your review-gate settings alongside anything waiting on you — pending creative reviews and pending media-buy approvals — and hand decisions or gate changes back to Murph in chat.
• Activity feed entries now record how each action was initiated. A new actorOrigin field on buyer and storefront audit logs distinguishes a change made directly by a person (human) from one the Murph agent made on a user’s behalf (agent), as well as autonomous and system actions. The activity timeline shows a “via Murph” badge on agent-initiated changes so you can tell at a glance who — or what — made a change.
• Added an in-chat Business Profile view to the seller Murph experience — see your storefront’s channels, regions, verticals, properties, and the pitch buyers see, and ask Murph to update it.
• Added an in-chat Merchandising Rules view to the seller Murph experience — see how your agent turns your inventory into sellable products (your operating instructions), with version history, and ask Murph to summarize or update them.
• Sellers now choose the country their business is based in when connecting a Stripe payout account. This country is set when the account is created and determines the payout/settlement currency (for example, a seller in Germany settles in EUR), so it can no longer default to US. Provisioning a Stripe Connect account now requires a country (ISO 3166-1 alpha-2) value, restricted to countries Stripe supports for payouts; an unsupported country returns a clear validation error instead of a generic failure.
• The seller Approvals view is now a place to do the work. Open Approvals (or /approvals) to drill into a pending creative review or media-buy approval, see how it was pre-screened (the policy/brand/readiness verdict and what was flagged), preview hosted creatives inline, and approve or reject it with a note — without leaving the view. Changes to live media buys are flagged; approving a flagged item asks for a deliberate confirm; and when an approval can’t reach your ad server you now get the specific reason (and the item stays pending to retry) instead of a generic error. Approval automation settings now live with your other policies rather than in the queue.
• Advertiser edits, archives, and restores — and attaching a discovery run to a campaign — now appear in your activity feed, with who made the change and when. Previously only advertiser and campaign creation was recorded.
• Closed two gaps where changes weren’t reaching the activity log. Creating an advertiser is now recorded (it previously left no audit entry, so “who created this advertiser?” had no answer), and a new ADVERTISER resource type is filterable in the activity feed. Storefront product changes — including floor-price edits — are now recorded as updates with a before/after diff instead of being logged as a fresh “create” with no history; identical re-saves are no longer logged at all, so routine discovery refreshes don’t add noise.
• Managed ad-server source changes and billing changes now appear in the activity log. Connecting, reconfiguring, rotating credentials for, deactivating, and reactivating a managed ad-server source, plus connecting a payout account and updating billing terms, are each recorded — so operators can see who changed what. Credentials and Stripe identifiers (account ids, onboarding links, client secrets, tokens) are never written to the log.
• Product discovery now only surfaces products priced in the storefront’s settlement currency. A storefront sells in one currency and can’t settle a buy in another, so products (Chef-composed or passed through from sources) with no pricing option in the storefront’s currency are no longer returned, and off-currency pricing options are dropped from the products that remain. Storefronts that have not yet confirmed a settlement currency are unaffected.
• The buyer and storefront activity feeds can now be filtered by who and how. New query parameters on the audit-log endpoints let you narrow to a specific actor (actorUserId/actorUserEmail), to how a change was initiated (actorOrigin, e.g. only changes the Murph agent made), to a single resource (resourceId), and to specific actions (actions). This makes questions like “what did the agent change last week?”, “who deleted this?”, and “what has this user done?” answerable directly. Murph’s recent-activity lookup also now reports the origin and the before/after of each change, supports an end-of-window bound, and returns more rows.
• Setting credentials now opens the sales-agent management surface (where credentials live alongside setup and diagnostics) instead of a separate standalone credentials screen that showed “no sources found”. The seller rail’s sales-agent entry opens the same consolidated widget.
• Connecting an ad server no longer shows a server error on the Signals or Creative-formats tabs when the upstream ad-server adapter is briefly unavailable or doesn’t advertise those capabilities. Capability and creative-format probes now degrade gracefully to an “unavailable / not supported yet” state instead of failing the whole source view, so inventory, signals, and formats stay usable independently.
• Simplified seller source-management entry points around Source ad server and Source sales agent, with credentials, setup checks, and diagnostics managed in the sales-agent source widget.
• Media buy responses now populate creative formats for composed (storefront-curated) products, which previously came back empty because composed products aren’t in the raw product cache. The media buy list additionally fills in the product name and publisher for composed products. These are resolved from the storefront’s composition data and product index.
• Fixed media buy execution against embedded storefront sales agents whose in-process ADCP endpoints are stored as relative paths.
• Clarified that a storefront settles in one currency, which must match its connected Stripe payout account. The go-live currency copy no longer implies the currency is derived from your ad server, and the storefront agent now explains that clearing a second currency means setting up a second storefront rather than adding a currency to an existing one.
• The activity log now records mutation attempts that did not take effect, not just successful changes. Actions blocked by a permission or Terms-of-Service gate are recorded as “denied” and ones that errored mid-execution as “failed”, so you can answer “who tried to change this and why didn’t it stick” — including the “I didn’t do that” dispute case. The buyer and storefront audit-log endpoints accept a new outcome filter; by default the feed still shows only changes that succeeded, and passing outcome=denied (or failed) surfaces the attempts across all resource types. Murph’s recent-activity lookup can report and filter on the outcome too.
• Sellers can now ask Murph about their storefront’s activity log — who changed the storefront config, billing, or a managed ad-server source (connect, reconfigure, rotate credentials, deactivate), whether it was a person or the agent, and what got blocked or failed — over a time window. Connecting a Stripe payout account now appears in the seller activity feed.
• Advertisers are now single-currency. primaryCurrency is required when creating an advertiser, and it can only be changed while the advertiser has no campaigns — once the first campaign is created the currency is locked. Every campaign is created in its advertiser’s currency: if budget.currency is supplied on campaign creation it must match the advertiser’s currency, otherwise the advertiser’s currency is used.
• Source management is clearer and more self-serve in Murph and the seller widgets:
• Murph now explains the difference between an ad server source and a sales agent source and which you need, instead of dead-ending on the question.
• “Debug my sales agent” no longer silently assumes your ad server — when you have both, Murph asks which one, then diagnoses the right source (live connection probe, ranked likely causes, and next steps for an external agent; sync health for an ad server).
• The ad-server source widget adds a Health view that lists every blocking and warning issue with the exact next action — including a one-click Set default advertiser fix for the most common go-live blocker — and now consistently calls it your “ad server” (not “ESA”).
• The sales-agent source widget can now connect a new external AdCP agent directly (name, endpoint, protocol, credentials) instead of leaving you with nowhere to start.
• Opening a source widget now previews what you can do next instead of a bare “Opening…”.
• Ensured approved storefront creatives forwarded to third-party inventory sources register callback webhooks when asynchronous source-side review is available.
• Storefront media buys are now validated against the storefront’s settlement currency. A create_media_buy whose stated budget currency differs from the storefront’s confirmed currency is rejected with an INVALID_REQUEST (currency_mismatch) error rather than silently accepted. A storefront clears in one currency — to transact in another currency, use a storefront that clears in it. Buys that omit a currency are unaffected and are treated as denominated in the storefront’s currency.
• A storefront’s confirmed settlement currency is now verified against its connected Stripe payout account before go-live. The payout account’s settlement currency is captured when Stripe onboarding completes, and go-live is blocked if the storefront’s currency doesn’t match it — preventing payouts that would otherwise silently convert into a different currency.
• Campaign creation now accepts a feeType of GROSS or NET (defaults to GROSS), and campaign pricing is resolved through the Pricing Engine. GROSS means the budget is the all-in total the customer pays and the Scope3 fee is carved out of it (media budget = budget − fee); NET means the budget is the media spend and the fee is added on top (media budget = budget; total paid = budget + fee). The fee is the same percentage of the budget either way, and the campaign’s total budget is stored unchanged. feeType is returned on the campaign and is immutable after creation. The pricing rate is pinned at creation and refreshed on each budget edit while the campaign is still a draft; once the campaign is live the rate is frozen and budget edits re-split at that pinned rate — so a rate-card change can never silently re-price a running campaign. Media buys always draw against the media budget, never the total budget. Media-buy and package budget updates are now validated against the campaign’s media budget — raising a media-buy budget past what the campaign can fund is rejected instead of silently over-allocating.

​

2.171.0 — June 19, 2026 at 1:58 PM UTC

• Improved campaign media-buy status responses to distinguish draft, pending creative review, upstream submission, and delivery states, and added read-only ESA media-buy diagnostics for verifying upstream persisted buy state.
• Allow Murph creative workflows to attach MP4 video files up to 50 MB and preserve creative dashboard deep links from account-level URLs.
• Added in-chat Test Runs and Selling Terms views to the seller Murph experience, restored direct Murph seller navigation, and opened inventory sources in the inventory setup widget.

​

2.170.0 — June 19, 2026 at 11:41 AM UTC

• Advertise AdCP 3.1 release negotiation on storefront agents and use the stable 3.1 client pin for external seller calls.
• Storefront get_products now honors pricing currency filters when returning pass-through source products.
• Added customer notifications for managed storefront sync issues that require reconnecting an ad server adapter.
• Added embedded sales agent webhook and buyer discovery cache diagnostics to ESA status and admin sync health, with clearer storefront product-authoring validation in Murph.
• Storefront media buy creation now echoes source-returned package status fields while preserving storefront product and package identifiers.
• Improved chat widgets so they use the available width by default and long Inventory Sources sync views remain scrollable.
• Storefront product discovery now preserves product-scoped signal targeting metadata returned by upstream sources.
• Storefront product discovery now preserves vendor metric reporting and optimization metadata returned by upstream sources.

​

2.169.0 — June 18, 2026 at 8:39 PM UTC

• Publisher discovery now follows redirects and the ads.txt managerdomain fallback when resolving adagents.json, so domains managed by a network (e.g. Raptive/CafeMedia) correctly surface their authorized agents and properties.
• Murph can now set authentication credentials on an ADCP inventory source directly in chat through a secure credential form — basic auth and API key are entered inline, and OAuth sources get an Authorize button that opens the provider’s consent page. This replaces a storefront menu path that no longer existed. Open it with the /source credentials command or by telling Murph you have credentials to provide.
• Fixed a crash on POST /api/v2/storefront/resolve-brand when a brand manifest from the AAO registry contained non-string field values (arrays, numbers). The advertiser-industry classifier now filters these out instead of throwing a TypeError.

​

2.168.0 — June 18, 2026 at 7:16 PM UTC

• Fixed creative format validation incorrectly rejecting raw video creatives for VAST video placements when the publisher’s format declared the video slot without an explicit asset type. These creatives can now be assigned to and kept on media buys for those placements.

​

2.167.0 — June 18, 2026 at 6:04 PM UTC

• Fixed Murph approval controls so pending storefront setup confirmations stay visible when a conversation is reopened and stale approvals no longer block follow-up setup.
• Fixed Murph wrongly interrupting unrelated actions (like filing a report) with an ad-server credential redirect, and pointed the secure credential link for FreeWheel and SpringServe setup at the working inventory-source screen.
• Storefront legacy links now open the matching Murph storefront surfaces.
• Route the buyer creative workspace root through Murph so all creative asset entry points share the dashboard surface.
• Seller inventory-source links now open the shared Murph diagnostics widget instead of a standalone legacy page.
• Legacy advertiser and supply discovery URLs now open the equivalent Murph buyer surfaces.

​

2.166.0 — June 18, 2026 at 3:51 PM UTC

• Added a source diagnostics MCP app for third-party sales agents and modular inventory sources, including tool-level latency, timeout, outcome, and next-step rollups that Murph and other MCP hosts can launch with “open diagnostics.”
• Fixed an error when approving an action in Murph (such as filing a report). Approvals
• now reliably go through instead of occasionally failing with a confirmation error.
• Route the buyer activity deep link through Murph while preserving the full campaign activity workflow.
• Route advertiser-scoped creative asset deep links through the Murph creative dashboard surface.
• Migrated legacy product URLs with equivalent Murph surfaces so planning briefs, reporting, supply browse, and buyer connections open inside the unified Murph surface instead of standalone pages.
• Added a + menu and / commands to the Murph composer so launchable MCP widgets open from chat instead of static navigation. Sellers can open demand inbox, buyers, and sales-agent diagnostics from the composer, including /diagnostics and /inventory sources.

​

2.165.0 — June 18, 2026 at 1:18 PM UTC

• add_discovery_products and apply_proposal now report whether the discovery session is attached to a campaign. The response includes campaignBound, and when it is false a campaignWarning explains why no campaign reflects the products: either the session was never attached to a campaign (pass campaignId, or run discovery with campaignId, to bind it), or the campaign it was attached to has been archived (restore it, or pass campaignId for an active campaign). This removes the “add reported success but the campaign still shows 0 products” confusion.
• Improved media buy creative validation errors so invalid video assets are reported as invalid requests instead of source availability failures.

​

2.164.0 — June 18, 2026 at 10:13 AM UTC

• Added an explicit Linear visibility status to Murph escalation artifacts so clients can distinguish unavailable Linear tickets from role-redacted ticket references.
• Added customer-facing guidance for connecting ad platform accounts, including recommended Meta, TikTok, Google Ads, and other platform access levels, and linked it from the Connections setup experience.
• Improved activity diffs so long brief-style updates remain readable.
• Buyers can now request audio and dooh channels in discover_products. Both were previously rejected by schema validation even though the underlying ADCP layer already supported them.
• When discover_products returns zero results, the response now includes a specific reason - e.g. how many publishers were queried, how many were skipped and why, or whether no publisher connections are configured for the account. This prevents agents from blind-retrying identical calls.
• Keep MCP connections alive during long-running tool calls. Tool calls that take several minutes to complete (such as product discovery against a slow sales agent) no longer get dropped by the connection idle timeout before the result is returned.
• Fixed Murph incorrectly redirecting to the secure credential form when explaining ad-server setup steps. Guidance like “you’ll need to provide your FreeWheel credentials to complete the setup” is no longer mistaken for an in-chat credential request, while Murph still redirects genuine attempts to paste passwords or tokens directly in Slack.
• Fixed DMA code-to-market-name resolution so the buyer agent correctly identifies Nielsen DMA markets by name rather than relying on model memory.
• Fixed a bug where a campaign with a stranded DRAFT media buy (from a prior failed execution) could not be re-executed. The execute endpoint now bypasses the discovery session gate when DRAFT buys already exist, and the media-buy-status endpoint now surfaces DRAFT buys so they are visible rather than silently hidden.
• Fixed Murph starter prompt labels so they use the selected interface language instead of falling back to English.
• Ask Murph can now show you a “Your requests” panel — the issues and requests you’ve escalated to the Scope3 team, each with its current status, how long ago it was filed, and what’s happening next. Ask Murph to show your requests (or use the escalations shortcut) and the panel renders right in the chat, covering everything from open to resolved.
• Fixed product discovery only returning the first page of a sales agent’s catalog. Both catalog enumeration and buyer product discovery now retrieve the full catalog by following get_products pagination, so products on later pages (for example CTV, interstitial, or banner inventory listed after a first page of other formats) are discoverable and available for deals. Large catalogs that previously truncated at the first page are now returned in full.
• Make a curator’s media buy from a pool seller work end to end. Two gaps blocked the in-process buy that only a real (un-stubbed) buy exercised: the bridge’s SDK client refused create_media_buy because a storefront advertises itself as a discovery agent (its capabilities null out the media_buy protocol), and the curator’s forward only accepted a completed upstream status and rejected the pending_start (accepted-but-trafficking) state a storefront seller returns. The bridge now skips the pre-flight feature gate for the trusted in-process seller, and the forward accepts a linked seller’s create whenever it returns a media buy id. Adds an end-to-end real-Postgres test of the full cascade (curator → bridge → seller → modular terminal) with both spread-ledger legs booked.

​

2.163.0 — June 17, 2026 at 11:57 PM UTC

• Added selection and refinement actions to buyer starter proposal cards, and surfaced seller-side demand coverage in storefront readiness.
• Added seller documentation for diagnosing third-party sales-agent inventory sources, including source health, recent AdCP activity, and buyer discovery debug output.
• Brand resolution now classifies each resolved brand into a canonical AdCP advertiser-industry code (e.g. a steakhouse → food_beverage.restaurants), surfaced as advertiserIndustry on the brand manifest. Brands now share one category vocabulary across the platform and with AdCP, so a brand.json can advertise its canonical industry. This is the foundation for category-based starter briefs.
• Standardized the buyer dashboard page headers. Every section — Campaigns, Creatives, Data sources, Reporting, and Activity — now renders a consistent header at the correct size, with each section’s controls in the header: Reporting’s date filters, Creatives’ campaign filter, Data sources’ Catalogs/Conversions tabs, and Activity’s kind filter. Buyer page headers also stay pinned while scrolling, and the Planning Briefs page uses the standard page-header layout for a consistent title, description, and primary action.
• Storefront interchange is now an open marketplace pool. A curator storefront automatically discovers and composes wholesale inventory from every listed storefront whose offerings match the curator’s own channels — there is no per-storefront linking or approval step. A storefront participates simply by being listed in the marketplace, and a seller’s price floor and content policies are always enforced on every resale.
• Streamlined the storefront navigation. The rail is reordered around going live and daily demand, renamed for clarity (“Reporting”, “Agent training”), and Team and Billing moved into Settings to keep the rail focused on selling. Storefront testing now lives in the Demand inbox.
• Fixed a bug where multiple Anthropic API 500 errors from the same call site would each open a new GitHub issue instead of deduplicating onto a single issue. The Anthropic SDK embeds a unique request_id in each error message, which was causing the error fingerprinter to generate a distinct hash per occurrence.
• Fixed the activity feed rendering a campaign brief change one word per line. Long brief edits now show the new brief as a full-width paragraph instead of a cramped side-by-side diff.
• Customer account lists now include active child accounts accessible through parent administrator permissions.
• Fixed publisher authorization discovery so live authorization can clear stale verification results, and Murph checks specific seller domains with a fresh domain lookup instead of browsing cached catalogs.
• Corrected storefront setup documentation to use the canonical Interchange storefront agent URL and updated managed ESA publisher-property lookup to avoid treating ESA authorization checks as the source of truth.
• Fixed PUT /storefront rejecting a settlement-currency update with “At least one field must be provided to update”. defaultCurrency (and supportedLanguages) were valid fields but were missing from the update body’s non-empty check, so sending only defaultCurrency — the call required to clear the currency_confirmed go-live blocker — failed validation. These fields now satisfy the check, so a currency-only update works. Also documented the field in the storefront agent skill’s Update Storefront reference.
• Fixed media buy status not updating for buys placed through a storefront. A storefront fans a single media buy out to multiple upstream sources, so its status is now rolled up from those per-source statuses rather than left stuck at “pending approval”. A buy that is live upstream now correctly reports as active, and reflects paused, rejected, completed, and other states the same way.
• Localized buyer activity filters, empty states, pagination copy, and invitation accept prompts.
• Localized advertiser management copy, table labels, advertiser dialogs, and archive/restore prompts.
• Localized buyer storefront connection copy, status labels, account prompts, feature controls, and notification preference labels.
• Localized Discover Supply table, page, note, and submit copy.
• Localized storefront account card metadata and archive dialog fallback copy.
• Localized storefront card preview fallback messages and Supply page empty states.
• Localized storefront card channel/status labels and Supply page filter copy.
• Localized storefront demand signal cards and locale-formatted their budget, flight, and fit details.
• Localized storefront drawer readiness, pricing, and performance summaries.
• Localized storefront drawer chat prompts for setup, readiness, approvals, catalog, and document-processing actions.
• Localized storefront test-run diagnostics and helper status labels.
• Localized storefront inventory and source status labels across source tiles, details, and catalog rows.
• Localized storefront inventory-source chooser, filters, empty states, and adapter connection labels.
• Localized storefront link request dialogs and inbound request actions.
• Localized storefront setup task controls and demand contact editing copy.
• Localized storefront setup task rows and translated their status, action, and sync-health copy.
• Localized the storefront state drawer, including setup guidance, source diagnostics, buyer invite actions, and document-processing details.
• Re-validating a publisher’s adagents.json is now reliable when a fix has just gone live. If you publish or correct your adagents.json and product creation is still rejected as “not authorized”, you can ask the assistant to re-check your domain and it will re-read the live file, refresh authorization, and re-sync your properties so you can create products without an out-of-band support request. Storefront agent discovery also now self-heals a stale authorization flag when your live adagents.json is valid, regardless of how many properties are already registered.
• Murph campaign summaries now include stored campaign constraints, including AdCP geo metro targeting codes.
• Storefront interchange discovery now scopes the ambient wholesale pool by geo/region in addition to channel. A curator storefront discovers wholesale inventory from LISTED storefronts whose declared regions overlap its own (legacy region-code aliases are honored). Region scoping is lenient on the seller side: a storefront that has not declared regions stays discoverable everywhere — only a seller that explicitly serves non-overlapping regions is filtered out.
• Restored seller demand inbox and buyer management surfaces as MCP app widgets in the Murph chat shell.
• Brought the storefront chat experience in line with the buyer one: New chat and recent conversations are always visible in the rail, prompt suggestions now fill the composer (so you can add context before sending) instead of sending immediately, the chat input shows only in the chat view, and rail spacing, labels, and suggestion styling are tightened and consistent across buyer and seller.
• You can now delete a chat from Murph’s Recents list: hover a conversation, open the ”⋯” menu, and choose Delete chat. Deleting removes the chat from your sidebar right away. Behind the scenes the conversation is retained so support can review product issues, but it no longer appears anywhere in your view.
• The storefront overview now shows your realized margin and margin % alongside delivery metrics, so a curator can see resale profitability at a glance — what you charged buyers, minus what you paid sources — for the current period. Margin is reported in your primary settlement currency; it fills in once your media buys start delivering.
• The buyer assistant can now look up an operation’s exact request schema and a canonical example before calling it, so it gets field names and types right the first time instead of guessing. It also adds discovery products to a campaign through a verified workflow that confirms the campaign-facing product count actually rose — preventing a silent zero-count attach from being reported as success.

​

2.162.0 — June 16, 2026 at 6:58 PM UTC

• Fixed a media buy failing to save at execution when an inventory source returns tokenized product identifiers containing colons (e.g. wh:<source>:<product>). The id validation now accepts the colon-delimited token format these sources use, so the buy completes instead of erroring with an “invalid format” message after the source already accepted it.

​

2.161.0 — June 16, 2026 at 5:20 PM UTC

• Added GET /api/v2/storefront/reporting/margin — a curator’s resale P&L. It reports booked vs realized buy/sell/spread and margin %, rolled up buyer → media buy → package → source leg, so a storefront operator can see what it paid each source, what it charged its buyer, and the spread between them. Amounts are signed (a resale at a loss is shown, not hidden) and are reported per settlement currency, never summed across currencies. This is a cumulative as-of snapshot, scoped to the calling storefront.
• When you create an advertiser from a domain, the brand profile shown for confirmation is now the exact profile that gets saved — a freshly built profile is briefly cached and reused at save time instead of being re-derived, so what you confirm is what you get.
• Brand resolution now builds a profile from a buyer’s own website when the brand isn’t in the registry. Previously a domain that wasn’t registered (most local, regional, and smaller brands) resolved to nothing; now we read the site’s declared metadata (name, logo, description), its page content, and — when a brand publishes one — its /llms.txt summary to fill in name, industry/vertical, tagline, audience, and tone, so the buyer still gets a co-branded experience and a personalized proposal. Harder-to-read or ambiguous sites are read more thoroughly, including additional pages. The profile is always shown for confirmation and is never saved until the buyer reviews it.
• When creating an advertiser, a buyer can now look up their brand by domain and see a “here’s how I see you” confirmation card — logo, name, and industry/tagline resolved from the brand registry — before committing. A new POST /api/v2/buyer/brands/resolve endpoint resolves a domain to a brand-confirmation card with no side effects; the buyer confirms by creating the advertiser as before. Unregistered domains return a friendly “we’ll create one when you save” state instead of an error.
• Added a clear way to return from account settings to the main account screen.
• Restructured the Murph seller storefront surface so Dashboard and setup action areas are first-class left-rail widgets, added a go-live training dashboard for sellers, and fixed OAuth signup so new users reach signup reliably and remain signed in after completing it.
• Fixed an issue where a creative created or updated with a recognized format (such as VAST video) could be rejected when assigned to a new media buy. The canonical format is now inferred automatically, so these creatives attach without an extra step.
• Localized the storefront operating instructions tab.
• Localized the storefront ad-server connection dialog.
• Localized the storefront agent connection dialog.
• Localized the storefront AI usage reporting tab.
• Localized the storefront API access settings panel.
• Localized the storefront directory card modal.
• Localized the storefront communications settings panel.
• Localize storefront settings copy for state controls, brand identity, approvals, visibility, and regional settings.
• Localized the storefront inventory source detail dialog.
• Localized storefront inventory source status tiles.
• Localized the storefront single sign-on settings panel.
• Localize storefront team management copy, invite modal text, role labels, and membership auto-join settings.
• Fixed media buys to agent-backed storefront inventory sources being rejected with a “product not hydrated for account” error. The buyer’s brand is now forwarded consistently on both product discovery and the buy, so the source resolves the same account for both legs even when account sync is unavailable.
• Storefront product discovery and composition now transparently retry the underlying inventory source on transient connection failures (e.g. a brief upstream restart) instead of immediately surfacing a “service unavailable” error. Only idempotent reads are retried, with capped exponential backoff.

​

2.160.0 — June 16, 2026 at 8:31 AM UTC

• Creative assets now report their actual pixel dimensions (width, height) in the manifest response for image and video files. Uploads are validated at creation time: a warnings array on each asset surfaces filename-vs-actual mismatches (e.g. a file named 300x250.png that is actually 600x500) and flags unusually small assets auto-assigned as the primary creative. When a media buy targets a format with explicit pixel requirements, those dimensions are also verified at assignment time.
• Added HTTP Basic Auth support for external inventory sources. Publishers can now register inventory sources that use username/password credentials by specifying authenticationType: 'BASIC_AUTH' with auth: { type: 'basic', username: '...', password: '...' }.
• Completed HTTP Basic Auth support for storefront inventory source registration, UI configuration, polling clients, and local end-to-end validation.
• Fixed create_media_buy failing with PRODUCT_NOT_FOUND (“not hydrated for account … call get_products first”) when forwarding to a pass-through sales agent. The buy now syncs and forwards the same account the get_products discovery leg established, so the source resolves the buy against the account its products were hydrated under instead of a different one.
• Localized activity feed labels and controls, including locale-aware activity timestamps and campaign budget details.
• Localized the buyer planning brief list, detail view, response cards, and sharing dialog.
• Localized proposal cards and storefront media buy approval review surfaces, including locale-aware budget and submission date formatting.
• Localized the storefront proposal queue and proposal code composition flow.
• Add a centralized seller dashboard summary endpoint and wire the Closer widget to use it for buyer brief closing analytics.

​

2.159.0 — June 15, 2026 at 7:03 PM UTC

• Expanded reviewed UI translation catalogs and added safeguards for new localized UI copy.
• Murph now treats portfolio seller onboarding and avails intake as explicit storefront setup flows, with checklist guidance for missing seller materials before inventory can be loaded.

​

2.158.0 — June 15, 2026 at 6:40 PM UTC

• A buyer sponsored into a storefront now lands on a bespoke proposal — “here’s what can do for you” — instead of a blank planning brief. A new GET /api/v2/buyer/proposals endpoint runs a brief-less product discovery scoped to the buyer (confined to the sponsor’s storefront for a sponsored buyer) and returns the resulting media-plan proposals, and the buyer home renders them as a card grid (plan, why it fits, placements, budget guidance). Selecting a proposal carries it into the chat to set up. Buyers with no advertiser yet, or storefronts whose agents don’t return plans, degrade gracefully to the co-branded home.
• Murph can now draft a concrete avails-feed request and CSV template when seller-provided material is market context rather than actual sellable availability rows.
• Fixed “Service token with ID 0 not found” error when deleting API keys from the UI.
• Fixed product discovery returning no results from strict sales agents. Outbound get_products requests now send only the brand identity (domain and brand id), matching the behavior already applied to create_media_buy and sync_accounts.
• Storefront modular avails feeds can now preview and commit raw seller rows from CSV text, JSON text, or spreadsheet-like row objects before publishing updated availability.
• Murph now distinguishes seller market summaries from actual avails feeds and asks for real sellable inventory rows before committing modular feed updates.

​

2.157.0 — June 15, 2026 at 2:43 PM UTC

• Catalog sync responses and catalog listings now expose feed health, freshness, version summaries, and item-change summary fields. Catalogs can also store deterministic transform definitions that turn feed items into campaign groups, creative prompt cache keys, budget hints, and backend-inferred seller sharing plans; syncs with an active transform automatically generate a latest activation plan. Item-level catalog changes remain internal to support catalog-driven campaign, creative, and seller re-syndication workflows.
• Creative collections now fan out member creatives into campaign assignments on attach, respecting the format_kind upgrade gate. Added advertiser-scoped collection endpoints (GET/POST /advertisers/:advertiserId/creative-collections) and owner_scope field on collection summaries.
• Added locale-aware Murph preference plumbing, reviewed core-language UI catalogs, and a glossary-aware translation workflow for seller-facing Murph actions.
• Added a storefront demand inbox: every buyer brief sent to your storefront, how your agent responded, and the commercial outcome. GET /api/v2/storefront/intelligence-runs now accepts a buyingMode filter (brief, wholesale, refine) and a commercialResult filter (booked — forwarded upstream or delivering; pending — awaiting your acceptance-policy approval; rejected) so you can pull just the demand that converted, the demand still waiting on your sign-off, or the demand that didn’t — and each run carries its qualification reason and composed-product explanation.
• Added a buyer MCPUI setup widget and workspace launcher for registering advertiser event sources with expert-run setup, integration mapping metadata, basic ingestion health, and alignment with the shared ADCP event taxonomy.
• Fixed the buyer Ask Murph landing page so it no longer uses seller Merchandising Agent naming.
• Fixed product discovery returning no results from sales agents pinned to AdCP 3.0. Discovery get_products calls no longer attach a discovery webhook (push_notification_config) when the client is below AdCP 3.1; results are retrieved synchronously via polling instead.
• Fixed media buy execution and account sync failing against sales agents that strictly validate the brand field. Outbound create_media_buy and sync_accounts requests now send only the brand identity (domain and brand id); brand-kit and other inline brand overrides are resolved by the seller from the brand’s published brand.json.
• Fixed Murph handing out broken ad-server credential-connection links outside of Slack. Links now always point at the configured storefront domain so the secure FreeWheel/SpringServe credential form is reachable.
• Campaign-level postal-code guardrails now merge correctly with the country-local postal area shape: the country is preserved and postal codes are no longer merged across different countries that share a postal system. Targeting a single country’s postal codes (e.g. South Africa) through a campaign guardrail now produces valid, country-scoped targeting.
• Storefront update_media_buy is more honest when a multi-source buy only partially applies: if some sources accept the update and others reject it, the storefront now returns an error with per-source detail instead of reporting a clean success for a half-updated buy. Budget changes that the storefront cannot parse (for example a non-numeric amount) now require seller approval rather than being auto-forwarded, and a buyer’s push-notification callback config is no longer forwarded to upstream sources.
• Fixed storefront media-buy updates so mutable fields are forwarded to inventory sources, material updates enter seller approval before taking effect, and pending update tasks emit terminal webhooks.
• Storefront update_media_buy now forwards each change to the correct source instead of broadcasting the buyer’s full update to every source. Per source, the storefront keeps only that source’s packages (translated to the upstream package IDs) — each package carrying its own budget — and passes through lifecycle and flight changes (pause/resume, cancel, start/end, targeting). This fixes over-committing on multi-source media buys, where every source previously received every package.
• Added an opt-in FreeWheel modular inventory source setting that attempts campaign, insertion order, and placement execution automatically while falling back to the source work queue when execution cannot complete.
• The capability gate that rejects unsupported targeting on ROUTED media buys now covers metro-area systems (geo_metros) in addition to postal codes, and is structured as a generic per-dimension registry so future targeting dimensions are covered without bespoke wiring. Behavior is unchanged for postal and for any seller that does not declare a given dimension (fail-open).
• Extended the seller dashboard spec with contract metadata, data sources, metric definitions, data status, and the Closer widget for seller brief outcomes.
• The identity-match targeting feed now accepts root-relative seller agent endpoints (e.g. platform-hosted storefronts) in addition to absolute URLs, so packages backed by hosted storefronts are no longer dropped from the feed.
• Storefront sales agents now declare postal-code targeting per country (ISO 3166-1) and translate buyer-supplied country-local postal codes into each platform’s native geo targeting. Snap and Meta read the buyer’s geo_postal_areas (previously dropped) and emit country-scoped postal targeting; Reddit no longer advertises postal targeting it cannot honor. Declared postal support remains US-only pending per-country platform verification.
• Storefront-to-storefront buying is now end-to-end: a curator storefront with an ACTIVE link can place, update, and track a media buy against a linked seller storefront’s inventory. Create/update/delivery forward in-process to the seller, the seller’s manual-approval responses are reconciled automatically, and the buyer-facing status rolls up across linked and direct sources. A reach-fence restricts the linked connection to buyer operations only, the loop/depth guard and call-time link-active recheck extend to every mutating call, and the seller is never disclosed to the buyer.
• Added seller-facing endpoints and storefront controls for modular inventory source work items.
• Improved buyer catalog refresh and activation history so feed updates show clearer downstream impact and seller delivery readiness.
• Improved buyer catalog feed visibility with recent refresh and fan-out history in catalog responses.
• Murph no longer pauses ESA product creation when a publisher domain has no
• adagents.json / AAO record. AAO publication remains a separate, optional
• setup step in the business-profile flow — operators can author products
• immediately and add AAO authorization on their own timeline.
• A buyer sponsored into a storefront now enters a co-branded experience scoped to that sponsor. A new GET /api/v2/buyer/scope endpoint surfaces the sponsoring storefront (name, branding, channels, regions, and account status), the buyer home and shell are framed in the sponsor’s brand, and Murph speaks in the sponsor’s voice — scoping guidance and starter actions to advertising through that storefront. While an account is awaiting the storefront’s approval (or suspended), the home and Murph explain the status and steer toward setup instead of buys that can’t go through yet. Ordinary marketplace buyers are unaffected.
• Storefronts can now decline buyer briefs that clearly don’t match what they sell or violate their acceptance policy, before composing products — cutting wasted composition cost and capping buyer-driven spend. Fit is judged from the storefront’s actual inventory (its packages, channels, regions, and verticals); policy is judged from its acceptance policy. If you set an acceptance policy, briefs that violate it are declined automatically. Buyers receive a standard “no matching products” response — the seller’s reasons are never exposed. Every incoming brief is recorded with its outcome (responded / declined for fit / declined for policy), filterable via GET /api/v2/storefront/intelligence-runs?disposition=..., so sellers can see exactly which briefs they’re winning and missing. This applies to every configured storefront, and the qualifier fails open (composes) on any error so a fault never silently turns away demand.
• The storefront intelligence-runs list endpoint gains a q query parameter for case-insensitive brief search, alongside the existing disposition filter: GET /api/v2/storefront/intelligence-runs?disposition=declined_fit&q=fintech. Find the demand you’re winning and missing by searching brief text and filtering by outcome.
• get_media_buy_delivery now reports a real, rolled-up status for a media buy that spans multiple sources, instead of always returning pending_start. The status reflects the worst material leg — a rejected or unreachable source is never hidden behind a delivering one — and per-source problems (a refused leg, a source that could not be reached) are listed in the response errors array. When no source returns observable delivery, the call returns a SERVICE_UNAVAILABLE error rather than zeroed totals under a misleading status.
• get_media_buys now reports a real, rolled-up status for each media buy instead of always returning pending_start. A background reconciler keeps each source’s upstream status fresh, and the list folds the per-source statuses into one buyer-facing status — fail-visible, so a rejected or unreachable source is never hidden behind a delivering one. The list is cached for cheapness; get_media_buy_delivery remains the live, authoritative current status.
• Added structured buyer brand context to planning briefs and storefront proposals, and forwarded storefront product selectors through live passthrough discovery.
• Offering-based postal targeting now honors each offering’s country. Previously, postal codes supplied via an offering’s geo_targets were always targeted in the US — a non-US offering’s postal codes were silently mis-targeted. Offerings now carry country-aware postal areas (geo_targets.postal_areas), and the legacy country-less postal_codes field is wrapped using the offering’s country (falling back to US only when no country is known). On Meta, package-level targeting supplied by the buyer is also preserved when an offering adds its own geo, instead of being dropped.
• Storefront MCP connections now stay reliable across multiple server instances. A follow-up request that lands on a different instance than the one that opened the session is transparently recovered instead of intermittently failing, matching the behavior of the buyer and creative MCP surfaces.

​

2.156.0 — June 14, 2026 at 3:08 AM UTC

• ROUTED media buys are now rejected at execution when the selected sales agent has not declared support for the requested postal-code targeting (geo_postal_areas), instead of silently dropping the targeting or failing with an opaque seller error. The seller’s declared postal support is read from get_adcp_capabilities.

​

2.155.0 — June 14, 2026 at 12:46 AM UTC

• Added storefront acceptance policies plus creative and media-buy policy evaluation so approval workflows can distinguish definitely-on-policy, definitely-off-policy, and human-escalation cases instead of relying on generic operating instructions.
• Optimization suggestions awaiting operator approval are now automatically expired when the underlying media buy is updated. Previously, an operator could approve a suggestion only to discover at apply time that the media buy had been edited and the suggestion was no longer valid. The expiry now happens at the moment the new media buy version becomes active.
• Fixed optimization suggestion apply flow so that when a media buy is updated between when a suggestion is produced and when it is applied, the suggestion is correctly handled based on whether the content actually changed. Stale pins where the underlying configuration is identical now retarget to the current version automatically; pins where the configuration has drifted are marked as expired with a clear reason. Suggestions that pre-date this change continue to use the prior strict-version-equality check.
• Deleting a creative manifest now succeeds even when the creative is actively synced to sales agents. Instead of returning an error, the creative is archived, unlinked from any media buys it was assigned to, and the removal is synced to those sales agents.
• Your Merchandising Agent now learns which negotiation strategy actually wins deals and leans into it. Its strategy recommendation favors the posture that has booked the most for you recently — but only once there’s enough evidence to trust (at least four runs that used it, and only if it’s actually converting). Your operating instructions and a buyer’s live signals still take precedence, and the reasoning is recorded with each run so you can see why a strategy was chosen. Below the evidence threshold, the agent falls back to its existing heuristics.
• Advertiser-scoped creative, discovery, and account-sync calls now use the advertiser’s linked brand reference so downstream partners receive the resolved brand identity consistently.
• Murph now publishes reviewed brand.json updates to the AAO community registry through the ADCP SDK registry client.
• Every storefront now starts with default selling behavior: the Merchandising Agent uses your wholesale products and signals to answer briefs as best as possible from the moment the storefront is created. Operating instructions no longer appear in the storefront panel or block going live — you refine how your agent sells by coaching Murph in plain language, and the readiness check now reads “Selling behavior.” Pricing stays separate throughout: wholesale rates come from your inventory sources (your embedded or third-party sales agent), and your rate card shapes buyer-facing pricing. The version history remains available on the operating instructions tab for audit.
• The storefront detail endpoint (GET /api/v2/buyer/storefronts/:storefrontId) now includes an adcpCapabilities field exposing which AdCP operations the underlying agent declares support for. Buyers can check supportsUpdateMediaBuy, supportsCreateMediaBuy, supportsGetReporting, supportsSandbox, extensions, protocols, and reporting delivery methods before attempting calls, without needing to call the agent directly. The capabilitiesCachedAt timestamp indicates when the manifest was last refreshed from the agent.
• Murph and buyer agents now explicitly warn that budget.currency is immutable after campaign creation and must always be confirmed with the user before calling create_campaign. This prevents campaigns from being silently created in the wrong currency (e.g., USD when EUR was requested), which required a full campaign recreate to fix.
• Fixed a bug where creating a GAM advertiser via the storefront ESA endpoint (POST /api/v2/storefront/esa/:id/gam/advertisers/ensure) failed with a validation error on the live path while the dry-run path succeeded. The upstream service returns a numeric advertiser ID on real creation; the response schema now accepts both string and numeric IDs and coerces them to strings.
• Updated Google Ads offline conversion logging to use the Google Data Manager API.
• Added modular inventory source controls for operator-confirmed avails feeds, reservations, lifecycle readiness, demo Cadent handoff preparation, booking release, and source-side work queues.
• Storefront diagnostics now live with the storefront. Each inventory source’s drill-in shows its recent ADCP calls and status changes next to its health diagnostics, so a failing source carries its evidence with it. The seller navigation slims down to chat and history: the standalone Diagnostics and Dashboard pages are no longer in the seller nav (test runs live in “Test your storefront”, change history and activity are available by asking Murph), and the conversation-history sidebar starts collapsed.
• Before your Merchandising Agent is selling, the storefront panel now shows the journey instead of a console: the header counts what stands between you and your first buyer brief (“Two things stand between you and your first buyer brief.”), each open blocker is a numbered step you can tap to fix with Murph (with consequence framing — “No sources connected — your agent has nothing to sell yet”), and everything non-blocking is tucked into a single “How your agent represents you” section. The status chip now reads “Selling” / “Not selling yet”. Once the agent is selling, the panel becomes the health dashboard as before.
• Media buy execution failures against storefront agents now preserve the structured AdCP error envelope, including details.per_source. When every inventory source rejects a media buy, the per-source errors appear in debug output (errors[].debug.response.adcpError) instead of being flattened to a single message string.
• Your storefront now prices to value, not to cost. For every brief, the Merchandising Agent sets the price from what the brief is worth to that buyer — premium format, scarce audience, advertiser type, urgency, stated budget — bounded by your wholesale floors and any ceilings you’ve set, never anchored to a historical auction-clearing percentile. The old fallback percentile is retained only for explainability and no longer sets prices; Murph no longer asks you to choose one. Explicit rate-card targets still act as a value floor the agent can exceed for higher-value briefs, and wholesale rates continue to come from your inventory sources.
• The “Watch your agent sell” card now leads with reality: when buyer demand signals are queued for your storefront, the card shows the actual brief — buyer name, audience, geo, budget — and “Answer this brief” takes it straight to Murph. With no queued demand, briefs are generated from your business profile (your channels, regions, and verticals) instead of a generic pool. Before a storefront exists, the storefront panel now shows a single action — create your storefront — and sections appear only as they become real.
• Improved the storefront Merchandising Agent screen with clearer onboarding copy, a live seller performance dashboard, and cleaner action hierarchy.
• REST error responses with a 5xx status now return a generic message (“An internal error occurred…”) instead of the underlying error detail. Internal errors previously embedded the raw error string — which can include database/driver internals — into the response body; that detail is now logged server-side only. Intentional 4xx messages (validation, not-found, conflict) and the 503 retry message are unchanged.
• Seller analytics now breaks conversion down by the negotiation strategy your agent actually used. The show_seller_analytics payload includes a postureConversion rollup: per-posture run count, booked count, win rate, and booked budget, plus an adherence summary comparing how often your agent followed its recommended posture and whether following it converted better. This turns the per-run strategy capture into “which strategy wins deals” — the evidence base for tuning your selling terms.
• Murph’s seller starter prompts now speak in selling verbs instead of setup verbs — “See my agent handle a brief”, “Train how I sell”, “Connect what I sell”, “Is my agent ready to sell?” — and the seller chat header reads “Train the agent that sells your inventory.”
• Murph now stays in the seller’s register when things break or go deep: connection failures are summarized in plain language with an offer to write up the technical details for your developers, ad-server objects keep the names operators use (never internal identifiers), and acronyms are expanded on first use. Copy refresh from the fresh-eyes audit: the example brief on the chat home is labeled “Example brief”, and the starter chips say “Show me my latest buyer briefs” and “What can my agent sell right now?”. The panel header no longer clips its collapse button in narrow layouts.
• The Merchandising Agent panel now has a “Selling terms” section showing the enforced facts your agent prices and gates on. Under “How it prices”, each rate-card rule shows its floor / target / ceiling by pricing model, marks enforced floors (“Hard floor”) versus advisory guidance, and names the brief it applies to. Under “Reviews & approvals”, your creative-review and media-buy approval gates are shown in plain language, with a one-tap “Change approvals” action. When you have no price rules, it says so plainly — your agent prices from your sources’ rates — with a one-tap “Set selling terms” action. Wholesale rates always come from your inventory sources; these rules shape the buyer-facing price.
• The inventory-source health indicator now tells the whole truth. A source no longer reads “healthy” while its connection is failing or degraded, while nothing has ever successfully synced or been called, or while its inventory list hasn’t been pulled — each of those states now downgrades the verdict, explains itself in the status tooltip, and marks the matching row in the source’s detail view.
• Storefront sellers can now see their AI usage by model over time in a usage dashboard.
• The storefront api_call tool now supports a named operation field (e.g. list_partner_agents, get_storefront, create_esa_connection), matching the buyer surface. Operation mode derives method and endpoint automatically, validates path parameters before dispatch, and rejects unknown operations and unexpected path params — so agents call storefront operations by name instead of constructing raw endpoint URLs. Raw method+endpoint mode still works as a fallback.
• Sellers can now see how their agent is selling, broken down by negotiation strategy. A new GET /api/v2/storefront/seller-analytics endpoint returns the posture-conversion rollup — per-posture run count, booked count, win rate, and booked budget, plus how often the agent followed its recommended strategy and whether following it converted better. The Merchandising Agent rail surfaces this as a “How your agent is selling” section once the storefront is live, so the answer to “which strategy wins deals” lives on a durable surface, not just in chat.
• Manual-approval media buys are now visible end-to-end. Storefront operators see pending media buys on the storefront homepage (live count) and can review, approve, or reject them on the new Media buy approvals page. Buyers can see which layer a PENDING_APPROVAL media buy is waiting at via the new pendingAt field (storefront, salesagent, or unknown) on campaign media buys. Executing a campaign with no media buys to execute now returns mediaBuysExecuted: 0 with reason: no_media_buys_to_execute and no longer marks the campaign ACTIVE. The execute-campaign request body now rejects unknown fields with a 400 that names them.
• The seller chat home now opens with “Watch your agent sell”: a synthetic buyer brief your Merchandising Agent answers honestly from your actual setup — naming the missing supply when no inventory is connected, asking to be trained when selling rules are missing, and offering to run the brief once you’re live. “Train how I answer this” starts the coaching conversation with Murph; “Try another brief” rotates briefs, leading with the channels you sell.

​

2.154.1 — June 12, 2026 at 9:38 PM UTC

• Brand identity for product discovery, campaigns, and media buys is now always governed by the brand configured on the advertiser — it can no longer be set or overridden per request. Previously a brand_manifest sent on a media buy could override the advertiser’s brand at execution time, producing a brand domain that didn’t match the one products were discovered under; valid products were then reported as unknown and the buy failed before reaching the sales agent. Media buy execution and product discovery now both resolve the brand solely from the advertiser, so the two can never disagree. Additionally, an advertiser must have a brand configured before product discovery can run or a campaign or media buy can be created: these actions now fail with a clear validation error directing you to add a brand to the advertiser first, instead of failing later with confusing errors.

​

2.154.0 — June 12, 2026 at 9:06 PM UTC

• Creative manifests now expose a requires_upgrade boolean field. Legacy manifests (created without a format_kind) have requires_upgrade: true and must be upgraded via the new POST /campaigns/:campaignId/creatives/:creativeId/upgrade endpoint before they can be assigned to new media buys. Existing media buy assignments are unaffected.
• Fixed optimization suggestion HIL expiry so that newer suggestions correctly supersede older pending suggestions for the same media buy, even when a media buy update created a new version between them.
• Fixed optimization-suggestion expiration so that a new suggestion only expires prior pending suggestions for the same media buy. Previously, a new suggestion on one media buy expired pending suggestions across all media buys in the campaign, leaving only one pending suggestion per campaign at any time.
• Storefront media-buy and creative approvals now surface consistently in the storefront-managed approval queue, execute against the underlying sales agent after approval, and send buyer ADCP webhooks when queued approvals resolve.
• Reframed the storefront setup panel around your Merchandising Agent. The panel header now shows how far the agent is from going live and names the next blocker, the readiness section is a blocker-led go-live checklist, brand identity and business profile are combined into a single “About your business” section, and sandbox test plans are now “Test your storefront”. Section summaries lead with what needs attention (for example “1 of 2 sources needs attention”) instead of raw counts. Every empty state now offers a one-click action — Connect inventory, Run a test brief, Build my profile, Draft my instructions — that drops a ready-made prompt into the Murph composer, and suggested prompts stay available above the composer mid-conversation instead of appearing only on a new chat.
• Media buys forwarded through a storefront to its inventory sources no longer fail client-side schema validation on creative asset values the seller would accept — most notably VAST tag URLs containing [MACRO] placeholders (e.g. IAS [OMIDPARTNER]), which previously failed format: "uri" validation before the request ever reached the source. The source now adjudicates its own request schema; validation issues are logged as warnings.
• TikTok adapter now preserves the upstream HTTP status and response body when a request fails. Gateway errors and timeouts previously collapsed into an opaque “Upstream request failed” with no detail; they now surface the real HTTP status and a body snippet so failures are diagnosable.
• TikTok adapter now logs the upstream error code, message, and request ID when TikTok rejects a request with a structured error (e.g. budget below minimum, invalid parameter, account/permission issue). Previously these rejections were masked to a generic “Upstream request failed” with no detail in logs, making the actual cause impossible to diagnose.

​

2.153.0 — June 12, 2026 at 6:00 PM UTC

• Currency pickers (advertiser primary currency, planning brief budget) now offer every ISO 4217 currency instead of a fixed list of ten.
• Campaign currency now defaults to the advertiser’s primary currency when not specified on create (instead of hard-defaulting to USD); an explicit budget currency still takes precedence. Contract rate cards no longer constrain a campaign’s currency — only product pricing must match the campaign currency. An advertiser’s primary currency can now be changed at any time, even when existing campaigns use a different currency (each campaign keeps its own currency); the previous block has been removed. The advertiser creation form now prompts for the primary currency (defaulting to USD) so it is set explicitly during setup.

​

2.152.0 — June 12, 2026 at 5:08 PM UTC

• Fixed a bug where package budget and bid allocations were not persisted locally after an optimization suggestion was applied. Agents that don’t return affected_packages in their update_media_buy response left the optimizer with stale baseline data for future runs.
• Improved Google Ad Manager buyer-routing diagnostics for storefronts, including safer advertiser-create recovery guidance and warnings when an advertiser sync completes without reporting how many advertisers were retrieved.
• The Terms of Service update prompt now requires admins to tick a confirmation checkbox before the “Agree” button becomes active, so accepting updated terms on behalf of an organization is a deliberate two-step action rather than a single dismiss-the-popup click.

​

2.151.0 — June 12, 2026 at 2:40 PM UTC

• Adds an advertiser-level creative library. Creative manifests can now be created directly under an advertiser (without requiring a campaign), stored as reusable masters, and assigned to campaigns via new endpoints:
• POST /advertisers/:id/creatives/create - create an advertiser-level creative master
• GET /advertisers/:id/creatives - list the advertiser’s creative library
• POST /advertisers/:id/creatives/:creativeId/campaigns - assign a master to a campaign
• DELETE /advertisers/:id/creatives/:creativeId/campaigns/:campaignId - remove a campaign assignment
• Existing campaign-scoped creative endpoints are unchanged.
• Child accounts can now create campaigns using their parent organization’s contract pricing. Previously, creating a campaign from a child account failed with “No active contract found for customer” even when the parent organization had an active contract.

​

2.150.1 — June 12, 2026 at 1:38 PM UTC

• Capability-mismatch errors (CAPABILITY_NOT_SUPPORTED) from update operations are now classified as correctable and include suggestions naming the specific actions the sales agent does not support (for example update_pacing), so you can remove the unsupported field(s) and retry. Previously they were classified as transient with no guidance, which could prompt repeated identical retries of a request that can never succeed as-is.

​

2.150.0 — June 12, 2026 at 1:21 PM UTC

• Fixed storefront inventory source assessments so AdCP 3.0 agents that support signals are probed with a schema-valid signals discovery request instead of being marked unsupported before a request is sent.
• Fixed product discovery returning zero products from storefronts whose connected inventory source requires a buyer account. The buyer account is now passed through when discovery runs against an in-process storefront agent.
• Improved buyer campaign creation guidance so explicitly requested budget currencies are preserved when campaigns are created.

​

2.149.0 — June 12, 2026 at 2:38 AM UTC

• Added embedded sales agent signal management endpoints and an interactive widget for authoring mapped and composite signals.
• Allowed advertiser creation to register a reviewed brand identity when registry enrichment has no brand data.
• Buyers can now inspect the AdCP capability manifest for any storefront via GET /api/v2/buyer/storefronts/:storefrontId/capabilities. Returns the supported operations, account resolution mode, billing types, and raw capability payload for each source agent — useful for diagnosing why an operation like update_media_buy may be gated.

​

2.148.1 — June 11, 2026 at 10:12 PM UTC

• Fixed format_option_ref to use the AdCP 3.1 scope-discriminated union. Now accepts scope:"publisher" (requires publisher_domain) and scope:"product" (forbids publisher_domain). Legacy flat input without a scope field continues to work — scope is inferred from publisher_domain presence.

​

2.148.0 — June 11, 2026 at 8:40 PM UTC

• Clarified and implemented campaign-level budget reductions for executed media buys: lowering a campaign budget now proportionally reduces live package budgets when needed, while explicit package amounts remain available through the campaign update operation.

​

2.147.0 — June 11, 2026 at 6:44 PM UTC

• Operating instructions now make their effect clear during storefront setup. The storefront panel keeps a plain-language “what this does” line on the active instructions — that these rules drive every buyer request to decide what it offers, prices, and rejects — instead of collapsing to a bare version/status once a version is live. Murph also states the effect and next step while showing the assembled draft, before asking to activate.
• Tidied the embedded sales-agent catalog view in the storefront panel so its create-product and add-signal actions read as a consistent, matched pair.
• Fixed media buy pacing and budget queries to exclude pending update proposals, ensuring calculations use only the current active version of each media buy.
• Fixed a bug where Murph would abandon the GAM inventory-source provisioning flow after the operator confirmed the service-account grant. Murph now calls the provisioning endpoint immediately on confirmation instead of stopping the flow.
• Murph’s inventory selector widget now hands selections to chat without
• requiring a product name up front. After you click “Send selection to
• Murph,” Murph proposes a sensible default name based on your publisher
• and selectors and asks you to confirm or rename before validating or
• creating the product. Empty selection now shows a clear next-step
• prompt instead of a disabled form.
• A storefront can no longer be opened for transactions when it has no products available, so buyers only see “Active” storefronts they can actually buy from. Storefronts whose product availability cannot yet be confirmed are unaffected.

​

2.145.0 — June 11, 2026 at 3:14 PM UTC

• Added creative collections for grouping saved creatives and source assets, plus a bulk creative update operation for previewing and applying saved creative changes with canonical click-through URL updates that refresh creative tracking metadata.
• Allowed buyers to connect multiple provider accounts for the same official adapter storefront, such as separate Snap business accounts.
• Reducing campaign budget and active media buy budget in the same request now works correctly. Previously the validation checked the campaign budget against current allocations before applying the media buy changes, causing atomic reduce requests to fail with INSUFFICIENT_MEDIA_BUDGET even when the new budgets were consistent.
• Fixed an inventory-selector search error that affected storefronts on SpringServe (and would have affected any adapter whose selectors carry null name, path, or status). Previously the response parser rejected the upstream payload as malformed; it now accepts the documented contract shape so SpringServe operators can browse cached selectors and author wholesale products.
• Storefront inventory-source views no longer surface an embedded sales agent connection that has no ad server attached (and was never provisioned) as a separate source. These incomplete connections previously rendered as a second “Embedded” card next to the real ad-server connection — reading as a confusing duplicate — and inflated the inventory-source count and health summary. Embedded connections that have an ad server attached continue to appear, including ones that are still provisioning or have failed, so genuine setup work stays visible.
• Improved advertiser setup guidance so agents research brand domains before asking follow-up questions and avoid unnecessary optimization-mode prompts.
• Sped up the buyer storefronts list (GET /api/v2/buyer/storefronts). Adapter-connection status is now resolved only for the storefronts on the requested page, so response time no longer grows with the total number of adapter storefronts a buyer has accumulated.
• Storefront cards now show the status chip in the footer next to the “Visit website” action, giving the brand name the full card width so longer titles no longer wrap awkwardly.

​

2.143.0 — June 11, 2026 at 3:28 AM UTC

• Expanded the buyer Murph workspace rail with campaign and reporting prompt actions alongside creative and asset context.
• Buyer MCP API calls now mirror additional REST routes and filters, including campaign product lookup, data delivery credential revalidation, and measurement record date/geography filters.
• Improved creative-session MCPUI review data so buyer agents can render source assets, processed renditions, and shared creative review widgets more consistently.
• Expanded the buyer Murph workspace rail with creative, audience, catalog, and event prompt areas for advertiser setup and iteration workflows.
• Prevented discovery product selections from reporting success when the request is bound to a different campaign discovery session.
• Fixed Murph customer switching during multi-customer admin conversations so scoped writes can recover from customer ambiguity.
• Hid storefront sandbox test runs from the buyer creative workspace so the rail starts with creative work and advertiser assets.
• Murph customer list tools now use server-side filters, larger default pages, and explicit pagination metadata for advertiser, campaign, and sales-agent audits. Buyer advertisers can also be filtered by linked partner account before pagination.

​

2.142.0 — June 10, 2026 at 10:26 PM UTC

• Added the reactivate-campaign endpoint to the buyer API reference and made it callable as the reactivate_campaign named operation. POST /api/v2/buyer/campaigns/{campaignId}/reactivate reactivates a paused campaign and cascades to its paused media buys, returning the per-media-buy outcome. Previously this endpoint existed but was undocumented and could not be invoked through the named-operation path.
• Added clickable asset URLs, copy actions, and a gallery view to buyer creative asset management.
• Made Murph’s agent call trace control a compact footer icon instead of a full-width button below each message.
• Fixed formatted creative previews so they no longer reload the raw preview URL as a fallback.

​

2.141.0 — June 10, 2026 at 8:43 PM UTC

• Added an embedded sales agent inventory browser for searching, expanding, selecting ad-server selector hierarchies, and drafting wholesale products with observed ad sizes.
• The buyer storefront detail response (GET /buyer/storefronts/:storefrontId) now reports a single storefront-level connection status instead of a per-source sources[] array. Each storefront returns connected (ready to transact), requiresCredentials (the buyer must register credentials first), and customerAccounts (the buyer’s registered accounts for the storefront, deduped across sources). Credentials are still registered against individual sources.
• Improved Murph creative generation workflows with connected creative-adapter discovery, richer draft/refine/finalize guidance, locked asset and rendition handling, creative workspace previews, and current default image generation models.
• Scoped the Murph creative workspace brand and asset views to the selected advertiser.

​

2.140.0 — June 10, 2026 at 5:48 PM UTC

• Storefront operators can now invoke ADCP protocol tools directly on connected seller agents via POST /api/v2/storefront/agents/{agentId}/invoke. Supported tools: get_products, create_media_buy, update_media_buy, get_media_buys, get_media_buy_delivery, get_adcp_capabilities. Use this to drive deal validation flows and test agent integrations end-to-end.

​

2.139.3 — June 10, 2026 at 4:30 PM UTC

• Fixed pacing period packages submitting a past start time when a period’s start date has already begun. The package start time is now clamped to the current time, enabling same-day execution.
• Buyer agent lookup and media-buy creation now reject a storefront’s underlying inventory-source agent. Buyers transact with the storefront, which routes to its sources; the source agents are not addressable directly.
• Product discovery now resolves inventory exclusively through storefronts. Buyers transact with the storefront, which routes to its underlying sources, instead of addressing those sources directly. Discovered products are attributed to the storefront that surfaced them.

​

2.139.1 — June 10, 2026 at 1:28 PM UTC

• Murph now surfaces the correct endpoints for browsing GAM ad units and placements when operators ask how to search inventory selectors on an ESA. Previously, ask_about_storefront_capability returned no guidance for selector search, causing 404s on incorrect paths.

​

2.139.0 — June 10, 2026 at 12:38 PM UTC

• Creative sessions now track derived asset renditions for locked product assets, including transparent cutouts and thumbnails, while preserving the original source asset.
• Murph can now compare uploaded or linked brand artifacts against current AAO brand.json state, upload logo images to AAO review, preview proposed updates, and publish confirmed brand.json updates to AAO for verified storefront operator domains.
• Fixed ESA connections not triggering initial reporting, pricing/availability, and signal coverage syncs after creation. These data streams now start automatically when a new embedded sales agent connection is provisioned.
• Fixed GET /campaigns returning 500 when any campaign in the list had an end date on or before its start date. The date-ordering validation is now applied only on create and update requests, not when reading persisted campaigns.
• Murph now gives tighter, more scannable replies during multi-step flows like campaign setup: it leads with the decision you need to make instead of re-stating context it already covered, and keeps each turn focused on one thing.
• Surface embedded sales agent creative-format discovery errors instead of returning an empty format catalog when discovery is unavailable.
• Embedded sales agent signal listing now surfaces upstream failures instead of silently returning an empty list. Previously any error while fetching signals was swallowed and shown as “no signals”, which could make a populated signal catalog look empty. Genuine “not found / not wired” responses still degrade to an empty list.

​

2.138.0 — June 9, 2026 at 10:16 PM UTC

• Fixed an issue where pacing period dates on draft media buys could not be modified, even though draft buys have never been submitted to a publisher.
• Ask Murph’s side panels now adapt to the window width. As the window narrows, the conversation rail collapses to a slim strip first, then the state rail — each expanding into a panel that floats over the conversation when opened, instead of squeezing it. Wide windows keep both rails docked side by side; narrow windows stack the panels into a single column.

​

2.137.0 — June 9, 2026 at 7:55 PM UTC

• Refreshed the buyer test-runs rail in Ask Murph to match the storefront sandbox-test layout: scan the run list with at-a-glance status icons, then click a run to drill into its full diagnostics — execution trace, agent calls, and a copyable diagnostic trace. Failed or blocked runs can be sent straight to the chat composer for help.
• Improved creative session planning so image, audio, and video adapters expose generation strategy, composition strategy, and native capability metadata, with cleaner evaluator selection for modality-specific creative review.
• Creative sessions can now carry locked brand assets such as logos from advertiser brand data or chat uploads through draft, refinement, preview, and finalization.
• Property list creation with large domain counts no longer intermittently times out when the AAO registry is slow. The registry lookup phase is now bounded to 45 seconds; when that limit is reached, domains are classified as unresolved (the same behaviour as when the registry is unavailable).
• Storefronts that cannot serve products due to a missing operating-instructions ruleset are now automatically paused and the operator is notified. Buyers see “This storefront is temporarily unavailable” instead of an internal configuration message.

​

2.136.0 — June 9, 2026 at 4:54 PM UTC

• Added a Murph diagnostics workspace for test runs, third-party agent debug calls, and account change history.
• Audio creative sessions now preserve requested AudioStack ad duration/language, allow ElevenLabs voiceover drafts without requiring a separate image-generation key, and keep draft preview links stable across API instances.
• Fixed external signals catalog probes so AdCP 3.0 sellers are not sent unsupported wholesale signals requests.
• Keep the Ask Murph chat composer focused after sending a message, so you can keep typing without clicking back into the input.
• Murph now treats staying in character as a hard rule. When a tool fails, a validation step errors, or the customer must supply inputs Murph doesn’t hold, it states the limitation in Interchange terms and asks for what it needs instead of stepping back to describe its underlying model or deny being Murph.

​

2.135.0 — June 9, 2026 at 1:53 PM UTC

• Added a buyer creative iteration workflow with draft variant galleries, natural-language refinement, linked asset preservation, staged evaluator checks, creative previews for image/video/audio assets, and finalization into campaign creative manifests.
• Creative sessions now plan draft target formats and required manifest assets from a plain brief, can start AudioStack draft audio variants without raw adapter JSON, and treat fal.ai as the creative provider while using transformers such as FLUX for model-family selection.
• Buyer-stack sandbox test runs resolved by storefront name are now recorded against their storefront, so they appear in that storefront’s test history instead of being saved without a storefront.
• Corrected the discovery selected-products response schema: the per-product price field is now documented as bidPrice (the value the API actually returns) instead of cpm. The wire response was always bidPrice; only the schema and generated reference were mislabeled.
• Murph now always replies with a clear message when it can’t complete a request. Previously, if Murph ran out of tool steps mid-task (for example, while repeatedly probing for data that wasn’t available), it could return a blank “no answer” response and the user had to ask again. Murph now makes a final pass to explain what it found and why it’s stuck, falls back to a plain-language message if it still has nothing to say, and stops probing failed calls sooner so it spends its effort on a useful answer.
• Murph now offers publishers a faster path to going live. As soon as an ad server is connected, Murph can propose a set of run-of-site starter products — one per authorized site and creative size, with no targeting — that are sellable as-is as a non-guaranteed CPM auction, surfacing the ad server’s pricing guidance, and frames targeted packages, curated bundles, and guaranteed deals as later steps to grow revenue rather than go-live requirements.
• Storefront sandbox test plans now show every test run for that storefront, scoped per storefront instead of per signed-in user. Operators on the same account now see each other’s test runs, and a storefront’s drawer no longer mixes in runs from other storefronts on the account.
• Murph can now retrieve storefront catalogue and embedded sales agent wholesale product lists through the storefront API tool.

​

2.134.0 — June 8, 2026 at 10:18 PM UTC

• Fixed BYOK creative-family storefronts so ElevenLabs and Veo expose usable audio and video creative formats.
• Fixed PayloadTooLargeError (413) on get_products webhook callbacks. Seller product catalogs can exceed the previous 64KB body-size cap; the limit is now 5MB for get_products and remains 64KB for all other task types.
• Fixed generated creative manifests so image, audio, video, text, and URL assets include ADCP-required asset type metadata.
• Fixed generated creative manifests so text and URL assets include required delivery metadata.
• Fixed an issue where extra creative assets (not declared in a publisher’s format spec) were included in media buy submissions, causing publisher validators to reject the request.
• Fixed create_media_buy payloads for fixed-price CPM products to include an impressions count derived from budget and CPM rate.
• Removed unused incrementalityTestingEnabled field from advertiser measurement configuration.
• The storefront panel now surfaces sandbox buyer test-run diagnostics. Each run lists its status and a step-by-step execution trace, and you can drill into a run to see per-agent get_products results — including the upstream request and response summary for each agent. When a run fails or is blocked, an “Add to chat” shortcut sends a prefilled prompt (the failed steps and any suggested next actions) into Murph chat so you can resolve it without retyping the diagnostics.
• When a seller rejects a media buy update because it falls outside the original quote envelope, the error is now logged with the specific field(s) that triggered the rejection and actionable recovery guidance.
• Publishers can now declare base template format IDs (e.g. display_html, video_vast) on their products and buyers’ sized creatives (e.g. display_300x250_html, video_vast_30s) will be correctly matched and assigned. Previously only exact format ID matches were accepted.

​

2.133.0 — June 8, 2026 at 2:17 PM UTC

• Added webhook callbacks for adapter-hosted creative review status transitions.
• Add storefront adapter support for Gemini, OpenAI, FLUX, Veo, and ElevenLabs creative generation families.
• Added MCP endpoints for family-filtered creative generation and preview tools.
• Buyers now land on the Ask Murph chat experience when opening their home page, keeping the same URL. Accounts without Ask Murph enabled continue to see the existing buyer home.
• Fixed embedded sales agent (ESA) product authoring so validation failures and product lists are reported accurately. A failed product validation now surfaces the specific offending field(s) instead of an opaque error, and the product list no longer renders empty when the upstream response can’t be read — it now reports a clear “couldn’t load” error so a real fault isn’t mistaken for “no products yet”.
• Fixed Murph occasionally rendering its closing question merged into the last bullet of a list instead of as its own line.
• Media buy creative updates now send inline package creatives to sales agents that do not support creative library sync. For library-only sellers, creative sync failures now fail the update synchronously instead of continuing with local-to-seller creative state drift. Malformed creative format agent URLs are rejected before inline creative delivery.
• Storefront adapter OAuth metadata now points developers to the agentic-api adapter documentation.
• Added storefront API controls for inspecting modular inventory source setup state and updating non-secret module configuration.

​

2.132.0 — June 5, 2026 at 7:00 PM UTC

• Added a seller-side preview discovery endpoint so storefront owners can test how buyer agents respond to a brief before going live.
• Fixed Murph losing access to buyer write tools (create advertiser, create campaign) mid-conversation when the router classifies short affirmative messages (“yes create it”, “go ahead”) as knowledge-only. Buyer API tools now remain available for any turn that follows a turn where they were already successfully used.
• Fixed product validation during campaign execution blocking media buy creation when sales agents return non-deterministic product IDs across calls. Products are now trusted as valid until their expiration date once discovered, eliminating the re-query that caused spurious “product not found” errors.
• Creative manifests now accept format_kind (AdCP 3.1 canonical format kind, e.g. image_carousel) as an alternative to format_id when creating or updating a manifest. Also added format_option_ref to pin a manifest to a specific product format option via capability_id, and industry_identifiers to attach Ad-ID, ISCI, Clearcast clock, or IDcrea identifiers. All three fields are returned in manifest responses.
• Format spec lookups now correctly handle parameterized (template) format IDs such as {id: "display_static", width: 300, height: 250}. Dimension and duration parameters are applied as asset slot requirements in the resolved spec, and different parameterizations of the same template get distinct cache entries so validation results are accurate per variant.
• Exposed managed GAM advertiser search, ensure, and default selection operations through the storefront MCP API so sellers can complete buyer-routing advertiser setup from chat.
• Data Delivery Outputs now substitute date placeholders in object-store path prefixes. {YYYY}, {MM}, {DD}, and {HH} are filled from the delivery period start (UTC) and {DATA_DELIVERY_TYPE} from the Output’s data type, so a prefix like lld/{YYYY}/{MM}/{DD}/{HH}/{DATA_DELIVERY_TYPE}/ writes to lld/2026/06/03/14/IMPRESSIONS/. Previously these tokens were written literally.
• A pathPrefix that contains an unsupported placeholder (for example {YYYYMMDD} or {yyyy}) is now rejected when the Output is created or updated, instead of being silently written into the object key. Any text that is not a brace-delimited placeholder is still used verbatim.
• The format detail endpoint (GET /formats/:agentUrl/:formatId) now returns capability_id alongside format_id. Use this value in build_creative or PackageRequest.capability_ids[] to target a specific format option on a product.

​

2.131.0 — June 5, 2026 at 1:14 AM UTC

• Bumped the Storefront MCP AdCP SDK integration to include the latest task polling and authorization error behavior.
• Fixes an issue where storefront adapter media buys would fail after pod restarts when scoped product IDs couldn’t be resolved to their product config.
• Enabled async completion webhooks for storefront inventory source product discovery.
• Fixed submitted product discovery polling so account-scoped inventory sources can return completed get_products results.
• Improved third-party inventory discovery so async product lookups can register callbacks and complete reliably with AdCP 3.0 seller agents.
• Child customers now inherit alpha access over MCP when their parent organization is enrolled. Previously the MCP tool-listing and execution gates only matched a customer’s own ID, so child accounts saw an empty tool list and “access denied” even when their parent was opted in — REST and the web app already honored this inheritance.
• Fixed media-buy product validation so account-scoped sales agents receive advertiser account context when products are revalidated before execution.
• Fixed refresh_agent_capabilities MCP tool surfacing a garbled error message when the remote agent is unreachable. The tool previously doubled the “Failed to refresh capabilities:” prefix; the message now surfaces cleanly.
• Fixed a crash on the storefront Intelligence tab where the page failed to load with “Something Went Wrong” for runs that were skipped or that listed matched products.
• Send campaign creatives inline when creating media buys so sellers without a creative library can transact from buyer workflows.
• Added a Dashboard view to Ask Murph for storefront operators. The sidebar now offers a “Dashboard” entry that swaps the chat column for a tabbed surface — Overview, Reporting, Activity, and Merchandising engine — without leaving Murph, while the conversation sidebar stays in place.
• Updated the AdCP SDK used by buyer and storefront integrations to 9.0.0-beta.24.

​

2.130.0 — June 4, 2026 at 6:05 PM UTC

• When connecting Google Ad Manager, Murph now explains what access Scope3 needs, what it will not do, and what the granted role allows, then asks for explicit consent before walking a publisher through granting access to their network.
• Fixed access token cookie expiry being set to 1 hour regardless of the token’s actual lifetime. The cookie now expires when the JWT does, preventing unnecessary session interruptions for long-lived tokens.
• Wait for async product discovery results from third-party inventory sources before falling back or returning no products.
• Fixed credential rotation so stale credential secret references can be replaced when the existing secret cannot be updated.
• Fixed the assistant chat not scrolling to follow new messages when a conversation is started fresh. Auto-scroll now engages as soon as the first message is sent, keeping the latest reply and the “writing it up” indicator in view.
• OAuth token exchange and refresh now delegate to adapter-provided methods when available, enabling TikTok and other providers with non-standard OAuth flows. TikTok is now a refresh-supported provider.
• Flight date updates (start and end time) on active media buys no longer require seller pre-approval. The update is still dispatched to the seller via the normal ADCP flow.
• The assistant chat now keeps the latest message in view as you send and receive messages, automatically following the conversation. When you scroll up to read earlier messages it stays put instead of yanking you down, and a control lets you jump back to the latest. Auto-scrolling respects your reduced-motion preference.
• Multi-day delivery reports now produce correct per-day, per-package metrics in delivery reporting. Previously a report covering several days collapsed its package metrics onto a single day; reporting timeseries now attribute each day’s spend and impressions to the correct date.
• Refreshed the storefront cards to a clean, consistent look. Every card is now the same light surface with a thin brand-color accent on top, so a directory of storefronts reads as one cohesive set instead of a patchwork of differently colored headers. Each logo sits on a tile chosen to contrast it — dark or colored logos on a clean white tile, light/knockout logos on a dark tile drawn from the brand’s own colors (e.g. a white wordmark on the brand’s signature color) — so logos never wash out. Whether a logo is light or dark is resolved once when the brand is looked up — from the brand.json logos[].background field, the logo’s color tags (light/dark), or its filename — and persisted on the storefront, so cards render instantly with no per-card image processing.

​

2.129.0 — June 4, 2026 at 1:48 AM UTC

• Buyer storefront listings now include each storefront’s coverage regions alongside channels, so buyers can see and filter the marketplace by region.

​

2.127.3 — June 3, 2026 at 10:55 PM UTC

• Fixed adapter storefront product discovery so returned products remain valid when executing media buys for the selected provider account.
• Fixed routed adapter storefront execution so scoped products discovered through adapter storefronts can be purchased without being rejected by repeat product validation.
• Allow adapter storefront sales agents to execute routed media buys without requiring legacy operator-auth flags.
• Fixed adapter storefront MCP calls so buyer-connected provider accounts are passed through to sales adapters.
• Fixed campaign execution so selected product budgets are constrained to the campaign’s remaining media budget after fees.
• Fixed GET /campaigns/:id returning duplicate mediaBuyRefs entries and stale optimizationGoals when a media buy had both an ACTIVE and PENDING_APPROVAL version due to SCD Type 2 versioning. The response now de-duplicates by media_buy_id, preferring the pending version which reflects the most recent buyer-requested state.
• Fixed routed campaign execution for adapter-backed storefronts so buys dispatch through the storefront adapter with delegated provider authorization.
• Prevented storefront-backed media buy status refresh from reporting spurious upstream agent URL errors.
• Fixed storefront sync_accounts dry-run responses so clients receive the expected structured result.
• Fixed third-party storefront inventory sources so buyer account sync and account-scoped product discovery use the submitted natural-key account instead of upstream account discovery.

​

2.127.1 — June 3, 2026 at 4:58 PM UTC

• Improved error propagation in the account-switch flow: internal errors now preserve their original cause for easier diagnosis, and creating a child account now correctly returns a 500 instead of an empty response when user-info retrieval fails after account creation.
• Database circuit-breaker errors now return HTTP 503 with a Retry-After header instead of HTTP 500, and no longer trigger spurious GitHub error reports.
• Fixed storefront cards on the Browse storefronts page briefly rendering in the default palette before swapping to each storefront’s real branding. Cards now show a loading placeholder until branding resolves.

​

2.127.0 — June 3, 2026 at 4:38 PM UTC

• Connections are now accessible from Account Settings in the buyer UI. OAuth-capable providers no longer show a redundant bearer token option.
• Fixed product discovery for BYOK adapter storefronts (Snap, Meta, etc.) returning zero results. The buyer’s connected provider credential is now correctly resolved and forwarded when discovering products across adapter storefronts.
• Storefronts backed by a third-party sales agent no longer require an operating-instructions ruleset to return products. When no ruleset is active, these storefronts now pass the sales agent’s catalog through directly instead of returning a composition_pending error — matching the behavior already in place for embedded sales agents.
• Fixed TikTok OAuth authorization URL to use app_id parameter instead of client_id, resolving the “app_id: value is required but missing” error when connecting TikTok from the buyer connections page.
• Ask Murph now lets you keep typing while a reply is still streaming. Follow-up messages you send mid-reply are queued and delivered one at a time as each turn finishes, so you no longer have to wait for an answer before lining up your next question. Queued messages show as pending bubbles and can be removed before they send.
• Storefront operators can now refresh a sales agent’s cached capabilities themselves via POST /api/v2/storefront/agents/{agentId}/capabilities/refresh (also available through the storefront MCP). This previously required platform admin access. Use it when an agent changes what it advertises (for example, whether it requires operator credentials or which billing modes it supports) and the cached state hasn’t caught up yet. Sellers can only refresh agents their own storefront owns.

​

2.126.0 — June 3, 2026 at 2:31 PM UTC

• Added compatibility handling for media buy delivery reporting webhooks that are sent without an ADCP task envelope.
• Adapter storefront inventory is now identified as ROUTED-only and rejected when used with DECISIONED campaigns.
• Added an account analysis MCP tool for adapter-backed storefronts, including structured findings, recommendations, and an interactive analysis viewer. The tool uses delegated storefront adapter connections for provider auth, and Spotify is available as a wired storefront adapter provider.
• Added adapterProviderType field to the buyer storefront list response, indicating the adapter platform (e.g. “meta”, “tiktok”) or null for non-adapter storefronts.
• Buyer storefront browse now filters by status, channel, and region server-side. GET /api/v2/buyer/storefronts accepts three new optional query params: status (configuring | transacting | archived), channel (an ADCP channel code such as display, olv, or ctv), and region (a region code such as EMEA, NORAM, or APAC), returning only matching storefronts. On the browse page, the status, channel, and region filters are now populated from known option sets and drive the query directly, so they render fully on first paint instead of appearing only after the storefront cards finish loading.
• Delivery webhooks now deduplicate on idempotency_key, preventing duplicate processing when sellers retry delivery reports.
• Murph seller analytics now returns historical performance and strategy signals, and product composition can use recent storefront outcome history to tune built-in negotiation defaults.
• Added seller recommendation signals to Murph seller analytics.
• Products now surface formatOptions in discovery responses when the sales agent publishes AdCP 3.1 format_options[] declarations. Each entry carries a format_option_id that buyers can reference via format_option_refs in create_media_buy to select a specific format option.
• Added durable storefront adapter connections so server-side workflows can use delegated provider credentials without client-held tokens.
• AM-1287: Derived managed ad-server operational health from the upstream tenant status feed, and treated local provisioning state as lifecycle bookkeeping rather than request-readiness.
• Added Spotify as a supported expert-run adapter provider for Storefront configuration.
• Fixed adapter storefront discovery so connected adapter storefronts can be used from buyer-agent product discovery workflows.
• Added buyer-facing provider connections for official adapter storefronts, including browser handoff URLs for OAuth providers and bearer-token setup for direct adapter credentials.
• Documented the storefront source graph architecture, clarified the Storefront routing boundary, and exposed storefront-level routing metadata plus adapter OAuth discovery for expert-run adapter storefronts. Linked storefronts and embedded sales agents are private Chef sources, not Storefront routing modes.
• Expanded Murph seller analytics with buyer-level negotiation conversion, monthly seasonality signals, and richer guidance for storefront negotiation strategy.
• Fixed third-party sales-agent calls (get_products, create_media_buy) failing with a spurious ADCP error. Activity capture is now best-effort: when a source has no entry in the shared agent registry, the activity is skipped rather than failing the underlying call.
• Fixed the adapter OAuth success page close button so it works under the deployed content security policy.
• Fixed adapter OAuth authorization so allowed localhost callback URLs can be used with providers that auto-register OAuth clients.
• Fixed a race condition in Ask Murph where clicking “New Chat” while a response was streaming would be overridden by the completing stream, leaving the user in the old conversation instead of starting fresh.
• Fixed buyer agent access to official adapter storefront connection management.
• Improved Buyer MCP tool discovery so agents can reliably find and use the API call tool after selecting an account context.
• Fixed carousel creatives being rejected during sync when the format spec declares only a repeatable group (no individual asset slots). The asset builder was incorrectly falling back to generic type-based keys (image, image_2, etc.) alongside the correct cards array, causing the pre-sync asset validator to flag those keys as unrecognized and block the request.
• Fixed a 500 (Failed to browse products) in product discovery when a sales agent returns a product card without a format id. The product-card projection now tolerates a missing format_id instead of throwing, matching the guarding already used elsewhere in the same path.
• Fixed list tables showing a contradictory “Page 1 of 0” pager when there were no results. The pagination footer is now hidden whenever a list is empty, across the campaign creatives page and all tables built on the shared entity table (storefront, proposals, advertisers, connections, discover supply, and others).
• Fixed storefront media buys so products backed by embedded sales agents can be bought and have creatives synced end to end.
• Fixed Storefront adapter OAuth authorization so allowed redirect URIs can be used reliably after server restarts or across multiple API pods.
• Improved storefront product pricing so audience signals do not incorrectly apply unrelated inventory rate card rules to premium packages.
• Fixed a budget error that blocked executing a campaign whose selected products carry no explicit per-product budget (for example a single discovered product executed directly). Such products now default to a share of the campaign’s post-fee media budget rather than the fee-inclusive total, so they no longer overshoot the media budget and get rejected during execution.
• Product discovery is now resilient to a single sales agent returning a malformed response. Previously, one agent’s unparseable products (for example an invalid format list) could fail the entire discovery request with a 500; now the offending agent is skipped and recorded, and the remaining agents’ products are still returned.
• Updated the buyer storefront browse copy: renamed “Browse the Interchange” to “Browse storefronts” with the subtitle “Discover who sells on the Interchange.” on both the home-page section and the full storefronts page.
• Renamed the embedded-sales-agent surface from “PSA” to “ESA” across the storefront API. Storefront REST routes move from /api/v2/storefront/psa/... to /api/v2/storefront/esa/..., the inventory-sync webhook moves from /webhooks/psa-sync/... to /webhooks/esa-sync/..., and the response/schema names (PsaConnection, PsaTenantStatus, PsaSyncHistoryResponse, etc.) are renamed to their Esa... equivalents. The unrelated Platform Services Agreement (“PSA”) used in terms-of-service acceptance is unchanged.
• Fixed adapter storefront product discovery routing when existing storefront agent rows had stale MCP endpoints.
• Storefronts now compose third-party sales-agent inventory into their own branded catalog, alongside embedded sources. A connected third-party agent’s products are warmed, offered to Chef composition as single-source products, and exposed pass-through — all routable on create_media_buy. If composition is briefly unavailable, the storefront still serves each source’s own products rather than returning empty.
• Storefront MCP sessions now use the AdCP SDK platform handler at the existing /storefront/:platformId/mcp endpoint. Storefront discovery, buyer session binding, and config-derived capabilities are preserved. Mutating Storefront tools now advertise and enforce AdCP idempotency with a 24-hour replay window, SDK request/response validation is strict, and buyer-visible SDK tasks are persisted in Postgres for restart and cross-pod polling safety.
• Storefront source diagnostics now report per-source health. Each entry in a storefront’s readiness sourceDiagnostics includes a health object — status (healthy / degraded / unhealthy / unknown), the last error message and code, and the last error / success / check timestamps — so operators can see when an upstream inventory source last responded and why a read degraded.

​

2.125.0 — May 30, 2026 at 6:45 PM UTC

• Added a Murph-guided sandbox buyer campaign test planning flow that checks storefront visibility, sandbox advertiser readiness, and the buyer-infrastructure steps Murph would run once server-issued approval tokens are available.
• Added buyer-level outcome and ask rollups to Murph seller analytics.
• Improved Murph document processing so uploaded files can be converted into structured facts, gaps, recommendations, next steps, and brand.json mapping candidates during offline processing.
• Added attributed booking and delivery outcome summaries to Murph seller analytics.
• Added an optional seller analytics panel to Murph responses so storefront operators can visualize recent pricing, composition, and refine activity.
• Improved storefront product composition guidance for price objections, packaging changes, and buyer-history negotiation context.
• Added storefront outcome attribution so seller analytics can connect product exposure to media-buy booking and delivery events.
• Add card-by-card authoring UI for image_carousel creatives. The creative detail page now switches to a carousel editor when the format spec declares a repeatable_group asset slot, letting buyers add, edit, reorder, and delete cards with image uploads and text fields.
• Fixed a bug where deleting a sales agent did not remove it from service_token.active_adcp_agent_ids. The cleanup query was using the numeric database id instead of the stable agent_id string, so deleted agents could remain referenced in service-token active agent arrays.
• Improved Murph document uploads by summarizing PDF contents, highlighting gaps and recommendations, separating next steps, and recording first-pass processing status for the storefront state rail.
• Added a Murph-operated sandbox test execution path for connected external sales-agent inventory sources.
• Added Murph guidance for planning a test campaign against a connected external sales agent before running any campaign execution steps.
• Improved Murph’s storefront setup flow for registering and assessing external sales agent inventory sources.
• Added per-inventory-source diagnostics to storefront readiness and surfaced them in Murph’s setup rail.
• Returned a clear client error when ADCP webhooks use an unsupported payload envelope.

​

2.124.0 — May 30, 2026 at 3:54 PM UTC

• Murph seller analytics now includes attributed booking and delivery outcome summaries. The sellerAnalytics payload adds a top-level outcomes object and per-run outcome details using last-touch product-overlap attribution.
• Murph seller analytics now includes buyer-level outcome and ask rollups, and booked budget is counted once per attributed media buy instead of being inferred from the latest event.
• Murph now surfaces storefront health blockers, including managed sales agent setup tasks, when operators start a storefront conversation.
• Added storefront composition pricing settings for value-based pricing facts, fallback auction pricing targets, Murph-authored structured pricing rules, composed-product pricing options, wholesale product pass-through, and negotiation analytics capture.
• Fixed operator domain setup incorrectly failing with “Domain is already registered to another organization.” Multiple organizations can now share the same operator domain. Setting a shared domain no longer reassigns another organization’s signup routing.
• Allowed storefront owners to test product discovery and Murph-run brief evals against their own configuring storefronts before opening them for transactions. Murph now offers candidate test briefs and runs pre-built, imagined, or pasted briefs through the same dry-run storefront eval path, and intelligence-run records include a user-facing explanation of why products were selected, priced, omitted, or rejected.
• Added buyer endpoints to poll and cancel media buy update proposals: GET /api/v2/buyer/update-proposals/:id and DELETE /api/v2/buyer/update-proposals/:id.
• Show all returned storefronts in Browse the Interchange, simplify the section description, require storefronts to pass marketplace review before appearing to buyers, and notify Slack when a storefront is ready for review.

​

2.123.0 — May 29, 2026 at 8:18 PM UTC

• Data Delivery is now discoverable from the buyer MCP. Added a Data Delivery section to the buyer skill documentation (concept model, field reference, Probe lifecycle, advertiser-vs-campaign scoping) so ask_about_capability can surface it, and registered a revalidate_data_delivery_credential operation that re-runs the destination Probe without resubmitting the credential. Also published a buyer guide for end-to-end setup across GCS, S3, and Azure Blob destinations.
• Added storefront API support for managed-sales-agent buyer advertiser routing, including GAM advertiser search, advertiser ensure, buyer mapping management, recent buyer visibility, and readiness checks for upstream Sales Agent setup blockers.
• Advertisers now have a primary currency. Campaign budget currency defaults to the advertiser’s primary currency when not specified. Selected product pricing is rejected when it uses a currency that does not match the campaign budget currency.
• Aligned Storefront setup, inventory-source, and Merchandising Agent terminology across the v2 API descriptions, docs, and UI copy.
• When a media buy update requires seller approval (requires_approval mode), the campaign update endpoint now returns HTTP 202 with a proposals array instead of a blocking error. Each proposal entry includes proposalId, mediaBuyId, and status: PENDING_SELLER_APPROVAL. Updates that require requires_proposal mode continue to return an error until that flow is implemented.
• Clarified storefront readiness checks by separating required go-live checks from setup guidance and optional status checks.
• Closed multiple cross-tenant authorization gaps in the /tools route-handler surface (also reached via Murph invoke_action):
• customer_get and customer_get_seats: now reject requests for customers the caller is not authorized to view (matches existing MCP tool behavior).
• customer_invitation_approve / resend / reject / cancel: now verify the invitation belongs to a customer the caller can access before forwarding to the internal backend.
• product_save / product_discover: now scope writes and reads to the caller’s customer for non-SuperAdmin callers; non-SuperAdmins can no longer pollute or read another customer’s product catalog or create generic (null-customer) Scope3 products.
• seat_details_get: cross-tenant seat fetches by non-SuperAdmin callers now return a not-found error instead of leaking seat name, members, and connected agents.
• PSA storefronts now return their warmed catalog products when buyers call get_products, instead of blocking with a composition_pending error due to missing operating instructions.
• Fixed media buy delivery webhooks failing with VALIDATION_ERROR on the status field since the SDK 8.0.0 upgrade. The delivery notification the SDK passes to handlers contains only the inner report data, not the task-envelope status field that GetMediaBuyDeliveryResponseSchema now requires. The fix merges status from the webhook metadata before schema validation so sender payloads in the correct MCP format are accepted again.
• Non-admin users whose organization has an unaccepted Terms of Service now see a blocking modal with a “Notify your admins” button, instead of landing on a page where all API calls fail silently. If no admins exist on the account, the modal directs the user to support@scope3.com.
• When a media buy update is blocked because the sales agent requires seller approval (rather than a self-serve flow), the API now returns a distinct SELLER_APPROVAL_REQUIRED error code instead of the generic CAPABILITY_NOT_SUPPORTED. The error message and recovery suggestions tell the buyer to have the seller approve or activate the buy before retrying.
• Surface Sales Agent cached product pricing guidance, forecast freshness, bookability, and managed sync-health drill-down in storefront discovery.

​

2.122.0 — May 28, 2026 at 1:56 PM UTC

• Added a storefront managed-sales-agent connection test action and secure credential-form deep links so publishers can re-check ad-server connectivity after setup or credential updates.
• Murph chat now supports dragging and dropping PDFs, images, and common document formats into the conversation.
• Added secure Slack handoff buttons for Murph ad-server credential setup so operators can enter SpringServe and FreeWheel credentials in Storefront instead of chat.
• Added POST /campaigns/:campaignId/creatives/validate for dry-run creative manifest validation. Calls the ADCP agent’s validate_input tool and returns per-target results indicating pass, fail with slot-level violations, or unvalidatable (for nondeterministic formats).
• Allow shipping the same Data Delivery type (e.g., IMPRESSIONS) to multiple credentials on a single advertiser or campaign scope. The uniqueness rule on Data Delivery Output arrays is now (dataDeliveryType, credentialName) instead of dataDeliveryType alone — list one Output per destination to fan a type out to several buckets or warehouses.
• Fixed signup notifications failing to reach admins when a customer has no domain mapping configured. The system now automatically populates the customer domain and mapping table after the first signup for that customer, so subsequent signups resolve admins correctly without manual intervention.
• image_carousel manifest validation now enforces the allowed_card_media_asset_types constraint declared in the format specification. Submitting a card with a disallowed media type (e.g. a video card in an image-only carousel) now returns a card_media_type_invalid validation error instead of silently accepting the manifest.
• Murph can now read transcript text from supported Loom links and clearly reports when a Loom recording has no readable transcript available.
• Fixed Data Delivery transfers failing with “Anonymous caller does not have storage.objects.list access” by aligning the worker’s google-auth-library version with the one bundled inside @google-cloud/storage. Impersonated credentials now attach correctly to the export-bucket read, so GCS, S3, and Azure deliveries can complete.
• Prevented Murph from confirming reports, learnings, or business profile writes unless the corresponding action completed, and corrected report confirmations to use the ticket ID returned by the filing action.
• Prevented Murph from self-disclosing as an underlying model or treating routine action confirmations as roleplay tests during active conversations.
• Improved Murph storefront setup guidance so next-step questions continue the setup flow instead of reworking agent personality suggestions.
• Kept Murph’s storefront setup tools available throughout storefront setup conversations so operators can activate confirmed product-rule versions from chat.
• Fixed re-inviting users who were previously removed: admins can now successfully re-add users who had been removed from a customer or seat.
• Fixed signup blocking new domains: the CSP backend returns showPsaBox but the agentic API was reading showTosBox, causing all first-time signups from unregistered domains to be incorrectly blocked.
• Fixed brand name drift between POST /storefront/resolve-brand and the cached storefront.brand_name column. The endpoint now persists the resolved brand name and logo URL back to the caller’s storefront row when the resolved domain matches their operator domain, so the Configuration view and the storefront state drawer no longer disagree. The drawer also falls back to the live resolution when the column is null. Also pointed the storefront gear icon at the Account tab instead of Configuration.
• getFormatDetails now discovers AdCP v2 canonical formats (image_carousel, sponsored_placement, responsive_creative, agent_placement) via static SDK definitions, and supplements format discovery with get_adcp_capabilities → creative.supported_formats for seller-declared formats.
• url_type values in URL assets now normalize to lowercase (clickthrough, tracker_pixel, tracker_script, vast) to match the AdCP spec. Uppercase inputs are still accepted and automatically lowercased.
• Improved managed sales agent sync status reporting so storefronts show derived refresh health, safe warnings, and retry progress instead of raw sync-run failures.
• Renamed the storefront’s per-pass observability endpoints from /chef-runs to /intelligence-runs. The endpoints now sit under a “Storefront intelligence” framing that scales to future input → reasoning → output use cases beyond product composition (creative approval, media-buy approval, pricing, policy).
• GET /v2/storefront/chef-runs → GET /v2/storefront/intelligence-runs
• GET /v2/storefront/chef-runs/:id → GET /v2/storefront/intelligence-runs/:id
• PUT /v2/storefront/chef-runs/:id/label → PUT /v2/storefront/intelligence-runs/:id/label
• The wire field ingredientsSnapshot on each row is renamed to inventorySnapshot for consistency with the storefront’s “inventory sources” vocabulary. The OpenAPI schemas ChefRun* / LabelChefRunBody are renamed to IntelligenceRun* / LabelIntelligenceRunBody.
• The readiness check id surfaced via GET /v2/storefront/readiness changes from first_chef_run to first_intelligence_run.
• Simplified the S3 Data Delivery Credential shape. The config.auth block (with mode: ASSUME_ROLE, roleArn, and externalId) has been removed — S3 credentials now require only bucket and region. Scope3 writes objects into the buyer’s S3 bucket using a single shared IAM principal; grant s3:PutObject (and s3:DeleteObject for the Probe sweep) to that principal in your bucket policy under the Output path prefix.
• Carousel card validation now rejects cta values not in the format’s declared cta_values list, returning a structured card_cta_invalid error with the allowed values. When cta_values is not declared, any CTA is accepted.

​

2.121.0 — May 27, 2026 at 1:18 PM UTC

• Added Data Delivery query support for impressions, clicks, MMP postbacks, and media-buy delivery report types. Outputs configured with these dataDeliveryType values now produce log-level exports against the corresponding signals tables. The MEASUREMENT data delivery type has been removed from the API — it was never wired and is not on the near-term roadmap; submitting it on an Output now returns a validation error.
• Add carousel authoring support: POST /campaigns/:id/creatives/create and the buyer MCP api_call tool now accept a cards array for image_carousel format creatives. Each card supports filename (for multipart file uploads) or url (for pre-hosted assets), plus optional headline, description, cta, and landing_page_url.

​

2.120.0 — May 27, 2026 at 3:23 AM UTC

• Storefronts now appear in buyer-side product discovery as first-class ADCP agents. Every storefront has a matching row in the ADCP agent registry so buyers can reach the storefront’s curated product surface through the same discovery flow they already use for third-party agents. Existing storefronts are backfilled automatically.
• Pre-flight capability guard on campaign update now consumes the structured available_actions[] vocabulary from AdCP RFC #4480 (PR #4514), with fallback to the legacy valid_actions[] for sellers that pre-date the spec. Direction-of-change for budget and flight mutations is resolved per-buy (extend vs shorten, increase vs decrease), so mismatches surface before any downstream call. The runtime path additionally parses the structured ACTION_NOT_ALLOWED error so failure responses carry the typed attempted_action, reason, and currently_available_actions fields.

​

2.119.0 — May 26, 2026 at 9:47 PM UTC

• Added Azure Blob Storage as a Data Delivery destination. Buyers can now register a Data Delivery Credential with a container-scoped SAS token and a Data Delivery Output pointing at it; scheduled deliveries write JSONL files into the buyer’s Azure container. The SAS expiry (se= claim) is parsed at credential submission and surfaced on the credential response as expiresAt so the credential can be rotated ahead of time.
• Creative manifests now accept carousel/multi-card creatives. The image_carousel canonical format is fully supported: the cards asset slot accepts an array of card objects (each with a required media image or video, plus optional headline, description, cta, and landing_page_url). Cardinality bounds from the format declaration are validated (min/max card count). Previously, repeatable-group slots were silently dropped during validation.
• Bump @adcp/sdk to 8.1.0-beta.13 and wire the beta.13 get_products cache_scope behavior through storefront MCP responses.
• Account-scoped composed products are partitioned from public products across brief and refine flows, and async ADCP response errors are surfaced as advisory errors without making synchronous seller errors non-fatal.
• Added channels field to buyer storefront list and detail responses, surfacing the ad channels each storefront supports (e.g. CTV, display, audio). POST /api/v2/storefront/resolve-brand now prefers iconographic logo variants (icon, mark, square) over wordmarks when selecting logoUrl, so storefront cards render a brand mark next to the brand name instead of duplicating it as a wordmark image.
• Fixed apply_proposal failing with “No discovery results cached” after Redis cache expiry. Proposals are now persisted to the database when discovered so they can be recovered even after the cache expires and ADCP re-discovery fails.
• Fixed campaign budget-mode pacing allocating incorrect package budgets when media buys were executed from separate discovery sessions. Each media buy’s packages now receive the correct proportional share of its own product budget across periods.
• Fixed advertiser update so a single PUT can replace Data Delivery Credentials and Outputs together when the new Outputs point at new credentials. Previously, the request was rejected because the old credentials were archived before the Outputs that referenced them were cleared. Updates now upsert credentials first, replace Outputs, then archive credentials no longer referenced.
• Duplicating a creative now generates fresh tracking URLs for the new creative, so the click-through and impression tracker URLs are present immediately after duplication.
• Fixed a crash when setting per-buy pacing periods on campaigns where the media buy start_time is stored as a text string rather than a Date object.
• Fixed platform-managed (PSA) storefronts not appearing in buyer storefront listings. Storefronts backed by Scope3-managed sales agents were invisible to buyers due to a query that required an agent ID - PSA sources have no agent ID by design. These storefronts now appear as connected with no credentials required.
• Fixed storefront not appearing in buyer discovery after going live. When a storefront was set to transacting, any inventory sources whose agents were still pending at registration time would remain stuck in a pending state and be excluded from buyer listings.
• Fixed a validation error when syncing HTML and text creatives to sales agents. Assets are now stamped with the required asset_type discriminator field before being submitted to the ADCP protocol.
• Accounts that inherit their organization’s contract no longer have their own row, no longer prompt for ToS, and contract reads transparently walk to the organization. New /api/v2/contract response fields (inheritedFromOrganization, organizationId, organizationName) and new status values (inherited_active, inherited_hidden, organization_contract_missing). New PATCH /api/v2/contract lets organization admins toggle whether inheriting accounts can see contract details and rate cards. POST /api/v2/accept-tos returns 403 for accounts that inherit.
• The .well-known discovery endpoints (/.well-known/jwks.json, /.well-known/brand.json, /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, /.well-known/openid-configuration) now return the same response on both https://interchange.io and https://api.interchange.io. Programmatic API and MCP endpoints remain at https://api.interchange.io.

​

2.117.0 — May 25, 2026 at 5:06 PM UTC

• Added per-storefront buyer instructions: notes + discount rules scoped by (operator_domain, brand_domain) and optionally filtered by country. Storefront operators manage rows via GET/POST/PATCH/DELETE /v2/storefront/buyer-instructions; the product-composition agent resolves matching rows at get_products time (most-specific notes ordered first, MAX discount across matches).
• Approving a pending media buy now forwards the stored request to the underlying source(s) and records the routing so subsequent update_media_buy / get_media_buy_delivery calls work end-to-end. When an operator decides approved on POST /api/v2/storefront/media-buy-approvals/{mediaBuyId}/decide, the service replays the buyer’s create_media_buy payload, fans it out per source, persists the upstream media_buy_ids, and stamps forwardedAt. The response now includes per-source forward results so the operator UI can render partial failures. The decision itself is recorded regardless of forwarding outcome — partial or failed forwards are retryable separately. Direct-forward (offersCampaignApproval=false) and post-approval modes share a single forwardMediaBuyToSources helper.
• The product-composition agent now owns pricing arithmetic deterministically: each composed product’s baseCpm, operator discount, and finalCpm are computed server-side from the selected bundles and signals plus any matched buyer instructions. Prompts to the model carry a precomputed price playbook and explicit guidance to vary channel mix and record any excluded bundles in the run rationale.
• Storefront agent hardening from review feedback: scope every storefront media-buy route to the buyer that opened it (cross-buyer leak fix on get_media_buys and friends), bind each per-storefront MCP session to its authenticating customer (refuse 403 on hijacked session ids), only stamp forwarded_at after every source completes (adds a POST /api/v2/storefront/media-buy-approvals/:mediaBuyId/retry-forward for the operator UI), and stamp a deterministic idempotency_key on each forwarded source call so retries dedupe upstream. Tightens chef pricing (clamp final CPM at zero, take the min CPM across multi-priced bundles, warn on dropped currency-mismatched signal addons) and trims a few storefront wire shapes (creative-review response is camelCase end-to-end, get_adcp_capabilities tucks the scope3 storefront block under extensions.scope3, list endpoints drop the fake pagination envelope when the service doesn’t paginate yet).
• PSA-backed storefronts now honor operator-stored workflow flags for offersCreativeReview and offersCampaignApproval. Previously all three capability flags were force-locked on for any storefront with a PSA inventory source — operators could not opt their PSA storefront into pass-through review or pass-through approval even when that was what they wanted. offersProductComposition remains locked on (a PSA must surface composed products or it has nothing to sell), but the review and approval workflow flags now flow from storefront_config.settings.capabilities verbatim so operators can configure either queue-mode or pass-through per storefront.
• Adopted the AdCP SDK’s typed response builders across the storefront MCP surface: productsResponse, mediaBuyResponse, updateMediaBuyResponse, getMediaBuysResponse, deliveryResponse, syncAccountsResponse, syncCreativesResponse, and taskToolResponse. Replaces hand-rolled structuredContent objects with builders whose data parameter is the canonical AdCP type — TypeScript now catches schema drift at compile time instead of at storyboard runtime. As a side effect, sync_accounts now returns proper SyncAccountsSuccess.accounts[] entries with brand, operator, action, and status; create_media_buy direct-forward returns a proper CreateMediaBuySuccess with media_buy_id and packages; get_media_buy_delivery returns the canonical GetMediaBuyDeliveryResponse with reporting_period, aggregated_totals, and media_buy_deliveries. Storyboard runner moves from 22-passing/18-failing to 25-passing/16-failing.
• Storefront operators can now inspect the product-composition agent’s reasoning over time. Each get_products pass writes an internal compose-run record capturing the buyer scope it resolved against, the prompt it built, the raw and parsed LLM output, the matched buyer-instructions rows, and the products it persisted. Operators read these via GET /v2/storefront/chef-runs and GET /v2/storefront/chef-runs/:id; evaluators attach structured labels via PUT /v2/storefront/chef-runs/:id/label.
• Added per-storefront creative review endpoints. When a storefront takes over creative review from the underlying salesagent, buyer-submitted creatives land in a review queue that operators can browse and decide via GET /api/v2/storefront/creative-reviews, GET /api/v2/storefront/creative-reviews/:creativeId, and POST /api/v2/storefront/creative-reviews/:creativeId/decide. The decide endpoint accepts approved or rejected. Submissions are idempotent on (creative_id, buyer_customer_id) — a buyer resubmitting the same creative updates the stored payload without resetting a prior operator decision.
• Storefront get_products now honors AdCP buying_mode and the refine[] change-request array. buying_mode: 'brief' is the existing fresh-discovery path; buying_mode: 'refine' lets a buyer iterate on a previous response — entries with scope: 'product' reference an existing product_id and an action (include / omit / more_like_this, optionally with an ask), scope: 'request' adds whole-response asks, and scope: 'proposal' is acknowledged but not yet honored. Product identity is preserved across refines: more_like_this and ask modifications keep the existing product_id and update the recipe in place; omit drops the product from the response; include with no ask is a verbatim passthrough. The response includes a position-matched refinement_applied array. buying_mode: 'wholesale' returns UNSUPPORTED_FEATURE — storefronts are curated discovery surfaces, not raw catalogs.
• Storefronts now expose a per-storefront AdCP MCP endpoint at
• /storefront/:platformId/mcp. The tool surface is capability-filtered
• from the storefront’s flags: get_adcp_capabilities is always available;
• get_products, sync_creatives, and create_media_buy are registered
• only when the matching storefront capability is enabled. Pass-through
• storefronts (advertiseAsAgent === false) and unknown platform IDs
• return 404. The endpoint accepts scope3 customer API key auth this
• round; product composition, creative review, and campaign approval
• handlers remain placeholders while their pipelines land.
• Storefront MCP surface (/storefront/:platformId/mcp) now exposes the full AdCP buyer tool set, not just get_products. New tools: sync_accounts, sync_creatives, create_media_buy, update_media_buy, get_media_buys, get_media_buy_delivery. Capability flags drive the implementation path, not whether a tool is exposed: offersCreativeReview and offersCampaignApproval switch between operator-managed queues and direct pass-through to the underlying sources. create_media_buy resolves each package’s source from the composed product’s stored implementation_config and fans out per source. Subsequent calls to update_media_buy, get_media_buys, and get_media_buy_delivery read a new storefront_media_buy_routes table so they route per source automatically. sync_accounts registers buyers on every connected source and records the per-source upstream account id in storefront_account_routes.
• Added per-storefront media-buy approval queue endpoints. When a storefront opts into operator review of buyer-submitted media buys, buyer create_media_buy calls land in a pending queue and operators decide via the new REST surface: GET /api/v2/storefront/media-buy-approvals (defaults to pending; ?status=approved|rejected|revoked to filter), GET /api/v2/storefront/media-buy-approvals/:mediaBuyId (single entry), and POST /api/v2/storefront/media-buy-approvals/:mediaBuyId/decide with body { status: 'approved' | 'rejected', reviewerNotes? }. Decisions are recorded with the reviewing operator and timestamp; double-decide attempts are rejected. Re-submitting the same media_buy_id while pending is idempotent; re-submitting after a decision requires a fresh id.
• Added per-storefront operating instructions endpoints. Operators can author versioned markdown rules that the storefront’s composition agent consumes when producing products: GET /api/v2/storefront/operating-instructions, GET /api/v2/storefront/operating-instructions/active, GET /api/v2/storefront/operating-instructions/:version, POST /api/v2/storefront/operating-instructions (creates a new version, never overwrites prior versions), and POST /api/v2/storefront/operating-instructions/:version/activate (swaps the storefront’s active version). Versions are immutable and per-storefront monotone — creating a new version produces a clean cutover so composition output for the new rules is distinguishable from the prior generation.
• Storefront get_products responses now meet the AdCP v3 schema contract. Every product carries publisher_properties (derived from the storefront’s platformId), reporting_capabilities (daily UTC reporting with the standard impressions+spend metrics and date_range_support), and pricing options now use the canonical pricing_option_id + fixed_price shape (not the previous rate/is_fixed pair). The response envelope itself includes the v3 canonical status field and echoes the buyer’s request context back unchanged. get_adcp_capabilities accepts and echoes context as well. These changes move the AdCP storyboard runner from 3-passing/33-failing to 22-passing/18-failing on the same agent surface — the remaining failures are protocol-level error-code conformance (PRODUCT_NOT_FOUND, VERSION_UNSUPPORTED, TERMS_REJECTED, etc.) and response-shape work on sync_accounts / sync_creatives / create_media_buy envelopes.
• Storefront MCP tools now echo the AdCP context field on every response (success and error), reject unsupported adcp_major_version values with the canonical VERSION_UNSUPPORTED envelope, and validate start_time / end_time semantics on create_media_buy before forwarding (reversed dates and past start times return INVALID_REQUEST directly). Every tool’s inputSchema now declares context + adcp_major_version so MCP doesn’t strip them from incoming args. Fixed a column-name bug in the storefront-source resolver (source_kind → execution_type) that was hiding the inventory sources from sync_creatives + sync_accounts fan-out. Storyboard runner moves from 25-passing/16-failing to 34-passing/8-failing on the same agent surface — schema conformance is now table stakes; the remaining failures cluster around behavioral seller errors (TERMS_REJECTED, accept-buy returns media_buy_id) and a single security_baseline assertion.
• Simplified sync_accounts on the storefront MCP surface. For embedded storefronts the storefront is the buyer agent, so the call now echoes the submitted account_refs back as acknowledged rather than fanning out to underlying sources. Advertiser provisioning on the source side is deferred to create_media_buy and owned by each source’s upstream_advertiser_mode config — the storefront does not remember per-source upstream account ids. The storefront_account_routes table was dropped (it was never referenced by approved code paths). storefront_media_buy_routes (the routing for update_media_buy / get_media_buys / get_media_buy_delivery) is unchanged.

​

2.116.0 — May 22, 2026 at 8:19 PM UTC

• Creative manifest list now includes target_format_ids — additional format IDs a creative covers beyond its primary format. The campaign creative assets page shows which formats are already covered (alongside which are still missing) and allows assigning an existing creative to a missing format without re-uploading assets.
• Fixed apply_proposal returning “No discovery results cached” when the discovery cache had expired. It now automatically re-runs discovery to repopulate the cache before retrying, matching the existing recovery behavior in other discovery operations. Also extended the discovery cache TTL from 30 minutes to 4 hours.
• Fix format selector missing format IDs (e.g. banner_728x90) that are declared on products but not returned by the ADCP creative agent’s listFormats call.

​

2.115.0 — May 22, 2026 at 11:51 AM UTC

• Child customers can now view their contract from Account Settings → Contract,
• Billing & Invoices. Rate cards inherited from a parent customer are surfaced
• under an “Inherited rate cards” label — when the parent has opted to share
• them the rates appear, otherwise the section indicates that rates are
• inherited from the parent.
• Fixed a race condition where simultaneous storefront inventory source auto-activations (e.g. a source creation and an agent-activation hook firing at the same time) could fire duplicate activation events. The auto-activation UPDATE is now idempotent and only emits a log/audit event for the writer that actually transitions the row from PENDING to ACTIVE.
• Fixed a bug where package budget, pacing, and bid_price updates were not sent to the SSP when updating an active media buy. The SSP would receive the existing values instead of the requested changes, leaving the media buy stuck in PENDING_APPROVAL. Also added Sentry capture for ADCP sync failures that were previously only logged to GCP.
• Fixed inventory sources backed by OAUTH sales agents being auto-activated before the OAuth token exchange completed. Sources now stay PENDING until the agent has a stored credential reference; only NO_AUTH sources skip that check.
• Fixed a bug where verifying one storefront’s operator domain would incorrectly mark all of the customer’s other storefronts as verified. The auto-verification backfill is now scoped to the specific storefront whose domain was just verified, so storefronts with different operator domains remain unverified until each is independently checked.
• Fixed a server-side request forgery vector in the storefront discover-agents flow. The server-side fetch of https://{domain}/.well-known/adagents.json no longer follows redirects, so a third-party host cannot bounce the request to an internal address and have the response surfaced through the discover-agents response.
• Fixed POST /api/v2/storefront/resolve-brand and GET /api/v2/storefront/discover-agents to return the standard response envelope ({ data, error }) on both success and failure. Previously these endpoints returned raw bodies on validation errors, breaking clients that rely on the consistent wire format used everywhere else in the v2 API.
• Hardened Stripe Connect onboarding callback tokens by binding each token to the specific Stripe account and adding a 15-minute expiry. Leaked or replayed callback URLs can no longer be used to mark onboarding complete or mint fresh onboarding redirects.

​

2.114.0 — May 21, 2026 at 8:00 PM UTC

• Added duplicate creative endpoint. POST /campaigns/:campaignId/creatives/:creativeId/duplicate creates a copy of an existing creative manifest (including all assets) with a “Copy of” prefix on the name.
• Add domain auto-join setting for customer orgs. Admins can enable allowDomainAutoJoin on their customer to let users with a matching verified domain email join immediately as members without requiring admin approval.
• Added S3 as a supported Data Delivery destination. Data Delivery Credentials and Outputs can now target a buyer-owned S3 bucket, with cross-account access via AWS STS AssumeRole. Buyers create an IAM role that trusts the Scope3 AWS principal (with an optional externalId) and reference it in credential.config.auth.roleArn. Probe validation and per-cadence object delivery use the assumed role; no long-lived AWS access keys are stored.
• Operator note: the Temporal worker pod must provide a base AWS identity that the SDK’s default credential provider chain can read, so that STS AssumeRole calls can be made. Supported options: (a) GKE Workload Identity Federation → AWS via OIDC (AssumeRoleWithWebIdentity); (b) AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY env vars for a Scope3 IAM principal with sts:AssumeRole permission; (c) IAM Roles Anywhere. The buyer IAM role’s trust policy must trust whichever principal we use. Without one of these, the first delivery will fail with CredentialsProviderError.
• GET /api/v2/accounts/current now includes customerDomain so callers can tell whether the current customer has a registered organization domain (required before enabling domain auto-join).
• Fixed inventory source status badges and Activate/Disable actions always showing the wrong state. The UI was comparing lowercase status strings against the API’s uppercase values (PENDING, ACTIVE, DISABLED), causing health indicators to always appear as “Pending” and status-toggle requests to be rejected by the server.
• Fixed CORS rejection for requests from the https://interchange.io apex domain to the PSA storefront proxy endpoints. The previous allowlist regex required at least one subdomain, causing fetch requests from the PSA admin iframe to be blocked in production.
• Fixed a gap where toggling transacting: true on a storefront could bypass the readiness check if the request went through the MCP storefront tool surface or any other internal caller that did not pre-check readiness. The gate now runs inside StorefrontService.update() itself, so every path returns the same blocker list when required setup is incomplete.
• Murph conversations are now persisted and retrievable. Added two member-scoped endpoints — GET /v2/murph/conversations and GET /v2/murph/conversations/:conversationUid — and a shareable /$customerId/murph/c/:conversationUid route in the UI so the chat history survives page refresh and can be linked to a teammate.
• Add Murph proactive surfaces: a digest endpoint that summarizes unread notifications, personalized starter prompts driven by user state, an online/health indicator, and a closed-set ?askMurph=<intent>&entity=<entityRef> deep-link convention with “Ask Murph about this” buttons on campaign, advertiser, and sales-agent detail pages. The digest is automatically folded into the orchestrator’s first-turn context so Murph can answer “what changed?” without an extra round-trip.
• Storefronts now carry a capabilities block on the v2 response declaring which AdCP extensions the storefront advertises to buyers: offersCreativeReview, offersCampaignApproval, offersProductComposition. A derived advertiseAsAgent boolean tells callers whether the storefront should be addressed as an AdCP agent (vs. pass-through to the underlying inventory source). Embedded (PSA-backed) storefronts have all three capabilities locked on with capabilitiesLocked: true; third-party storefronts default all off (pass-through). The PATCH /api/v2/storefront body accepts a capabilities patch — locked storefronts reject writes that would turn any capability off.
• Buyer-facing surfaces now display the storefront’s name as the seller identity instead of the underlying sales agent’s name. The storefront IS the agent buyers see in this product — underlying sales agents (third-party AdCP agents and embedded managed agents) are internal routing detail, not separate seller identities. Product cards, the discovery productCard modal, media-buy sections, and proposal badges all read from storefrontName now. Discovery responses stamp storefrontId / storefrontName on every Proposal and persist them through cached rails so the seller label is reliable across both fresh discovery and saved discoveries that get replayed. Cached rails group by storefront instead of sales agent — products from multiple underlying agents that belong to the same storefront collapse into one rail.

​

2.113.0 — May 20, 2026 at 11:19 PM UTC

• Measurement sources now expose an outcomeTypes array field listing all record-level outcome type slugs the source produces. This enables correct linkage between multi-metric sources (e.g. video reports delivering impressions, clicks, and video quartile events) and their individual measurement records.
• Fixed the Creatives tab being blank when “All advertisers” is selected on the buyer home page. The tab now auto-selects the first available campaign and loads creatives correctly.
• Fixed seat-scoped API tokens being rejected with ACCESS_DENIED (“No user context available for seat permission check”) when calling endpoints scoped to their assigned advertiser. The token’s seat role was set during authentication but not propagated into the service-layer context used by seat access checks.
• Reporting data now persists additional AdCP delivery metrics when sales agents report them: conversion value, ROAS, new-to-brand rate, cost per acquisition, cost per click, reach unit, viewed seconds, attention seconds, attention score, engagements, follows, saves, and profile visits. Package-level breakdowns also persist delivery status, paused state, and is-final flags. Previously these fields were dropped during ingestion; they are now stored alongside existing impression, click, view, and conversion metrics.
• Replace the storefront status enum (PENDING / ACTIVE / DISABLED) with two simpler stored fields: transacting (boolean) and archivedAt (timestamp). The API now returns a derived, read-only displayStatus with one of three values — configuring, transacting, or archived — computed from those two fields. Clients toggle live/paused by setting transacting: true | false on PUT /storefront; archiving is now a single explicit operation at POST /api/v2/storefront/archive that sets archivedAt and forces transacting = false. Archived storefronts are read-only — every mutation against an archived storefront is rejected. Existing rows are migrated automatically (status = 'ACTIVE' → transacting = true; everything else → transacting = false).

​

2.112.0 — May 19, 2026 at 10:42 PM UTC

• Property list file uploads now return 202 Accepted immediately and process identifier resolution in the background. Poll the GET endpoint for status updates. Large uploads no longer risk load balancer timeouts.
• Users who request access to an existing organization now see “Your access request is pending approval” on the signup screen instead of the misleading “An invitation is required” message. We also post a Slack notification listing the org’s admins (and page oncall when there are none) so requests don’t sit unanswered when an org’s only admins are stale or unreachable.
• Grouped the logEvent endpoint under the Event Sources section in the Buyer API reference, alongside listEventSources and syncEventSources, so all event-source-related endpoints appear together.
• Improved ad-product retrieval on campaigns:
• mediaBuys[].products[] on GET /campaigns/:id now include productName and publisherName so callers no longer need to reconstruct names from reporting CSVs or audit logs.
• GET /campaigns/:id/products is now the authoritative list of every ad product attached to a campaign. It sources from the campaign’s media buys (joined with the local products cache) and folds in any discovery-staged products not yet executed. Each entry includes productName, publisherName, salesAgentName, pricing, and the media buys it lives on.
• GET /campaigns/:id/products now accepts a mediaBuyId query param (single or repeated) to narrow the response to specific buys, avoiding context-window truncation on campaigns with many products.
• Property lists now create a local Property row for every uploaded site domain that didn’t already have one (same shape as the canonical web property creation path: DISPLAY-WEB channel, AUTO_SYNC, BROWSER). Previously, identifiers without a matching Property fell into unresolvedIdentifiers and were silently dropped from the list, so they didn’t take effect at bid time. Buyer-submitted exclusion and inclusion lists now honor the full domain set.
• Reframed the Add inventory source chooser around what storefront operators actually know about their setup. Two side-by-side cards — “I don’t have a sales agent” (Managed) and “I have my own sales agent” (BYO/AdCP) — replace the title-cased “Connect an ad server / Connect an agent / Link a storefront” rows. Federation moves into a quiet “Coming soon” rail below the cards so it stops competing for attention before it ships. Downstream forms are unchanged.

​

2.111.0 — May 19, 2026 at 2:40 PM UTC

• Added POST /api/v2/identity-match/targeting, returning the seller-keyed audience targeting configuration for every package available to the authenticated token. System tokens receive every active package; customer tokens receive packages they own as a buyer or host as a seller. An optional after ISO-8601 cursor switches the response to delta mode, returning only configs whose package or owning media-buy was updated/archived since that instant. targetSegments is audience-only — audience_include maps to anyOf, audience_exclude to noneOf.
• Allow attaching a clickthrough URL alongside uploaded creative assets on every format. Previously the Clickthrough URL field was hidden (and the slot rejected by the API) when the resolved format spec didn’t declare a click_url / clickthrough_url / landing_page slot, forcing buyers to choose between files OR a click URL. The slot is now accepted universally and stored on the manifest; formats that declare it continue to render it in the AdCP payload.
• The ADCP property list resolve endpoint (GET /lists/{listId}) now supports pagination via max_results and cursor query parameters and returns a pagination object with has_more, cursor, and (on the first page) total_count. Defaults to 1000 identifiers per page; max 5000.
• Storefront demand contact now enforces a both-or-neither rule: name and email must be set together or both cleared. The operator UI has an explicit “Remove contact” action, and partial updates that would leave the pair half-set are rejected with a validation error.

​

2.110.0 — May 19, 2026 at 3:31 AM UTC

• Added a demand-contact name and email to the storefront configuration. Operators can curate the person who fields buyer demand signals (RFPs, prospective briefs, weekly digests); the fields are surfaced via GET /api/v2/storefront as demandContactName and demandContactEmail, and can be edited any time through PUT /api/v2/storefront. Pass null to clear either value.
• Fixed two ways a customer’s operator domain could be incorrectly auto-verified:
• 1. Parent-fallback ignored the child’s own domain. The CHILD-customer verification fallback was returning verified whenever the parent customer had any active member matching the parent’s registered domain, regardless of whether the child’s own customerDomain matched the parent’s. As a result, a child customer parented under (e.g.) Scope3 could appear verified for an unrelated operator domain because Scope3 employees match scope3.com. The fallback now only applies when the child’s customerDomain equals the parent’s customerDomain.
• 2. Approval rows were keyed only by customer. Each customer_domain_approval row is now bound to the specific domain it was issued for (approved_domain column). Previously the read path returned verified whenever any approval row existed for a customer, even if the customer had since changed customerDomain to a different value than the one originally approved. Legacy rows without approved_domain are no longer trusted; customers who still qualify via an active member’s email re-verify automatically on the next read, otherwise a SuperAdmin must re-attest under the current domain.

​

2.108.0 — May 18, 2026 at 10:48 PM UTC

• Creatives now support promoting a different asset to “primary” (the renderable source). Pass primary_asset_id on the update endpoint to demote the current primary and promote the target asset. Only IMAGE, VIDEO, AUDIO, HTML, and VAST assets may be set as primary.
• Pre-launch campaigns can now be edited freely. Start date and pacing periods may be modified after the original start date has passed, as long as the campaign has no live media buys (any non-draft, non-archived buy blocks the edit). Pacing periods also accept a budget or weight of 0 so a single week can be skipped without removing the period.
• Cleaned up the campaign creative assets page: the upload modal no longer auto-opens when a creative has unresolved HTML asset refs (the missing-assets banner now has an inline upload button instead), and the Native copy tab is always visible across both the create-creative flow and the upload-to-existing-creative modal with clear empty states when a format hasn’t been picked or doesn’t declare native slots.
• The single-creative upload paths on the campaign creative assets page (both create-creative and add-files-to-existing) now accept .zip archives. Dropped zips are expanded client-side into their constituent files before upload, matching the behavior of the bulk upload modal. Nested zips are extracted recursively, so standard HTML5 ad bundles work in all upload spots.
• Embedded managed sales agents now support SpringServe and FreeWheel in addition to Google Ad Manager.
• When connecting an ad server you can pick the adapter type and supply the appropriate credentials:
• Google Ad Manager — Scope3 provisions a per-customer service account; you grant it access in your GAM admin console and supply your numeric network code.
• SpringServe — log-in email + password (the salesagent caches a 2-hour token and refreshes it automatically). An API token is also accepted for testing.
• FreeWheel — Publisher API username + password (auto-refreshing OAuth2 password grant). A 7-day temporary access key is also accepted under the advanced section for testing.
• Publisher-supplied credentials are forwarded to the upstream salesagent tenant at provision time and never persisted by Scope3. Only non-secret display fields (login, environment, default advertiser/demand-partner id) are stored so the UI can render “connected as …” after provisioning. Rotating credentials on a live tenant preserves all tenant state (products, principals, sync history) via the new PUT /api/v2/storefront/inventory-sources/{sourceId}/adapter-config endpoint.
• Fixed the storefront card editor so selecting “North America” no longer renders as “Namibia”. The region group code now uses NORAM (matching the signals subsystem) to avoid colliding with the ISO 3166-1 alpha-2 country code NA (Namibia); existing storefronts that stored NA for the North America group are transparently migrated on read.
• Fixed media buy updates being silently dropped by sellers that dedupe on the ADCP idempotency key. The key for update_media_buy previously stayed constant across every edit of the same media buy, so a spec-compliant seller would replay the response of the first update for every subsequent one and the new budget/pacing/bid_price/targeting changes never reached the seller’s ad server. The key now incorporates a fingerprint of the request body, so distinct edits get distinct keys while retries of the same edit still de-duplicate as intended. The same fix is applied to cascade pause/resume and to package-level cancellations.
• Storefront now surfaces inventory-sync state from the managed sales agent: an active PSA shows a dedicated “Inventory sync” row in the source detail dialog (with a Retry button when failed), and the setup-tasks checklist shows a blocker task when inventory sync has failed and an informational row while the first sync is running. Closes #2549.
• When a managed sales agent adapter probe fails, the storefront UI now shows a specific next step driven by the upstream’s structured remediation hint:
• vendor_enables_role — your account doesn’t have the API role this operation requires; contact your SpringServe / FreeWheel rep to enable it.
• customer_rebinds_account — re-enter your username (or email) + password.
• customer_rotates_token — paste a fresh temporary access key or API token.
• The full upstream message and any vendor_fault block continue to be surfaced as supporting detail so support engineers see exactly what the ad server returned.
• Storefront inventory-sync state is now webhook-backed. The salesagent’s sync_run.completed / sync_run.failed events land on a new agentic-api receiver (POST /webhooks/psa-sync/:customerId/:tenantId, HMAC-signed) and update a persisted inventorySync block on each PSA connection — visible to the UI directly via PsaConnection.inventorySync. The per-PSA /status poll cadence drops from 30s to 5 min as a safety net for missed deliveries; the dialog and setup-tasks panel read the persisted state so they reflect sync changes within seconds.
• Set PSA_WEBHOOK_SECRET (shared HMAC secret) and PSA_WEBHOOK_CALLBACK_BASE_URL (defaults to BASE_URL) to enable the webhook path. When unset, the receiver returns 503 and the polling fallback alone keeps the state fresh. Closes the V2 of #2549.
• The Connect Ad Server dialog now shows the right copy when GAM rejects a managed-sales-agent setup. Typos point at the network code, propagation delays show the soft “wait a few minutes” affordance, and an invalid service account auto-pages the operator instead of confusing the publisher. The PSA connection’s lastErrorCode carries the new typed values (ADAPTER_NETWORK_NOT_FOUND, ADAPTER_PERMISSION_DENIED, ADAPTER_INVALID_CREDENTIALS, ADAPTER_INVALID_CONFIG, ADAPTER_CONNECTION_FAILED) so external API consumers can branch on the failure class instead of parsing the message.

​

2.107.0 — May 17, 2026 at 9:26 PM UTC

• POST /api/v2/storefront/psa is now atomic: it provisions the managed sales agent tenant upstream and writes the local connection row in a single transaction. The connection is either fully active on response or no row is persisted, eliminating the in-between pending / failed states that previously required client-side retry plumbing.
• Removed POST /api/v2/storefront/psa/{psaId}/provision and POST /api/v2/storefront/inventory-sources/{sourceId}/provision — they are no longer needed. Retries are clean re-POSTs of the original create request.
• Added POST /api/v2/storefront/psa/{psaId}/reactivate and POST /api/v2/storefront/inventory-sources/{sourceId}/reactivate to bring a deactivated tenant back online without re-running the create flow.
• If the salesagent rejects provision with EXTERNAL_ORG_ID_CONFLICT and returns the conflicting tenant id, the agentic-api now adopts that tenant into a fresh local row instead of erroring. Self-healing when the local DB lost a row but the upstream tenant survived (and friction-free in local dev when a dev wipes the agentic DB but not the salesagent’s).
• Fixed click and impression tracker URLs being generated against /clk and /imp paths, which return 404 on the tracking endpoint. Tracker URLs now point at /agentic/clk and /agentic/imp to match the routes the tracking service exposes. New creatives created after this change will produce working tracker URLs; existing creatives need their tracker URLs backfilled separately.

​

2.106.0 — May 15, 2026 at 10:57 PM UTC

• Storefront compliance checks are now cached for 30 minutes per agent, so the inventory sources page no longer re-runs the full AAO compliance suite on every load. Each agent tile shows a Retry button next to the health label to force an immediate re-check when you need a fresh answer. Tiles also wait for the compliance result before reporting “Healthy”, which fixes a transient mismatch where a failing agent could briefly read as healthy while the check was still in flight.
• Fixed operator-domain verification status flipping between “Verified” and “Pending verification” depending on who was viewing the storefront. Verification is now decided entirely server-side based on whether any active member of the customer has an email matching the registered domain (no longer restricted to ADMIN role), and the decision is persisted with an audit reason so the chip stays stable across viewers.
• Fixed a flickering “Approve GAM service-account access” row on the storefront inventory-sources setup checklist. The row previously reappeared on every refetch of the managed-sales-agent status feed even when the PSA was already healthy and serving — provisioning success itself proves GAM honored the service account, so the row no longer renders once the connection is active. Later revocations continue to surface via the existing sync-failure row.
• Fixed dynamic HTML5 creative previews showing broken images for Google Web Designer (GWD) banners. The asset-reference rewriter now recognizes the source= attribute used by <gwd-image> custom elements, and template auto-detection picks the HTML template whenever an HTML wrapper is uploaded alongside sibling images (previously the first image in the upload list won, leaving the creative classified as a static image).

​

2.105.0 — May 15, 2026 at 7:14 PM UTC

• Creative manifests now accept text_assets and url_assets keyed by AdCP format slot asset_id, so structured formats like native can carry headline, description, business name, disclosure, and landing page copy without uploading text files. The creative dashboard exposes a Native copy form per format spec.
• Added storefront reporting endpoint GET /api/v2/storefront/reporting/metrics. Returns delivery metrics for every media buy that the storefront’s sales agent(s) are a party to, organized as advertiser → media buy → package. Supports summary and timeseries views, date-range filters (startDate/endDate/days), optional inventorySourceId filter, download=true for CSV export, and demo=true for synthetic data.
• Storefront Communications: the per-event email/Slack toggle table is now hidden until at least one notification destination (notification email or Slack webhook) has been saved. The table’s toggles cannot fire without a saved destination, so showing it beforehand suggested controls that didn’t yet work.
• Validation errors for enum-like fields (e.g. geo_metros.system, geo_postal_areas.system, campaign status) now list the accepted values in the error message (“must be one of: nielsen_dma, uk_itl1, …”) instead of returning a generic “Invalid input”.
• Storefront Communications: when no notification channel is configured, the page now shows a quiet placeholder card (“Connect a channel above to choose which events trigger a notification.”) in place of the per-event toggle table, matching the design.
• The storefront Team page now lists pending invitations alongside accepted members, with Resend and Cancel actions so admins can manage stuck invites without leaving the workspace.

​

2.104.2 — May 15, 2026 at 2:14 PM UTC

• Company domain now shows as verified immediately when an admin on the account has an email at that domain — no extra approval step required. Previously, new sellers signing up with their own work email saw “unverified” until they created or edited a storefront, which blocked the “Connect an agent” path.
• Fixed Forbidden: identity_org_mismatch when opening a managed sales agent admin UI for storefronts with multiple sales agents. The proxy now stamps X-Identity-Org-Id with the exact value the upstream tenant was registered with, instead of the unsuffixed customer id.
• When provisioning a managed sales agent fails, the storefront UI now keeps the “Connect an ad server” dialog open and surfaces the actual error inline (previously the dialog closed silently and the publisher was bounced back to an unchanged storefront page with no signal). Provisioning failures against the upstream salesagent also fire a high-priority ops alert to Sentry + Slack so the on-call team is paged immediately instead of waiting for a customer escalation. User-fixable failures (e.g. bad GAM credentials) still surface to the publisher inline but do not page the ops channel.

​

2.104.1 — May 15, 2026 at 7:38 AM UTC

• Fixed “Connect an ad server” tile in the Add inventory source modal being incorrectly disabled when a storefront already had a managed sales agent. Multiple managed sales agents per storefront are supported, and the tile is now always enabled.

​

2.104.0 — May 15, 2026 at 2:49 AM UTC

• Campaign constraints now accept AdCP-shaped targeting fields directly: geo_countries, geo_countries_exclude, geo_regions, geo_regions_exclude, geo_metros, geo_metros_exclude, geo_postal_areas, geo_postal_areas_exclude, language, device_type, device_type_exclude, and device_platform. When set on a campaign, these flow into every media-buy package’s targeting_overlay — include lists intersect with package targeting, exclude lists union. The legacy countries field is accepted as a deprecated alias and normalized to geo_countries.
• Storefronts can now add multiple managed sales agents (e.g. one GAM network per brand) instead of being limited to one per customer. The managed-sales-agent REST surface is now id-keyed: GET /api/v2/storefront/psa returns an array, POST /api/v2/storefront/psa creates a new connection, and per-PSA actions live under /api/v2/storefront/psa/{psaId}/.... Existing managed sales agents continue to work without any data migration.
• Customer context selected via customer_switch now stays scoped across short breaks. The stored selection slides its expiry forward each time it’s applied, so an actively-used customer scope persists until the user is idle for more than 24 hours.
• The storefront card is now operator-curated. The GET /api/v2/storefront response and PUT /api/v2/storefront request body accept five new fields — membershipStatus (AAO_FOUNDING_MEMBER / AAO_MEMBER / NONE), regions (ISO 3166-1 alpha-2 country codes and group codes like GLOBAL / EMEA), description, channels (ADCP channel codes), and website — so operators can tune what buyers see on Interchange without re-publishing brand.json. brand.json still seeds identity (name, logo, colors, description, website); these overlays let publishers fill in fields brand.json doesn’t reliably carry.

​

2.103.0 — May 14, 2026 at 11:20 PM UTC

• Added DELETE /api/v2/accounts/{customerId} to hard-delete a child customer account. The caller must be an admin on the parent (or a Scope3 SuperAdmin) and cannot delete the customer they are currently scoped into. The endpoint refuses with 409 Conflict if the child still has linked resources, so existing accounts with data continue to require a deactivation flow.
• Discovered products are now grouped by storefront instead of by sales agent. Each product carries storefrontId and storefrontName reflecting the storefront it was discovered through. A single sales agent that backs inventory across multiple storefronts now appears under each storefront’s group with its own slice of inventory, so buyers see inventory the way they configure it — one group per storefront they’ve connected to.
• Documented the POST /advertisers/{advertiserId}/log-event endpoint in the v2 OpenAPI spec for logging conversion and marketing events (ADCP log_event spec).
• Fixed a 404 on the embedded storefront’s “Create product” flow caused by app-level salesagent JSON APIs (e.g. /api/formats/list?tenant_id=…) not being routed by the storefront proxy. The proxy now also forwards /storefront/psa/api/* to upstream /api/*, resolving the tenant from the tenant_id query parameter for session validation. This unblocks the format/targeting widget and the downstream 500 on products/add that resulted from posting with empty targeting data.
• Fixed an issue where users signing in through enterprise SSO could be silently rejected when the WorkOS access token didn’t carry an exact-match email claim. User lookup by email now falls back to a case-insensitive match so a casing skew between the identity provider and the user record no longer blocks first-time login; subsequent API calls additionally fall back to the WorkOS user id, and the auth middleware logs a warning that names exactly which claims the token did carry, so the failure mode is no longer invisible.
• Fixed an SSO sign-in failure where users with accumulated duplicate auth cookies (for example, a host-only staging.interchange.io cookie alongside the parent-domain .staging.interchange.io cookie) were silently bounced back to the login page. The browser was sending both cookies on the same request and the server was reading the stale one, so the freshly minted session was unusable. Auth cookie writes now emit clear directives for every historical (domain, path=/) variant before setting the fresh value, so affected users self-heal on their next successful sign-in.

​

2.102.0 — May 14, 2026 at 2:20 AM UTC

• Reworked the campaign creative assets page: replaced the creative dropdown with a server-paginated list view of all creatives for the campaign (search, multi-select with bulk delete, per-row quick edit and delete) and added a back link from the creative detail view. The list also auto-picks the first advertiser and campaign on landing so you see content immediately instead of empty filters.
• Bulk re-uploading creatives no longer creates duplicates. When a creative manifest with the same name already exists in a campaign, the create endpoint returns the existing manifest with already_exists: true instead of inserting a duplicate. If the request carried files, the response also includes ignored_files with the count that was dropped (use the update endpoint to add or replace assets on the existing manifest). The bulk upload UI surfaces this as a distinct “Already uploaded” row state with an “N files ignored” hint when applicable, so users can safely re-run a partial upload to finish what was missed. The pre-batch row label changed from “Queued” to “Waiting” to avoid implying a server-side queue.
• Fixed a bug where a user invited as admin to a customer they already had a default permission for was silently kept at their lower role. Accepting an invitation now upgrades the existing permission to the invited role (never downgrades).
• Fixed an MCP session bug where switching into another customer would silently revert to the user’s home customer whenever the session was recreated on a different pod. Subsequent writes (e.g. campaign creation) now consistently land in the customer the caller switched into.
• Added a way for admins to invite specific people (vendors, contractors, new teammates) to their customer’s existing Slack or Teams support channel without changing seat membership. Available via the new POST /api/v2/customer/communication-channel/invite-users endpoint and the “Invite people to the channel” form in both the admin support-channels section and the storefront Communications settings. Newly invited seat members are now also automatically added to the communication channel when one is provisioned. The communication-channel POST endpoints (set provider, resend invite, invite users) now require an ADMIN or SUPER_ADMIN customer role.
• MCP clients (Claude Code, Claude Desktop, mcp-remote) can now auto-discover OAuth on the /mcp/* endpoints. Previously, 401 responses from these endpoints did not advertise the OAuth Protected Resource metadata, so clients without a pre-configured API key had no way to initiate the OAuth flow. They now include a standards-compliant WWW-Authenticate: Bearer challenge pointing at /.well-known/oauth-protected-resource.
• POST /api/v2/buyer/campaigns now rejects with ACCESS_DENIED when the request’s customer context does not match the advertiser’s owning customer. Previously, unscoped SuperAdmin sessions could create a campaign tagged to their home customer while pointing at another customer’s advertiser, producing cross-customer data that was invisible to the advertiser’s actual customer.

​

2.101.0 — May 14, 2026 at 12:20 AM UTC

• Disconnecting an external ADCP agent now keeps the source visible in the inventory list as “Deactivated” (mirroring the managed-sales-agent lifecycle) instead of archiving it. The source detail dialog shows a single “Reconnect” action for a deactivated agent. Reconnecting a NO_AUTH agent no longer fails with a spurious “Cannot activate agent without authentication configured” validation error.
• Extend org-admin-on-parent access to a few remaining surfaces that still required a direct user_permission row on the target customer. The MCP customer_switch tool, the stateless MCP current-customer overlay, and the accept-tos endpoint now all honor admin permission on a parent customer, matching the behavior introduced for service-token creation.
• Fix unsupported MIME types on creative uploads being rejected as ECONNRESET (connection reset) instead of a clean 400 Validation Error.
• Fixed creative file uploads failing with “Unsupported file type: application/octet-stream” when clients (such as Safari or generic HTTP tools) do not set an explicit MIME type. The server now resolves the actual content type from the file extension and returns a proper 400 validation error instead of a 500 when the MIME type cannot be determined.
• PSA provision now returns 503 (instead of 500) when the per-customer service account exists but its Secret Manager key is not yet retrievable. This matches the existing 503 surface for the “SA missing” case and tells the storefront UI to retry rather than showing a generic server error.
• Map upstream salesagent Tenant Management API failures (network errors, 5xx responses, wire-shape drift) to 503 Service Unavailable instead of 500. The storefront UI can now show a “retry” state when the PSA backend is briefly unhealthy instead of a generic server error.
• Added a multipart upload endpoint for property lists (POST /advertisers/:advertiserId/property-lists/upload) that accepts xlsx or csv files up to 100,000 identifiers per request. Removes the need to batch large exclusion or inclusion lists through repeated JSON calls.
• Added a campaign-scoped visibility endpoint (GET /campaigns/:campaignId/property-lists) and an includePropertyLists=true query flag on GET /campaigns/:campaignId. Both return the property lists actually applied to a campaign via its media-buy packages, so callers can verify exclusion / inclusion state at a glance without traversing media buys manually.
• Tightened agent guidance on create_property_list and update_property_list: directs the agent to the upload endpoint for large lists, and requires a server-confirmed verification step (list_property_lists after create, get_property_list after update) so a write is never reported successful without ground-truth confirmation.
• Removed the one-agent-per-storefront limit. Storefronts can now connect as many AGENT inventory sources as they need; MANAGED_SALES_AGENT rows remain slot-exempt as before.
• Storefront homepage now renders real data instead of stubs:
• Inventory source responses include two new optional fields, reportingType and reportingPollingCadence, projected from the underlying agent registration. Use them to show how each agent reports delivery (polling / webhook) and its cadence (hourly, daily, etc.) without a follow-up query.
• Storefront setup checklist in the UI now covers operator-domain verification, brand-profile completeness, billing connection, per-source OAuth handshakes, and the GAM service-account grant — each with a deep-linked CTA.
• Source tiles populate the Open work column from PsaTenantStatus for managed sales agents, Reporting from the new agent fields, and append the endpoint host and GAM network code as identity chips.

​

2.100.0 — May 13, 2026 at 6:17 PM UTC

• Adds the Data Delivery Credential entity and the data plane that delivers configured Data Delivery Outputs.
• Credentials: Buyers can now register reusable destination credentials per advertiser via dataDelivery.credentials[] on POST/PUT /api/v2/buyer/advertisers. Each credential carries the auth target (e.g., the GCS bucket) and is validated asynchronously by a destination-specific Probe. New and updated credentials are returned with status: "PENDING" while the Probe runs; clients should poll GET /api/v2/buyer/advertisers/:id (or call the dedicated revalidate endpoint) to observe terminal VALIDATED or FAILED status. Use POST /api/v2/buyer/advertisers/:id/data-delivery-credentials/:name/validate to re-run the Probe after fixing destination-side permissions.
• Outputs now reference credentials by name: dataDelivery.outputs[].deliveryConfig no longer carries the bucket field. Each Output instead specifies credentialName (referencing a credential within the same advertiser) and only the per-subscription address (e.g., pathPrefix for object stores). The credential’s destinationType must match deliveryConfig.type.
• Delivery: Configured Outputs now actually ship. A reconciliation workflow materializes Output rows into Temporal schedules, which fire a delivery workflow that exports the data to a staged GCS location and transfers it to the buyer’s destination. Each delivery is recorded in data_delivery_log. v1 supports GCS only; S3, Azure Blob, Snowflake, and Databricks land additively.
• Fix API key creation failing for org admins on child customers. When an admin accessed a child customer via parent-child hierarchy, creating a customer-scoped service token returned “User does not have access to this customer” because the user has no direct UserPermission row on the child. The token is now created as an org-level token in this case, mirroring how SuperAdmin acting on another customer is handled.
• Fixed the Personal API keys page so SuperAdmins impersonating a specific user see only that user’s keys, instead of every personal key at the customer. SuperAdmins scoped to a customer (without user impersonation) keep the admin view that lists all users’ personal keys with the User column.
• PSA provision now returns 503 SERVICE_UNAVAILABLE (instead of 400 VALIDATION_ERROR) when the per-customer service account is still being provisioned. The condition is transient — clients should retry — and the new status code reflects that.
• Sign-in with Google and SSO now respect the email you type. The login form forwards the typed email as a login hint and asks Google to show its account chooser, so you sign in as the account you typed instead of silently being signed in as whichever Google account your browser already has cached.
• The discovery card modal on /storefront has been polished: title is now “Your storefront card” with subtitle “This is how you appear to buyers on Interchange.”, the primary action reads “Edit card” in the brand-primary color, and the floating “Verified” chip has been removed. Card-body typography has been tightened to match the directory rendering.
• Fixed update_media_buy and campaign-update flows incorrectly rejecting updates on media buys with multiple version history rows with “Media buy has no products. Cannot validate creative formats.” Creative format validation now resolves against the live version of the media buy.
• Storefronts now get a dedicated GCP service account per customer instead of sharing a single global account. Service accounts are automatically created when a new seller customer is provisioned, with keys stored securely in Google Secret Manager. A SuperAdmin backfill endpoint is available to provision service accounts for existing sellers.
• update_campaign accepts pacingPeriods on each mediaBuys[] entry. Use this to shape spend on one specific media buy (e.g. a heavy-up on a publisher with seasonal or event-driven inventory) without affecting the other media buys under the campaign. The per-buy schedule replaces the campaign-level pacingPeriods shape for that buy and uses the same mode + periods[] shape. On DRAFT / PENDING_APPROVAL buys, the schedule is persisted and used at execute time. On ACTIVE / PAUSED paced buys, strict appends are sent to the seller via update_media_buy.new_packages (requires the seller to advertise add_packages in valid_actions). Bootstrapping pacing onto an unpaced live media buy is rejected, create a new media buy instead. Campaign GET responses surface pacingPeriods on each media buy with resolved budgets.
• Fixed campaign-level pacingPeriods cascades in budget mode: when appending a new period to a campaign with multiple paced media buys, each period’s budget is now split across the buys proportionally to each buy’s share of total budget. Previously each buy treated the period budget as its own, multiplying total spend by the number of paced buys.
• Managed sales agent actions (provision, launch, test connection, refresh, deactivate, status, ad-server config) are now exposed under the unified /api/v2/storefront/inventory-sources/:sourceId/... surface in addition to the legacy /api/v2/storefront/psa/... routes. New clients should target the inventory-sources path; the legacy /psa/... surface stays for one release while existing UIs migrate.
• The managed sales agent now surfaces through /api/v2/storefront/inventory-sources alongside external agents, and executionType values move to UPPER_CASE: existing 'agent' becomes 'AGENT' and the new managed-sales-agent value is 'MANAGED_SALES_AGENT'. Inventory-source responses include an embedded managedSa block (provisioning status, tenant id, ad-server config) when the source is managed.
• Breaking change: clients reading or writing executionType must use the new UPPER_CASE values. Existing rows are migrated in place (no action required for stored data). The change aligns executionType with the other UPPER_CASE wire enums on the storefront surface (API_KEY, MCP, SALES, etc.).
• Existing /api/v2/storefront/psa/... endpoints continue to work unchanged; subsequent releases will move actions under the inventory-sources surface.
• Disconnecting an inventory source from a storefront now archives the row instead of hard-deleting it, preserving the prior agent binding, original creation time, and audit-trail context. Archived rows are filtered from all list/lookup endpoints, and the same source_id can now be reconnected after disconnection.
• Breaking: the status field on inventory source responses now returns UPPERCASE values (PENDING, ACTIVE, DISABLED) instead of lowercase. This aligns with every other status field on the API (storefront, agent, media buy). Update any client code that compared source.status against lowercase strings. The DB column is also a real Postgres ENUM so dirty values can’t be written through raw SQL.
• Storefronts can now federate with each other through “Link a storefront” — a buyer storefront asks a seller storefront to authorize surfacing the seller’s inventory. Once the seller approves, buyer traffic can fan out through the seller’s underlying agents and ad servers. New REST endpoints under /api/v2/storefront/links (buyer: create / cancel; seller: approve / reject / cancel), plus /api/v2/storefront/storefronts/search backing the “Link a storefront” picker. The link state lives inline on the buyer’s inventory_source row — no separate sidecar — and the seller has permission to update the link_* fields when responding. The link is an authorization handshake only; economic terms (revenue share, scope, exclusivity) are negotiated per-transaction in get_products / create_media_buy, never at link time.
• The /storefront page now lives inside a two-tab shell: Inventory sources (the existing unified registry from Path B PR4) and Settings. A page-level header above the tabs surfaces the storefront identity (brand name + handle + “View storefront card” button), and a setup banner tracks the three preconditions to go live — Discovery card (resolved from brand.json), Inventory source (≥1 connected), and Billing (Stripe Connect). Each banner chip deep-links to the right surface.
• The Settings tab covers State (pause/resume), Identity (operator domain + brand.json status), API access (published MCP endpoint), and Billing (deep-linked to the existing /storefront-billing flow). Visibility, People, Channels, Locale, and Danger sections render as labelled placeholders until their backend wiring lands.
• The discovery card modal reads exclusively from the publisher’s brand.json — if it doesn’t resolve, the modal prompts the publisher to register at agenticadvertising.org (free) rather than offering a manual edit fallback. brand.json is the single source of truth for the discovery card.
• The Pause / Resume button in storefront settings is now wired to the API. Pause shows a confirmation dialog since it stops buyer agents from receiving responses to new briefs; resume goes through readiness checks so the same gates that block first-time go-live also block re-activation.

​

2.99.0 — May 11, 2026 at 8:54 PM UTC

• Add bulk creative upload to the campaign creative assets page. Drop a folder, multi-select files, or a zip and the UI groups them into proposed creatives (one per subfolder, one per loose file, with zips auto-extracted), lets you edit names and remove rows, then uploads them in parallel with per-row progress and retry-failed support.
• Fixed media_product_list returning INTERNAL_ERROR when an unknown agent_id is passed. The tool now returns a proper NOT_FOUND error instead.
• Password reset now forwards the Firebase tenantId from the reset-email URL to the backend, fixing INVALID_CODE errors for multi-tenant users.
• get_campaign now returns a performance snapshot for each media buy with impressions, spend, clicks, views, completedViews, conversions, leads, and lastUpdated. The snapshot is refreshed synchronously when sellers push webhook deliveries or when on-demand seller calls fetch fresh data — it represents the latest cumulative totals, not a billing-stable timeseries. For billing-stable daily metrics, continue to use the reporting endpoint.

​

2.98.0 — May 10, 2026 at 3:18 PM UTC

• Removed the unused executionConfig field from POST/PUT /api/v2/storefront/inventory-sources. The field was an opaque JSONB pass-through with no consumers; per-execution-type configuration will land as typed fields per integration type when needed. Requests that include executionConfig continue to succeed — the field is silently ignored at the schema boundary, matching today’s behavior where it was nulled at the service layer.

​

2.97.1 — May 9, 2026 at 12:05 AM UTC

• Storefront Go Live checklist now shows agent connectivity/compliance status and hides the Prebid Sales Agent check when irrelevant.

​

2.96.0 — May 8, 2026 at 6:34 PM UTC

• Fixed a 500 error on GET /api/v2/buyer/campaigns/:id/products for campaigns that have an associated discovery session.
• Password reset links no longer auto-verify on page load. Users now click a “Continue to reset password” button before the reset code is checked against the backend. This prevents email security scanners (Microsoft Defender Safe Links, Mimecast, Proofpoint, etc.) from pre-fetching the link and causing the user to see an “expired link” error when they click through. Mirrors the existing signup email verification flow.

​

2.95.1 — May 8, 2026 at 3:46 AM UTC

• Clarified the Stripe billing copy on the storefront onboarding flow and “Go live” panel to better describe Scope3’s role in consolidated payment processing when sellers opt in or out of Stripe Connect.

​

2.95.0 — May 8, 2026 at 2:13 AM UTC

• Made storefront billing setup always optional and aligned the buy-side sync_accounts payload with campaign type and seller billing state.
• Seller (storefront):
• billing_setup readiness check now starts as optional for new storefronts. It flips to required (blocker) automatically once a connected agent’s capabilities advertise agent in accounts.supported_billing — that’s the buyer-side toggle that asks Scope3 to clear payments, so Stripe Connect becomes mandatory before go-live.
• When billing is optional and Stripe is unconfigured the readiness check returns status: optional with description copy warning the seller their sales agent is limited to external agreements with buyers (Scope3 will not clear payments; seller must bill the buyer directly).
• When billing is required (some agent supports agent billing) the readiness check returns status: missing/partial with isBlocker: true and explains why.
• The storefront onboarding UI consumes the readiness check directly — the “Set up billing” step’s required/optional label and copy track the server.
• Buyer (media buy execution):
• On every media buy execution, the billing field sent to sync_accounts is now resolved per buy:
• • ROUTED campaigns always send billing: operator.
• • DECISIONED campaigns against a Scope3-hosted seller without Stripe Connect are forced to billing: operator and an internal no_seller_billing flag is logged for ops; the seller’s billing status is never echoed back to the buyer.
• • DECISIONED campaigns against a seller with billing honor the buyer’s choice (agent or operator) when supplied via executeMediaBuy options. When the buyer doesn’t specify, the default is agent (Scope3 clears) — the happy path on DECISIONED campaigns.

​

2.94.0 — May 7, 2026 at 7:01 PM UTC

• Storefront agent picker (GET /storefront/discover-agents) now only surfaces agents that are actually present in the canonical AAO agent registry. Agents that an operator self-claimed in their AAO operator profile but never registered are filtered out, so the modal can no longer offer agents that the connect call would reject.
• The connect-time AAO registry gate on POST /storefront/inventory-sources now applies uniformly to every caller — the SuperAdmin bypass and the complianceBypassed response field have been removed. Failing or pending AAO compliance still does not block connecting an agent (going-live continues to be gated by storefront readiness).
• Buyer storefronts and product discovery now line up around storefront-level visibility:
• GET /api/v2/buyer/storefronts accepts a visibility query parameter. The default visibility=public continues to return ACTIVE storefronts available to any buyer; visibility=private returns ALL storefronts (ACTIVE, PENDING, DISABLED) owned by customers in the caller’s parent org. Buyers can set up credentials, link advertiser accounts, and discover products against any of their parent org’s storefronts regardless of lifecycle state. List and detail responses now include a status field on each storefront.
• GET /api/v2/buyer/storefronts/{storefrontId} no longer 404s when an ACTIVE storefront has no active inventory source — it returns the storefront record with an empty sources[] array. Previously the detail endpoint required at least one wired-up source; that requirement only made sense when the list endpoint hid those rows, which is no longer the case.
• POST /api/v2/buyer/discovery/discover-products and GET /api/v2/buyer/discovery/{discoveryId}/discover-products now expose a storefront-level filter and no longer accept salesAgentIds / salesAgentNames. Use storefrontIds (integer array, IDs from list_storefronts) and storefrontNames (string array, case-insensitive substring) instead. An empty array on the request is treated the same as omitting the field — both mean “no request-level filter,” and the campaign-level pin is used as the fallback when a campaignId is also provided.
• Campaigns can be pinned to a set of storefronts. create_campaign and update_campaign accept a new storefrontIds field. When set, every discover_products run for that campaign auto-applies the pinned filter — buyers don’t need to resend it on each call. Pass an empty array on update_campaign to clear the pin. On the campaign response (get_campaign, list_campaigns, create_campaign, update_campaign) the pin is surfaced as a hydrated storefronts array — each entry has the storefront id, platformId, and name so the response is renderable without a follow-up lookup.
• The CUSTOMER_SCOPE_REQUIRED error from api_call now includes the user’s available customers (id + company) and a directive suggestion in its structured payload, so agents can call customer_switch directly without first calling customer_list.
• Reporting endpoint cleanup:
• “All time” reporting (days=0) now returns the actual range of available data (first impression to today) instead of a hardcoded 2020-01-01 placeholder. The MCP reporting widget initializes from the requested range instead of always defaulting to the last 7 days.
• Removed the breakdown query parameter from GET /api/v2/buyer/reporting/metrics. It was a UI-only hint with no effect on the returned data; agents no longer have to ask the user a redundant “how do you want it broken down?” question. The MCP reporting widget’s chart group-by dropdown still works interactively.
• CSV exports now round derived metrics (Spend, eCPM, CPC, CTR, Completion Rate) to at most 4 decimal places, eliminating JS floating-point artifacts like 50.00000000000001.
• Fixed /auth/sign-up returning a misleading “Password is too weak” message when the failure was actually a backend validation error or other unrelated issue. The catch block now matches the structured WorkOS password_strength_error code instead of the substring “password” appearing anywhere in the error body.

​

2.93.1 — May 7, 2026 at 12:58 PM UTC

• Fixed ADCP webhook endpoint returning HTTP 500 when a sender’s HMAC signature was invalid. Signature verification failures from the SDK now return HTTP 401 with UNAUTHORIZED instead of INTERNAL_ERROR. Added a fallback verification path that accepts the legacy raw ADCP_WEBHOOK_SECRET so sellers provisioned before the per-agent key derivation rolled out can keep delivering webhooks while their stored credentials are rotated.

​

2.93.0 — May 7, 2026 at 12:07 AM UTC

• Added managed Prebid Sales Agent (PSA) provisioning for storefronts. New endpoints under /api/v2/storefront/psa accept a GAM network code, expose the shared service-account email a publisher must grant access to, and provision a per-storefront PSA tenant against the upstream salesagent Tenant Management API. A new psa_connection readiness check appears in /api/v2/storefront/readiness. Provisioning, test-connection, and deactivation flows are end-to-end when SALESAGENT_TENANT_API_URL and SALESAGENT_TENANT_API_KEY are configured; without them the endpoints return 503 with a clear “not configured” message.
• Add buyer-advertiser routing rules to managed sales agent storefronts. Publishers can now map specific (operator, brand_house, brand_id) triples to dedicated GAM advertisers and see which buyers in recent traffic are still falling back to the tenant default. New REST endpoints under /api/v2/storefront/psa:
• GET /mappings — list routing rules
• POST /mappings — create a rule
• PATCH /mappings/{id} — update a rule
• DELETE /mappings/{id} — delete a rule
• GET /recent-buyers — distinct buyer triples seen in recent traffic, with the precedence step that won the resolution chain
• The storefront homepage gains a “Buyer routing” panel that surfaces both lists side-by-side, with a “Pin to rule” CTA on recent buyers that pre-fills the create dialog.
• Two storefront onboarding cleanups:
• Sync state moves out of the agent card into the dedicated Importing your inventory panel below. The card row now shows just operational metrics (workflows, products, packages, creatives) without sync controls squeezed in. The sync panel always renders when the tenant is active and adapts its title to state: Inventory (synced + non-empty), Inventory sync needs attention (synced + empty), or Importing your inventory (running). Refresh button + view-sync-details deep-link live in the panel header.
• Setup tasks panel now filters out platform-managed publisher items the upstream emits but the publisher can’t act on in embedded mode (ad_server_connected, tenant_name, tenant_cname, sso_configuration, multiple_currencies, currency_limits, gemini_api_key, slack_integration, signals_agent). Stopgap until the sales agent suppresses these in setup_tasks for is_embedded=true tenants. Visible items now match what the publisher can actually do — products, principals, creative guidelines, naming conventions, etc.
• Hand buyer-advertiser routing back to the sales agent. The Storefront-side Buyer routing panel + create/edit dialog and their REST endpoints (GET/POST/PATCH/DELETE /api/v2/storefront/psa/mappings, GET /api/v2/storefront/psa/recent-buyers) are removed. The data lives in the sales agent and so does the management UI — publishers manage routing rules from inside the iframe’s settings/advertisers surface. Storefront keeps the default-advertiser fallback (the one piece publishers commit to early during onboarding); per-buyer mapping work moves entirely upstream.
• Inventory sync visibility on the storefront homepage is now honest about empty syncs:
• Item count totaled on the agent card. “Last synced: just now · 0 items” tells the publisher at a glance when something went wrong, instead of “synced just now” implying success.
• Sync progress panel keeps rendering when sync completed but a stream imported 0 items (the “synced but empty” state). Title flips to “Inventory sync needs attention” with a warning explaining common causes and a View sync details → button that deep-links into the sales agent’s inventory page for per-stream run history and re-trigger.
• Per-stream errors surface inline with a red message under the stream name when the upstream reports an error string.
• Storefront onboarding polish from the ad-ops audit:
• Properties panel: redesigned around two big counters (registered + authorized for the chosen agent) with a single gap-aware CTA whose copy adapts to the actual gap (“Authorize Interchange on N more properties”, “Register your properties at AAO”, or “Manage on AAO”). The AAO link now carries ?authorize={agentUrl}&return={currentUrl} so the publisher’s pre-fill and round-trip flow is preserved (assuming AAO honors those query params).
• Connect Ad Server dialog: spelled out the GAM service-account onboarding path (Admin → Access & authorization → Users → New user), the recommended role (Administrator, with Order Manager + Trafficker as a fallback), and the “don’t add it under your personal user settings” gotcha that’s the most common stumble.
• House domain + public agent URL are now stamped automatically on the upstream tenant on first provision (operator domain + canonical agent URL), so embedded tenants don’t sit with null platform-managed config.
• Sales agent iframe drops the “Back to storefront” wrapper. The salesagent’s embed-aware breadcrumbs (driven by an X-Embed-Breadcrumb-Root header pointing at the customer’s storefront URL) provide a continuous nav lineage from our app into theirs.
• Properties panel on the storefront homepage now always deep-links to AAO’s /publisher/{domain} page as the canonical “manage my inventory” CTA, regardless of whether the publisher self-hosts adagents.json or has AAO host it. AAO’s publisher page handles the three-way fork (self-host instructions, AAO-hosted CNAME, not-configured) and surfaces the per-agent authorization rollup directly. The self-hosted manifest URL stays visible as informational text so publishers can see where their authoritative file lives.
• Storefront homepage now defers publisher and advertiser management to the salesagent’s own screens. A single salesagent tenant can rep multiple publishers (Publisher Partners), and advertiser/principal mapping has its own UI on the salesagent (Principals); duplicating those surfaces on the storefront didn’t fit the multi-publisher model. Removed: the AAO-derived “Properties” panel, the GET /api/v2/storefront/properties-status endpoint, the “Pick a default GAM advertiser” dialog, the gamDefaultAdvertiserId field on PsaConnection, and the corresponding REST endpoint and DB column. Per-publisher AAO state (property registration, adagents.json verification, agent authorization) and per-buyer advertiser mapping both happen in the salesagent now and surface via its setup_tasks block, which the storefront’s Sales agent setup panel renders directly. Each setup-task CTA now correctly deep-links into the iframe at the path the salesagent provided.
• Polished the Products stat in the storefront homepage’s agent card. The “Manage” CTA was rendering as a heavy filled button that overpowered the surrounding read-only stats (Workflows, Packages, Creatives). Replaced with a subtle underlined text-link beneath the count so the row stays visually consistent.
• Fixed product discovery returning zero products when sales agents emit responses that fail AdCP 3.0 schema validation. The ADCP SDK no longer silently filters partial-shape products out of get_products responses, and any schema violations on a sales agent response are surfaced as a structured warning log with agent name, product count, and the failing fields. Buyers see the actual products that came back even when an upstream agent omits newly required fields like reporting_capabilities.
• Two fixes for the inventory sync surface:
• The View sync details → button now deep-links to /inventory/browse instead of /inventory. The /inventory route is locked for embedded-mode tenants (Sprint 4 platform-managed-page rework); the actionable diagnostic + manual-sync surface lives at /inventory/browse.
• Dropped the Refresh button from the inventory panel header. The Tenant Management API’s /refresh endpoint queues SyncJob rows but doesn’t actually kick off the sync threads (salesagent bug). Pressing it produced a misleading “Refreshing… / last run just now / still pending” state. Until that’s fixed upstream, the panel surfaces a single primary CTA (Open sync page → / Manage sync →) that takes the publisher to the salesagent’s working “Sync All” button.
• Storefront onboarding now closes the post-provision dead zone:
• New Importing your inventory panel surfaces the three sync streams (inventory, custom targeting, advertisers) with per-stream status while sync is running. Self-hides once everything’s caught up.
• Default GAM advertiser setup task no longer fires before the advertisers sync completes — picking from an empty cache was a dead-end. The task now waits for syncs.advertisers.status === 'success'.
• Buyer routing panel disables its “Add rule” button and shows a “we’re still importing your advertisers” alert until the same sync finishes, so publishers don’t tap into a form whose advertiser list is empty.
• Storefront customers using the managed Prebid Sales Agent now provision real tenants in the embedded sales agent backend. Previously the request lifecycle fell back to a stub client that returned service unavailable. Five new env vars (SALESAGENT_TENANT_API_URL, SALESAGENT_TENANT_API_KEY, GAM_SHARED_SERVICE_ACCOUNT_EMAIL, GAM_SHARED_SERVICE_ACCOUNT_KEY_JSON, INTERCHANGE_CANONICAL_AGENT_URL) wire the API to the salesagent service deployed in the same cluster.
• Surface managed sales agent product counts on the storefront homepage. The new products block on /api/v2/storefront/psa/status (active / draft / archived counts) flows into a clickable Products stat that deep-links the iframe directly to the sales agent’s /products page. The launch endpoint now accepts an optional path for path-only deep links (sanitized server-side to prevent escaping the tenant prefix).
• Adopt the upstream sales agent’s Sprint 1.8 wire-shape additions:
• GET /api/v2/storefront/psa/status now returns a setupTasks block whose publisher-scope items merge into the storefront homepage’s setup task list. Items the upstream marks platform-scope are dropped — those represent provisioning gaps Scope3 owns.
• PUT /api/v2/storefront/psa/default-advertiser now round-trips the value to the sales agent before persisting locally. Upstream errors fail the request instead of being silently swallowed, so the publisher’s chosen advertiser can’t drift between surfaces.
• POST /api/v2/storefront/psa/refresh proxies straight through to the sales agent’s now-live /refresh endpoint.
• TENANT_NOT_ACTIVATED ADCP errors raised by the sales agent’s natural-key resolution are surfaced as “Publisher hasn’t finished setup yet.” instead of the raw upstream message.

​

2.92.0 — May 6, 2026 at 6:44 PM UTC

• Buyers can now configure standing log-level data subscriptions per advertiser and per campaign on the v2 advertiser/campaign endpoints. Use the new dataDelivery.outputs[] array on POST/PUT /api/v2/buyer/advertisers and POST/PUT /api/v2/buyer/campaigns to declare what log-level data to ship (MB_DELIVERY, IMPRESSIONS, CLICKS, VAST_EVENTS, CAPI_ATTRIBUTION, MMP_POSTBACKS, MEASUREMENT), the firing cadence (HOURLY, DAILY, WEEKLY), and the destination. v1 supports GCS only — additional destinations land in a follow-up release. Campaign-scoped outputs override advertiser-scoped outputs by dataDeliveryType. Pass an empty dataDelivery.outputs array to clear; omit dataDelivery entirely to leave existing outputs untouched.
• customer_switch called without a customerId (reset to home) now clears the user’s persisted MCP customer selection instead of overwriting it with the home customer ID. Stateless clients fall back to the JWT-default customer when no overlay is present, so the persisted row was redundant on reset, and leaving the home id written there bypassed the multi-customer mutation guard for users who were exiting a switched context rather than committing to home.
• Fixed an issue where users who only had read access on their current customer could not accept an invitation to join another customer. Accepting and declining invitations now both require read-level access, matching the fact that invitation acceptance is a personal action authorized by the recipient’s email.
• Fixed the org switcher hiding organizations the user belongs to as a child customer. When you only had a membership on a child organization (and not its parent), that organization was missing from the “Switch org” list, leaving you stranded after switching to a different org. The dropdown now surfaces those memberships directly so you can always navigate back.
• Fixed customer_switch MCP tool returning INTERNAL_ERROR when switching to a non-existent or inactive customer. The tool now returns a NOT_FOUND error for missing or inactive customers, and ACCESS_DENIED when the user lacks permission for the target customer.
• media_buy_execute now returns NOT_FOUND instead of INTERNAL_ERROR when the requested media buy ID does not exist.
• Fixed an org-settings navigation bug where users with hierarchical or SuperAdmin access to a parent organization could be redirected back to their child customer instead of landing on the org-settings page.
• Fixed SSO sign-in failures showing a misleading “isAuthError is not defined” message instead of the real authentication error. Failed SSO callbacks now display the actual cause returned by the server.
• Fixed an authentication issue where logging in on staging.interchange.io would log the user out on interchange.io (and vice versa). Auth cookies are now scoped per environment so sessions in one environment can no longer overwrite or invalidate sessions in the other.
• Existing buyer customers can no longer log into Interchange unless their customer is in the alpha-opt-in cohort. Buyers who are blocked at login are routed to an inline waitlist on the sign-in page; sellers and SuperAdmins are unaffected. New buyer accounts created via “Add account” by an already-enrolled parent are auto-added to the cohort, so child teammates inherit access without manual onboarding.
• ADCP delivery webhook (POST /adcp/webhook/...) now responds with 400 VALIDATION_ERROR and a details.validationErrors array ({ field, code, message } per issue) when the payload fails schema validation, instead of the previous generic 500 INTERNAL_ERROR. This lets sales agents self-diagnose payload mistakes (e.g. uppercase pricing_model: "CPM" when the spec requires lowercase cpm) without needing to contact support.
• Hid underlying-agent identifiers from the buyer-facing storefront and account-linking endpoints. Buyers now drive the full register-credentials → discover-accounts → link-account flow in (storefrontId, sourceId) terms — agent identifiers are never exposed.
• BuyerStorefrontSource no longer includes protocol (MCP/A2A). Use requiresCredentials to drive registration instead.
• GET /api/v2/buyer/storefronts/credentials — credentials no longer include agentId/agentName. Each credential exposes a sources[] array of { storefrontId, storefrontName, sourceId, sourceName } listing the storefront sources it gives access to. accountType and updatedAt are now part of the documented response. registeredBy may be null for legacy credentials that predate registration tracking.
• POST /api/v2/buyer/storefronts/:storefrontId/sources/:sourceId/credentials — when the source uses OAuth, the response’s oauth object contains { authorizationUrl, storefrontId, sourceId, sourceName } instead of { authorizationUrl, agentId, agentName }.
• GET /api/v2/buyer/advertisers/:advertiserId/accounts, GET /api/v2/buyer/advertisers/:advertiserId/accounts/available, and POST /api/v2/buyer/advertisers/:advertiserId/accounts accept storefrontId + sourceId to identify the source. partnerId is no longer accepted.
• POST /api/v2/buyer/advertisers and PUT /api/v2/buyer/advertisers/:advertiserId — each linkedAccounts[] entry takes { storefrontId, sourceId, accountId, billingType? }. partnerId is no longer accepted.
• Account responses (AccountOutput, AccountSummary, AvailableAccountOutput, and the embedded LinkedAccount on the advertiser resource) no longer include partnerId/partnerName. They expose sources[] of { storefrontId, storefrontName, sourceId, sourceName } listing the storefront sources that surface the account. The list can be empty when the underlying source has been deactivated — render those accounts as no longer reachable.
• Fixed /auth/check-email-availability so that when the backend rejects an email (for example a typo’d domain or a disposable address), the specific reason is surfaced to the caller as a 400 instead of being swallowed as a generic 500 with no detail.
• Fixed sync_accounts failing when a sales agent’s capabilities were synthesized from its MCP tool list rather than served from a get_adcp_capabilities response. The call now retries against a v2-tolerant client instead of surfacing as an error.

​

2.91.2 — May 4, 2026 at 10:40 PM UTC

• Fixed get_campaign so the mediaBuyId query param actually narrows the embedded mediaBuys[] array when called via the MCP api_call tool. Previously the filter only worked over REST; through MCP it was silently ignored and the full media-buy tree was always returned.

​

2.91.1 — May 4, 2026 at 10:03 PM UTC

• Fixed duplicate buttons on the storefront Account setup card. The billing step previously showed both “Connect Stripe” and “Setup” side-by-side; now only the primary action renders while a step is in progress.
• Account discovery for advertisers no longer fails when a sales agent advertises AdCP v3 without declaring adcp.idempotency.replay_ttl_seconds. The platform now retries sync_accounts against a v2-tolerant client instead of surfacing the underlying version error.

​

2.91.0 — May 4, 2026 at 6:27 PM UTC

• get_campaign now returns a mediaBuyRefs array ({ mediaBuyId, status } per buy) placed early in the response so LLM clients can enumerate every media buy on a campaign even when the heavier nested mediaBuys[] tail is truncated by their context window. get_campaign also accepts a mediaBuyId query param (single value or repeated) that narrows the embedded mediaBuys[] to just the requested buys without changing the campaign object itself.

​

2.90.0 — May 4, 2026 at 5:00 PM UTC

• Cleaned up the Go live checklist copy on the storefront onboarding page so each item shows a single concise description instead of a redundant action + status pair.
• Fixed Go-live readiness check showing “Billing — Stripe Connect not configured” for child customers that inherit billing from a parent. The readiness check now resolves billing the same way the storefront billing endpoint does, walking up to the parent customer’s customer_billing row when the child has none.
• Fixed storefront go-live readiness incorrectly flagging agents configured with NO_AUTH as missing authentication credentials. Only agents that actually require auth (API_KEY, OAUTH, JWT) now gate go-live.
• Fixed three creative format pipeline bugs: the Asset requirements panel now recognizes the primary slot as satisfied when a CREATIVE_SOURCE asset is uploaded (instead of always reading “Missing”); the creative preview endpoint normalizes assets before forwarding so the remote sales agent’s preview_creative validator no longer rejects them for missing asset_type; and creatives built solely from a URL or webhook now correctly tag that asset as the primary creative source instead of leaving every manifest with no renderable primary asset.

​

2.89.0 — May 4, 2026 at 4:55 AM UTC

• Storefront onboarding and account configuration improvements.
• Documentation improvements.

​

2.88.1 — May 3, 2026 at 9:18 PM UTC

• Update SSO configuration page to be under account configuration, and improve documentation.

​

2.88.0 — May 3, 2026 at 7:26 PM UTC

• OAuth discovery metadata (/.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, /.well-known/openid-configuration) and the MCP WWW-Authenticate header now reflect the hostname the client used to reach the API. Requests to api.interchange.io get interchange.io issuer/endpoints; requests to api.agentic.scope3.com continue to get the legacy domain. Fixes Claude.ai connector setup at the new domain.
• Removed the following v2 endpoints and their corresponding MCP tool operations: /hypotheses, /test-plans, /allocations, /human-feedback, /learning-cycle/run, /belief-state, /testability, and /learning-records. Measurement source, measurement record, and freshness endpoints remain available.

​

2.86.0 — May 1, 2026 at 9:03 PM UTC

• Added content moderation guardrails on LLM inputs and outputs. User-supplied campaign briefs (POST /v2/campaigns, PUT /v2/campaigns/:id) are now screened for prompt-injection, jailbreak attempts, and critical content (hate speech, illegal content, violence uplift) before any LLM call. All LLM provider outputs (Claude, Gemini, Bedrock) pass through an output filter that blocks slurs, CSAM, weapons-uplift, and PII leaks, and counts refusal/identity leaks for monitoring. Content blocked by moderation returns 422 CONTENT_MODERATION_BLOCKED with structured findings.
• The mediaBuys[] array returned on GET /campaigns/:id now includes each media buy’s startTime and endTime, so buyers and agents can see the media buy’s flight window without a separate call. The media buy createdAt is now stable across versions: editing a media buy no longer rewrites its creation date, and a backfill aligns existing rows so the live row reflects the original creation timestamp. Use updatedAt (and valid_from on historical version reads) to identify when a specific version was created. As part of this work, campaign allocatedBudget and unallocatedBudget are now correct while a media buy update is awaiting approval — previously both versions of the in-flight media buy would briefly count toward the allocated total.
• Fixed daily delivery webhooks failing with 403 “Agent does not have access to this resource” for buyers using open-auth partner sales agents (e.g. Ozone, CMI Media Group, Planet Nine VDS). The webhook agent↔customer binding check now allows a customer through when they have at least one media buy on the agent, in addition to the existing case where the customer owns the agent. Resource-level tenant scoping in the downstream handlers is unchanged.
• Versioned agreement URLs now follow a /agreements/<document>/<version> shape:
• GET /agreements/terms-of-service/{version} (e.g. /agreements/terms-of-service/v3-0)
• GET /agreements/facilitated-agreement-terms/{version} (e.g. /agreements/facilitated-agreement-terms/v1-0)
• The previous /agreements/{version}/terms-of-service and /agreements/{version}/facilitated-agreement-terms paths are kept as permanent aliases — they serve identical content (no redirect) so historical PSA links and external bookmarks stay valid. Responses on the legacy paths include a Link: <canonical>; rel="canonical" header pointing at the new shape, so log/analytics tooling can normalize on a single URL. Use the new shape for all new integrations.

​

2.85.0 — May 1, 2026 at 5:04 PM UTC

• Fixed several documentation bugs found in a follow-up audit. The buyer API reference now shows the correct request body for POST /advertisers/:advertiserId/test-cohorts (cohortType and definition instead of the non-existent type/percentage/startDate/endDate) and PUT /advertisers/:advertiserId/measurement-config (mmmEnabled, mmmConfig, incrementalityTestingEnabled, brandLiftEnabled). The reporting endpoint is correctly documented as GET /reporting/metrics (was /advertisers/:id/reporting, which doesn’t exist), with the actual hierarchical response shape. The MCP tools section now accurately lists the six registered tools — including accept_tos, which buyers must call after their first 403 TOS_ACCEPTANCE_REQUIRED. Removed the phantom help tool entry. Also fixed shared-router notification paths in both buyer and storefront skill files (/api/v2/notifications/..., not /api/v2/buyer/notifications/... or /api/v2/storefront/notifications/...). Removed phantom POST /event-sources (only /sync exists) and the accountPolicy ghost field from the storefront skill. Conversion API now correctly shows the required account: { account_id } field. Added five missing storefront routes to the OpenAPI generator (registered agents listing, agent detail, agent OAuth authorize endpoints, storefront audit logs, PUT /billing admin update, and POST /billing/account-session) and regenerated storefront-api-v2.yaml.
• Bump @adcp/sdk to 6.5.0.
• Pulls in two production-correctness fixes for buyer agents on top of the 6.1.0 pre-send AJV ordering fix:
• 6.4.1 strips top-level null envelope fields (errors, context, ext) before validating v2.5 seller responses, so Pydantic-based v2.5 sellers no longer fail discovery with must be array / must be object.
• 6.4.1 wraps SingleAgentClient.executeTask in a try/catch so pre-flight errors (feature validation, endpoint discovery, schema validation, version detection, request adaptation) return { success: false, status: 'failed', error } instead of throwing — restores the declared TaskResult contract for callers like list_authorized_properties against v2.5 MCP sellers.
• 6.2.0 also ships decideRetry retry semantics for buyer agents (additive; no callers yet).
• Storefront compliance responses (/storefronts/:id/readiness) gain a new silent value on the per-track status enum: the track was wired but observation-based assertions saw zero resources to attest. Distinct from pass (verified) and skip (didn’t run).
• Updates to v2 campaigns that target unsupported downstream sales-agent capabilities are now rejected at the API boundary with a CAPABILITY_NOT_SUPPORTED (HTTP 422) error, instead of failing mid-flight after partial state changes. The error response includes an unsupported[] array detailing each blocked media buy, the agent, and the missing capability.
• Added automatic cascade of appended pacing periods to live media buys via ADCP 3.0 update_media_buy.new_packages. The update_campaign response now includes a pacingCascadeResult block reporting per-media-buy outcomes (updated, skipped, failed, unsupported). Only strict appends to pacingPeriods are cascaded; insertions, modifications, and removals continue to require manual new media buys. Sellers that don’t advertise add_packages in their valid_actions are reported as unsupported.
• V2 list endpoints (list_*) now return a fixed summary shape, while detail endpoints (get_*) continue to return the full resource. List rows include identity, display, state, categorization, and at-a-glance scalar signals — embedded child collections, long text, and nested configuration objects are no longer returned on lists.
• Summary contracts narrowed across the board. Fields that were previously on list responses but now appear only on get_*:
• list_advertisers: description, optimizationApplyMode, campaignBudgetType, linkedAccounts, frequencyCaps, utmConfig, linkedBrand
• list_audiences: consentBasis, lastOperationStatus
• list_advertiser_accounts: advertiser, billingProxy, house, billing
• list_creatives: format_previews, auto_detected_template, message, tracking, html_processing, frequencyCaps, per-asset details
• list_campaigns: brief, mediaBuys, audiences, creativeFormats, frequencyCaps, pacingPeriods, performanceConfig, constraints, fees, mediaBudget, allocatedBudget, unallocatedBudget, products, discoveryId, catalogId
• list_buyer_storefronts: full sources[] array (replaced by counts)
• list_partner_agents: customerAccounts[] array (replaced by count)
• New derived scalars on list responses (replace previously-embedded arrays): linkedAccountCount (advertisers), sourceCount and connectedSourceCount (buyer-storefronts), customerAccountCount (partner-agents), asset_count (creatives), tagCount (allocations).
• Behavior change on list_advertisers: the includeAccounts, includeBrand, and includeFrequencyCaps query parameters are removed (they remain available on get_advertiser).
• Wire change on list_test_plans and list_hypotheses: responses are now wrapped as { testPlans, total } and { hypotheses, total } respectively, to match the rest of v2 (both were previously bare arrays).
• Wire-format updates:
• list_campaigns: budgetTotal and budgetCurrency are replaced by nested budget: { total, currency } (matches get_campaign’s nested shape).
• list_creatives: sync_synced and sync_agent_count are replaced by nested sync_status: { synced, agent_count } (matches get_creative’s nested shape).
• Campaign.campaignType is now optional. Older campaigns where the type was never recorded will return campaignType: undefined. Code that narrowed against the previously-required field needs a null-check.
• Migration: callers that relied on array.length for child collections should switch to the corresponding *Count field; callers needing the full resource should switch from list_* to get_* for the resources they care about.
• Discover Products MCP widget: surface refine errors as a dismissable banner under the controls row (no longer hidden behind the dropdown), move the selection summary below the product cards, and tighten the radius hierarchy (cards 8px, buttons and nested chips/callouts 4px).
• Discovery sessions are now reused across multiple discovery runs within the same campaign. Each run creates a new search context with its own brief, and products are tagged to the run that discovered them. Added a new GET /campaigns/:id/products endpoint (and get_campaign_products operation for api_call) to view all staged products with their discovery context and media buy status.
• Links in emails, redirects, and UI navigation now resolve to the correct domain (interchange.io or scope3.com) based on where the user is accessing the platform.
• Fixed a crash on the campaign creative assets page when the manifest or format list responses were not arrays.
• Property lists now accept the full set of AdCP property identifier types — sourced directly from @adcp/client/types so the schema stays in lockstep with the AAO property registry. Create / update / check endpoints accept a typed identifiers: [{type, value}] array; the existing domains: string[] field remains supported as shorthand for domain-typed identifiers. Property list responses now include typed identifiers, unresolvedIdentifiers, and registeredIdentifiers arrays alongside the derived domains, unresolvedDomains, and registeredDomains views. The ADCP resolve endpoint (GET /lists/:listId) and /property-lists/check endpoint return the typed identifiers. Today the local DB resolves web (domain, subdomain) and mobile/CTV app identifiers (ios_bundle, android_package, apple_tv_bundle, bundle_id, apple_app_store_id, google_play_id, roku_store_id, fire_tv_asin, samsung_app_id); other AdCP types accepted by the schema (DOOH venues, podcast feeds, station IDs, etc.) pass validation but currently fall through to unresolvedIdentifiers until corresponding inventory data lands. Non-domain types short-circuit to the assess bucket on /check pending upstream AAO support.
• V2 storefront reporting is now driven end-to-end by AdCP 3.00 capabilities.
• Webhook dispatch on storefront media buys is driven by per-product reporting_capabilities (supports_webhooks / available_reporting_frequencies / available_metrics) and gated by the seller’s media_buy.reporting_delivery_methods. If the seller doesn’t advertise "webhook", webhook dispatch is suppressed regardless of product-level capabilities.
• Offline (bucket) reporting is now configurable per linked partner account. New endpoint PUT /advertisers/{advertiserId}/accounts/{linkId}/reporting-bucket sets or clears the bucket; pass reporting_bucket: null to clear. After persisting, the seller is notified via sync_accounts using the spec-defined preferred_reporting_protocol field plus a Scope3 transitional ext.scope3_reporting_bucket extension; if that notification fails, the local row is still updated and the response is 503 with the persisted account in the error details. The same operation is exposed via the v2 MCP api_call tool as the new update_account_reporting_bucket operation. Seller-provisioned account.reporting_bucket values returned from list_accounts / sync_accounts are also persisted, with buyer-supplied buckets winning on conflict.
• When a seller advertises offline-only reporting and no reporting_bucket is configured for an account, media-buy creation now logs a warning and audit-log marker pointing at the configuration endpoint and proceeds (polling via get_media_buy_delivery is always available as a baseline per AdCP 3.0).
• The reportingType and reportingPollingCadence parameters on the agent register tool are deprecated.
• Product discovery now skips sales agents whose advertised channel coverage does not overlap with the requested channels, instead of fanning out a request the agent will reject. The skipped agents appear in the per-agent debug output (when debug=true) with a reason like Agent does not sell requested channels (supports: display, ctv; requested: social). Failed-agent debug output also includes a new skipReason field carrying the human-readable rejection text from the agent, useful for the agents that still respond with an error after passing the pre-filter.

​

2.84.0 — April 29, 2026 at 11:47 PM UTC

• Customer admins can now remove a member from a customer via the admin members page. Removed members lose access immediately and must be re-invited to regain it.
• ADCP integration upgraded to @adcp/client 5.x with hardened webhook handling and new public discovery endpoints.
• New public endpoints /.well-known/jwks.json and /.well-known/brand.json for AdCP RFC 9421 request signing — sellers can verify our outbound calls and resolve our brand profile.
• UpdateCampaignBody now rejects explicit null (previously accepted); send omitted fields instead of null to indicate “no change”.
• billingType vocabulary updated: brand is now advertiser. Existing data is migrated automatically.
• ComplianceTrackResultSchema no longer accepts expected — only the documented values are valid.
• activate_signal MCP tool now requires destinations (minItems: 1) per AdCP v3.
• Internal: webhook handlers gain per-tenant + per-agent scoping (customer_id + sales_agent_id in DB predicates), opportunistic RFC 9421 signing on outbound calls, and improved error surfaces (adcpError, correlationId) propagated from the SDK.
• Fixed creative attachment to media buys, which had been silently broken in three independent ways. (1) Uploading a creative to a campaign with existing DRAFT media buys was rejected by Postgres because the auto-link query referenced the UPDATE target inside a LATERAL subquery; the entire transaction rolled back, leaving media_buy.creative_ids and media_buy_products.creative_assignments unchanged, and execution then skipped sales-agent sync. Eligible product/buy pairs are now resolved in a CTE before the UPDATE. (2) The autoPublishCreative brand-domain lookup queried the advertiser_brands table (renamed to advertiser_settings) on a column that never existed, leaving brand_domain undefined on synced creatives — fixed and the silent catch replaced with an actual log line. (3) update_campaign accepted mediaBuys[].creative_ids in the request body but the service silently dropped it and overwrote with the campaign’s auto-synced creatives, so buyers had no escape hatch when auto-sync was wrong; the field is now honored verbatim (with the existing format/customer/campaign validation in updateMediaBuy surfacing any errors) and only falls back to auto-sync when the field is omitted. The mediaBuys[], mediaBuys[].packages[], and mediaBuys[].products[] schemas now use Zod .strict() so unknown keys (typos, removed fields) fail validation instead of being silently stripped — closes the class of bug that hid #3.
• When a sales agent rejects create_media_buy with an adcp_error envelope, surface the agent’s actual error code and message instead of the misleading “Sales agent returned completed status but no packages” protocol-violation error.

​

2.83.3 — April 29, 2026 at 2:59 AM UTC

• Fixed the campaign creative-upload flow so the “Creatives still required” banner clears once a matching creative is uploaded. Previously, a trailing-slash mismatch in agent_url between a product’s required formats and the uploaded creative’s format caused the requirement to never be marked satisfied.
• Fixed format previews not rendering on the creative detail page for some providers and creative types.
• The “Formatted previews” grid is now driven entirely by the format definition: it no longer hides the entire grid when the manifest has no creative-source asset (which happened for webhook- or URL-only creatives), and per-tile media fallbacks tolerate a missing source asset instead of throwing.
• The agent’s preview_creative is now called whenever a format is selected, not just when there are no sized siblings. When both sized siblings (e.g. display_300x250_html, display_728x90_html for display_html) and agent-rendered previews are returned, the agent’s preview_url/preview_html is merged into each sibling tile by matching dimensions so each size shows the actual rendered creative.
• Tile labels and iframe titles now show the format ID rather than the per-render ID.
• Fixed sync_creatives request validation error when syncing creatives to third-party sales agents. Per-package assignments are now sent as the spec-compliant array of { creative_id, package_id } objects and forwarded on the ADCP request.

​

2.83.2 — April 28, 2026 at 11:49 PM UTC

• Keep the global navigation header (org/account switcher, notifications, account menu) interactive while the Terms of Service acceptance modal is showing. Previously, the modal blocked the entire page, so a stale ToS on the current org prevented users from reaching any other org or account they had access to. ToS is per-customer, so switching is now a valid path forward without accepting on the current org first.
• Block child accounts from accepting Terms of Service against the parent organization’s contract. When a child account’s effective contract resolves via parent fallback, ToS acceptance is refused unless the request comes from an organization admin. The user info response also surfaces a new tosBlockedReason field so the UI can render the right experience: organization admins see an “Accept for the organization” button, while non-admins see a sign-out modal explaining that an organization admin must accept first.
• Fixed creatives being rejected before sync to sales agents because the auto-publish flow was injecting domain assets (brand_name, impression_tracker, click_url) into the creative payload regardless of whether the format spec actually declared a slot for them. Strict sales agents (e.g. Wonderstruck) reject the creative for unrecognized asset keys, and the same hardcoded asset_ids meant agents that name their slots differently (e.g. brand_text, imp_pixel, clickthrough_url) never got those slots filled.
• Replaced the per-field injection logic with a single asset-capability registry that walks the format spec, matches each slot by pattern (asset type + asset_id shape), and writes the resolved value using the asset_id the spec actually declared. Adding a new domain field is now one entry in the registry rather than another bespoke injection block.
• Invite-member error toasts now show only the human-readable message instead of the full JSON error blob (e.g. “Too many invitation requests. Please try again in 15 minutes.” instead of {"errorCode":"...","errorMessage":"..."}).

​

2.83.1 — April 28, 2026 at 6:25 PM UTC

• Fixed the Terms of Service acceptance modal not appearing when switching into a member organization that has not yet accepted the latest ToS. The check now correctly distinguishes a SuperAdmin impersonating an unaffiliated customer (bypass ToS) from any user — including a SuperAdmin — switching into a customer they are a member of (must accept ToS for that customer).

​

2.83.0 — April 28, 2026 at 5:36 PM UTC

• Added public, unauthenticated endpoints to serve Scope3 legal agreements as markdown:
• GET /agreements/terms-of-service — latest pinned Terms of Service (currently v3.0)
• GET /agreements/<version>/terms-of-service — versioned Terms of Service (e.g. v3-0)
• GET /agreements/facilitated-agreement-terms — latest pinned Facilitated Agreement Terms (currently v1.0)
• GET /agreements/<version>/facilitated-agreement-terms — versioned Facilitated Agreement Terms (e.g. v1-0)
• GET /agreements/privacy-policy — Scope3 Privacy Policy
• Documents are checked into the repository and versioned in code, so the latest pointer is deterministic per release.
• Fixed two cases where creatives could be silently misrouted on media buys. Product format lookups during creative validation now correctly scope by sales agent and customer, so a creative that doesn’t match the active agent’s product is rejected upfront with a clear validation error instead of being silently dropped at the per-package boundary. Products without declared formats no longer receive every creative; they receive none, surfacing the misconfigured product to the buyer.
• Fixed broken endpoint URLs across the v2 docs and clarified how API versioning works.
• Buyer and storefront REST examples now use the canonical /api/v2/buyer/... and /api/v2/storefront/... base paths everywhere (previously a mix of /api/buyer/... and /api/storefront/..., which only worked via the 308 redirect alias). Shared endpoints — /notifications, /notification-preferences, /notification-email, /slack-configuration, /service-tokens, /accounts, /accept-tos — are now documented at their correct /api/v2/... (no /buyer/ segment) paths. Skill-file and OpenAPI YAML download URLs were updated to the same versioned canonical paths.
• Added a Versioning section to the Authentication page explaining the difference between the canonical versioned URLs (/api/v2/buyer, /mcp/v2/buyer, etc. — pinned to v2 across future major versions) and the unversioned aliases (/api/buyer, /mcp/buyer, etc. — 308-redirect to whatever is currently stable). Corrected two notes in the migration guide and the “Built for Agents” page that previously claimed the versioned URLs auto-roll to latest stable, which is the opposite of how versioning actually works.
• Also corrected the discovery POST budget example (scalar number, not { total, currency }), the creative manifest list endpoint (/creativeManifest), the format catalog endpoint (/formats, /creatives/templates), and the polling example for GET /campaigns/:id/media-buy-status (response shape uses media_buys[], not a top-level status).

​

2.82.0 — April 28, 2026 at 2:14 PM UTC

• Added a storefront activity feed for sellers. A new GET /api/v2/storefront/audit-logs endpoint returns the recent config and inventory source changes for your storefront, and sellers can now access the feed from the home page under the Organization section.
• Exposed the activity feed through the MCP api_call tool on both the buyer and storefront surfaces. Buyers can now list audit log events via the new list_activity operation (GET /api/v2/buyer/audit-logs); the storefront api_call routes GET /api/v2/storefront/audit-logs to the same audit log dispatch.
• Synced the storefront API documentation with the live route surface. Removed the legacy Pylon-specific POST /storefront/notifications/provision and GET /storefront/notifications/status endpoints from the storefront skill file and OpenAPI spec, and removed pylonAccountId from any documented response. Communication channel provisioning is configured at the customer/account level and is not part of the storefront onboarding flow, so it is not advertised here. Also corrected the storefront API reference (no DELETE /storefront; clarified POST /storefront is idempotent), aligned /api/storefront/... examples to the canonical /api/v2/storefront/... form, replaced confidential customer placeholder values with Acme, and fixed the AAO builder URL and the agent compliance shape in the storefront skill file.
• Added GET /api/stripe/payment-method-status to check whether a customer has a payment method on file. The buyer billing page now surfaces a warning when no payment method is configured, so admins can add one before invoices fail to charge.
• Fixed six v2 storefront billing operations that returned “Endpoint not found” through the MCP dispatcher despite being documented: provision Stripe Connect account, get billing config, account status, transactions, payouts, and onboarding URL. The underlying REST endpoints were unaffected.

​

2.81.0 — April 27, 2026 at 9:05 PM UTC

• Added a customer communication channel flow for support: during signup (or via a new Admin → Support tab / home page prompt) customers can opt into a Slack Connect or Microsoft Teams channel (ext-agentic-[env-]{customer-slug}-{customerId}). The chosen provider, channel name, and invite state are persisted on the customer. For Slack, the channel is automatically linked to a Pylon account and tagged Buyer or Sales agent based on the customer role.
• New endpoints:
• POST /api/v2/customer/communication-channel — provision Slack/Teams, or pass provider: null to decline
• GET /api/v2/customer/communication-channel — read current provisioning state
• POST /api/v2/customer/communication-channel/resend-invite — re-send the invite without re-creating the channel
• On provisioning, the channel is auto-populated with configured Scope3 internal support staff (buyer or seller list) and all of the customer’s admins. Same-workspace Slack users are added via conversations.invite, external admins via Slack Connect; Teams external emails are added as B2B guests via the backing M365 group with retries for Graph propagation lag.
• Clarified that the views metric (in reporting and as an optimization goal) refers to viewable impressions (the MRC-viewable subset of impressions, per AdCP), not raw rendered impressions. Documentation and schema descriptions for views, completedViews, and the MetricGoal.metric field have been updated to reflect this and to note that a viewability rate goal can be expressed as metric: "views" with a threshold_rate target.
• Embed Stripe invoices and pending transactions directly on the billing page for buyer accounts, storefront accounts, and per-storefront child accounts in collapsible sections.
• Fixed an issue where retrying or rapidly clicking “Connect Stripe” could create multiple orphaned Stripe Express accounts for the same client. Provisioning now uses a deterministic idempotency key per customer, so duplicate requests resolve to the same Stripe account.
• Fixed a duplicate-key error that blocked activating new media buy versions when a sales agent accepted an update_media_buy change. Status sync now performs the version transition atomically, superseding the old version instead of attempting two simultaneously active rows. New media buy versions also activate immediately when the sales agent’s synchronous update_media_buy response shows the change is already live, instead of waiting up to an hour for the next status poll.
• Fixed inflated reporting metrics on GET /api/v2/buyer/reporting/metrics when a media buy had a pending update. Both the active and pending-approval versions were being returned in the breakdown, causing the media buy to appear twice and its metrics to be double-counted in the campaign, advertiser, and grand totals. Pending versions (which have no reporting data) are now excluded from the response.
• Notifications are now available to all authenticated customers at GET /api/v2/notifications. Previously the route was registered only under /api/v2/buyer/notifications, which returned CUSTOMER_ROLE_DENIED for storefront customers and broke the in-app notifications bell on storefront login. The legacy /api/v2/buyer/notifications REST path has been removed; MCP api_call paths are unchanged.
• Moved SSO Configuration from the user account dropdown to a new SSO tab on the organization settings page. Existing /sso-config links now redirect to the new tab.

​

2.80.0 — April 24, 2026 at 8:48 PM UTC

• The Connect agents dialog now offers a “Sign in with AAO” button. Signing in via OAuth adds private and member-only agents registered under your operator domain to storefront agent discovery alongside public agents. The token is used only for the active session and is not stored.
• Renaming a storefront no longer regenerates its platform_id. The identifier is now stable once assigned at creation, which prevents “A storefront with a matching platformId already exists” conflicts when renaming into a slug another storefront already uses.
• Added buyer-side frequency cap configuration (frequencyCaps) on advertiser, campaign, and creative endpoints. Each cap specifies a maxExposure and a rolling window (interval + unit). Single GET always includes active caps; LIST endpoints include them when includeFrequencyCaps=true is passed. CREATE/UPDATE bodies accept an optional frequencyCaps array — omit to preserve existing caps, pass an empty array to clear, or supply a new list to replace.
• ADCP webhook endpoint now returns proper HTTP status codes for each failure mode instead of a blanket 500. Malformed webhook payloads return 400 with the underlying error message so senders can see what’s wrong, invalid URL path params return 400, and internal infrastructure failures still return 500.

​

2.79.0 — April 23, 2026 at 10:47 PM UTC

• Added a notification bell to the v2 app header: opens a dropdown of recent notifications with an unread count badge, mark-as-read on click, and mark-all-as-read.
• Tracking pixel URLs now include the advertiser (seat) ID as an advid query parameter alongside cid (creative) and camp (campaign). Applies to both ADCP asset tracker URLs and HTML-injected tracking pixels for v2 creatives.
• Fixed URL-based creative assets (VAST tags, clickthrough URLs, tracker pixels) so the stored filename is derived from the URL (e.g. tag.xml or qawolf.com) instead of the URL type label. Also aligned creative update so VAST URLs are stored with asset_type: VAST, matching creative create — previously updates always stored them as asset_type: URL.
• Fixed campaign updates failing with “Creative format validation failed” when a campaign has creatives in multiple formats (e.g. video and display) and is linked to format-restricted media buys. Creatives are now filtered per media buy based on product format compatibility before syncing.
• Fixed campaign creation failing with “No active contract found for customer” when a child customer inherits its contract from a parent. Pricing resolution now walks the parent hierarchy to match the same contract-lookup behavior as the rest of the API.
• Updating a property list now retroactively syncs active media buys for advertisers linked to that list, so sales agents receive the refreshed include/exclude properties without needing to recreate the campaign. The update response includes an optional cascadeSummary summarizing how many active media buys were notified.
• Fixed the get_media_buy_status operation on the v2 buyer MCP tool. It previously returned “Endpoint not found” through the MCP dispatcher despite being documented in the skill; the underlying REST endpoint was unaffected.

​

2.78.0 — April 23, 2026 at 12:16 AM UTC

• Campaigns now have a campaignType (DECISIONED or ROUTED) and the budget total includes Scope3 fees.
• campaignType is required when creating a campaign and immutable after creation. DECISIONED campaigns means Scope3 is applying real-time decisioning, optimization, or consolidated invoicing and payment processing operations. ROUTED campaigns means the buyer is directly connecting to the seller; they transact and settle directly and do not use Scope3’s real-time decisioning or optimization.
• Response includes mediaBudget (allocatable to media buys) and a fees array with the Scope3 fee breakdown.
• Updating budget is rejected if the new media budget drops below the sum of existing media buy allocations, or if by reducing the budget the fee would no longer be payable.
• ROUTED campaigns only accept media buys whose sales agents require operator authentication; discovery results are filtered to match when a ROUTED campaign ID is supplied.
• Existing campaigns are grandfathered with campaignType=DECISIONED, an 8% fee rate or custom negotiated price, with mediaBudget set equal to the existing budget so previous spend capacity is preserved.
• Updated the “creatives still required” banner on campaign creative assets to group requirements by creative agent and show per-product “one of [formats]” options, matching how products actually require coverage (at least one creative per product, not per distinct format).
• Corrected the v2 buyer skill and update_campaign schema descriptions for media buy start_time / end_time. Clarifies that a media buy cannot start before the campaign’s flightDates.startDate, and that pacing periods do not strictly govern media buy dates — media buy dates MAY correspond to a pacing period’s start / end when applicable, but are always allowed to be any dates within the campaign flight, with or without pacing periods.

​

2.77.0 — April 22, 2026 at 8:49 PM UTC

• Added measurement engine endpoints for managing hypotheses, test plans, measurement sources, measurement records, allocations, human feedback, learning cycles, belief state, testability analysis, measurement freshness, and learning records. Includes filtering by flight ID on hypotheses, date range and geo filters on measurement records, and paginated learning records.
• Fixed AAO compliance gating to handle the current registry contract, where /compliance returns status: "unknown" for both unregistered agents and registered-but-untested agents. Registered agents without a graded compliance status now pass through storefront source creation instead of being incorrectly rejected. Added handling for upstream 429 responses on property-list bulk resolution so clients see a retryable 503 instead of a 500.
• Fixed capability refresh failing for operator-auth sales agents (e.g. Snap) by always authenticating with the agent-level credential instead of resolving through the per-customer credential chain.
• Prevent agents from conflating campaign and media-buy end dates when a campaign has pacing periods. The v2 buyer skill now documents pacingPeriods and states that a media buy’s end_time comes from its pacing period’s end, not the campaign flight end date. Strengthened the end_time description in the v2 update-campaign schema to reinforce the same rule.
• Fixed format details endpoint returning an OAuth token resolution error by restricting the seat lookup for an agent to seats whose credential belongs to the calling customer, preventing a seat from another customer (e.g. a master account) from being selected.
• Fixed a bug in the product discovery MCP view where multiple pricing chips appeared selected on products with duplicate pricing option IDs. The selection state now tracks the option by position rather than ID, so products with identical-shape options (same pricing model) render and select correctly.
• Fixed property list endpoints (POST/GET/PUT /advertisers/:advertiserId/property-lists[/:listId]) to wrap the response in { propertyList: ... } as documented in the OpenAPI spec. Previously the endpoints returned the bare property list object.
• Inventory source creation now requires the partner agent to pass AAO compliance testing. Agents that are not registered or not passing will be rejected with a validation error; temporary AAO outages return a service-unavailable error so the request can be retried.
• Added optimization_goals to media buys. Optimization goals (event-based CPA/ROAS targets or metric-based CPC/completion-rate targets) can now be set on a media buy and are applied to every package at execution time. Exposed via the v2 update_campaign → mediaBuys entries. Media buy responses now include optimization_goals.
• Property lists now accept up to 100,000 domains per create, update, and check request (previously capped at 10,000 for create/update and 1,000 for check). Large requests are chunked server-side against the AAO registry and local database, so clients no longer need to split their own batches. Create and update responses now include a resolutionSummary object — totalRequested, resolvedCount, registeredCount, unresolvedCount, resolutionRate — so buyers can see at a glance how many of their submitted domains will actually target. The check endpoint response adds a reportIds array containing every registry report generated (one per chunk); the existing reportId field remains and equals reportIds[0] for back-compat.
• Property list checks now retry once and surface a 503 Service Unavailable when the AAO registry returns transient errors (429 or 5xx), instead of failing with a 500 on the first blip. Clients that retry on 503 will see fewer spurious failures during registry flakes.
• Property list checks now retry once when the AAO registry rate-limits a chunk (HTTP 429) instead of failing the whole request, making large bulk checks resilient to brief registry throttling. System service tokens now also pass SuperAdmin-gated checks so operators can drive admin-only flows (e.g. AAO compliance bypass) end-to-end.

​

2.76.0 — April 21, 2026 at 10:24 PM UTC

• Fixed storefront go-live button hanging when activating a storefront. Activation no longer runs a synchronous agent compliance probe (up to 60s per agent) and is gated only on setup readiness checks.
• Renamed the VIDEO_VAST URL asset type to VAST on the url_type field for creative URL assets. The UI label and backend enum value now both read VAST. Existing stored rows are migrated to the new value.
• Reading a storefront now re-evaluates operator-domain verification against the customer’s (or parent’s) registered domain, so storefronts that were saved before auto-verification was available no longer stay stuck as unverified.
• Storefronts operated by a child customer now auto-verify against the parent organization’s registered domain when the child’s own domain is absent or different, so partner-adapter storefronts no longer require manual verification.

​

2.75.2 — April 21, 2026 at 7:32 PM UTC

• Fixed a bug where the description field on advertisers was silently dropped on create and update, and was never returned from get or list endpoints.
• Fixed an issue where newly invited users could not see any seats after accepting their invitation. All users now have implicit access to all active seats within their customer, with permissions derived from their customer-level role.
• Show the Stripe Connect billing dashboard (Account / Balances / Payments / Payouts) for all parent and standalone customers on the Billing settings tab, regardless of customer role. Configure the Stripe publishable key so the embedded Connect components actually load, and surface a clear error if the key is missing instead of rendering empty section containers. Also return users to the Billing settings tab after completing Stripe Express onboarding instead of the legacy admin billing page.
• MCP api_call now rejects POST/PUT/PATCH/DELETE requests with CUSTOMER_SCOPE_REQUIRED when the session’s user has access to more than one customer and has not called customer_switch first. This prevents mutating requests from silently landing on the wrong customer. GET requests are unaffected. Agents must call customer_switch with the intended customerId before any mutating request in multi-customer sessions. Applies to both /mcp/v2/buyer and /mcp/v2/storefront.
• Require bidPrice when adding auction-priced products to a discovery session, and reject unknown pricingOptionIds at add time. Catches these errors early instead of failing later at campaign execution.

​

2.75.0 — April 21, 2026 at 4:01 PM UTC

• Added an Activity page for buyers that shows a timeline of actions taken on your campaigns, media buys, and related resources (creations, edits, archives, executions, pauses). Filter the feed by time period, advertiser, and campaign. The GET /api/v2/buyer/campaigns endpoint now also supports an includeArchived=true query parameter for retrieving archived campaigns.
• Add pacing periods to campaigns. Campaigns can define time-based spend periods with weights or hard budgets. On execution, products are automatically split into per-period ADCP packages with proportional budgets and period-specific flight dates.
• Fixed a 500 error when deleting creative manifests by removing a reference to a non-existent archived_at column on the creatives table.
• Fixed creatives not propagating to media buys when an existing creative manifest is updated, and added cascade cleanup when a creative manifest is deleted. Non-DRAFT media buys now correctly create a new pending-approval version and notify the sales agent via ADCP when creatives are removed, so the change follows the normal approval flow instead of silently mutating the active version. An empty creative list is now propagated to the sales agent as a clear-all instruction rather than being skipped.
• Creative upload UI now shows the list of format IDs still required based on the products selected for the campaign. The GET /campaigns/:campaignId/creatives/templates response now returns campaign_format_ids populated from the campaign’s products (sourced from media buys and the discovery session) instead of an empty array.
• The update_campaign and list campaigns responses now include the creatives assigned to each media buy and package, so callers can confirm which creatives are linked without issuing a follow-up query. Updating a media buy’s creatives now also populates each package’s creative_assignments, filtered by the formats accepted by that package’s product.

​

2.74.0 — April 20, 2026 at 10:38 PM UTC

• Added allocatedBudget and unallocatedBudget computed fields to the Campaign resource returned by GET /api/v2/campaigns and GET /api/v2/campaigns/:id. These expose how much of the campaign budget is currently allocated to active media buys (including performance spend from archived media buys) and how much remains available for new media buys, without requiring clients to sum media buy budgets themselves.
• Added a new GET /api/v2/buyer/campaigns/:campaignId/media-buy-status endpoint that polls sales agents for the live status of all media buys within a campaign. Also available via the api_call MCP tool as operation get_media_buy_status. A background sync now periodically reconciles media buy statuses to catch transitions that may have been missed by webhooks.
• Fixed customer switching for non-admin users in the MCP integrations. The customer_switch tool is now available in the v2-buyer and v2-storefront MCP integrations, so any user can switch into a customer they have an active membership on (previously only SuperAdmin users could switch via the admin tool).
• Fixed MCP sessions being dropped after 4 hours of active use. Sessions now stay alive as long as there is ongoing activity, matching the intended idle-timeout behavior.
• Fixed GET /api/v2/buyer/reporting/metrics?view=timeseries&download=true so the generated CSV now matches the summary export columns plus a Date column, with one row per hierarchy leaf (advertiser → campaign → media buy → package) × day. Previously the export silently returned the summary (hierarchy) CSV with no date breakdown, regardless of the view parameter.

​

2.73.0 — April 20, 2026 at 4:14 PM UTC

• Added per-package breakdown to the reporting metrics response. Each media buy now exposes its packages with per-package metrics, and every package includes both productId and the human-readable productName.
• Added a metadata field to optimization suggestions, allowing arbitrary contextual data to be stored and returned alongside suggestion details.

​

2.72.0 — April 17, 2026 at 9:04 PM UTC

• Enforce campaign flight date guardrails on PATCH /api/v2/buyer/campaigns/:id. Updates now reject flight date changes that would conflict with non-DRAFT media buys (start before earliest active media buy, end before a media buy’s start or end). Cascade failures to DRAFT media buys now fail the update instead of being silently logged.
• Tracking pixel URLs now always include {MEDIA_BUY_ID} and {PACKAGE_ID} as DSP-resolved macro placeholders, alongside existing {AXEM} and {TMPX} macros. These values are resolved by the publisher at impression time, allowing creatives and their trackers to be reused across multiple media buys and packages.
• Agents now auto-activate when authentication credentials are configured, removing the need for a separate activation step before going live. Added auth credential editing to the storefront seller onboarding flow.
• Exposed four v2 storefront onboarding endpoints through the MCP api_call dispatcher so AI agents can run the full onboarding flow: POST /storefront/resolve-brand, GET /storefront/discover-agents, POST /storefront/notifications/provision, and GET /storefront/notifications/status. PUT /storefront via MCP now also auto-verifies operatorDomain when it matches the caller’s customer domain, matching the REST behavior.

​

2.70.0 — April 17, 2026 at 5:05 PM UTC

• Audience sync notification emails now name the specific audiences that were synced and summarise the outcome for each, so recipients can tell at a glance which audience the email is about.
• Campaign execution now returns an error when the linked discovery session is not found, instead of silently succeeding with no changes.
• Fixed media buy creation to default start_time to today when not provided or when the date is in the past. Also auto-corrects stale start_time at execution time to prevent errors from draft media buys created before their execution date.
• Made media buy start_time optional — defaults to campaign start date (if future) or today.

​

2.69.0 — April 16, 2026 at 9:04 PM UTC

• Allow customers to configure an organization-wide notification email address and manage email notification type preferences from the org settings page.
• Redesigned the buyer reporting table with a “Show percentages” toggle, improved visual hierarchy for advertiser/campaign/media buy rows, and aligned empty states with the design system.
• Fixed an issue where creatives added to a campaign after media buy execution were not assigned to packages on the sales agent side.
• Increased per-audience member limits for the audience sync endpoint from 10,000 to 100,000 for both add and remove operations.

​

2.68.0 — April 16, 2026 at 3:09 PM UTC

• Fixed re-executing an active campaign with new products for the same sales agent now correctly creates additional media buys instead of silently skipping them.
• Fix customer switching for SELLER accounts by moving role-agnostic routes (accounts, service tokens, notification preferences, contracts, Slack configuration, ToS) from buyer-only router to a shared router accessible by all customer types.

​

2.67.0 — April 16, 2026 at 1:04 AM UTC

• Fixed an issue where the OAuth authorization popup window would not reliably close after completing authorization. The OAuth completion page now notifies the originating window when authorization is complete, allowing connected sessions to refresh automatically without a manual page reload.

​

2.66.0 — April 15, 2026 at 8:08 PM UTC

• The Buyer API has been migrated from Sales Agents to Storefronts. The new GET /api/v2/buyer/storefronts and GET /api/v2/buyer/storefronts/:storefrontId endpoints replace the previous sales agents endpoints, returning storefronts with their associated inventory sources and credential/connection status.
• Credentials for inventory sources are now registered via POST /api/v2/buyer/storefronts/:storefrontId/sources/:sourceId/credentials, replacing the previous per-agent credential registration endpoint.
• Registered credentials can now be listed via GET /api/v2/buyer/storefronts/credentials.
• API error responses now follow a consistent envelope format: { "data": null, "error": { "code": "...", "message": "...", "field": "...", "details": {} } }. The field property identifies which specific input caused the error when applicable.
• MCP tool errors now return structured error objects with code, message, field, and suggestion fields in addition to a human-readable text message, making it easier to handle errors programmatically.
• Two new error codes are now documented: INVALID_STATE (400, operation not allowed in current resource state) and INTERNAL_ERROR (500, contact support).
• Fixed an issue where the agentId field was incorrectly included in buyer storefront API responses.
• Fixed an issue where buyer storefront queries used an incorrect column, which could cause incorrect results.
• Fixed a bug where users with an invalid customer ID in the URL were not properly redirected to their correct customer context.
• Fixed back navigation, password validation, and rate limiting behavior in the sign-up flow.
• Fixed an issue where parent customer accounts were incorrectly blocked by the buyer/seller role gate.
• Added productId to package-level reporting metrics.

​

2.65.0 — April 15, 2026 at 1:50 PM UTC

• Added new Slack webhook integration endpoints under /api/v2/buyer/slack-configuration, allowing buyer admins to connect a Slack channel to receive platform notifications.
• GET /api/v2/buyer/slack-configuration retrieves the current Slack configuration; the webhook URL is masked in the response for security.
• PUT /api/v2/buyer/slack-configuration creates or updates the Slack configuration, accepting a webhook URL, enabled state, and a list of notification event types to subscribe to.
• DELETE /api/v2/buyer/slack-configuration removes the Slack configuration and stops all Slack notifications.
• POST /api/v2/buyer/slack-configuration/test sends a test message to the configured Slack channel to verify connectivity.
• All Slack configuration endpoints require admin-level access; requests from non-admin users will receive a 403 response.
• Platform notifications are now automatically delivered to a customer’s configured Slack channel when the relevant event type is enabled.
• Fixed an issue where seller and buyer access permissions were not correctly applied in certain authentication scenarios.

​

2.64.0 — April 14, 2026 at 10:53 PM UTC

• Added refinement support to the POST /api/v2/buyer/discovery/discover-products endpoint: you can now pass a refine array with a discoveryId to iteratively refine discovery results (e.g., “more video options”, omit a product, or get more like a specific product). The response includes a refinementApplied field describing how each instruction was handled.
• Notification preferences have changed from opt-out to opt-in. The GET and PUT /api/v2/buyer/notification-preferences endpoints now use an optIns field instead of optOuts. Only explicitly opted-in notification types will be delivered.
• Fixed a bug where the OAuth callback for storefront partner integrations would show a generic error instead of the actual error message returned by the OAuth provider.
• Fixed an issue where the OpenAPI YAML spec was not resolved correctly in production, which could cause spec-serving endpoints to fail.
• Fixed an issue where trace IDs were being surfaced in user-facing error messages; errors now contain only relevant context.
• Improved error logging for campaign creation failures to surface more actionable debug information.

​

2.63.1 — April 14, 2026 at 5:01 PM UTC

• The user impersonation list now returns all available users instead of being capped at 50, making it easier to find and select users in larger organizations.
• Format group names in the creative format dropdown now display consistently using the format’s source URL, improving clarity when working with multiple format sources.

​

2.63.0 — April 14, 2026 at 4:19 PM UTC

• When creating a creative, you can now provide a VAST tag URL directly as a primary asset by selecting the new “URL” tab and choosing the “Video VAST” type.
• Creative creation now supports a “Webhook” tab, allowing you to configure a webhook endpoint (with method, timeout, response type, and optional HMAC or API key security) as the primary creative asset source.
• The VIDEO_VAST value is now supported for the url_type field on URL assets when creating creatives via the API.
• Fixed an issue where media buy execution could fail incorrectly when the response contained an empty errors array rather than actual errors.

​

2.62.0 — April 14, 2026 at 3:20 PM UTC

• When a user signs up under an existing customer organization, the relevant customer admins are now notified automatically.
• Products can now be removed from completed discovery sessions, not just active ones.
• Fixed an issue where email notification suppression was not applied consistently across all token types.
• Fixed an issue with creative sync where assignment data was not being formatted correctly, which could cause sync requests to fail or behave unexpectedly.

​

2.61.0 — April 14, 2026 at 1:47 PM UTC

• The ARCHIVED storefront status has been removed. Storefronts that were previously archived have been migrated to DISABLED status. Valid statuses are now PENDING, ACTIVE, and DISABLED.
• Notification emails for user-initiated actions (such as optimization suggestions) are now sent only to the user who triggered the action, rather than to all users on the account.
• Campaign health events now trigger notifications when a campaign becomes active or transitions away from active status, replacing generic create/update/delete notification events.
• Users who are members of a child account can now see their parent organization and sibling accounts in the customer context list, providing complete hierarchy visibility.
• Tracking pixels now include the tmpx={TMPX} macro in addition to the existing axem={AXEM} macro on both impression and click tracker URLs.

​

2.60.0 — April 13, 2026 at 6:49 PM UTC

• The Storefront API now exposes a full set of signals management endpoints: create, list, get, update, delete, and discover signals (POST/GET/PUT/DELETE /api/v2/storefront/signals and POST /api/v2/storefront/signals/discover).
• The storefront enabled boolean field has been replaced with a status field supporting four lifecycle states: PENDING, ACTIVE, DISABLED, and ARCHIVED. Clients should update any code that reads or writes enabled to use status instead.
• Status transitions are now validated — for example, an ARCHIVED storefront cannot be transitioned to any other state.
• The customerId field on the delete user endpoint is now optional; requests without it will succeed rather than returning a validation error.
• The ask_about_capability tool now returns complete documentation sections without truncation, ensuring responses include the full context needed to answer capability questions.

​

2.59.0 — April 13, 2026 at 4:31 PM UTC

• The api_call tool now supports a named operation parameter (e.g., "operation": "list_advertisers") as an alternative to specifying method and endpoint directly, reducing the chance of incorrect HTTP methods or malformed paths.
• When an api_call fails due to a malformed endpoint (missing path prefix, trailing slash, etc.), the API will now automatically attempt to correct and retry the request rather than returning an error immediately.
• OAuth is now supported when creating or editing inventory sources in the UI.
• Child customer users can now see their parent organization and sibling accounts in the customer selector, enabling easier navigation across accounts in a hierarchy.
• Fixed an issue where email notifications were not being delivered due to missing configuration in the API deployment.

​

2.58.0 — April 12, 2026 at 9:46 AM UTC

• During signup, the company name field is now pre-filled using a brand registry lookup based on your email domain, replacing the previous email domain parsing heuristic. When a match is found, a confirmation message (“We found your company in the brand registry.”) is shown in the form.
• The POST /auth/check-email-availability endpoint now returns an optional suggestedCompanyName field in the response when a company name can be resolved from the email domain for new customers.
• Rate limiting has been applied to POST /auth/check-email-availability, consistent with other signup endpoints.
• Authentication status checks are now cached client-side for up to 2 minutes, reducing redundant network requests during navigation while maintaining session security.

​

2.57.2 — April 11, 2026 at 4:39 PM UTC

• OAuth and SSO users signing up will now automatically skip the personal details step, as their name and email are pre-filled from the identity provider.
• Fixed an issue where child accounts could fail to resolve their active contract correctly; child accounts will now properly fall back to the parent contract when needed.

​

2.57.1 — April 10, 2026 at 11:04 PM UTC

• The accept_tos tool is now available in the v2-buyer and v2-storefront MCP contexts, allowing organizations to accept the Terms of Service before making API calls.
• Advertiser API responses now correctly return the id field across all advertiser endpoints (list, create, get, update, restore).
• Validation error messages for tool inputs now consistently read “Validation error for tool” for clearer error reporting.
• Media buy status filtering now includes pending_creatives and pending_start statuses in addition to the existing active, paused, and completed states.

​

2.57.0 — April 10, 2026 at 10:21 PM UTC

• MCP tool calls now return clear, descriptive error messages immediately when required fields are missing or field values are invalid, rather than failing later with a less informative error.
• Advertiser API responses now consistently return the advertiser identifier as id across all endpoints (list, create, get, update, restore).

​

2.56.0 — April 10, 2026 at 7:58 PM UTC

• Administrators on a parent organization can now switch into and access child customer accounts without requiring explicit per-account permissions.
• The account list now includes child customers accessible through parent organization hierarchy, so all manageable accounts appear in the customer selector.
• A maintenance banner is now displayed in the application when scheduled or active maintenance windows are configured, showing relevant timing and status information.
• Fixed an issue where switching customer context could result in incorrect access permissions or an inconsistent impersonation state.
• Fixed an issue where child customers now correctly inherit their parent’s contract and Terms of Service when they have no contract of their own.
• Fixed an issue where returning from an impersonated customer session now correctly restores the previous customer context and page location.
• Error messages shown in notifications now display the human-readable message instead of an internal error code when both are available.

​

2.55.0 — April 10, 2026 at 4:50 PM UTC

• Added notification preference opt-out controls: users can now manage which notification types they receive per channel via GET /api/v2/buyer/notification-preferences and PUT /api/v2/buyer/notification-preferences.
• In-app notifications now respect per-user opt-out preferences, automatically filtering out notification types the user has opted out of.
• Email notifications now respect per-user opt-out preferences, skipping delivery for users who have opted out of a given notification type.
• Signup flow now accepts only Advertiser and Seller as account types; previously accepted types such as “Agency” and “Other” are no longer valid.
• Invitation requirement for joining an existing organization is now enforced by default for all users, without requiring a feature flag to be enabled.
• The audience sync member removal schema has been aligned with the latest spec; the externalId, hashedEmail, hashedPhone, and uids fields are now consistently structured.
• Fixed a security issue where an OAuth re-registration could allow one customer’s credentials to be overwritten by another customer using the same account identifier.
• Fixed an issue where switching to a customer account via the API could return users scoped to the wrong customer.
• Fixed authentication callback handling to correctly display a fallback for non-standard auth flows and handle missing customer state gracefully.
• Fixed cross-links on the authentication pages to use correct navigation behavior, preventing unintended full page reloads.
• Fixed Terms of Service and Privacy Policy links on the signup page to render as standard anchor links.
• Fixed the customer_switch MCP tool to return a clear validation error when a non-numeric or invalid customer ID is provided, rather than an internal database error.

​

2.54.0 — April 8, 2026 at 9:11 PM UTC

• Users now receive email notifications when new notifications are created, keeping teams informed of important updates without needing to log in.
• A new suggestion apply flow has been added with webhook status tracking, allowing optimization suggestions to be applied and their progress monitored end-to-end.
• Discovery session activity is now logged for analytics, enabling better insights into marketplace search and product interactions over time.
• The UI now preserves the intended destination path through account resolution, so users are correctly redirected to their original target after authentication.
• Packages are now associated with a single product via a direct relationship, improving consistency and reliability of package-product data.

​

2.53.0 — April 8, 2026 at 2:14 PM UTC

• Added a new endpoint POST /api/v2/buyer/advertisers/:advertiserId/measurement-data/sync for syncing advertiser performance measurement data to the ingestion pipeline.
• Unversioned API paths /api/buyer and /api/storefront now permanently redirect (308) to their versioned equivalents /api/v2/buyer and /api/v2/storefront.
• The source field on measurement data objects now accepts only the values advertiser, mmp, or measurement_partner instead of any free-form string.
• A new optional source_metric_name field is available on measurement data objects for mapping raw partner metric names.
• Trace context (traceparent) and MCP session ID headers are now propagated to all downstream service calls, improving end-to-end request traceability.
• Fixed a bug where customer-level API users were incorrectly blocked from updating or deleting campaigns that belong to a specific seat within their organization.
• Fixed a data corruption issue where brand profile URLs were being double-serialized, which could cause campaign execution to fail or send malformed data.
• Fixed a bug where the brand_manifest URL field was not validated, allowing invalid values to be stored and forwarded.
• Improved error messages when a tactic cannot be created because no brand is linked to the campaign, replacing a technical internal message with a clearer user-facing explanation.
• When creating an advertiser, the brand is now automatically saved without requiring a separate “Register & Create” action.

​

2.52.0 — April 7, 2026 at 4:18 PM UTC

• Added new optimization suggestion endpoints to the Buyer API, allowing you to list, view, approve, and reject AI-generated optimization suggestions for your media buys via the api_call tool.
• Expired OAuth tokens are now automatically refreshed when resolving agent accounts, reducing authentication failures for OAuth-connected integrations.
• API responses now include an x-trace-id header, making it easier to correlate requests with support when troubleshooting issues.
• Fixed a bug where the campaign optimizer job used an incorrect argument format, which could cause optimization runs to fail silently.
• MCP sessions are now reliably consistent across server instances, eliminating cases where customer switches or seat selections made on one server were not reflected when requests routed to a different server.

​

2.51.0 — April 6, 2026 at 5:38 PM UTC

• Added a new testing endpoint POST /api/v2/testing/deleteSsoConnection that allows deletion of all SSO connections for a given WorkOS organization ID, returning 204 whether connections existed or not (idempotent). Requires SUPER_ADMIN authentication.
• Seat-scoped API tokens now automatically infer the advertiser ID, allowing use of /advertisers/me/ in endpoint paths as a shorthand that resolves to your token’s advertiser. Explicit advertiser IDs in requests are validated against the token scope and will return a clear error on mismatch.
• Advertiser account linking now returns a validation error immediately if any requested account is not found or has a sandbox/production mismatch, rather than silently skipping the invalid accounts.
• Fixed a bug where the deleteUser cleanup endpoint would return a 502 error if the backend deletion step failed; the operation now completes successfully and reports the partial result.
• Non-OAuth inventory source agents are now created in PENDING status instead of being auto-activated on inventory source creation.
• Fixed the Terms of Service modal so the ToS link is now clickable and opens correctly.
• Fixed an issue where isCustomerSwitched was not correctly detected for member-level customer switches, ensuring contract and ToS enforcement behaves correctly when switching between customers.
• The measurement config API list endpoint now uses limit instead of take as the pagination parameter, and response data is accessed at data.data.items.

​

2.50.1 — April 3, 2026 at 6:50 PM UTC

• Fixed an issue where the authConfigured field on storefront agent responses could incorrectly reflect a non-existent configuration source, ensuring it now accurately indicates whether authentication is set up.

​

2.50.0 — April 3, 2026 at 5:58 PM UTC

• Inventory sources can now be edited after creation, including updating the endpoint URL, protocol, authentication type, and credentials.
• A new hosted sales agent setup flow is available when creating inventory sources, simplifying agent onboarding.
• Agents associated with non-OAuth inventory sources are now automatically activated upon source creation, removing the need for a manual activation step.
• A new GET /billing/accounts endpoint is available for parent customers to view billing status across all managed child accounts.
• Billing configuration is now scoped to the customer account rather than the storefront, enabling more consistent billing management across storefronts.
• Parent customers can now accept the Terms of Service directly without needing to switch accounts first.
• The Terms of Service acceptance flow now automatically provisions the required contract, removing a manual step that previously blocked new customers.
• The ToS enforcement error code has been unified: all cases where ToS acceptance is required now return TOS_ACCEPTANCE_REQUIRED instead of the previous CONTRACT_REQUIRED code.
• Fixed an issue where customer session context (including account type) was not correctly persisted when switching between parent and child accounts.
• Fixed a bug where parent-account access restrictions were incorrectly applied after switching away from a child account.
• Fixed a bug where a missing bid_price field in campaign execution returned an unformatted error; it now returns a clear validation error.
• Fixed an issue where products added via product IDs were missing the bid_price field.
• Fixed an issue where the generation_prompt asset status and creative brief were not resolving or clearing correctly.
• Fixed a bug where tactic creation failed when no agent was associated with the campaign.
• Fixed an issue where the SSO configuration feature flag was not evaluated for super admins and sellers.
• Fixed distributed tracing context propagation so tool call spans are correctly linked to their originating HTTP request.

​

2.49.0 — April 2, 2026 at 4:45 PM UTC

• The buyer campaigns list endpoint now supports an includeMediaBuys query parameter (true/false); when enabled, each campaign in the response will include its associated media buys with products, packages, and delivery data.
• The Creative Assets page filters (Advertiser, Campaign, Creative) have moved into the page header, and the Campaign dropdown no longer requires selecting an advertiser first — you can now search campaigns independently.
• Selecting a campaign in Creative Assets will automatically resolve and set the matching advertiser, improving navigation flow.
• The billing readiness check on the Storefront page is now clickable for admin users, navigating directly to the billing settings page.
• Org settings now support deep-linking to a specific tab via a ?tab= query parameter (e.g. ?tab=billing), and tab changes update the URL accordingly.
• Fixed an issue where media buys were missing from the buyer campaigns list response.
• Fixed an issue where accounts with a restricted billing onboarding status were not shown the onboarding card to complete their Stripe setup.
• Fixed a loading state issue on the billing page where content would not show a skeleton placeholder immediately on load.
• The onboarding card for billing now shows a different message for accounts that have a partially connected Stripe account, prompting them to finish setup.

​

2.48.0 — April 2, 2026 at 2:13 PM UTC

• Storefront readiness status now surfaces partial states and failure details, giving you clearer visibility into why a storefront check did not fully pass.
• Creative assignments are now reliably tracked per product based on format compatibility, ensuring the correct creatives are associated with each product in a media buy.
• Super admins now correctly bypass the alpha opt-in feature flag, giving them full API access without needing explicit flag enrollment.
• Compliance track results now include an optional failureReason field in the API response, explaining why a track failed or only partially passed.

​

2.47.0 — April 1, 2026 at 8:10 PM UTC

• When creating a storefront, the platformId is now automatically generated from the storefront name (e.g. “CVS Media” becomes cvs-media), so you no longer need to provide it manually.
• Campaign creatives are now automatically synchronized to media buys when a campaign is updated, removing the need to manage creative assignments manually.
• Product discovery now uses your storefront’s configured inventory sources first, with a fallback to the broader agent catalog, so buyers see a more curated and relevant set of products.
• Storefront compliance checks now load asynchronously, reducing wait times when accessing storefront readiness information.
• A new endpoint GET /api/v2/buyer/creative-dashboard-url?advertiserId={advertiserId}&campaignId={campaignId} returns a fully-resolved URL for managing creative assets, replacing the previous two-step lookup flow.
• Fixed an issue where the contract page incorrectly displayed “No active contract” even when an active contract existed.
• Fixed the discover products selection bar and recommended plan flow to behave correctly.
• Fixed an issue where switching customers did not redirect to the homepage; role-based route guards are now enforced on navigation.
• The advertiser status filter has been moved to the page header dropdown for easier access.

​

2.46.0 — April 1, 2026 at 1:09 AM UTC

• Non-admin users can now list accessible customers and switch between customer contexts via the MCP customer_list and customer_switch tools, without requiring administrator privileges.
• Media buys can now be canceled or archived directly through the campaign update endpoint (PUT /api/v2/buyer/campaigns/{id}) using the new action field ("cancel" or "delete") in the mediaBuys array.
• The /tools endpoint now enforces Terms of Service acceptance, returning a TOS_ACCEPTANCE_REQUIRED or CONTRACT_REQUIRED error if the organization has not completed onboarding requirements.
• Localhost URLs are now permitted for storefront agent registration when running in a development environment, enabling local agent testing.
• Fixed an issue where account API keys were not displaying correctly and new key creation was failing.
• Fixed a bug where the storefront MCP endpoint was not mounting correctly following a recent rename.
• Fixed an issue where switching organizations from the org settings page did not navigate to the home page as expected.
• Fixed a bug where the admin portal could be incorrectly redirected to a customer-scoped URL.
• Fixed an issue where media buy cache was not invalidated after product budget updates, causing stale data to be returned.
• Fixed a bug where Terms of Service enforcement could be bypassed when switching accounts.
• Fixed format previews not displaying for certain creative types.
• Fixed upstream error details not being forwarded correctly in event logging responses.
• The confirmStandaloneConversion field has been removed from the child account creation request body; standalone conversion now happens automatically.
• The Storefronts section has been renamed to “Storefront” in the UI and now includes an edit dialog.

​

2.45.0 — March 31, 2026 at 3:46 PM UTC

• When a new seller account is created, a default storefront is now automatically provisioned for that account.
• Existing seller accounts with a single active sales agent have been retroactively provisioned with a default storefront.
• When a sales agent is registered, a storefront and inventory source are now automatically created for the seller if one does not already exist.
• Product discovery responses now include empty result groups for sales agents that were successfully queried but returned no matching inventory, making it clear the agent was reached but had no products to offer.
• When a sales agent returns zero products during discovery, the response now includes a message indicating no matching inventory was found and suggests adjusting the brief, budget, or filters.
• Fixed an issue where empty results from a sales agent during product discovery were indistinguishable from a null or failed response.
• Failed sales agent queries are no longer surfaced to end users in discovery summaries; only successful agent results are shown.

​

2.44.0 — March 31, 2026 at 2:19 PM UTC

• OAuth redirect URIs can now be managed dynamically, enabling faster onboarding of new integration partners without requiring a service deployment.
• Access to MCP and API features is now gated behind an alpha opt-in flag, allowing gradual rollout to eligible users.
• The buyer assistant AI has been updated with additional guardrails to reduce inaccurate or fabricated responses.
• Fixed an issue where an empty dropdown in the Creatives section was not labeled clearly and could not be clicked.
• Fixed an issue where the Creatives card was incorrectly visible to seller users on the home page.

​

2.43.1 — March 30, 2026 at 10:19 PM UTC

• The Event Sources API has been streamlined: individual create, get, update, and delete endpoints have been removed in favour of the sync (POST /api/v2/buyer/advertisers/:advertiserId/event-sources/sync) and list (GET /api/v2/buyer/advertisers/:advertiserId/event-sources) endpoints only.
• Fixed an error on the reporting page that caused it to fail to load metrics data correctly.

​

2.43.0 — March 30, 2026 at 9:15 PM UTC

• The Partner API has been renamed to the Storefront API. All endpoints previously under /api/v2/partner/ are now available at /api/v2/storefront/, and requests to the old path will be automatically redirected.
• The MCP endpoint for the Storefront API has moved from /mcp/v2/partner to /mcp/v2/storefront (and /mcp/partner to /mcp/storefront).
• A new GET /api/v2/buyer/advertisers/{advertiserId}/events/summary endpoint is available, returning hourly-aggregated event counts (impressions, clicks, conversions, measurements, and MMP events) for an advertiser. Supports optional filtering by event type and custom date ranges.
• The events summary endpoint defaults to the last completed UTC hour when no date range is specified, and event data may take up to 1 hour to appear after being reported.
• Two new audience notification event types (audience.synced and audience.sync_failed) are now supported and will be delivered via the notifications system.
• All authenticated pages now include the customer ID in their URLs (e.g., /208/reporting), making links shareable across users and customer contexts.

​

2.42.0 — March 30, 2026 at 3:32 PM UTC

• The default UTM parameters applied to advertiser landing page URLs have been updated to better align with GA4 standards: utm_medium is now included with the value agentic, and the creative parameter now uses the standard utm_content key instead of utm_creative.
• Fixed an issue where the Advertisers management table appeared empty even when data was successfully returned by the API.

​

2.41.0 — March 30, 2026 at 3:50 AM UTC

• The Creative Manifest API (v2) is now available, enabling campaign-scoped management of creative assets including HTML processing, format previews, ADCP template detection, and tracking pixel support. Manifests are created and uploaded via the dashboard UI; list, get, update metadata, and delete operations are available via the API.
• Audience sync now delivers a push notification webhook to the buyer upon completion. Provide a pushNotificationConfig (with url, authentication, and token) in the sync request body to receive the callback.
• Storefronts now enforce a readiness gate before going live: setting enabled: true returns a 400 error if required readiness checks are not yet passing. Setting enabled: false is always allowed without restriction.
• Inventory source registration now makes sourceId optional. When omitted, a sourceId is automatically generated from the name field (e.g. "Auto Generated Source" becomes "auto-generated-source").
• The Conversion Events API (/advertisers/{advertiserId}/conversion-events) has been removed. Conversion tracking is now handled via event sources; use GET /advertisers/{advertiserId}/events/summary with type: "conversion" to view available events for optimization.
• Fixed a bug where property list responses contained incorrect data and missing entries. Properties are now sourced from an updated registry for improved accuracy.
• Fixed an issue where per-agent discovery errors were silently swallowed; they are now surfaced in debug output for easier troubleshooting.
• Fixed an issue where the Create Storefront modal opened automatically on page load.

​

2.40.0 — March 27, 2026 at 12:26 AM UTC

• The POST /api/v2/buyer/accounts/create-child endpoint now requires a customerRole field (BUYER or SELLER) when creating a child account.
• Creating a storefront no longer requires a platformId — if omitted, one is automatically generated from the storefront name.
• A new storefront billing page is available, providing Stripe Connect integration for sellers to manage payments, payouts, and balances.
• A new storefront management page is available, showing readiness checks and configuration status for your storefront.
• Discovery card product listings now include biddable pricing indicators and updated fonts and styling.
• The advertiser_id field has been removed from the measurement data request body; it is now taken from the URL path parameter and injected automatically.
• Pricing option data now includes a priceGuidance object with floor, p25, p50, p75, and p90 price percentile fields when available.
• Fixed an issue where media buy requests were not compatible with older publisher versions; the buyer_ref field is now sent in the expected format for all publisher versions.
• Fixed an issue where the customer dropdown was disabled and not properly visible during superadmin impersonation sessions.
• Fixed an issue where the billing page did not prompt users to set up a storefront when none existed.
• The OAuth redirect URI for bayes.fly.dev is now supported.

​

2.39.0 — March 26, 2026 at 1:19 PM UTC

• Added a new POST /api/v2/buyer/advertisers/:advertiserId/log-event endpoint for ingesting conversion and marketing events (purchases, leads, page views, etc.) with support for user matching, custom data, and test event codes.
• Added a new POST /api/v2/buyer/accounts/create-child endpoint allowing admin users to create child accounts under their organization hierarchy, including support for converting standalone accounts.
• The GET /api/v2/buyer/campaigns endpoint now accepts a mediaBuyStatus filter parameter (single value or array) to narrow campaign results by the status of their associated media buys.
• The resolve-account response now includes endpointUrl and authenticationType fields.
• Users with pending invitations are now automatically routed to the correct customer organization during signup, and the email availability check response now surfaces pendingInvitations when applicable.
• Added a POST /api/v2/buyer/campaigns/:id/reactivate endpoint to reactivate a paused or stopped campaign and cascade the update to its associated media buys.
• The property list resolve endpoint has moved from GET /api/v2/buyer/property-lists/:listId/resolve to GET /lists/:listId to align with the expected URL convention used by sales agents.
• Audience webhook payloads now use camelCase field names consistently.
• Fixed an issue where users signing up for an existing domain with a pending invitation could be incorrectly blocked from completing registration.
• Reduced the per-agent discovery timeout from 90 seconds to 30 seconds, resulting in faster error responses when an agent is unreachable.
• The MediaBuyStatus enum now includes CANCELED and INPUT_REQUIRED as valid values across relevant API responses and filters.

​

2.38.0 — March 25, 2026 at 11:36 AM UTC

• Advertisers now support configurable UTM parameters (utmConfig) at creation and update, allowing you to define custom tracking parameters appended to landing page URLs during clickthrough. Defaults (utm_source, utm_medium, utm_campaign, utm_content, utm_media_buy, utm_package) are applied automatically if no config is provided.
• Campaigns now support a utmConfig field to set campaign-level UTM parameter overrides, which take precedence over advertiser-level defaults for matching parameter keys. Use deleteMissing: true for replace mode, or omit it for additive updates.
• Storefront readiness checks now include live agent compliance results, giving you richer diagnostics on agent connectivity and compliance status.
• Discovery product browsing now caches enrichment results (descriptions and relevance summaries) across requests, so repeated browses within the same session return consistent, faster results.
• Fixed an issue where media buy validation errors (such as invalid dates, missing fields, or budget problems) were incorrectly treated as server errors instead of client errors, resulting in cleaner, more actionable error messages.
• Fixed signal tools failing when no seat was selected.
• Fixed an issue where the tracking endpoint used an incorrect authentication key, which could cause measurement sync requests to fail.

​

2.37.1 — March 24, 2026 at 5:48 PM UTC

• The Storefront API endpoints have been simplified: all storefront and billing routes now use /storefront (singular) instead of /storefronts/:platformId, since each customer has exactly one storefront. The platformId path parameter is no longer required for any storefront, billing, or inventory source operations.
• The GET /storefront endpoint now serves as the single way to retrieve your storefront, replacing both the previous GET /storefronts and GET /storefronts/:platformId endpoints.
• Billing endpoints (/storefront/billing, /storefront/billing/connect, /storefront/billing/status, etc.) no longer include platformId in their responses.
• Fixed an issue where users who had already been migrated to the new authentication system would receive an unhelpful error during login; they now correctly receive an “invalid credentials” response instead of being sent through a redundant migration flow.
• Improved the error message shown when account setup fails during login migration — the message now suggests resetting your password and no longer references internal migration processes.
• System tokens now have full administrative access when using the customer_switch tool, resolving an issue where those operations were incorrectly restricted.

​

2.37.0 — March 24, 2026 at 12:28 PM UTC

• Added a new POST /api/v2/buyer/syndicate-audience endpoint that triggers an audience syndication backfill. On success, it returns a 202 Accepted response with an operationId (UUID) that can be used to track the operation.
• Fixed the request body format sent to the audience sync endpoint to use camelCase field names, aligning with standard API conventions.

​

2.36.0 — March 24, 2026 at 8:14 AM UTC

• Added a new suggestion data structure to support optimization recommendations linked to campaigns and media buys.
• Fixed an issue where product selection in the media planning interface could break due to a field naming mismatch, causing pricing options and biddable products to not display or behave correctly.
• Clarified API documentation to distinguish between using the demo flag (to return synthetic demo data) versus filtering reporting results by an advertiser or campaign whose name contains “demo”.
• Fixed incorrect endpoint references in the v2 partner API documentation to match the actual available endpoints.

​

2.35.1 — March 24, 2026 at 1:06 AM UTC

• Reporting CSV exports are now available via the REST API using the ?download=true query parameter on the reporting metrics endpoint; the response includes a downloadUrl, fileName, and an expiration timestamp valid for 7 days.
• Fixed a bug where the offset (and limit) pagination parameters were being ignored when listing advertisers through the API; pagination now correctly respects these values.
• Fixed MCP session errors that could cause requests to fail when a client reconnected or sent requests before completing the initialization handshake.
• Fixed MCP App UI rendering issues related to how widget display domains are resolved for different AI client types.

​

2.35.0 — March 23, 2026 at 3:59 PM UTC

• Storefront billing is now available via Stripe Connect. Partners can provision a connected account, complete onboarding, and view account status, balance transactions, and payouts through new endpoints under /api/v2/partner/storefronts/{platformId}/billing.
• Storefronts now accept an optional publisherDomain field (e.g. "cvs.com") on create and update, used for Stripe Connect business profile setup.
• Notifications now include a status field (success, error, warning, or info) and can be filtered by status when listing.
• Service tokens can no longer be created using another service token — token creation now requires a user context. Requests authenticated with a service token will receive a 400 error if they attempt to mint new tokens.
• Fixed an issue where seat invitations were not visible immediately after login. Invitation processing now completes before the auth response is returned.
• Fixed an issue where seat auto-assignment was not triggered when inviting a new customer member via the v1 invite flow.
• Fixed an OAuth session loop and stuck callback page that could occur during MCP authentication.
• Fixed an issue where MCP session IDs provided in an invalid format were silently accepted, which could cause sessions to fail to persist correctly. Invalid session IDs are now rejected early with a warning.
• Fixed a race condition in SSE connections where heartbeat writes could trigger a headers-already-sent error.
• Fixed MCP request IDs not being consistently propagated across the full session lifecycle, improving log correlation.
• The advertiser list endpoint now returns more results per page, matching what the UI displays.
• ChatGPT plugin OAuth now correctly supports dynamic redirect URIs, resolving authentication failures for ChatGPT-initiated OAuth flows.

​

2.34.1 — March 21, 2026 at 12:52 AM UTC

• Improved reliability of real-time streaming (SSE) connections by reducing the frequency of keepalive signals, preventing unexpected disconnections that some clients were experiencing during MCP sessions.

​

2.34.0 — March 20, 2026 at 11:12 PM UTC

• The List Advertisers endpoint (GET /api/v2/buyer/advertisers) now returns a paginated response with items, total, hasMore, and nextOffset fields instead of a flat array with separate meta.pagination wrapper.
• Pagination parameters for the List Advertisers endpoint have changed from take/skip to limit/offset, with a maximum page size of 10.
• The user management API now supports multi-customer views, returning each user’s memberships across all accessible child customers instead of a single permission level per user.
• Inviting a user to a specific child customer is now supported via the optional targetCustomerId field on the invite endpoint.
• Updating a team member’s role now accepts an optional customerId field, allowing parent account admins to update roles on child customer accounts.
• The measurement data sync endpoint (POST /api/v2/buyer/advertisers/{id}/measurement-data/sync) has updated field names: start_date/end_date are now start_time/end_time, and event_id/event_value are now metric_id/metric_value.
• The measurement data sync endpoint now requires metric_id (from a fixed set of supported metrics), unit (currency, count, ratio, or percentage), and at least one entity identifier (advertiser_id, campaign_id, media_buy_id, package_id, or creative_id). Currency code is required when unit is "currency".
• Fixed an issue where campaigns in terminal states could be incorrectly re-executed; campaign status is now preserved correctly on failure.
• Fixed incorrect data returned by the measurement configuration API.
• The POST /api/v2/buyer/accounts/create-child endpoint has been removed.

​

2.33.0 — March 20, 2026 at 9:06 PM UTC

• The List Advertisers endpoint (GET /api/v2/buyer/advertisers) now returns a paginated response with items, total, hasMore, and nextOffset fields instead of a flat array with separate pagination metadata.
• Pagination parameters for List Advertisers have changed from take/skip to limit/offset, with a maximum page size of 10.
• The Measurement Data Sync endpoint now uses updated field names: start_time/end_time (replacing start_date/end_date), metric_id/metric_value (replacing event_id/event_value), and requires a unit field (currency, count, ratio, percentage). When unit is currency, a 3-letter ISO 4217 currency code is required.
• Measurement Data Sync now accepts additional optional fields: source, source_platform, external_row_id, and advertiser_id. At least one of advertiser_id, campaign_id, media_buy_id, package_id, or creative_id must be provided per measurement object.
• The POST /api/v2/buyer/accounts/create-child endpoint has been removed.
• Fixed an issue where campaign execution could be triggered when a campaign was already in a terminal state; campaign status is now correctly preserved on failure.
• Fixed an issue where completed media buys had an incorrect valid_to value set, which could affect versioning and data accuracy.
• Fixed MCP session authentication so that session state is reliably consistent across server instances, improving stability for multi-turn agentic workflows.
• The User Management tool now supports multi-customer access, allowing parent account admins to view and manage users across their child accounts in a single call.
• Member invitation now accepts a targetCustomerId parameter, allowing parent admins to invite users directly to a specific child customer.
• Updating a member’s role now accepts an optional customerId parameter, allowing parent admins to update roles on child customer memberships directly.

​

2.32.0 — March 20, 2026 at 3:31 PM UTC

• Added a new POST /api/v2/buyer/accounts/create-child endpoint that creates a child account under the authenticated user’s organization. Requires ADMIN role; automatically promotes standalone accounts to parent accounts and grants the requesting user admin access on the new child.
• The customer switcher in the application now includes a “New Account” option for eligible admin users, allowing child account creation directly from the navigation menu.
• The API keys page has been updated with an improved layout, clearer section titles and descriptions, and tabs for switching between personal and organization keys.
• Dialog titles for API key actions have been updated to use consistent casing (e.g. “Edit API key”, “Delete API key”, “API key created successfully”).
• The “Delete API key” confirmation dialog now displays a cleaner confirmation message and uses a more appropriate button style.
• The API key secret dialog now shows a “Copied” confirmation tooltip when the token is copied to clipboard, and displays a clearer security warning message.
• The API keys list now displays up to 50 keys per page, up from 20.
• Fixed a layout issue on the API keys page where the list could overflow the screen; it now sizes to fit its content correctly.

​

2.31.0 — March 20, 2026 at 11:56 AM UTC

• The GET /api/v2/buyer/campaigns/{campaignId} response now includes discoveryId, products, and productCount fields for campaigns in DRAFT status, reflecting the products selected during the discovery workflow. These fields are not present on campaigns that have been executed.
• API requests to v2 REST routes are now blocked with a 403 error if your organization has not accepted the Terms of Service or does not have an active contract. Affected responses will include an error code of TOS_ACCEPTANCE_REQUIRED or CONTRACT_REQUIRED respectively. Account and contract management endpoints remain accessible regardless.
• Fixed an issue where pricing type detection could behave incorrectly in certain v2/v3 pricing scenarios, which may have caused errors when creating or executing campaigns with some pricing configurations.

​

2.30.0 — March 20, 2026 at 8:42 AM UTC

• Added a new POST /campaigns/{campaignId}/auto-select-products endpoint that automatically selects products and allocates budget for performance campaigns using AI-driven scoring, returning selected products, budget context, and a rationale explaining the selection strategy.
• API fields across campaigns, discovery, syndication, and catalog endpoints have been standardized to camelCase (e.g., bid_price → bidPrice, is_fixed → isFixed, resource_type → resourceType, adcp_agent_ids → adcpAgentIds, publisher_domain → publisherDomain). Update any requests and response parsing that reference the old snake_case field names.
• Error responses from API tools now include a recovery field (correctable, transient, or terminal) to help clients determine whether to retry, prompt the user to fix input, or stop. HTTP status codes are also more precise (e.g., 404 for not found, 409 for conflicts, 429 for rate limiting).
• Validation error messages throughout the v2 API are now more descriptive and human-readable, making it easier to identify and correct invalid request payloads.
• Fixed a bug where duplicate products could appear in media buy queries.
• Fixed an issue where campaign update requests could incorrectly send conflicting identifier fields simultaneously, which caused update failures.
• Fixed enforcement of operator authentication requirements during agent authorization flows.

​

2.29.0 — March 19, 2026 at 7:38 PM UTC

• Added a new measurement data endpoint (POST /advertisers/{advertiserId}/measurement-data/sync) for syncing advertiser performance data as time-series events, supporting upsert semantics with up to 1,000 measurements per request.
• Added property list management endpoints (/advertisers/{advertiserId}/property-lists) for curating include/exclude lists of publisher domains that automatically apply to all campaigns under an advertiser.
• Added a domain validation endpoint (POST /property-lists/check) that checks domains against the AAO Community Registry, identifying blocked domains, normalizing URLs, and flagging unknowns.
• Added storefront management endpoints (/partner/storefronts) enabling partners to create and configure storefronts with inventory sources and an agent lifecycle, replacing the previous partner/agent registration flow.
• Added SCD Type 2 versioning for media buys — updating an active media buy now creates a PENDING_APPROVAL version; the original remains active until the publisher approves the change.
• Added a debug parameter to the product discovery endpoints (POST /discovery/discover-products and GET /discovery/{id}/discover-products) that returns detailed per-agent request/response logs when set to true.
• Added support for multiple credential sets per sales agent — customers can now register more than one set of credentials for the same agent, with a credentialId parameter on the account discovery endpoint to specify which credential to use.
• Added multi-account support with endpoints to list accounts (GET /buyer/accounts), get the current account (GET /buyer/accounts/current), and switch between accounts (POST /buyer/accounts/switch).
• The sales agent list endpoint now returns a maximum of 10 results per page and includes a nextOffset field in the response for easier pagination.
• Fixed an issue where child accounts incorrectly required users to accept terms of service when the parent account had already accepted.
• Fixed media buy budget calculations in v1 to correctly sum all products and round spend values.
• Fixed a sync failure that occurred after media buy versioning where associated packages could not be found.
• Removed partner CRUD endpoints (GET/POST/PUT/DELETE /partner/partners) from the v2 API; partner management is now handled through the storefront onboarding flow.

​

2.28.0 — March 18, 2026 at 8:11 PM UTC

• Campaigns now support an optional catalogId field on both create (POST) and update (PUT) requests, allowing you to attach a catalog to a campaign. Pass null to detach an existing catalog.
• The signal keyType enum has been updated: liveramp is renamed to rampid, and three new values are added — uid2, euid, and pairid.
• Parent customer accounts are now restricted from accessing most REST API endpoints directly. Affected requests will receive a 403 PARENT_ACCOUNT_RESTRICTED error. Switch to a child account to regain access.
• When connecting an MCP client, users with an existing valid session are no longer shown a redundant login page — they are redirected directly to the callback, preventing duplicate browser tabs from opening.
• Media buys are now automatically transitioned to COMPLETED status once their end time has passed, keeping campaign and media buy statuses consistent without manual intervention.
• Fixed an issue where switching customer accounts in an MCP session did not correctly update permission checks for the new account’s type.
• Fixed a bug where the MCP connector flow could display multiple OAuth pages during authentication.
• Resolved an issue where signals were being polled for media buys that had already passed their end time.

​

2.27.0 — March 13, 2026 at 9:49 PM UTC

• Added support for partner seats when creating organization-level API keys, allowing users to select both advertiser and partner seats with appropriate type disambiguation
• Enhanced audience sync processing to integrate with real-time syndication services, improving audience delivery performance
• Fixed dependency issues with Google Cloud services to ensure reliable BigQuery and Secret Manager operations

​

2.26.0 — March 13, 2026 at 6:06 PM UTC

• Added multi-currency support in product pricing displays, now showing proper currency symbols (€, £, ¥) based on product currency instead of defaulting to USD
• Added SSO configuration page for admin users to self-service setup single sign-on with their identity providers
• Fixed discovery endpoint performance issues that could cause timeouts during product searches
• Fixed data accuracy issues in V2 reporting by removing duplicate entries that could inflate metrics
• Improved load balancer timeout handling by increasing from 2 minutes to 4 minutes for better reliability
• Enhanced discovery session lookups by removing redundant filters that could slow down searches

​

2.25.0 — March 12, 2026 at 6:04 PM UTC

• Added advertiser name field to query responses for better identification and filtering
• Fixed media buy creation process to ensure proper validation order and prevent errors
• Improved authentication to support additional Google Cloud Platform credential types
• Fixed API response format to remove unnecessary internal fields and ensure consistent parameter forwarding
• Updated service token creation to allow organization-level tokens without requiring individual user assignment
• Improved credential management system with enhanced security and updated terminology
• Increased API timeout limits to reduce connection errors and improve reliability
• Enhanced deployment stability with longer grace periods for service updates

​

2.24.0 — March 12, 2026 at 5:20 PM UTC

• Added advertiser name to ADCP queries for improved query context and results
• Fixed service token creation for organization-level tokens to work without requiring a specific user ID
• Updated API response terminology from “credential registration” to “account linking” for better clarity
• Removed deprecated accountResolution field from API responses to streamline data structure
• Fixed query parameter forwarding for MCP queries to ensure proper request handling
• Increased API timeout limits to prevent request interruptions and improve reliability
• Updated API response format to v2 specification for consistency across endpoints

​

2.23.0 — March 11, 2026 at 8:16 PM UTC

• Added campaign audience targeting functionality to campaigns API - allows targeting and suppressing specific audiences when creating or updating campaigns
• Added timeframe selection controls to reporting metrics - users can now select custom date ranges and preset timeframes (7 days, 14 days, 30 days, all time) when viewing campaign performance data
• Added new suggestion history tracking table to store campaign suggestion status and transitions
• Fixed signal creation tool to make agent ID and access parameters optional for more flexible signal registration
• Fixed issue where certain table formatting was incorrectly triggering interactive UI detection
• Fixed Docker builds by properly scoping gitignore patterns for output directories
• Improved authentication model to enforce stricter security checks across customer boundaries

​

2.22.1 — March 11, 2026 at 1:43 AM UTC

• Temporarily disabled webhook signature verification to resolve compatibility issues with upstream client libraries
• Fixed linkedAccounts field to return an empty array instead of undefined when includeAccounts=true is specified but no accounts exist
• Improved CSV export reliability by using a dedicated storage bucket for report downloads
• Fixed reporting data lookups to use the correct media buy identifiers for more accurate BigQuery results
• Removed creative sets endpoints from the API specification

​

2.22.0 — March 10, 2026 at 11:48 PM UTC

• Added push notification configuration support to the audience sync API endpoint to enable real-time updates when sync operations complete.
• Fixed advertiser list responses to properly return the advertiserId field instead of incorrect field mapping.
• Enhanced observability functions to handle edge cases more gracefully and prevent potential API errors.

​

2.21.0 — March 10, 2026 at 7:02 PM UTC

• Added signal groups for audiences, allowing you to organize and manage multiple signals together for better audience targeting
• Added optimization apply mode setting that controls whether AI model optimizations to media buys are applied automatically or require manual approval - can be set at advertiser level (default for all campaigns) or overridden per campaign
• Fixed text formatting issues in sales agent and advertiser list responses to ensure all account status, credential requirements, and linked account information is properly displayed
• Improved production deployment reliability by fixing Docker build issues that could occur during retry scenarios

​

2.20.0 — March 10, 2026 at 4:56 PM UTC

• Added sandbox field to media buy API responses to indicate when a media buy belongs to a sandbox advertiser
• Moved audience management endpoints from separate “Audiences” tag to “Advertisers” tag in API documentation for better organization
• Fixed button text readability issues in dark mode across the UI
• Added enriched brand preview functionality when creating or editing advertisers with unregistered domains
• Increased API timeout from 30 seconds to 3 minutes for acceptance tests to handle longer-running operations
• Improved production deployment reliability by fixing retry scenario handling

​

2.19.0 — March 10, 2026 at 3:37 AM UTC

• Added comprehensive product detail view showing detailed manifest information including formats, reporting capabilities, optimization goals, setup requirements, and targeting approach
• Added publisher domain filter to product discovery allowing filtering of products by specific publisher domains
• Added audience syndication endpoint to distribute audiences to sales agents with status tracking
• Implemented audience syndication status query endpoint with filtering by resource type, status, agent, and other parameters
• Added product detail endpoint for retrieving full product specifications and manifest data
• Enhanced product descriptions with formatted display showing bold labels for structured information
• Fixed cross-sandbox linking prevention to ensure data isolation between different sandbox environments
• Improved product discovery service integration for more reliable product recommendations
• Enhanced UI formatting for better readability of product information and descriptions

​

2.18.0 — March 9, 2026 at 8:48 PM UTC

• Added pricingModel filter to product discovery endpoints to filter inventory by pricing type (cpm, vcpm, cpc, cpcv, cpv, cpp, flat_rate)
• Added sandbox parameter to advertiser creation for testing campaigns without real spend - all operations for sandbox advertisers use test accounts
• Added sandbox query parameter to advertiser listing to filter by sandbox/production advertisers
• Enhanced product discovery UI to support multiple pricing options per product with interactive price selection
• Fixed OAuth credential storage to prevent cross-customer account linking security issue
• Fixed malformed JSON responses from AI services that could cause discovery failures
• Improved streaming connection reliability for real-time updates with automatic resumption on disconnect
• Fixed budget field conversion issues that could cause campaign creation errors

​

2.17.1 — March 6, 2026 at 9:47 PM UTC

• Renamed bundleId to discoveryId across all API endpoints for better terminology clarity
• Updated /api/v2/buyer/bundles/* endpoints to /api/v2/buyer/discovery/* to reflect the product discovery workflow
• Campaign creation and updates now use discoveryId instead of bundleId to reference product selections
• All API responses now return discoveryId instead of bundleId for consistency
• Updated product selection workflow terminology from “bundle” to “discovery session” throughout the API

​

2.17.0 — March 6, 2026 at 8:03 PM UTC

• Added multi-provider AI service with automatic fallback and circuit breaker protection for improved reliability and faster response times
• Added new notification event types for optimization suggestions (received, approved, rejected, applied, failed)
• Fixed product discovery view to display actual pricing models (CPM, vCPM, CPC, etc.) instead of hardcoded “CPM” labels
• Fixed pricing consistency issues in product recommendations by including pricing options in product data
• Improved bundle descriptions by deprioritizing pricing information to focus on key features
• Enhanced customer domain handling by using database values instead of deriving from email addresses

​

2.16.0 — March 6, 2026 at 6:59 PM UTC

• Multi-provider AI service with automatic failover for improved reliability and reduced downtime when generating content
• Added new optimization suggestion notification event types for campaign optimization workflows
• Fixed pricing model display in product discovery to show actual model (vCPM, CPC, etc.) instead of always showing “CPM”
• Fixed pricing options data consistency in product listings and API responses
• Improved pricing display logic to show appropriate labels based on actual product pricing models
• Enhanced bundle descriptions by reducing emphasis on pricing information for better readability
• Fixed customer domain resolution to use database values instead of deriving from email addresses

​

2.15.0 — March 6, 2026 at 12:46 AM UTC

• New audience management endpoints: sync CRM audiences with hashed identifiers, list stored audiences, and track processing status
• New task status endpoint to poll async operation progress when webhooks aren’t available
• New notification system with endpoints to list, mark as read, and acknowledge notifications about campaigns, agents, and other resources
• New contract information endpoint for platform admins to view contract details
• New user invitation management for admins: approve, reject, resend, or cancel pending invitations
• Enhanced product discovery with AI-generated “why” explanations for recommended media plans
• Bundle management now supports replacing all products instead of just adding new ones
• Bundle apply-proposal endpoint to automatically add products from recommended plans with budget allocations
• Interactive product selection UI improvements with better handling of existing bundle products and confirmation flows
• Added parent-child customer hierarchy support allowing parent account users to access child accounts via header
• Sales agent status transitions now properly enforced - disabled agents cannot be updated
• Fixed campaign budget calculations to exclude archived media buys
• Fixed sales agent manifest resolution during campaign execution
• User access request flow for existing organizations when invitation system is enabled
• Enhanced MCP session management with cross-pod synchronization and better impersonation persistence

​

2.14.0 — March 5, 2026 at 11:15 PM UTC

• Added new audience management endpoints for syncing first-party CRM data with hashed customer identifiers for targeting
• Added notification system with endpoints to list, mark as read, and acknowledge notifications about campaigns, agents, and other resources
• Added task polling endpoints to check status of asynchronous operations like audience syncing and media buy creation
• Added contract information endpoint for admin users to view their organization’s contract details
• Added parent-child customer hierarchy support allowing parent users to access child organization data via header
• Added user invitation system with request access flow for existing organizations
• Added bundle proposal application endpoint to automatically apply recommended media plans with budget allocations
• Enhanced bundle product selection to support replace mode instead of just adding products
• Enhanced product discovery with AI-generated explanations for recommended plan allocations and budget guidance
• Enhanced signup flow to require invitations for joining existing organizations when enabled
• Fixed campaign budget calculations to properly exclude archived media buys
• Fixed media buy retrieval to work without seat filtering restrictions
• Fixed brief updates in product discovery to show current information
• Fixed cross-pod session synchronization to prevent stale data when switching between servers

​

2.13.0 — March 5, 2026 at 4:40 PM UTC

• Added new audience management endpoints for syncing first-party customer data with hashed identifiers
• Added new notification system with endpoints to list, mark as read, and acknowledge system notifications
• Added contract information endpoint for admin users to view agreement details and status
• Added task status endpoint for tracking asynchronous operations like audience syncing
• Added LLM-enhanced recommendation logic that provides detailed rationale for suggested media plans
• Fixed media buy retrieval to work properly without seat-based filtering
• Fixed campaign budget calculations to exclude archived media buys from active budget totals
• Fixed brief updates in product discovery to work more reliably
• Fixed audience data type handling to properly support large seat ID values

​

2.12.0 — March 4, 2026 at 9:41 PM UTC

• Enhanced media buy creation and updates to automatically extend campaign end dates when media buy end times exceed the campaign timeline
• Added start_time and end_time fields to media buy responses, allowing independent scheduling within campaign bounds
• Improved webhook signature validation to return 401 errors instead of 500 errors for authentication failures
• Fixed session state persistence issues that could cause seat selection and customer switching to fail silently
• Enhanced brand agent ID validation in API tools to provide clearer error messages when invalid IDs are provided
• Improved error handling for session state changes to ensure consistency between local and stored state

​

2.11.0 — March 4, 2026 at 7:59 PM UTC

• Added support for media buy-level start and end dates that can be set independently from campaign dates
• Media buy end dates that exceed campaign end dates will now automatically extend the campaign end date
• Enhanced webhook security with HMAC signature verification for improved request authentication
• Fixed webhook signature validation errors that were previously returning HTTP 500 instead of HTTP 401
• Fixed session state persistence issues that could cause seat and customer switches to fail silently
• Improved brand agent ID validation to require numeric values and provide clearer error messages when invalid IDs are used

​

2.10.0 — March 4, 2026 at 1:12 AM UTC

• Added new POST /api/v2/buyer/advertisers/{advertiserId}/event-sources/sync endpoint for bulk syncing event sources with upsert functionality
• Fixed OAuth redirect URI validation to support dynamic query parameters for Microsoft Copilot Studio integrations
• Resolved build warnings in the user interface that could affect page loading performance

​

2.9.0 — March 3, 2026 at 11:14 PM UTC

• Added Microsoft Copilot OAuth support with OpenID Connect discovery endpoint for seamless integration
• Fixed UI v2 flag to automatically grant app access, simplifying feature flag management
• Improved MCP session reconnection reliability by preserving session state across API deployments
• Fixed authentication credential lookup to use the correct database table for improved connection stability

​

2.8.0 — March 3, 2026 at 4:46 PM UTC

• Improved error reporting when media buy submissions fail - you’ll now receive more specific error messages to help diagnose issues
• Streamlined seat management by consolidating description storage, improving performance for advertiser and partner operations
• Fixed automatic installation of pre-archive hooks during workspace setup to ensure proper workflow execution

​

2.7.0 — March 3, 2026 at 5:52 AM UTC

• Catalog sync and listing endpoints moved to new paths: POST /api/v2/buyer/advertisers/{advertiserId}/catalogs/sync and GET /api/v2/buyer/advertisers/{advertiserId}/catalogs (replacing previous /sync_catalogs and /list_catalogs endpoints)
• Account linking now supports soft-delete functionality to preserve historical account assignments for better media buy attribution
• Improved account resolution logic ensures more reliable account identification across different sales agent configurations
• Fixed account assignment workflow to properly handle account reassignment scenarios when advertisers switch to new accounts
• Enhanced catalog sync validation to ensure advertiser ID consistency between URL path and request body
• Improved database query performance and reliability for account-related operations

​

2.6.0 — March 2, 2026 at 10:07 PM UTC

• Added new endpoint POST /api/v2/advertisers/:id/restore to restore archived advertisers (admin users only)
• Added support for filtering advertisers by status with new ALL option to retrieve both active and archived advertisers
• Fixed webhook processing to maintain backward compatibility with legacy systems that don’t include HMAC signature headers

​

2.5.0 — March 2, 2026 at 5:56 PM UTC

• Added new catalog management endpoints for syncing and listing product catalogs via /api/v2/buyer/sync_catalogs and /api/v2/buyer/list_catalogs
• Added comprehensive account linking workflow for advertisers with new endpoints to discover and link partner platform accounts
• Added new /api/v2/buyer/sales-agents/accountCredentials endpoint to list all registered sales agent credentials
• Enhanced advertiser creation and updates to support linking partner accounts at creation time
• Added includeAccounts parameter to advertiser list endpoint to embed linked partner account information
• Fixed JSON response formatting for AI assistants to use proper structured output mode
• Added new url value to signal key types for expanded targeting capabilities
• Enhanced platform monitoring with comprehensive metrics, dashboards, and alerting for better service visibility

​

2.4.0 — February 27, 2026 at 4:23 AM UTC

• Fixed an issue where default channels and country codes were being automatically injected into product discovery requests, ensuring that empty channel and country filters are now respected as intended.

​

2.3.1 — February 27, 2026 at 12:56 AM UTC

• Performance campaigns now support multiple optimization goals with priority ordering, allowing more sophisticated targeting strategies
• Event-based optimization goals now support multiple event sources and improved targeting options including maximize value and threshold rate targets
• Metric-based optimization goals introduced for optimizing seller-native delivery metrics like clicks, views, and engagement
• Fixed issue where production deployment notifications were not properly marked as skipped for staging-only releases
• Fixed version bumping process to correctly include all application components during production releases
• Improved campaign execution workflow to properly handle new optimization goal structure

​

2.3.0 — February 26, 2026 at 9:54 PM UTC

• Added new event source validation that enforces valid IAB ECAPI event types at the database level
• Added organization-level API key management with role-based permissions and advertiser scoping
• Enhanced service token API to support revealing token secrets via includeSecret query parameter
• Improved partner and advertiser management UI with updated styling and navigation
• Fixed changelog display by replacing accordion layout with plain bullet lists for better readability
• Enhanced OAuth token refresh flow with better error tracking and logging for MCP clients
• Improved Stripe billing portal session creation with better customer ID persistence and deduplication
• Fixed product discovery to work correctly even when campaign briefs are not provided
• Enhanced service token creation and management workflows with improved validation and user experience

​

2.2.0 — February 26, 2026 at 2:16 PM UTC

• Added seat-scoped service tokens with full CRUD support via the V2 REST API
• Added ability to bypass Terms of Service acceptance for customers with custom contracts
• Fixed service token creation to make the name field optional with a sensible default
• Fixed brand agent listing to correctly filter by customer for SuperAdmin users

​

2.1.5 — February 25, 2026 at 1:18 PM UTC

• Fixed request timeout handling for AI model requests to prevent hanging operations and improve response reliability.
• Resolved an issue where certain aborted AI generation requests would unnecessarily retry, reducing API latency.
• Updated AI model version for more consistent response quality and performance.

​

2.1.4 — February 25, 2026 at 3:58 AM UTC

• Internal improvements and maintenance

​

2.1.3 — February 25, 2026 at 1:30 AM UTC

• Improved compatibility with partner integrations by retrying failed requests using an alternative brand identification format
• Improved error detection to correctly identify and handle validation failures during brand identification

​

2.1.2 — February 24, 2026 at 8:13 PM UTC

• Improved product discovery reliability with automatic fallback when brand identification fails
• Fixed documentation site routing to correctly serve versioned API docs
• Updated advertiser form field naming for consistency
• Updated homepage copy and messaging

​

2.1.1 — February 24, 2026 at 3:00 AM UTC

• Fixed documentation homepage returning 401 errors and broken routing for v2 API docs

​

2.1.0 — February 23, 2026 at 11:10 PM UTC

• Added reporting page with hierarchical metrics table for campaign performance visualization
• Fixed budget currency handling to use the actual currency from product pricing options instead of defaulting to USD
• Fixed creative format assignment to ensure each product only receives creatives that match its supported formats
• Added stable versioned documentation URLs with dark mode branding
• Improved metrics grid layout for better responsiveness across different screen sizes