Software development using Content API and dummy store

Content API does not provide a separate sandbox environment. Testing must be done in production, but there are supported ways to do this safely without impacting live ads.

Key points and options:

1. Requirement for a real Merchant Center store
   • To use Content API, a Microsoft Merchant Center (MMC) store must be created and approved.
   • The store must meet all standard requirements (verified and claimed domain, valid privacy policy, SSL checkout, supported markets, etc.). Stores that look like “dummy” or non-real commerce sites are likely to be rejected for policy reasons.
   • A store will be denied if there is already a store registered for the same domain or within the same account, or if policy requirements (privacy policy, SSL, etc.) are not met.
2. Testing Content API without changing live data
   • For the Product and Inventory resources, the dry-run query parameter can be used to test requests:
     • Example pattern: https://content.api.bingads.microsoft.com/shopping/v9.1/bmc/{bmcMerchantId}/products/{itemUniqueId}?dry-run
     • With dry-run, the service validates the request and returns validation errors but does not store data or affect the live feed.
     • Limitations:
       • Insert operations do not return IDs.
       • Secondary error messages (data quality, editorial, database validations) are not generated.
   • dry-run is not supported for the Catalogs resource.
3. Using the Store resource (closed beta)
   • There is a Store resource for managing stores via API, but it is available only to closed-beta participants and subject to change.
   • It supports a dry-run query parameter as well, which allows testing add-store calls without creating actual stores.
   • Participation requires coordination with an account manager.
4. Constraints on multiple or “dummy” stores
   • Policy does not allow duplicate named or owned stores to be active simultaneously, and a store is denied if a store is already registered for the domain or account.
   • Multiple stores are allowed only when they represent distinct offerings (for example, separate category stores) and still comply with all policies.
   • Domains cannot be changed after store creation, so the domain used for testing must be a compliant, verified domain.
5. Practical guidance for integration tools
   • For an integration tool intended for other advertisers, the typical pattern is:
     • Use a fully compliant demo or staging site that meets all Merchant Center requirements (real-looking catalog, valid privacy policy, SSL checkout, supported markets).
     • Get that store approved and then use dry-run for most development and validation.
     • Use real write operations only when necessary, understanding they will modify the store’s catalog.
   • If a demo store was rejected, review the documented rejection reasons (privacy policy, SSL, supported markets, domain verification, duplicate store) and adjust the demo site and store configuration accordingly, then request a review.

References:

• Create a Microsoft Merchant Center store
• Get Started with the Content API
• Testing your Code in Sandbox
• Store Resource
• Microsoft Advertising Sandbox