Following feedback from our merchants, we are relaxing our contact policy website requirements for merchants. Currently we require merchants to publicly display on their website at least two methods of contact information (such as an email, business address, or phone number).

To give merchants more flexibility in the information they share with customers, beginning August 2, 2021, we will require merchants to provide on their website a minimum of one form of customer-facing contact information, for example:

• A “contact us” form
• A link to a social media business profile
• An email address
• A phone number

In addition to this change, all new merchants will be required to provide their business address and phone number on creation of their Merchant Center account, as well as for any existing accounts that require a review. This private contact information can be entered manually in the Merchant Center user interface or via Content API for Shopping.

To update the private contact information using Content API for Shopping, provide both the address and phoneNumber fields via the AccountBusinessInformation object (nested under the Account object) using the following methods:

• Accounts.update (Existing Merchant Center accounts)
• Accounts.insert (New Merchant Center accounts)

Important: Take care when updating existing accounts. Any fields that are not provided to Accounts.update will be deleted from the resource.

Note: If you have made contact information changes to an existing Merchant Center account that has an account-level disapproval, you may need to request an account re-review. See the following article on Understanding account-level enforcement for product data quality violations to find the steps to make the request.
If you require further support implementing this change, please visit the Content API for Shopping forum.
Ian Ballantyne, Content API for Shopping Team

What’s changing?

The Content API for Shopping will gradually roll out improvements to request validation from January 1, 2021 to February 15, 2021. These changes will be applied to a growing percentage of requests during that time, reaching 100% by February 15, 2021. The validation improvements will ensure that certain requests that are not in the proper format result in an error instead of having the Content API attempt to infer the request's intent. As long as you are submitting the proper type and structure for each field, you will not be affected by this change.

The following sections describe two examples of incorrectly formatted requests that may fail after January 1st, 2021. If your requests start to fail after January 1st, 2021, please refer to the error message returned and correct the formatting issue.

Example: Providing an invalid structure for a repeated field

This error applies to providing any invalid type for a repeated field, such as providing a list of objects instead of a list of strings, or vice versa.

Example invalid v2.1 request

The following request is invalid because the includedDestinations field requires a list of strings, not a list of objects:

{
  "targetCountry": "US",
  "offerId": "123",
  "contentLanguage": "en",
  "channel": "online",
  "includedDestinations": [{"destinationName": "Shopping", "intention": "default"}]
}

Example valid v2.1 request

To correct this issue, change the list of objects to a list of strings:

{
  "targetCountry": "US",
  "offerId": "123",
  "contentLanguage": "en",
  "channel": "online",
  "includedDestinations": ["Shopping", "SurfacesAcrossGoogle"]
}

Other common fields affected by this change

• v2.1:
  • product.excluded_destinations (a common mistake is providing the v2 format of this field for requests to v2.1)
• v2:
  • product.destinations (a common mistake is providing the v2.1 format of this field for requests to v2)
  • product.sizes
  • product.additional_image_links
  • product.shipping

Example: Submitting a string that represents a float instead of an integer

This error applies to providing a string containing a floating point number when an integer is required.

Example invalid v2.1 request

The following request is invalid because the sellOnGoogleQuantity requires a string in int64 format, but the string “100.0” is a float:

{
  "targetCountry": "US",
  "offerId": "123",
  "contentLanguage": "en",
  "channel": "online",
  "sellOnGoogleQuantity": "100.0"
}

Example valid v2.1 request

To correct this issue, change the value to an integer:

{
  "targetCountry": "US",
  "offerId": "123",
  "contentLanguage": "en",
  "channel": "online",
  "sellOnGoogleQuantity": "100"
}

Other common fields affected by this change

• v2.1:
  • product.unit_pricing_base_measure.value
• v2:
  • inventory.sell_on_google_quantity
  • product.unit_pricing_base_measure.value

What do I do?

We recommend that you address any incorrectly formatted requests before January 1st, 2021 to avoid any disruptions to your application.

If you are already submitting the proper type for each field as described in the Content API for Shopping reference docs, no action is required.

Need More Help?

If you have any questions or need assistance, please reach out to us on the forum.

 Benji Rothman, Content API for Shopping Team