Google's Content API for Shopping is gone: 410 feed errors and the Merchant API migration path

What happened

Google retired the Content API for Shopping (v2.1) on 18 August 2026, and the fallout is now hitting anyone running a custom feed integration. According to a migration checklist published on dev.to by The Trillium Company, product feed synchronisation jobs have been failing intermittently with HTTP 410 responses since 1 September 2026 whenever the calling Google Cloud project lacks an active extension. Citing Google's deprecation page, the post warns that every request will stop working in early 2027.

The problem is specific to homegrown integrations: scripts, cron jobs or bespoke feed services. Merchants on mainstream ecommerce platforms or installed apps generally do not need to act, because the vendor handles the transition.

Reading the error

The failure is deliberate, not flaky infrastructure. The 410 response carries an ABORTED status with the reason content_api_sunset and the domain shoppingcontent.googleapis.com, plus metadata pointing to a help centre link. Two practical notes from the post stand out. First, retrying will not help, because the errors are intentional and will become more frequent. Second, many sync jobs swallow non-2xx responses, so instead of crashing they let products quietly go stale inside Merchant Center. Logging the error reason explicitly is recommended.

One-time setup before any code changes

Three project-level steps are required, separate from rewriting calls:

• Enable the Merchant API in the Google Cloud project.
• Register the project once via developerRegistration:registerGcp against the primary, production Merchant Center account. Skipping this yields a 401 UNAUTHENTICATED error stating the project "is not registered", and the post advises allowing a few minutes after registering.
• Create an API-input data source. productInputs.insert requires a dataSource query parameter, and inserting an offer that another data source currently owns transfers ownership of it.

Authentication is OAuth 2.0 or a service account with admin access on the Merchant Center account.

How the endpoints change

Content API v2.1	Merchant API	Watch out for
products.insert	productInputs.insert	dataSource is required; attributes move under productAttributes
products.delete	productInputs.delete	also requires dataSource
products.custombatch	no equivalent	use parallel calls or HTTP multipart batch, capped at 2,000 requests per batch
productstatuses.*	products.get / products.list	status now lives in productStatus
datafeeds.fetchnow	dataSources.fetch

Payload changes that fail silently

Beyond the endpoint renames, several data-format shifts can break a sync without an obvious error:

• Product identifiers change shape, from channel:contentLanguage:targetCountry:offerId to accounts/{account}/products/{contentLanguagefeedLabelofferId}. The channel segment disappears, the tilde becomes the delimiter, and identifiers containing characters such as /, : or ~ must be base64url-encoded.
• Prices switch from {"value": "33.45", "currency": "USD"} to {"amountMicros": "33450000", "currencyCode": "USD"}.
• targetCountry is replaced by feedLabel, and free-form strings such as availability become typed enums like IN_STOCK and NEW.

The post's advice is to verify every change against Google's compatibility guide rather than relying on any summary alone.

Locating legacy calls in a codebase

To help with the audit, the company behind the post maintains a dependency-free scanner called merchant-migration-scan. It statically scans a repository for Content API usage across the Python googleapiclient library, the PHP Google_Service_ShoppingContent service, the Node googleapis package and raw REST calls, and lists the Merchant API replacement alongside a risk note for each. Because it is a pure text scan with no network calls and no credentials, it can miss dynamically constructed requests and cannot confirm whether a project holds an extension, so the output should be treated as a checklist rather than proof of migration completeness.

Why it matters

A silently stale feed is worse than a crash: products lose freshness in Merchant Center without any alert, degrading listings while the integration looks healthy. The intermittent nature of the 410s makes this especially deceptive, since some requests still succeed and can mask the problem until the hard cutoff in early 2027. The migration is also not a base-URL swap — the registration step, the data source requirement, the new identifier format and the micros-based price format each demand code and test changes. Teams with custom feed tooling should log 410 reasons now, scan their codebases for old endpoints, and schedule the move well before the deadline.