Pingverablog ← Blog
Home › Blog › Content API for Shopping Sunset: Check Your Product Feed Before Peak

Content API for Shopping Sunset: Check Your Product Feed Before Peak

October 10, 2026 · 12 min read

Content API for Shopping Sunset: Check Your Product Feed Before Peak

Google's Content API for Shopping reached its official sunset on 18 August 2026. Since 1 September 2026, requests from projects without an approved extension have been failing at random with HTTP 410 Gone, and Google says those failures will become more frequent until the endpoints are switched off completely in early 2027. If any part of your store still sends products, prices or stock to Merchant Center through the Content API, some of those updates are already being lost, and your sync logs may not show it.

What to do this week: find every client of the old API (plugins, custom sync jobs, feed tools, scripts). For each one, confirm it has moved to the Merchant API or that it is covered by an extension. Then check in Merchant Center that products are still being refreshed. If you only use a supported ecommerce platform's built-in Google integration, or upload feed files, most of this work belongs to someone else. You should still check, because a missed refresh during Black Friday costs real money.

At a glance

Why it matters now

Google's developer documentation (last updated 10 September 2026) sets out the timeline:

Teams that need more time can submit Google's Content API extension request form. An approved extension stops the artificial errors only for the approved window, and never past final decommissioning.

The timing is the problem. Intermittent failures are the hardest kind to notice. A nightly job that worked on 90% of runs in September may work on far fewer by November, just as you change prices for Black Friday (27 November 2026 in calendars that follow it) and stock moves faster than at any other time of year. Under Google's product data rules, items submitted via feeds or the API expire 30 days after the last refresh. Products added directly in the Merchant Center interface do not expire. A sync that stops updating does not cause an outage straight away. It leads to stale prices, then disapprovals, then products dropping out, with weeks between cause and effect.

Who is affected

Use this rule of thumb. If code that you or your agency control calls shoppingcontent.googleapis.com, it is your migration. Typical places to look:

Usually not affected directly: scheduled fetches of an XML/CSV feed file, Google Sheets data sources, and integrations from platforms or feed vendors that have already moved to the Merchant API. For built-in platform integrations, Google's statement is that "your platform partner manages the migration on your behalf". Confirming that the partner has actually shipped it is still sensible.

Step-by-step: audit your feed integrations today

  1. List every writer to Merchant Center. In Merchant Center, open your data sources and write down each one, its input method (API, file, Sheets, platform app) and who owns it. An API source you cannot explain is the first thing to investigate.
  2. Search code and configuration. Look for shoppingcontent.googleapis.com, content/v2.1, customBatch, and client library packages named after the Content API. Repeat the search in scheduled scripts, serverless functions and Google Ads scripts, not only in the main repository.
  3. Search logs for the sunset error. Search recent application logs for 410 and content_api_sunset. If you find them, the integration has not moved yet, whatever the project plan says.
  4. Check how errors are handled. Many sync jobs log an error, retry once and then exit with a success code. Confirm that a failed API call makes the run fail visibly and that someone gets told.
  5. Ask each vendor in writing. For every plugin, app or feed tool, ask whether it uses the Merchant API now and since which version. Update it before your peak change freeze begins.
  6. Decide on an extension. If a custom integration cannot be migrated and tested safely before your peak trading period, submit the extension request now. Treat it as time for the migration, not as the fix.
  7. Verify freshness from the Merchant Center side. Pick a sample of high-revenue products. Check their last update time and their status, and compare price and availability with the live product page.
  8. Repeat weekly until the migration is done, then go back to your normal feed checks.

What changes in the Merchant API

Migration work is where new bugs come from. These differences come from Google's compatibility guide:

Area Content API for Shopping Merchant API What to test
Access Google Cloud project with API enabled One-time registration linking the Cloud project to the Merchant Center account Registration done for each project actually used in production
Product identifier channel:contentLanguage:feedLabel:offerId name such as accounts/{account}/products/{product}, with contentLanguage~feedLabel~offerId; channel removed No duplicate or orphaned products after cut-over
Price value (string) and currency amountMicros (int64) and currencyCode; one million micros = one currency unit Prices match the storefront on a sample, including discounted items
Batching customBatch Not supported; use parallel or asynchronous calls Full catalogue sync finishes within its time window
Where products go Inserted directly Inserted as product inputs into an API data source of type Primary or Supplemental Correct data source used; supplemental data still applied

The price change deserves extra care. A conversion error by a factor of a thousand or a million will not throw an exception. It produces a valid request with the wrong price, and that can lead to disapprovals for price mismatch.

Risk, owner, check, frequency

Risk Owner Check Frequency
Sync still calls the Content API Developer / agency Code and log search for the endpoint and content_api_sunset Once now, then after each release
Job "succeeds" while API calls fail Developer Failed calls make the run fail; alert on failed runs Every run
Job stops running at all Developer / ops Heartbeat expected after each successful run Every scheduled run
Products expire after missed refreshes Ecommerce manager Last-update time on a sample of top products Weekly; daily during peak
Wrong prices after migration Ecommerce manager Feed price vs live page on a sample, incl. sale items After cut-over; daily during promotions
Third-party app not migrated Store owner Written confirmation from vendor, version noted Once, before the freeze

Copyable artefact: Content API sunset checklist

CONTENT API FOR SHOPPING SUNSET CHECK  -  store: __________  date: ________

Inventory
[ ] All Merchant Center data sources listed with input method and owner
[ ] Every API data source mapped to a specific system / job / app
[ ] Code, scripts and Google Ads scripts searched for:
      shoppingcontent.googleapis.com | content/v2.1 | customBatch
[ ] Logs (last 30 days) searched for: 410 | content_api_sunset

Per integration (repeat)
  System: ______________  Owner: ______________
  [ ] Uses Merchant API (version / release: ________)  OR
  [ ] Extension approved (window: ________) and migration date set
  [ ] Cloud project registered with Merchant Center for Merchant API
  [ ] Prices sent as amountMicros; 10 sample products match storefront
  [ ] Product IDs map 1:1 to old IDs; no duplicates in Merchant Center
  [ ] Failed API calls make the run fail and raise an alert
  [ ] Successful run emits a heartbeat / timestamp someone watches

Merchant Center verification
[ ] Top 20 revenue products: last update within expected interval
[ ] No rise in disapproved or expiring items in diagnostics
[ ] Sale prices for the next promotion tested on 3 products

Sign-off: ______________   Next review: ______________

Worked scenario (illustrative)

A mid-size store on a custom platform pushes price and stock to Merchant Center every four hours with an in-house script built years ago on the Content API's customBatch. The script catches exceptions, writes them to a log file and always exits normally, so the scheduler shows a green tick every time.

In September a few runs per week hit 410 Gone. Because each batch is sent as one call, a failed call means none of that run's changes arrive. Most products are refreshed on a later successful run, so nothing looks wrong. By late October the failures are more frequent. Some slow-moving products have gone a long time without a successful refresh, and several sale prices set for a weekend promotion never reach Google. The first sign of trouble is a price-mismatch warning in Merchant Center diagnostics.

Before peak, the agency runs the checklist above. A log search for content_api_sunset confirms the problem in ten minutes. They submit the extension request the same day. They change the script to exit with an error when any API call fails, and they add a heartbeat after each successful run. The Merchant API rewrite, including a micros conversion test on discounted products, is scheduled for January, outside the freeze. The numbers and timings here are illustrative. Your failure rate and timing will differ.

Common mistakes

Honest limitations: this article covers operational checks, not a full migration guide. Google may revise the decommissioning date and the extension process. Read the official sunset page before making decisions, and note that platform vendors set their own timelines.

FAQ

Do I need to do anything if I use Shopify, WooCommerce or another hosted platform's Google integration?

Google says platform partners handle the migration for merchants who connect through them. Make sure the app or plugin is up to date, confirm with the vendor if you are unsure, and check that products are still being refreshed. Any custom code you added on top is still yours to check.

What does HTTP 410 Gone with content_api_sunset mean?

It means the request went to the retired Content API from a project without an active extension. Google is deliberately failing a growing share of those requests. Treat it as a migration signal, not a temporary outage.

Are XML or CSV feed files affected?

Scheduled fetches and file uploads do not depend on the Content API, so the sunset does not break them directly. They still need normal freshness and accuracy checks, because the 30-day expiry applies to feed-submitted products too.

Monitoring the sync after the fix

Once you know which jobs write to Merchant Center, the simplest lasting control is to have each successful run report in, and to alert when one does not arrive on time. Pingvera's heartbeat checks do exactly that: the sync job pings a URL after a successful run, and you get one alert (by email, Telegram or webhook) when the expected ping is missing. It does not look inside Merchant Center, so keep the weekly freshness sample from the checklist. For broader feed controls, see product feed monitoring and monitoring ecommerce integrations. For the wider pre-peak plan, see the peak sales readiness checklist.

Sources

Last reviewed: 2026-10-10

Know about problems before your customers do

Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.

Start free

Read next: Product Feed Monitoring for Ecommerce · Domain expiry: how to check when a domain expires · Ecommerce Peak Sales Readiness Checklist · SSL certificate expired: how to check and never miss the date · Check availability from several regions.

← All articles · Privacy policy · pingvera.com