Google Content API Shutdown: Merchant API Migration Checklist

What changed: Google sunset the Content API for Shopping on August 18, 2026. Since September 1, requests from clients without an active extension can fail intermittently with HTTP 410 Gone. A 410 marked content_api_sunset identifies the Google Cloud project that made the request; it is the starting point for finding the integration owner, not proof that every Merchant Center account or product feed is down. Google says failures will grow toward a final decommissioning in early 2027, and that timing can change.

If a product sync, report, inventory job or Google Ads Script is still calling Content API, first find which code or provider owns that call. Then map the project in the error response, check whether that Cloud project has an active extension, and finish moving the affected workflow to Merchant API. Retrying can sometimes get one request through, but Google says it is not a long-term fix. Google’s current sunset notice describes these milestones and the response fields.

What Merchant API is—and where the shutdown stands

Merchant API is Google’s versioned programmatic interface for managing Merchant Center accounts and product data, including related inventory and reporting workflows. Google describes it as a redesign of Content API for Shopping, organized into sub-APIs with new resources and methods; it is not a drop-in hostname replacement. See Google’s Merchant API overview for its scope and compatibility overview for how the migration differs.

As of October 10, 2026, the August 18 sunset date has passed. It did not mark a promise that every legacy request would fail at the same instant. Google introduced progressive service degradation on September 1: requests without an active extension can fail intermittently with HTTP 410, and the rejected share is expected to increase until the final shutdown. Google lists final decommissioning for early 2027 but says that schedule is subject to revision. Check the live sunset notice before acting on a date.

Google’s compatibility overview uses broad language that Content API can continue while teams migrate. Read that as migration guidance, not a guarantee of uninterrupted unextended access after September 1: Google’s specific sunset notice specifically says clients without an active extension can receive intermittent 410 responses.

First identify who owns the failing connection

A Merchant Center account can receive product data from several places. Start with the failed request’s endpoint, the job or app that sent it, and the Google Cloud project shown in the response. Do not assume the person who manages Shopping campaigns also owns the API client.

Google’s compatibility overview says merchants using a third-party technology partner to sync product data, including its Google & YouTube app example for Shopify, do not need to perform that API migration themselves because the provider manages it. Confirm that the statement covers your specific app and product-sync workflow. It does not establish that separate scripts, custom reports or other API jobs were migrated too. Google Ads Script users can check the current Advanced APIs list, which includes Merchant API, then ask the script owner to verify the actual code.

Use the HTTP 410 response to find the Google Cloud project

Google’s example response includes HTTP code 410, status ABORTED, reason content_api_sunset, and domain shoppingcontent.googleapis.com. Its metadata includes GCP_ID, GCP_NUMBER and a migration-help link. The project ID and project number identify the Google Cloud project making the request. They are not Merchant Center account identifiers.

The response excerpt and decision walk-through below are illustrative only; they were not executed and use fictional project details.

{
  "error": {
    "code": 410,
    "status": "ABORTED",
    "details": [{
      "@type": "type.googleapis.com/google.rpc.ErrorInfo",
      "reason": "content_api_sunset",
      "domain": "shoppingcontent.googleapis.com",
      "metadata": {
        "GCP_ID": "<project-id>",
        "GCP_NUMBER": "<project-number>",
        "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/compatibility"
      }
    }]
  }
}

1. Save the complete response, request time, endpoint and the job or application log entry. A response with the sunset reason is more specific than a generic HTTP status alone.
2. Use GCP_ID to locate the project in your cloud-project inventory or console. If you need help finding it, Google documents how to locate a Google Cloud project ID. Do not substitute the numeric project number or a display name in an extension request.
3. Ask the project owner which application, service account, scheduled job or vendor is making the request. If the project is shared, trace the request to the exact caller rather than assuming every integration under that project is affected.
4. Check whether that project has an active extension and whether the failed call is part of a provider-managed connection. Then give the owner a migration task for each remaining Content API workflow.

Worked decision for a fictional overnight inventory job: its response contains GCP_ID=fictional-shop-feed-prod. Use that project ID to locate the job owner and check the project’s extension submission and returned output. Do not use the Merchant Center account ID or numeric GCP_NUMBER in place of the project ID. If a platform provider owns the caller, route the migration check to that provider; if the job runs in your repository or cloud project, assign it to the code owner. Either way, record the remaining Content API methods and continue the Merchant API migration.

Google notes that some rejected requests may not count against API quota, and that a retry can sometimes succeed during progressive degradation. Neither fact makes retrying a repair: the rejection rate is expected to rise. If an HTTP 410 does not contain the sunset reason and project metadata above, inspect the full error and troubleshoot its actual cause instead of treating every 410 as a Content API sunset error.

What an extension does—and what it does not do

If your organization needs more time, use Google’s current Merchant API extension instructions. The current page, last updated September 24, 2026, says to submit the correct Google Cloud project ID. It explicitly says not to submit a project name or numeric project number. You can include multiple project IDs in one request as a comma-separated list.

Google says a request with correct project IDs is approved upon submission; it sends an email with the request output within a few days. The latest submission determines the project’s expiration date. If that date has passed and the project is already receiving API errors, Google says the form can be submitted again to request an extension. These instructions do not reveal whether a particular reader submitted the right ID or has current extended access; check the project’s own records and request output.

An extension is temporary protection from the scheduled degradation during its approved window. It is not a Merchant API migration, does not cover a different Cloud project, and does not extend beyond the final early-2027 decommissioning listed on Google’s sunset page. If the calls are already failing, prioritize the migration while resolving extension status; do not treat an extension as the long-term plan.

Merchant API migration checklist

Merchant API is a redesign rather than a hostname replacement. Google’s migration guide recommends mapping the Content API methods you actually use to the new methods, reviewing the sub-API-specific changes, registering the developer project, then implementing against the new resources.

1. Inventory every call and the business task behind it

Search application code, client libraries, Apps Script projects, cron jobs, cloud functions, integration settings and vendor documentation for shoppingcontent.googleapis.com, Content API v2.1 paths and the old client. Record the caller, Cloud project, owner, schedule and business outcome for each call. Include product writes, processed-product status, data sources, inventory, reports, account operations, promotions and notifications where relevant.

Do not mark the migration done because the daily product upload works. A separate inventory, reporting or diagnostics job may still call the old service. Link each old method to its new method and the test that will demonstrate the replacement works.

2. Register the project and map the methods

Google requires a link between the Merchant Center account and the Google Cloud project through Developer Registration before using Merchant API. These are separate identifiers: registration links the account to a project, but a Merchant Center account ID is not a Cloud project ID. Confirm the correct account and project with the integration owner, then follow the migration guide for the sub-APIs and features the integration uses. Prioritize according to the workflows that matter to your catalog; do not assume every Content API feature maps one-to-one.

3. Rework product writes, data sources and identifiers

In Merchant API, ProductInput represents submitted product data; the read-only Product is the processed result. Google’s product migration guide maps Content API products.insert, products.update and products.delete to Merchant API productInputs.insert, productInputs.patch and productInputs.delete. It maps productstatuses.get and productstatuses.list to processed products.get and products.list; the returned Product contains the productStatus field and its validation issues and destination statuses.

Every product-input write requires an explicit dataSource resource name. For these API writes, Google defines it as a primary or supplemental product data source and says only API data sources are supported; see the insert method requirements and data-source migration guide. Do not infer that a scheduled file feed itself made the API call. A wrong source can transfer a product to a different primary source. Google calls this “offer stealing.” Backfill the correct data-source resource name for each product and verify ownership before inserts, updates or deletes.

Keep the same offerId for the same product to avoid losing product history. Content API identifiers included a channel and colon-delimited fields; Merchant API resource names use a product identifier such as contentLanguage~feedLabel~offerId without the channel segment. Prefer the returned resource name instead of assembling one by hand. Review reserved characters and encoding against Google’s product migration guide. That guide also documents field changes such as price representation, so test any conversion against the source schema rather than copying old payloads.

4. Replace custom batching and make errors visible

Merchant API does not support Content API’s customBatch method. Google points developers to asynchronous requests or HTTP batching. Update concurrency, retry and rate-limit handling, and keep per-item errors visible so one rejected product does not disappear inside a successful batch job. Do not assume throughput will match the old implementation; compare it with your actual catalog and service constraints.

5. Validate the processed result, not just a successful write

For a controlled set of products, check that each input reaches the intended data source, then read the processed Product and review its status and issues. Google’s productInputs.insert reference warns that after inserting, updating or deleting an input, it may take several minutes before the processed product can be retrieved. Do not treat an immediate missing read as the final state; poll or recheck after processing time, then review the returned product status.

Compare the fields that matter to your storefront and destinations: offer ID, price and currency, availability, image, landing-page URL, feed label, destination and source ownership. Run the account, inventory, reporting and diagnostics workflows that depend on the integration. An accepted write is not proof that the product is current, eligible or attached to the intended source.

Key technical changes to include in migration QA

Google’s product migration guide and data-source guide document the method and source changes. The compatibility overview identifies the new Price type fields as amountMicros:int64 and currencyCode:string. Use the table as a QA map, then follow the linked sub-API documentation for the methods your integration actually uses.

Use a bounded rollout and monitor the feed after migration

A safe rollout makes errors attributable. Before each change, record the affected job, representative product identifiers, data-source mapping and recent run status. Move one integration or bounded catalog segment at a time, compare inputs with processed products and diagnostics, and expand after the checks pass. Keep a containment or rollback path for code you control, but do not count on the sunset Content API as a durable fallback.

• Freshness: Are price, availability and inventory updates arriving on the expected schedule?
• Coverage: Do submitted and processed product counts match the intended catalog scope?
• Diagnostics: Did item issues, destination exclusions or disapprovals change after a migration step?
• Ownership: Are products still attached to the intended primary or supplemental data source?
• Automation: Have scheduled jobs, reports and Google Ads Scripts stopped calling legacy methods?
• Traceability: Can you tie each release to its methods, project, catalog segment, error rate and validation result?

Treat campaign metrics as outcomes, not API diagnostics. A spend or ROAS change alone does not prove a Content API failure: auctions, bids, budgets and product eligibility can also affect delivery. Use request logs and Merchant Center feed diagnostics to establish whether the integration failed, then analyze campaign performance separately.

Once the feed connection is stable, review separate Merchant Center checks for price, availability and promotions in DMT’s Merchant Center holiday readiness checklist. That is a feed-quality follow-up, not evidence that the API migration itself is complete.

Frequently asked questions

Can my main product upload be a file feed while a separate API job still fails?

Yes. Google’s Merchant API overview says API-managed products can complement other upload methods, including files and autofeed. A separate script or service can still call Content API for inventory, reporting or diagnostics. Identify the caller in request logs; do not infer that the file feed itself made the API request.

About the author: Tayeeb Khan publishes Digital Marketer Tayeeb, a research-focused resource for marketers and small businesses. This refresh separates Google’s published API guidance from what a reader must verify in their own code, provider and Google Cloud project. Documentation was checked on October 10, 2026; no customer integration or extension request was tested.