Tag Archives: content_api

Automating website claims using the Content API for Shopping

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.

Upcoming QPS limits on calls to the Content API for Shopping

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.

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

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.

Accountstatuses to now include validation issues in Content API for Shopping

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.

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

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!

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

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.

Shopping for a Ruby to Go with new Content API samples

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.

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

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.

Productstatuses to include validation issues in Content API for Shopping

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.

Shippingsettings to replace Accountshipping in Content API for Shopping

We’ve launched a new Shippingsettings service which supports the new shipping settings in Merchant Center. This service replaces the old Accountshipping service, which has been deprecated and will be retired March 1st, 2017.

The new service uses rate tables instead of rate trees to describe complex rate systems, and also supports retrieving the available shipping services. Check out the updated Account-level Tax and Shipping guide and reference documentation if you're interested in what the new service looks like!

A note to users of Accountshipping: you can retrieve settings uploaded via Accountshipping through Shippingsettings, but not vice versa. Thus, if you currently have shipping settings, you can see what your current settings would look like in the new format expected by Shippingsettings by retrieving them using the new service.

If you're migrating from Accountshipping, we suggest you either first experiment with Shippingsettings on another Merchant Center account used for testing, or keep the code to upload settings via Accountshipping around until you're sure your new Shippingsettings code behaves as expected.

If you have any questions or feedback on the Shippingsettings service or other questions about the Content API for Shopping, please let us know on the forum.