Tag Archives: content_api

Content API for Shopping Roundup

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

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.
 - , Content API for Shopping Team

Onboarding for local inventory ads via the Content API for Shopping

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: 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.
 - , Content API for Shopping Team

Announcing service account creation in the Merchant Center

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.
 - , Content API for Shopping Team

Changes to issue reporting in the Content API for Shopping

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.
 - , Content API for Shopping Team

Invalid inserted products no longer result in immediate errors

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.
 - , Content API for Shopping Team

Changes to data feed management in the Content API for Shopping

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: 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: 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.
 - , Content API for Shopping Team

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


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.

 - , Content API for Shopping Team

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

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.
 - , Content API for Shopping Team

Changes in retrieving product data from Merchant Center via Content API

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.
 - , Content API for Shopping Team

Changes in retrieving product data from Merchant Center via Content API

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.
 - , Content API for Shopping Team