If a product-sync job has started returning intermittent 410 Gone responses, retrying harder is not a fix. Google sunset the Content API for Shopping on 18 August 2026 and began deliberate service degradation for projects without an active extension on 1 September.
First prove whether your business calls the old API directly. If it does, stop treating 410 as a transient incident: register the Google Cloud project, map every method to Merchant API v1, preserve offer identity, test a representative catalog cohort, and reconcile processed products before switching traffic.
A 410 response is a migration signal, not an ordinary outage
Google says Content API for Shopping reached sunset on 18 August 2026. Since 1 September, requests from clients without an active extension can fail intermittently with HTTP 410. The error payload identifies the affected Google Cloud project and points to Merchant API v1. Google also says rejected requests will become more frequent until full decommissioning in early 2027; retries are explicitly not a viable long-term solution.
That distinction matters operationally. A 429 or transient 5xx may justify bounded exponential backoff. A scheduled Content API 410 means the endpoint is being retired. Retrying it can hide the percentage of catalog updates that never reached Google while stock and prices continue to change in the store.
Contain the incident first. Alert on any 410 separately from ordinary transport failures. Preserve the full response, method, Cloud project ID, merchant account, offer cohort and timestamp. Check whether failed writes include price, availability or deletion events. Compare the last accepted update with the live product page and checkout; pause promotional assumptions if Google may be holding stale data.
Determine who actually owns the connection
Not every merchant needs to change code. Google's migration guidance says merchants that send product data through a third-party platform—such as an ecommerce app or feed provider—should have the provider manage the migration. Custom scripts, internal middleware, agency connectors and SaaS products that call shoppingcontent.googleapis.com/content/v2.1 are in scope for engineering work.
Do not decide from a Merchant Center data-source label alone. Trace credentials and network calls:
- search repositories, scheduled jobs and serverless functions for
shoppingcontent.googleapis.com,content/v2.1, old client libraries andcustombatch; - inspect Cloud logs and API metrics by project, service account and OAuth client;
- list every job that creates, updates or deletes products, inventory, promotions, data feeds, accounts, users or status reports;
- record the platform or team that owns each credential, deployment and alert;
- ask a vendor for written confirmation of the API version and completed cutover—“Google integration active” is not evidence.
The output should be a method inventory, not a generic architecture diagram. Include call volume, peak rate, merchant accounts, failure consequence, current response fields consumed by your code, and the business process that depends on each method. This prevents a product-upload migration from overlooking a nightly status export or account-management job.
Merchant API is not a hostname replacement
| Content API pattern | Merchant API v1 pattern | Migration risk |
|---|---|---|
| One broad API and numeric IDs | Versioned sub-APIs and resource name values | Hand-built paths target the wrong resource |
products.insert | productInputs.insert with an explicit data source | Input goes to the wrong source or steals an offer |
| Product ID uses colon and channel | language~feedLabel~offerId, no channel | Encoding or identity breaks history |
| Product object mixes input and status | Writable ProductInput; read-only processed Product | A successful write is mistaken for approval |
products.custombatch | Concurrent calls or HTTP multipart batching | Throughput, quota and partial failure change |
| Price value and currency | amountMicros plus currencyCode | Wrong unit or rounding changes price |
Merchant API requires a one-time developer registration for every Google Cloud project used for authentication. The production Merchant Center account needs a verified website; the identity making the registration call needs admin access. Third-party applications should use OAuth 2.0 for client accounts, while an in-house integration can use a service account. API keys are not supported.
Store resource name values returned by Google instead of parsing and rebuilding them. Google specifically recommends backfilling the data-source name into the local product record. This becomes important when a merchant has primary, supplemental, local or regional data sources and when offer IDs contain reserved characters.
Map behaviour before rewriting code
For every used method, create a contract with five columns: old request, new resource and method, request transformation, response fields consumed, and acceptance test. Start with the smallest business-complete vertical slice—for example one online product write, processed-product read and issue check—rather than mechanically converting every endpoint.
- Register and authenticate. Enable Merchant API, register the Cloud project once, and confirm the human developer contact can receive notices.
- Choose the data-source strategy. Retrieve or create the intended API data source and persist its full resource name.
- Build adapters. Keep the internal catalog model stable; translate it separately into old and new payloads during comparison.
- Preserve identity. Reuse the existing
offerIdfor the same sellable item so product history is not discarded. - Define reconciliation. Compare accepted input, final processed product, issues, and visible Merchant Center counts—not HTTP status alone.
Google allows staged migration by sub-API and supports Merchant API alongside Content API. Use that flexibility deliberately. Avoid uncontrolled dual writes: two producers can race, and an incorrect data-source reference can move ownership of an offer. Run shadow reads freely; run paired writes only for a documented cohort with idempotent source events and field-level reconciliation.
Treat product input and processed product as two states
In Merchant API, ProductInput is what your system submits. Product is the read-only result after Google processes inputs, rules and supplemental sources; it also exposes product status. A successful productInputs.insert starts processing. It does not prove that the offer is approved or serving.
Build a test matrix across content languages, feed labels, countries, currencies, normal and sale prices, in-stock and unavailable items, variants, local inventory, excluded destinations, and offer IDs containing reserved characters. For each sample, assert:
- the correct data source, content language, feed label and unchanged offer ID;
- price conversion into micros with an explicit ISO currency;
- the final resource name and encoded identifier are stored, not reconstructed casually;
- the processed product matches critical source fields after processing;
- item issues and account issues are collected from the new resources;
- the landing page, Product schema and checkout still agree with Google-bound data.
Protect deletions more aggressively than updates. Resolve the exact product and data source before deleting, limit the first cohort, and fail closed if the mapping is ambiguous. A migration script that uploads correctly but deletes from the wrong source can be more damaging than the API outage it was meant to fix.
Redesign batching, quotas and error handling
Content API's custombatch has no direct method equivalent. Merchant API supports concurrent individual requests and HTTP multipart batching; a batch of N requests still counts as N requests against quota. Model partial success explicitly and attach your own event ID to logs so a retry can be correlated with the original catalog change.
Read the quota groups available to the account and load-test below them. Bound concurrency, add jittered exponential backoff only for documented transient failures and rate limits, and send permanent validation or permission errors to a dead-letter queue for review. Do not retry every 4xx response. In Merchant API, machine-readable error detail is rolling out across sub-APIs, so store the HTTP status, reason, metadata, method and sanitized payload together.
Measure end-to-end freshness: source change to accepted input, accepted input to processed product, and processed product to a correct visible offer. Request success rate alone can look healthy while sale prices arrive late or a subset of products remains disapproved.
Use explicit gates for the cutover
| Gate | Evidence | Stop condition |
|---|---|---|
| Identity | Same offer IDs, correct names and data sources | Unexpected duplicate, missing or stolen offers |
| Truth | Price, stock, URL and variants reconcile | Material field mismatch |
| Coverage | Every old method has an owner or retirement decision | Unmapped production calls remain |
| Operations | Quota, latency, partial failure and alert tests pass | Backlog exceeds freshness target |
| Commerce | Processed status, page, schema and checkout agree | Eligible offers or conversion path regress |
Move one merchant account or a low-risk product cohort first. Observe at least a full catalog update cycle and a promotion or inventory change. Increase traffic only when counts and critical fields reconcile. After full cutover, disable the old writer and alert on any new Content API request; otherwise a forgotten cron job can keep generating 410 errors and stale-data noise.
If engineering cannot finish immediately, Google offers an extension request for active integrations. Treat an approved extension as a short risk window, not a new deadline: it prevents scheduled degradation only through the approved period and does not extend beyond final decommissioning.
A seven-day recovery plan
Seven days is realistic only for a focused product integration with known ownership. Advanced-account provisioning, local inventory, promotions, reports and many client accounts may require separate workstreams. Publish a method-level burn-down and protect the highest-value freshness paths first.
Frequently asked questions
Why is Content API for Shopping returning 410 Gone?
Google began intermittent 410 responses on 1 September 2026 for projects without an active extension after the API's 18 August sunset. The failures are scheduled service degradation, not an ordinary transient outage.
Can I fix Content API 410 errors with retries?
No. Google says failure frequency will rise until final shutdown. Retry only documented transient Merchant API errors; migrate the retired call instead.
Do Shopify or other platform merchants need to migrate code?
Usually the connected platform or feed provider owns the API migration. Verify which system sends the data and ask the provider for version and cutover evidence. Custom apps and scripts remain your responsibility.
Can Content API and Merchant API run together?
Yes, Google supports staged migration. Use shadow reads and carefully bounded paired writes; prevent two producers or data sources from taking conflicting ownership of an offer.
Does a successful Merchant API insert mean the product is approved?
No. It means the input was accepted for processing. Read the resulting Product and its status or issues, then reconcile it with the intended offer.
Sources and verification date
Verified 19 September 2026 against Google's official Content API sunset timetable, Merchant API migration overview, product migration guide, developer-registration requirements, batching guidance, and error-handling guide. Timelines, quotas and method availability can change; recheck the linked documentation during cutover.
Rendframe can inventory the legacy calls, build the Merchant API adapter, reconcile catalog truth and harden the sync against partial failure. Start with the Merchant Center feed audit, review the Product schema delivery audit, or send one redacted 410 response and the affected method.