Google Ads Developer Blog

Content API for Shopping live webinar on May 31st (Mandarin, Chinese)

2019-05-30T09:30:00.004-07:00

We are running a live webinar this Friday, May 31, on the Content API for Shopping. This webinar is for our Chinese-speaking developers that are interested in using the API to manage products and Shopping ads at scale.

The webinar will cover topics on:

Content API for Shopping use case
Merchant Center setup
Content API features
Best practices
API request/response demo

You will be able to submit questions throughout the live event. We will answer questions during the Q&A session in the webinar.

Note: The webinar content will be delivered in Mandarin, Chinese.

The webinar will begin at 10:00am (China Time, GMT +8) on Friday, May 31, 2019.

Join @ https://www.youtube.com/watch?v=aQ7qzgfTIbo

Please contact us via the Content API forum if you have any questions or need help.

If you’d like to review some of our previous webinars covering the Google Ads API, you can find them at the following links:

Fei Xiang, Google Ads API Team

Announcing v2.1 of the Content API for Shopping

2019-03-25T12:00:00.000-07:00

Updated (Feb 27, 2020): Updated timing of v2 support.
Today we're announcing the release of v2.1 of the Content API for Shopping. This version has been available as an experimental version since late last year and is now ready for production use by all Content API users.

Highlights
You can find a complete list of changes in the release notes and accompanying migration guide, but here are some highlights:

A more consistent product validation experience. Product insert requests no longer report non-fatal warnings or errors. This allows you to insert products and make subsequent updates to resolve issues via feed rules in the Merchant Center UI, just as you would with feeds maintained outside the API.
A better experience for managing Shopping Actions. Multiple improvements have been made to the Orders API based on feedback from beta users.
More features are on the way! Today's release contains many improvements, but more are on the way, including new ways to supply local inventory data and features to support supplemental feeds.
Continued v2 support. While we strongly encourage you to migrate to v2.1, support for v2 will continue at least through the third quarter of 2020. Subscribe to this blog to ensure you receive important updates on Content API releases and deprecations.

Updated client libraries
Updated client libraries with support for v2.1 are now available in multiple languages.

Learn more
Check out the v2.1 API reference documentation to explore the new version of the API, and read through the list of behavior changes and deprecations in the migration guide to help plan your upgrade to v2.1.

If you have any questions or need help with migration, please head over to our support forum.
- Josh Radcliff, Content API for Shopping Team

Subscribe to our RSS feed to get blog posts via email

2019-02-08T09:31:00.000-08:00

(If you want to continue getting email updates about our blog posts, read on. If you don't want email updates from this blog, you can skip this post.)

For some products, the Google Ads Developer team has used Google groups as a way to allow API users to subscribe and get new relevant blog posts delivered to their email address. Starting now, the way you can get email updates about blog posts is changing. We will no longer send an email to the Google group for each new blog post. We will continue to use the Google groups for other important updates, however.

For users who still want email updates, we've introduced new FeedBurner links on the right-hand panel of our blog homepage. You can subscribe to the RSS feed by clicking on the link for the product you're interested in, or subscribe by email by clicking on the [+] link to the right of the product name.

If you use any of the APIs that we discuss on this blog, make sure you subscribe to the feed to keep up with the latest news and updates:

- Mike Cloonan, Ads Developer Relations Team

Sunset of XML support in the Content API for Shopping

2019-02-05T11:01:00.000-08:00

What's changing?
Starting September 1, 2019, the Content API for Shopping will no longer support requests or responses with XML payloads. All requests with an XML payload will fail after the sunset date.

Why is this change happening?
Version 2 of the Content API for Shopping changed the default request and response format from XML to JSON, and version 2.1 of the API (currently marked experimental) will not support XML. The majority of API requests now use JSON, so we've decided to sunset XML support and instead focus on enriching our JSON APIs with new features and functionality.

What should you do?
Prior to the sunset date, identify the components of your application that are using XML payloads for any of the following impacted services:

For each case, modify your application to:

Send the request body as JSON.
Ensure you have removed the alt=xml parameter from the request.
Process the response as JSON.
Test your updated application using a separate test account.

Tip: The client libraries for .NET, Dart, Go, Java, JavaScript, Node.js, Objective-C, PHP, Python, and Ruby will send JSON requests and parse JSON responses for you. We strongly recommend that you use one of the libraries so you won't have to write marshalling and unmarshalling code in your application.

When converting a given request, you can use the JSON and XML tabs in the Request body section of the documentation for the method. For example, here's a partial screenshot of the XML tab for Inventory.set:

The corresponding JSON tab for that method is:

Compare the two tabs and use that as a guide when converting your request from XML to JSON.

You can find similar JSON and XML information for the response in one of the following locations:

Directly in the Response section for the method.
Example: The productsCustomBatchResponse for Products.custombatch.
In the Resource representations section of the documentation for the resource returned in the response.
Example: The products resource for Products.insert.

If you have any questions or feedback about this change, or any other questions about the Content API for Shopping, please let us know on the forum.
- Josh Radcliff, Content API for Shopping Team

Update on issue reporting changes in the Content API for Shopping

2019-02-04T09:33:00.000-08:00

In August, 2018, we announced that we would stop populating the dataQualityIssues field in Productstatus and Accountstatus resources in December of last year. Due to the recent holiday season, we decided to hold off on that change, but it will now be made starting February 25, 2019.

Please review the previous blog post for important details, including how to use the new and improved itemLevelIssues field in your platform's integration with the Content API for Shopping.

If you have any questions or feedback about this change, or any other questions about the Content API for Shopping, please let us know on the forum.
- Josh Radcliff, Content API for Shopping Team

More changes to issue reporting in the Content API for Shopping

2018-08-23T09:54:00.000-07:00

Update: The date for this change has moved to February 25, 2019.
What's changed?
There are three major changes being announced in this post:

Accountstatuses now returns aggregated product statistics.
Accountstatuses now includes the new format for product-level issues.
itemLevelIssues objects now contain human-readable descriptions.

Aggregated product statistics in Accountstatuses
The number of products in a given account can now be retrieved directly from Accountstatuses. Like the Merchant Center, you can retrieve the following aggregated statistics: active products, expiring products, disapproved products, and pending products. These statistics are given separately for each combination of destination, channel, and target country. For example:


"products": [{
  "country": "US",
  "destination": "Shopping",
  "channel": "online",
  "statistics": {
    "active": "1542",
    "expiring": "14",
    "disapproved": "152",
    "pending": "743"
  },
  ...
}]

Here, there are 1542 active products that target the USA that can be used in online Shopping campaigns, 14 active but expiring products, 152 disapproved products, and 743 pending products.

Product-level issues in Accountstatuses
In addition to the new product statistics, the "products" field also contains an itemLevelIssues field similar to the itemLevelIssues field added to Productstatuses earlier this year. Using the contents of this field, you can now see explicitly whether a given issue is impacting the servability of a product and whether the issue needs your attention or just further processing on Google's part.

Human-readable descriptions in itemLevelIssues
In both Productstatuses and Accountstatuses, the objects in the itemLevelIssues field now have some additional fields, which contain English descriptions and helpful links for issues that are suitable for surfacing to clients. The following fields have been added:

description contains a short English description of the issue.
detail contains a detailed English description of the issue.
documentation contains a URL for a web page that can help resolve the issue.

Here is an example itemLevelIssues object that includes these fields:


{
  "attributeName": "image link",
  "code": "image_link_pending_crawl",
  "description": "Image not retrieved (crawl pending)",
  "destination": "Shopping",
  "detail": "Wait for the product image to be crawled (up to 3 days)",
  "documentation": "https://support.google.com/merchants/answer/160640",
  "resolution": "pending_processing",
  "servability": "disapproved"
}

What do you need to do?
Now that the human-readable information is available for itemLevelIssues in both systems, we now consider the old dataQualityIssues fields deprecated. We will no longer include them in Productstatus or Accountstatus resources on Dec 1, 2018, therefore you should migrate to the new itemLevelIssues fields as soon as possible.

If you have any questions or feedback about this change, or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

A new guide for integrating Google Shopping ads using Google APIs

2018-06-25T09:17:00.000-07:00

Good news for developers planning to integrate Google Shopping ads! We have just released a brand new guide explaining how to automate the delivery of Google Shopping on behalf of merchants using Google APIs.

The Shopping Automation Guide covers the steps required to set up new merchants using a combination of the Content API for Shopping and AdWords API. It describes how you can fully automate certain tasks that would otherwise be performed manually using the Merchant Center and AdWords websites.

The guide is for developers interested in feed management, campaign management, or full automation workflow that includes both. The workflows provide detailed explanations of how the different APIs can be used for each stage of the user journey. You can follow the workflow step by step or navigate straight to the article you require using the side panel.

Head over to the developer pages to get started! If you have any questions or need help, please contact us on the relevant forums:

If you have any feedback on the guide, please use the “Send Feedback” link at the top right of each page.

We also appreciate any feedback on your experience using the guide. If you would like to share it, please complete this survey.
- Ian Ballantyne, AdWords API Team

Content API for Shopping Roundup

2018-04-20T07:54:00.002-07:00

There have been some smaller API updates and announcements that we'd like to let you know about!

We've published a new Getting started with Local Inventory Ads guide to walk you through the process of using the new LIA onboarding features in the Content API.
There's a new codelab available on creating and linking AdWords and Merchant Center sub-accounts!
You can now filter results by destination for Productstatuses and Accountstatuses method calls with the new destinations query parameter. If you don't specify a destination, you'll still only get Shopping-related issues, so there is no change to the default functionality.
You can specify holiday shipping cut-offs for shipping services as well. The supported holidays are available via the Shippingsettings.getsupportedholidays method.
You can specify when a particular shipping service is eligible for products. The new services[].eligibility field allows you to specify whether the shipping service applies to products bought via Shopping Actions and/or when bought in some other manner, such as via your own storefront.
We've added a new Datafeeds.fetchnow method to request an immediate fetch of a scheduled feed. Use this method to get feedback on a newly scheduled feed faster than waiting for the first scheduled fetch.

If you have any questions or feedback about these items or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Onboarding for local inventory ads via the Content API for Shopping

2018-03-27T09:17:00.001-07:00

Today, we're announcing the ability to configure your local inventory ads (LIA) settings and link Google My Business (GMB) accounts via the Content API for Shopping. This allows you to onboard accounts for LIA programmatically, instead of needing to manually configure each account separately via the Merchant Center website.

The new Liasettings service lets you perform the following actions via the Content API:

Set your target countries for LIA service and their About pages (if needed)
Add and check the status of contacts for local inventory verification
Request access to a GMB account
Request available business accounts from a linked GMB account
Request and check the status of local inventory verification

In addition, the new googleMyBusinessLink field in the Accounts resource states which business account should be linked. After setting this field, you can provide inventory information for the locations in that business account by uploading product and inventory information either through local product feeds and local product inventory feeds or through the Content API for Shopping with the channel field set to "local".

If you have any questions or feedback about these new features or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Announcing service account creation in the Merchant Center

2018-02-06T10:48:00.000-08:00

Today we're pleased to announce that you can now create service account keys to access the Content API for Shopping directly in the Merchant Center!

Even if you've already set up service accounts for your solutions, you can still create a new service account key here if you'd like to switch to managing your service account keys directly in the Merchant Center. See the Retrieve a service account key for authentication section of the Get Started guide for more details.

Note: This feature does not remove the other ways to create and manage Content API authentication. If you'd prefer to manage your Google API Console project and service accounts yourself, you can still follow the steps in the Service Accounts guide. If you are accessing others' Merchant Center accounts using OAuth 2.0, you'll still want to follow the steps in the Authorize Requests guide instead of using service accounts.

If you have any questions or feedback about the new service account management in the Merchant Center, or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Changes to issue reporting in the Content API for Shopping

2018-02-05T11:18:00.000-08:00

What's changed?
There are two major changes to the resource returned by Productstatuses:

a new format for product-level issues
changes to the destination-specific statuses for each product

A new format for product-level issues
We've added a new itemLevelIssues field to the productStatus resource. This field contains a sequence of issue entries, similar to the dataQualityIssues field, but each entry contains different information. For now, the Content API returns both fields (see the "What do I need to do?" section for more details).

Here is an example of the same issue in the old format and the new format:

dataQualityIssues
{ "id": "validation/missing_required", "severity": "critical", "location": "title", "detail": "Invalid or missing required attribute: title" }

itemLevelIssues
{ "code": "item_missing_required_attribute", "servability": "disapproved", "resolution": "merchant_action", "attributeName": "title", "destination": "Shopping" }

As shown above, each entry in the itemLevelIssues field contains the following information:

code: The issue ID

Note: This ID may differ from the ID provided for the same issue in the dataQualityIssues field, as in the example above.
servability: The serving status of the product based on this issue. May be one of the following string values:
- "disapproved": This issue has caused the associated product to be disapproved.
- "unaffected": This issue has not affected the servability of the associated product.
resolution: Whether or not the issue requires the merchant to take action. May be one of the following string values:
- "merchant_action": This issue requires action on the part of the merchant to resolve.
- "pending_processing": This issue requires further processing from Google to resolve this issue, and you do not need to do anything.
attributeName: The name of the product attribute that caused this issue, if applicable. For the "item_missing_required_attribute" issue example above, this field contains the value "title" since the product data triggering this issue did not include a title.
destination: The destination to which this issue applies. For example, a given issue may affect the servability of the product for Shopping campaigns (the "Shopping" destination), but not the servability for Display Ads (the "DisplayAds" destination).

Note: If an issue applies to multiple destinations, then there will be separate issue entries for each destination.

To summarize, the new issue format makes explicit whether a given issue affects the servability of the product and whether or not merchant action is required to resolve the issue.

Note: Currently, an entry in itemLevelIssues does not contain human-readable descriptions of the issue (e.g., the detail field in dataQualityIssues entries). This work is ongoing, and new fields that contain this information will be added in the near future. We will post another blog entry describing those fields when they are available.

Changes to destination-specific product statuses
We have also added a new approvalPending field to the destinationStatuses field. If set to true, then the approvalStatus of the entry may change due to further processing. This corresponds to the pending status of products when viewed in the Merchant Center. The approvalPending field is true only if there are no issues for that product that require action by the merchant.

Here's a concrete example of a destinationStatuses entry for a product that has "Shopping" as an intended destination with approval pending on further processing:


{
  "destination": "Shopping",
  "intention": "required",
  "approvalStatus": "disapproved",
  "approvalPending": true
}

In addition, the destinationStatuses field contains only entries for intended destinations. That is, this field will no longer contain statuses for excluded destinations. Due to this, the intention field of these entries will now always contain the value "required".

What do I need to do?
Currently, no action is needed. We do not expect you to transition to the new issue format yet as it is not on par with the old issue format. For now, we are describing the new issue format so that you get a head start on understanding it and to allow you to transition ahead of time if you do not need the currently missing information.

However, note that we plan to drop support for the old dataQualityIssues field on Aug 1, 2018. Once the new issue format has reached parity with the old issue format, we will update the blog with information about the new changes, and you should transition to the new issue format at that time.

If you have any questions or feedback about this change or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Invalid inserted products no longer result in immediate errors

2017-12-21T08:09:00.000-08:00

In July, there was a change in how the Content API for Shopping responds when inserting products that contain validation errors due to work related to advanced feed management.

What changed?
Here are the changes in behavior when inserting product information that contains validation errors and would result in an invalid product:

	Before	After
Inserting new product	Error (inserted)	Success (inserted)
Updating invalid product	Error (inserted)	Success (inserted)
Updating valid product	Error (not inserted)	Error (not inserted)

That is, before the Content API would return an error whenever the new product information contained validation errors. Now, an error is returned only if the product information cannot be updated because it would invalidate the currently valid product.

Note: With this change, the Content API now returns an error response to product insertion only when the returned error response contains the not_inserted error. Since this error is now redundant, we plan to remove it in the future.

Why has this behavior changed?
With the new advanced feed management features, the products inserted via the Content API may be augmented with information from associated supplemental feeds. This means that a product that would normally be invalid from just the information provided by the Content API may become valid when the information is combined with supplemental feeds to produce the final version of a product.

For example, suppose you submit product information via the Content API that lacks needed GTIN information. You then submit the GTIN information for your products separately via a supplemental feed that is connected to the Content API feed in Merchant Center. The products inserted by the Content API are not valid products due to the lack of GTIN information, but once the GTIN information from the supplemental feed is added, the resulting products are valid.

What do I need to do?
If you depend on error responses from Products.insert to detect validation issues, then you should instead also check your Content API feed for validation issues by using either Productstatuses or Accountstatuses. This will catch products that were inserted with invalid information and have not been made valid after insertion via supplemental feeds.

Note: If you are using Productstatuses.list to check all the products in a given account, you'll need to set the includeInvalidInsertedItems parameter to return products with validation errors.

If you have any questions or feedback about this change or any other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Changes to data feed management in the Content API for Shopping

2017-09-25T13:20:00.000-07:00

Starting today, the Datafeeds service will allow you to use the Content API for Shopping to set up data feeds that target multiple countries and/or languages, which a recent update added to the Merchant Center. The update to the Datafeeds service will also allow you more control over the destinations for products in data feeds managed via the Content API.

What's changing?
To handle feeds that target multiple countries and/or languages, a new targets field is being added. This field contains a list of targets, and each target contains the following fields:

country - the target country
language - the content language for this target
includedDestinations - a list of destinations to include for this target
excludedDestinations - a list of destinations to exclude for this target

Note: The above links to the reference documentation for the new fields will go live on the same day that the feature is introduced.

The following now-redundant fields are being deprecated:

Currently, code that uses these deprecated fields will continue to work as before for managing feeds with a single target. Any changes made via these deprecated fields will also appear as a single target in the new targets field, and vice versa if the targets field contains a single target. These deprecated fields will not be returned when retrieving feeds with multiple targets. Since these deprecated fields may be removed in the future, we recommend migrating your code to use the new targets field now.

To support feeds that have multiple targets, the Datafeedstatuses.get method now takes two additional parameters:

country - the target country
language - the content language

These new parameters must be supplied for feeds that have multiple targets, since the status of a feed may differ depending on the target. These parameters can be omitted when retrieving the status of a feed with a single target.

Similarly, when retrieving all feed statuses using the Datafeedstatuses.list method, you will receive multiple entries for a feed with multiple targets, where each entry corresponds to a particular target.

What do I need to do?
To manage feeds that use any of the following features, you must update your code to use the new targets field:

Feeds that target multiple countries and/or languages
Feeds that exclude destinations that are included by default

In addition, you must supply the new country and language parameters when retrieving the status of a feed that has multiple targets.

Otherwise, your existing code will continue to work as before. However, since we may remove the old fields in the future, we recommend you update your code for managing data feeds to use the new targets field.

Note: To use the new targets field and the new country and language parameters if you are using one of the Content API client libraries, update to a version published on or after Sep 21, 2017.

If you have any questions or feedback about the changes to data feed management or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Changes to sub-account deletion in the Content API for Shopping

2017-08-29T09:39:00.000-07:00

What's changing?

Currently, the Accounts.delete method deletes sub-accounts whether or not they contain products. On Sep 28, 2017, we will change the default behavior of Accounts.delete to only delete empty sub-accounts. We are introducing this change to help avoid accidental deletion of sub-accounts that are still serving products.

To override this behavior, we have introduced a force parameter, which currently defaults to true. On Sep 28, 2017, the default value will change to false. After this change, you must set this parameter to true to delete non-empty sub-accounts. Attempts to delete non-empty sub-accounts with force = false will result in a 403 Forbidden error. The error will also explain how to delete the non-empty account.

What do I need to do?

Right now, we suggest you familiarize yourself with the new force parameter. If you regularly delete non-empty accounts, you should adjust your code to set force to true to avoid errors when the default behavior changes. If you want to inspect the error that you will receive after the default behavior changes, you can manually set the force parameter to false and attempt to delete a non-empty account. (Of course, we suggest you create a new sub-account and add some products to it to try out this new behavior, instead of calling it on an existing live account.)

Once this change is live on Sep 28, 2017:

To delete an empty sub-account, you do not need to make any changes.
To delete a sub-account that contains products, you must set the new force flag to true when calling Accounts.delete.

Note: If you are using one of the Content API client libraries, you will need to update to a version published after Aug 28, 2017 to take advantage of this new parameter.

If you have any questions or feedback about the changes to account deletion or other questions about the Content API for Shopping, please let us know on the forum.

- Stevie Strickland, Content API for Shopping Team

Accountstatuses now includes account-level issues in the Content API for Shopping

2017-08-09T09:21:00.000-07:00

Starting today, calls to the Accountstatuses service return not only product-level issues, but also account-level issues. This means all account-level issues present in the Diagnostics tab of the Merchant Center can now be retrieved using the Content API. Account-level issues are located in a new accountLevelIssues field, so existing code should be unaffected by this change. For more details, see the accountStatus resource representation in the reference documentation.

Note: Some account-level issues, like unclaimed websites, were already returned as product-level issues. Currently, these issues still show up at the product level as well as at the account level, but this may change in the future.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Changes in retrieving product data from Merchant Center via Content API

2017-07-12T09:44:00.000-07:00

Starting today, we are deprecating the use of the Products.get and Products.list methods for retrieving all product attributes. These methods still work as expected today, but they may change in the future to return only partial information about products. If you want to retrieve all product attributes, you should use the Productstatuses.get and Productstatuses.list methods instead, which now optionally provide product attributes in addition to product issues and approval statuses.

Note that the Productstatuses.get and Productstatuses.list methods still do not return product attributes by default. To request product attributes be included, we have added an optional includeAttributes argument to these methods. When set, the resources returned by Productstatuses.get and Productstatuses.list will contain an additional product field that contains the attribute information.

If you have any questions or feedback about the changes to retrieving products or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Automating website claims using the Content API for Shopping

2017-05-31T12:36:00.000-07:00

Starting today, you can use the Accounts.claimwebsite method to claim the configured website for Merchant Center accounts. This means that you are no longer required to manually claim the website using the Merchant Center, but you can instead automate this part of account creation as well. As before, the website that you are attempting to claim must first be verified, either manually or using the Google Site Verification API.

If the call is successful, then you will receive an empty response with HTTP status code 200. If it is not, then you will receive an error response explaining why the claim attempt failed.

Note: If another Merchant Center has already claimed the website you are attempting to claim, you cannot use the API to overwrite their claim with your own. Instead, please follow the manual process instead.

In addition, there is a new websiteClaimed field in the resource representation returned by Accountstatuses. This field contains true if the associated account has successfully claimed its website.

If you have any questions or feedback about using the Content API to claim websites or any other questions about the Content API for Shopping, please let us know on the forum.

- Stevie Strickland, Content API for Shopping Team

Upcoming QPS limits on calls to the Content API for Shopping

2017-05-02T07:34:00.000-07:00

Starting on May 15, 2017, we will enforce new queries-per-second (QPS) limits on calls to the Content API for Shopping. This change will help with maintaining stability and uninterrupted access to all users of the API. Currently, almost all existing users already conform to the new QPS limits we will enforce, so unless you are directly contacted by us, you should not see any changes.

The new QPS limits will be in addition to the existing per-minute and per-day quotas on method calls. However, these limits will be enforced per Google API Console project, unlike the method call quotas which are enforced on individual Merchant Center accounts. Another difference is that the QPS limit will be for individual HTTP requests, not for individual method calls, so a single HTTP request to the custombatch method will count as a single call against the QPS limit. This is an additional reason to use custombatch methods if you plan on making many calls to a single service within a short time period. Once these limits are in force, they will be documented along with the other published limits for the Content API for Shopping.

If you have any questions or feedback about the QPS limits or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Productstatuses now includes issues older than 21 days in the Content API for Shopping

2017-03-14T11:35:00.001-07:00

Starting today, Productstatuses will return all the issues present in the Diagnostics tab of Merchant Center. Historically, only data quality issues from the last 21 days were available from Productstatuses. This means that you may see more issues returned by Productstatuses than before, but the number of issues should now match those available in the Diagnostics tab of Merchant Center.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Accountstatuses to now include validation issues in Content API for Shopping

2017-01-11T08:14:00.002-08:00

Starting on January 17th, 2017, Accountstatuses will return all the errors and warnings present in the Diagnostics tab of Merchant Center. This updates Accountstatuses to match the changes to Productstatuses from last August, so Accountstatuses will now report validation issues as well as data quality issues. This means that developers may see more issues returned by Accountstatuses than before.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Changes in severity for validation issues in the Content API for Shopping

2016-11-22T10:16:00.002-08:00

In August, we announced that returned Productstatuses would include any validation issues. Unfortunately, the way validation issues used the severity field differed from data quality issues, which led to confusion.

To clarify which validation issues are serious and which are just warnings, we will use the same mapping for validation issues as we do for data quality issues. In addition, we have published an accompanying guide, API Issue Severity and Diagnostics Issue Prioritization, which discusses how to compare the issue prioritization used in the Diagnostics section of the Merchant Center to the issue severity provided in the responses from the Productstatuses and Accountstatuses services.

As always, if you have any questions about these changes or any other questions or feedback about the Content API for Shopping, please let us know on the forum!
- Stevie Strickland, Content API for Shopping Team

Link your Merchant Center and AdWords accounts using the Content API for Shopping and AdWords API

2016-10-20T11:01:00.000-07:00

What's changing?
As of today, the getServiceLinks() and mutateServiceLinks() methods on CustomerService are available to all AdWords API users. Previously, these methods were only available to whitelisted users.

Using this functionality and the Content API for Shopping, you can now fully automate the process of linking Merchant Center accounts to your AdWords account. Previously, you could send a link invitation using the Content API for Shopping, but you could not accept or reject the invitation using the AdWords API.

What do the new features do?
I thought you'd never ask! :)

getServiceLinks() retrieves the status of links between your AdWords account and Merchant Center accounts.
mutateServiceLinks() accepts or rejects links between your AdWords account and Merchant Center accounts.

What should you do?
If you're interested in automating the linking process between Merchant Center and AdWords, check out the updated shopping campaigns guide.

If you have any questions or need help, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff, AdWords API Team

Shopping for a Ruby to Go with new Content API samples

2016-10-11T10:54:00.000-07:00

Our Samples and Libraries page has been updated with additional languages: Ruby and Go. For Ruby, the new samples are written in plain Ruby, which should make them easy to integrate into whatever Ruby framework you may be using for your particular project. If you haven't had a chance to try your hand at Go yet, the new Go examples provide the perfect excuse.

If you have questions about the samples or any feedback on how they might be improved or expanded, please feel free to file an issue on GitHub! If you have any other questions or feedback concerning the Content API for Shopping in general, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

How and when to use service accounts with the Content API for Shopping

2016-10-06T08:19:00.000-07:00

The Content API for Shopping documentation now includes a guide for using OAuth 2.0 service accounts with Content API for Shopping. This guide will be of particular interest to in-house developers, whose applications do not need access to third-party information. In such cases, requiring the application to get user approval and to keep track of refresh tokens may be unnecessary overhead. Instead, service accounts provide a private key that the application can use to authenticate when using the Content API.

For developers that work with third-party information, you should still use the OAuth2 three-legged authentication flow as described in the Authorize Requests guide to request permission from users for access to their information.

If you have questions about which flow is more appropriate for your project, or any other questions or feedback concerning the Content API for Shopping, please let us know on the forum.
- Stevie Strickland, Content API for Shopping Team

Productstatuses to include validation issues in Content API for Shopping

2016-08-31T15:08:00.000-07:00

Starting on September 14th, 2016, Productstatuses will return all the errors and warnings present in the Diagnostics tab of Merchant Center. To explain the changes, first we separate errors and warnings for products into two categories:

Validation issues are reported as a result of product insertion and update, and they include issues such as missing required fields or invalid item IDs.
Data quality issues are reported later after either automatic or manual review of the data provided to Merchant Center, and they include issues such as product images being too generic or a non-matching price on the landing page.

Historically, only data quality issues were available from Productstatuses, while validation issues required the developer to check the returned status from the insertion or update of the product. After this change, developers can retrieve both data quality and validation issues using Productstatuses, but this means that developers may see more issues returned by Productstatuses than before.

Please note that the includeInvalidInsertedItems URL parameter to Productstatuses.list still defaults to false. This means that, by default, calls only retrieve products which had no validation errors, and thus the retrieved products will only include data quality issues and validation warnings (if any). If you want to retrieve information about products with validation errors, please set this parameter to true.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.

-Stevie Strickland, Content API for Shopping Team