Copilot shopping feed management: what Microsoft actually reads

Shopping in Copilot is two separate jobs, not one. The first decides whether your product can be found at all, and it runs on a feed in Microsoft Merchant Center. The second decides whether it can be bought without leaving the assistant, and it runs on a transaction layer with a payment provider. Microsoft frames it in exactly that split: feeds enable discovery, the transaction protocol enables the purchase.

This article covers what a European seller can do today, which fields are genuinely required, where the traps sit that the interface never shows, and how to build the feed so that it does not need weekly attention. All of it checked in Microsoft documentation on 30 October 2026.

Who can sell in Copilot today, and who can only be visible

Here is the sentence that saves a week of work. Copilot Checkout, meaning completing the purchase inside Copilot, is a pilot for selected customers and carries a limit Microsoft states plainly: only English-language merchants selling to US buyers in USD are eligible at this time. The merchant remains the merchant of record.

The other half, discovery, reaches much further. Microsoft Shopping campaigns are available across a long list of countries that includes Poland, and in the Content API documentation Polish appears among content languages with PL among target countries.

One detail deserves checking before anyone forecasts revenue. The currency list on the price object in the Content API documentation does not include PLN, although it does include the euro, sterling, the Swedish krona and the dollar. We draw no product conclusion from that, because documentation and interface can disagree, but the currency for your market has to be confirmed on your own account before a build.

Required fields: a list that surprises twice

The Content API documentation carries a “required for insert” column and it pays to read it literally, because several entries are not obvious.

The first surprise is the requirement that price match the product page. It sounds obvious until someone runs hourly promotions in the store while the feed goes out once a day. At that point the price mismatch is a design choice rather than a bug.

The second surprise is the shipping trio. They sit in the required column, yet the footnote limits that requirement to the German market. Read the column alone and you will model shipping weights across Europe to satisfy one country.

Why offerId cannot change afterwards

A product ID in Merchant Center is a composite of four things: channel, content language, target country and your offerId. In the documentation it looks like Online:en:US:Sku123. All four parts are immutable once the product exists, precisely because the ID is built from them.

That settles a decision usually made in five minutes and lived with for years: what your offerId derives from. Derive it from a SKU that changes when a supplier or a pack size changes, and every such change becomes a new product with no history. Derive it from an internal identifier nobody ever rewrites, and the problem never appears.

There is no graceful fix after the fact. Changing the offerId convention is a catalogue migration.

The thirty-day trap, or how a catalogue goes quiet

This is the passage that costs the most in practice and reads the fastest. A product for which you supply no expiration date expires 30 days after it was added or last updated. A pause in your sync is therefore enough for the catalogue to vanish in batches, in the order things were added.

The second half of the same puzzle: a deletion can take up to 12 hours to stop delivering, and the documentation recommends setting availability to out of stock first and deleting afterwards. Do it in the other order and for half a day Copilot and search may show a product nobody can buy.

New in the feed: the AI content declaration

The documentation now carries an attribute that did not exist a year ago: a declaration of whether an offer contains AI-generated or AI-modified content. In a text feed it is advertiser_ai_label, in the Content API advertiserAILabel, and it takes three values: AI content with a request for a visible watermark, AI content without that request, or a declaration of no AI content.

Microsoft describes it as an advertiser declaration rather than the output of detection. Processing requires a store pilot to be enabled, and an unrecognised value ends in a validation warning with the field cleared.

For a store that generates descriptions with a model, that is a new step in the process rather than a technical detail. Decide once what you declare, write it into the rule that generates descriptions, and keep it out of manual editing at export time. If your copy comes from a model, see how we structure that in our piece on multi-language catalogues.

Where these builds break

Across our channel feed work the same four problems come back, whatever the store platform.

• A one-off import instead of a pulse. Someone sends the catalogue once, confirms the products are visible, and returns a quarter later to find the items expired.
• A price from a different moment than the page. Promotions calculated live in the store, a feed shipped overnight. The price-match requirement is then broken daily at nine in the morning.
• Testing in production. The documentation offers a dry-run parameter precisely so a request can be checked without touching data. Few teams use it until they have wiped a catalogue.
• No limits in the code. A batch request takes up to 12,000 items and up to 4 MB, so chunking is part of the integration rather than an option.

How to build it so it needs no nursing

The architecture is the one we described for Kaufland feed integration, and that is no accident: channels differ in field names rather than in mechanics.

• One source of truth per product. A catalogue feeding every channel, with required fields enforced on the way in.
• The channel schema in code. Microsoft field mapping, character limits and the offerId rule described once, with a test.
• Two cadences. A full sync daily, price and availability more often. Refreshing is also what protects you from the 30-day expiry.
• Validation and dry-run before production. Missing identifiers, over-long titles and mismatched prices surface on your side rather than in editorial review.

We deliver that scope as feed automation, and as channel expansion when a new channel goes live. If you want to know whether your catalogue clears Microsoft requirements without rewriting descriptions by hand, write to us and let us look at your product data together.

And a caveat that matters more here than usual. Shopping inside assistants changes month to month, pilots open and close, and nobody outside Microsoft knows when Copilot Checkout will reach Europe. So this article carries no date the documentation does not state, and no promise of traffic. Check the current version at source before you build.