A Google Merchant API migration should preserve offer identity and its verified data source. This proposed protocol separates local transformation, authorised publication and processed-product checks. It covers encoded names, US/UK contexts and stopping a defective writer. Request acceptance alone establishes neither listing eligibility nor additional traffic or orders.
In this article
A catalogue integration still using Content API for Shopping needs an immediate review before Q4. Google records sunset on August 18, 2026, intermittent 410 responses from September 1 without an active extension, and full decommissioning planned for early 2027 on a revisable schedule. That is not the same as every endpoint already being permanently unavailable. Google timetable
The useful migration task is to identify affected callers, preserve offer identity and verify processed products. A successful HTTP response does not prove listing eligibility, traffic or an additional order.
Establish who owns each integration
Start with an inventory of the ecommerce connector, feed app, internal scripts, scheduled jobs and manual operations. Record an owner, merchant account, authentication project, methods and data source for each route. Keep tokens and secrets outside that working document.
Google distinguishes custom callers from third-party platforms whose partner manages migration. Sunset scope A merchant using a managed connector should establish its compatibility status rather than introduce a second publishing route. A developer responsible for direct requests must examine that client.
When investigating a 410, retain the status, timestamp and available non-sensitive metadata. Identify the actual endpoint. A legacy API error does not mean the customer-facing product page returns 410; those are different systems. Retries can temporarily obscure the migration problem and make the operational record harder to interpret.
Keep submitted input separate from the processed product
Merchant API separates submitted ProductInput data from the processed Product. Writes identify the relevant data source. Product migration guide
Build two acceptance stages: validate the local transformation, then check the result available from Google. The first establishes what your program prepared. The second establishes what remains after processing and source rules. Combining them would turn request acceptance into an unsupported claim that the offer is ready for distribution.
In an internal ledger, distinguish prepared, sent, technically accepted, processed result checked and destination status reviewed. These are proposed workflow labels, not additional official API statuses. They help the commercial team see which evidence is still missing before a promotion starts.
Give each exception a clear next step. An accepted request awaiting readback should not share a success label with a reconciled offer. A rejected request needs a diagnosis before another attempt. This separation also makes a handover between developer and merchandising teams easier to review.
Map data sources before writing
Merchant API uses explicit API data sources, with source identifiers that need to be found and mapped to the integration. Data-source migration
The proposed procedure begins with an authorised inventory read. Build a ledger connecting an offer to its current source, relevant rules and operational owner. Review discrepancies before adding a replacement source.
Google documents “offer stealing”: inserting an existing offer into another primary source can move it and change the rules applied to it. Migration warning What looks like a duplicate publication test can therefore change the live offer.
To compare transformations, first use a local mode without publishing. The candidate transformer produces a difference file; the established route remains the only writer until cutover is authorised. Detecting a difference does not require modifying the production catalogue.
Preserve identities across US and UK contexts
The reference requires offerId, contentLanguage and feedLabel. It also documents unpadded base64url names, recommended especially for special characters. ProductInput reference
Avoid constructing a new URL with a simple colon replacement. Persist the resource names returned by the API, including encoded forms where necessary, and check that they resolve to the intended offer. Include a SKU containing a slash in your fixture set to reveal overly simple encoding assumptions.
A shared English language does not imply one currency, delivery promise or source for US and UK buyers. Targeting also depends on source settings and product attributes; a feed label is not a shipping policy. Product management and targeting
Keep technical offer identity, served country and visible commercial facts distinct. A customer must find the selected price and promise on the landing page. The same check protects against confusing a technically valid identifier with a correct international offer.
An illustrative Q4 ledger with no API calls
The following offers are fictional. Source aliases belong to an internal planning sheet; they are not identifiers ready to paste into a request.
| Offer | Language | Feed label | Expected price | Validated source alias |
|---|---|---|---|---|
| KIT-Q4-01 | en | US | 49.90 USD | source-us |
| KIT-Q4-01 | en | GB | 39.00 GBP | source-uk |
The acceptance scenario requires each row to retain its association with the verified real source. If the UK transformation reuses the USD price or US alias, the local test must fail before publishing. These prices are neither exchange-rate calculations nor actual catalogue prices.
Then compare the visible title, product link, availability and currency. Add a commercial check for a promotional price that is not ready on the landing page. That additional check is our proposed quality gate; it is separate from any promise of Merchant Center approval.
Make cutover limited and observable
The product-management guide limits these writes to API sources and separates processed-product retrieval. Management guide Prepare a representative small set before handling the entire catalogue: a simple offer, a variant, a special-character identifier and an international context.
Assign a cutover owner, an appropriate change window and a stopping rule. After each authorised operation, reconcile the expected offer, actual source and retrieved result. Processing delay remains a waiting condition, not an excuse to invent acceptance.
The reference limits versionNumber to insertions into primary sources; it is not a universal guard for PATCH. Field scope Where several producers update offers, establish ownership and processing order first. An incorrectly applied field cannot repair uncontrolled concurrent writers.
Suspending a defective writer is a more precise rollback decision than assuming the degraded legacy service will remain a reliable fallback. Preserve the last validated mapping and correction procedure so the team knows which operations it can safely stop.
Set the acceptance evidence before launching an offer
Our proposed review requires:
- an identified owner and recorded migration status for each connector;
- reconciled offer keys and sources without unintended movement;
- encoding cases checked against fixtures;
- matching processed prices, currencies and availability;
- destination diagnostics reviewed separately from HTTP responses;
- a documented way to pause the defective publishing route.
This research did not execute that matrix against a merchant account. It establishes no success rate or guaranteed processing time. Local fixtures can demonstrate transformation consistency, not eligibility of a real product.
Track errors by method, unresolved offer age and source-to-product differences. The free campaign resources can help organise these tasks. The Q4 goal is trustworthy product information. Visibility, visits and orders remain separate outcomes requiring their own evidence.
