The short answer
An HTTP 410 alone does not identify the cause. If a Content API for Shopping response includes reason=content_api_sunset, Google documents intermittent failures for projects without an active extension from September 1, 2026. A successful retry does not resolve the sunset. Identify who owns the integration, then verify the Merchant API data source, exact product, processed status, and ongoing updates before calling the migration complete.
Is this the sunset error, and who owns the fix?
Google dates the Content API sunset to August 18, 2026, with intermittent HTTP 410 failures from September 1 for projects without an active extension. Its documented error includes reason=content_api_sunset and Cloud project metadata. Preserve the endpoint, timestamp, and redacted error before diagnosing a generic 410 as this event.
The current timetable places full decommissioning in early 2027, subject to revision. Retries may succeed during degradation; they are not a migration strategy. Google assigns a third-party platform's migration to that provider. A merchant's separate custom script still needs its own owner. An approved extension is temporary.
| Your route | First action | Evidence to retain |
|---|---|---|
| A platform partner runs the entire sync | Identify the partner; use its migration and incident process | Provider confirmation and current product-sync evidence |
| Your team owns direct Content API calls | Assign a migration owner and inventory the callers | Jobs, endpoints, Cloud project, affected accounts, and redacted errors |
| Platform sync plus custom scripts | Review both paths separately | A platform update does not establish that the custom job moved |
| The request path or owner is unknown | Resolve ownership before changing product sources | Do not infer the caller from a Merchant Center source label alone |
A source labelled Content API can still be used by Merchant API
Google allows existing Content API data sources to be used with Merchant API. Their Merchant Center label can remain Content API after the caller migrates. Inspect actual requests and source resource names; the label alone does not prove that deprecated endpoints are still being called.
Choose the data source deliberately. New sources require explicit creation, and existing sources retain label/language constraints. Google documents that inserting an existing product into a different primary source can move it and change the applicable rules. A cosmetic rename or an unreviewed replacement source is not a cutover check.
Source: Google Merchant API: Migrate data sources; Google Merchant API: Migrate products
A successful write is one stage of the evidence
Merchant API separates submitted ProductInput data from the read-only processed Product, which includes productStatus. The product migration guide also changes resource names and requires a dataSource for product-input writes. Retain the same offerId for the same product, and review the intended account, language, feed label, and source together.
The insert reference says the processed product may take several minutes to become retrievable after a change. The product-management guide explicitly separates successful insertion from approval to show on Google. Keep the returned input, later processed record, and destination-specific status as different observations.
Source: Google Merchant API: Migrate products; Google Merchant API: productInputs.insert; Google Merchant API: Add and manage products
Eight checks before declaring the cutover complete
This is an authored manual review method, not a Google certification or an executed migration. Set the review sample, owners, observation window, and stop conditions before testing. A sample can expose a defect; it cannot establish that every catalog record is correct.
| Check | Evidence to collect | Keep open when |
|---|---|---|
| 1 · Caller inventory | Account, Cloud project, job owner, old and new request paths | A job or integration owner is unresolved |
| 2 · Registration and access | Developer registration and authorized access for the intended account/project | Only a different project or account was tested |
| 3 · Source ownership | Existing and chosen dataSource names, rules, label, and language | Source movement or rule effects have not been reviewed |
| 4 · Exact identity | Same offerId and an explicit match of account, language, feed label, variant, and pack | Only title similarity or aggregate counts were compared |
| 5 · Value mapping | Expected and submitted price/currency, availability, and relevant attributes | A type conversion or missing field remains unexplained |
| 6 · Processed result | Returned input, later processed Product, issues, and destination status, each timestamped | Only the write response was saved |
| 7 · Update continuity | An authorized controlled change and its later processed result; expected and actual reconciliation | Only the initial load was observed |
| 8 · Cutover control | Named active writer, monitored jobs, stop conditions, and approved recovery procedure | Competing writers or an untested recovery dependency remain |
Source: Google Merchant API: Start your migration; Google Merchant API: Migrate data sources; Google Merchant API: Migrate products; Google Merchant API: Add and manage products
Check the price type, not just the field name
Google's migration overview changes Price.value to Price.amountMicros and currency to currencyCode. One currency unit equals 1,000,000 micros. A fictional USD 19.99 item therefore maps to amountMicros=19990000 and currencyCode=USD. This arithmetic example is not a complete request or an observed provider response.
Reconcile the represented amount after conversion. Merely renaming value to amountMicros while retaining 19.99 does not preserve USD 19.99. Keep currency explicit and resolve any rounding policy before converting amounts that your own source permits.
Use one record to expose the missing evidence
The worksheet includes a blank cutover record and four fictional review situations: a retry mistaken for recovery, a migrated caller with the old source label, a successful write without a processed observation, and competing writers after cutover. They demonstrate review decisions, not measured failure rates or real merchant incidents.
Keep credentials, access tokens, customer data, and raw internal logs out of a shared worksheet. Store private evidence in an authorized location and reference it by a redacted record ID. Close a check only against the named evidence; leave unresolved observations visible.
Download four fictional cutover review cases (JSON)Review freshness after the migration
Define what must continue working after the initial load: price changes, availability changes, error handling, and reconciliation for the agreed sample and window. Record the expected result before an authorized test and compare it with a later observation. Do not create competing production writers just to obtain a sample.
A completed migration review does not demonstrate impressions, clicks, sales, or catalog-wide approval. Use the existing freshness method for supplied snapshots, then measure commercial outcomes in their own reporting. This guide supplies a review method; no merchant account was migrated for it.
Sources & scope
Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.
- Google: Content API deprecation and sunset ↗
Supports the dated degradation timetable, structured sunset error, retry limits, extensions, and provider/custom integration responsibility. The decommissioning timetable is subject to revision.
Checked October 17, 2026 - Google Merchant API: Start your migration ↗
Requires developer registration linking each Cloud project with the primary Merchant Center account. It does not verify a reader's account access.
Checked October 17, 2026 - Google Merchant API: Migrate data sources ↗
Supports retaining compatible existing sources and their Content API display label, explicit source creation, source strategy, and rule/ownership checks.
Checked October 17, 2026 - Google Merchant API: Migrate products ↗
Separates submitted and processed resources, documents productStatus, required source selection, offerId continuity, and unintended moves between primary sources.
Checked October 17, 2026 - Google Merchant API: productInputs.insert ↗
Documents the input response, required API data source, and possible processing delay. No exact completion deadline is promised.
Checked October 17, 2026 - Google Merchant API: Add and manage products ↗
Distinguishes a successful insertion from approval to show on Google and identifies the later processed resource and status.
Checked October 17, 2026 - Google: Migrate from Content API to Merchant API ↗
Documents amountMicros and currencyCode. The USD 19.99 conversion and eight-check review framework are authored examples, not an executed integration.
Checked October 17, 2026
AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.
Editorial policy & corrections ↗Cite this guide
George Kelly. Content API 410 Gone: diagnose the sunset and review your migration iamgeorgekelly. Updated October 17, 2026. https://www.iamgeorgekelly.com/field-guide/content-api-410-merchant-api-migration
Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.