Build on the backend
we run for you

You can now enter your own forecast corrections, such as a month's sales, ad spend or budget, with the new corrections:write scope. Corrections are saved under your name in the same place the forecasting app reads, so a correction made in one place shows up in the other. Interactive sign-ins have the scope by default, and a tenant admin can grant it to a service credential.

The forecast baseline request, FCT-BASELINE-01, now answers for merchants with enough sales history even when no forecast has been published for them. MixShift computes a revenue baseline from your warehouse data with the same engine the forecasting app uses and labels it as computed. A published forecast always takes priority, and the request still says plainly when there is not enough history.

Two more Forecasting requests join the readiness check from September 18, and both read the forecast the MixShift forecasting app publishes, with its users' corrections applied. The baseline returns the model, its monthly expectations and 95% ranges, the measured backtest, and what the forecast was trained on, for a merchant or one of its sub-brands, in revenue or units. The report-month tracker returns the forecast figures for a single month in the shape the monthly report reads: the year to date, what the model forecast before the month closed, what the current model projects for it, and the months still to come. Each says how old the published copy is, and when no forecast is published, or it was withdrawn or is below the history floor, the answer says so instead of guessing. Both run on the same Intelligence catalog, access, and metering as every other request, and Intelligence is open to every account by default.

Create, list, read, fix, and delete Amazon Marketing Cloud audiences through the platform, activated on a DSP advertiser or a sponsored-ads account. Audiences are the write side of AMC, so they need Ads write access and follow the same preview-then-commit pattern as every other change: a create previews first, and checks refuse what Amazon would only reject after a run, such as a refresh outside the allowed range, date arithmetic the clean room does not accept, or a query that reads a paid dataset the instance does not have. Only a failed audience can be fixed or deleted; one that succeeded is final.

Read a seller's own promotions live: deals, coupons, price discounts, and basket-building offers. Search them by status, type, product, or date, open one for its schedule, budget, discount, and any problems Amazon has flagged, and page through the products it covers. Read-only, and for seller accounts only; it runs on the authorization your seller accounts already granted MixShift.

Connecting MixShift from claude.ai, Claude Desktop, or ChatGPT now gives the connector the same access as signing in to the MixShift plugin: both are your own login reaching your own account. On top of the warehouse and live Amazon reads, a connector can now read brand context and the brand change log, add to the change log, retire or restore a brand, run MixShift Intelligence requests, and make Ads and listing changes. The consent screen names the changes it can make before you approve. The safety rails are the same as in the plugin: Ads writes default to a dry-run preview and are audit-logged, and a listing change previews first and commits only the exact change set you approved. A connector added before this change keeps the read-only access it was approved with; remove it and add it again to get the full set. Service credentials and partner apps still hold only the scopes granted to them.