Bing Ads Integration

Connecting your catalog to Microsoft Merchant Center puts your products in front of shoppers on the Microsoft Search Network — a pool of search demand that doesn't fully overlap with Google's. For most advertisers that means incremental reach, and often a lower cost-per-click than Google Shopping, without building a second catalog from nothing.

Microsoft's Content API guide lists Shopping campaigns and product ads as supported across a large set of markets — from the United States, Canada, and the United Kingdom to smaller markets such as Malta, Mauritius, Cyprus, and Fiji — with an additional set of countries available to pilot customers. That breadth means a single, well-structured feed can extend a Shopping presence into markets you may not have prioritized on Google.

Because Microsoft's Product schema was deliberately built to be interoperable with Google's, most of the same product data — title, price, images, GTIN, brand, MPN — required for a Google Merchant Center feed also drives your Microsoft Merchant Center listings, which keeps incremental setup effort relatively low.

Microsoft's Content API documentation is unusually candid about where its schema borrows from Google's — and where it quietly diverges. A number of fields in the Product object exist purely "for Google compatibility": Microsoft's API will accept additionalImageLinks, adwordsGrouping, adwordsLabels, destinations, and taxes, but its own documentation states plainly that Microsoft Merchant Center does not use these fields at all. If you're reusing a Google-formatted feed, these fields simply pass through harmlessly rather than doing anything on the Microsoft side.

Microsoft also documents a feature Google Shopping doesn't have in the same form: Shopping Campaigns for Brands. In this co-op model, a manufacturer uploads a product list containing only Brand, GTIN, and MPN, links it to a retail partner's Microsoft Merchant Center store, and both parties can then bid on the shared list of matched products — splitting the cost of clicks. Microsoft's documentation notes this is currently limited to the United States and United Kingdom and is under open beta for pilot customers.

One more practical divergence: Microsoft explicitly rejects adult products outright ("adult products are not supported and will be rejected"), and it maintains its own identifier-validation logic (see the required-attributes section below) that runs independently of whatever validation your feed already passed for Google.

Microsoft Merchant Center accepts your catalog in two broad ways, per its official documentation:

1. A flat feed file uploaded to your store or catalog, submitted on a recurring schedule via FTP/SFTP.
2. The Content API — a RESTful, JSON-based API documented at content.api.bingads.microsoft.com/shopping/v9.1/bmc/ — for inserting, updating, retrieving, and deleting individual products or processing them in bulk via the /products/batch endpoint.

The Content API's batch endpoint documents concrete limits worth planning around: a single batch request can include up to 12,000 items, but the total request body can't exceed 4 MB, so Microsoft's own guidance is that you can typically fit 2,000–6,000 uncompressed offers per batch (up to the full 12,000 if you gzip-compress the payload with the Content-Encoding: gzip header). List requests are paginated at a maximum of 250 products per call using max-results and start-token.

Products live inside a Microsoft Merchant Center store, and a store can optionally contain multiple catalogs (specified with the bmc-catalog-id parameter on insert). Every offer you submit needs an expiration horizon: Microsoft's documentation confirms that unless you set an explicit expirationDate, an offer automatically expires 30 days after it was written to the store.

Microsoft's Content API reference is explicit about which fields are mandatory to insert an offer, and which become mandatory conditionally. Per the official Products resource documentation:

Feedance builds the Microsoft Merchant Center feed directly from the product data you already manage in your store or PIM — no manual spreadsheet exports. The mapping engine assigns your source fields to Microsoft's schema, including the composite-ID fields (channel, contentLanguage, targetCountry, offerId) that Microsoft locks after first submission, so getting them right up front matters.

1. Connect your store or data source (ecommerce platform, PIM, or existing product export) to Feedance.
2. Map your fields to Microsoft's required and conditional attributes — Feedance flags missing identifiers and applies identifierExists: false automatically when brand, GTIN, or MPN genuinely aren't available, so you don't collect avoidable warnings.
3. Generate the feed in the structure Microsoft's Content API and store ingestion expect, and deliver it via scheduled feed upload or direct API submission to your Microsoft Merchant Center store ID.
4. Feedance monitors the resulting product statuses — Approved, Warning, Disapproved, pending, and expiring — so you can see and fix itemLevelIssues without logging into the Microsoft Advertising web app for every check.

Because your existing Google Merchant Center mapping already covers most of the same attributes Microsoft requires, connecting a second destination through Feedance is typically a matter of attribute review, not a rebuild.

Microsoft's own documentation sets a hard backstop: unless you explicitly set an expirationDate, every offer automatically expires 30 days after it was last written to the store — at which point it stops being eligible to serve. Simply re-submitting the product (even without changing any fields) resets that 30-day clock, but only if you haven't manually set an explicit expiration date yourself.

In practice, that 30-day expiration is a ceiling, not a target. Since price and availability must match what's on your live product page — Microsoft explicitly validates that the feed price matches the product's webpage — any catalog with regular price changes, stock-outs, or promotions should refresh far more often than once a month. A cadence of at least daily keeps availability and pricing accurate and avoids the silent gap between when a product sells out and when your feed catches up.

Microsoft's Content API returns concrete, documented status codes for problem offers rather than vague rejections. Two real examples straight from Microsoft's own product-offer-statuses reference:

1. GtinPlusBrandRequiredWarn — "Missing one or more identifiers - The Brand and GTIN or Brand and MPN are required." This is a warning, not an outright rejection: Microsoft's servability field marks it "Unaffected," meaning the offer still serves, but you should fix it — either supply the real identifiers or set identifierExists to false if none exist.
2. EVRejectedErr paired with a specific reason code such as EV_39 ("Trademark content") — this one is a hard disapproval; Microsoft's documentation shows the offer's status field set to "Disapproved" and servability set to "Disapproved," meaning the product will not serve until the flagged content is corrected.

Beyond individual item issues, Microsoft's documentation confirms that after passing basic validation, every offer goes through additional "offline validations and reviews, such as editorial reviews, that can take up to 36 hours" before it's eligible to serve — so a newly submitted or newly updated offer sitting in "pending" status for a day is expected behavior, not a bug. A store-level summary view (reachable via the ProductStatuses resource) reports counts across approved, disapproved, expiring, and pending, which is the fastest way to see catalog health at a glance.

1. Supply all three identifiers when they exist. Microsoft's documentation is explicit that if a manufacturer has assigned a GTIN, brand, or MPN, you must include it — omitting a known identifier produces the GtinPlusBrandRequiredWarn warning even though the offer still serves. If none genuinely apply, set identifierExists to false rather than leaving the fields blank.
2. Group variants with itemGroupId. For a product sold in multiple colors, sizes, or patterns, Microsoft's documentation recommends creating one offer per variant and linking them with a shared itemGroupId rather than trying to cram every option into a single offer.
3. Use customLabel0–customLabel4 for campaign segmentation. These five fields exist specifically so you can filter and bid on subsets of your catalog inside Microsoft Shopping campaigns.
4. Keep titles and descriptions promotion-free. Both fields explicitly "may not include promotional text" and both undergo editorial review — sale language baked into the title risks disapproval rather than driving clicks.
5. Track expiration proactively. Because offers silently expire 30 days after their last update unless you set your own expirationDate, feeds for slow-moving catalogs still need a refresh cadence, even if none of the underlying product data has changed.
6. Fill in shipping for German listings. Microsoft's documentation flags shipping, shipping label, and shipping weight as required specifically for a targetCountry of DE — a rule that's easy to miss if your primary market is elsewhere.

Is "Bing Ads" still a real product name? No — Microsoft rebranded Bing Ads to Microsoft Advertising in 2019. "Bing Merchant Center" is now Microsoft Merchant Center. The underlying platform and Shopping campaign mechanics are unchanged; only the name is.

Can I reuse my Google Merchant Center feed for Microsoft? Largely yes. Microsoft's Product schema mirrors many Google Merchant Center field names, and several Google-oriented fields (destinations, taxes, adwordsGrouping, adwordsLabels, additionalImageLinks) are accepted purely for compatibility even though Microsoft's documentation confirms it doesn't use them. You'll still want to review Microsoft-specific required fields like channel and conditional rules like Germany's shipping requirement.

Is a GTIN mandatory for every product? Only if the manufacturer assigned one. Microsoft's documentation requires gtin, brand, and mpn when they exist; if they genuinely don't, set identifierExists to false instead of leaving them blank.

What happens if I stop updating my feed? Per Microsoft's documentation, each offer expires automatically 30 days after its last update (unless you've set your own expirationDate), and an expired offer stops being eligible to serve.

How long does review take after I submit or update a product? Microsoft's documentation states that after basic validation, offers go through additional offline reviews, including editorial review, that "can take up to 36 hours" before the offer is eligible to serve.

Can I submit my feed via FTP instead of an API? Yes — Microsoft Merchant Center supports recurring feed file submission in addition to the JSON-based Content API, so teams without development resources can still automate delivery.