Build on the backend
we run for you

Put short tags such as brand, competitor or do-not-touch on advertising entities so you can find them again, filter by them, act on them in bulk, and key automation off them. Tags belong to your account, not to one app: the MixShift bid engine, the plugin, your own agent and the API read and write the same tags. Apply or remove tags on up to 2,000 entities in one atomic change, archive a tag without losing its assignments, and undo any change from its log. Reads need ads:read and changes also need context:write; tags never change anything on Amazon.

Failed calls to Amazon now carry source (fix your request, the account owner acts, Amazon declined this request, Amazon is briefly unavailable, or ours to fix), retryable (whether re-sending the same call can ever succeed), the verbatim words from Amazon when Amazon said no, and, where there is one, a concrete fix. Requests we reject before they reach Amazon, such as an unknown operation id or a malformed body, now return 400 invalid_request instead of 500 unknown, and MCP tool results that failed are flagged as errors. Branch on kind and retryable, not on HTTP status.

The newer Fulfillment Inbound API (version 2024-03-20) is now in the catalog, read-only: list inbound plans, then for each shipment read its carrier tracking (a tracking id per box for small parcel, the PRO and bill of lading for freight), its items, its boxes with the case-pack template they were packed with, pallets, the carrier, and the placement fees. It replaces the transport-details call Amazon removed in January 2025, and it runs on the authorization your seller accounts already granted MixShift.

When the daily sales and inventory history behind lost sales cannot be read for a run, because it took too long or is too large to read in one run, an Intelligence request that includes lost sales still completes. Lost sales is left out of the whole run, never priced as zero for one period, and the result's limitations say so in one plain sentence, so every other figure still arrives. A run cut short by time is not saved, so retrying later may bring lost sales back; a size verdict is saved, so retrying will not.

When one seller account carries several brands, define a sub-brand once by the product and campaign labels that select it, then ask the readiness check and the forecast baseline about that brand alone. Its forecast, corrections and budget are kept apart from the account's own. Sub-brand definitions are listed and created through the forecasting scopes endpoint, under a person's own corrections:write scope.

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.