7 Ways a Google Merchant API Migration Can Fail Even When the Code Compiles

Disclosure: AI-assisted research and editing helped prepare this article. I operate MicroStudio Evidence, which offers the paid source-code dependency review described near the end. The technical claims were checked against the linked Google documentation. All evidence examples are synthetic; no customer engagement or production migration is represented. Google says the Content API for Shopping will shut down on August 18, 2026. For a custom integration, the dangerous assumption is that the migration is mostly a client-library or hostname change. It is not. The change affects method contracts, resource identity, data-source ownership, money representation, batching, quota behavior, and the distinction between an accepted input and a processed product. A team can produce code that compiles against Merchant API and still lose writes, miss products, or report false success after cutover. The fastest way to make the work reviewable is to start with a source-code dependency inventory. Every observed Content API call should end in one of three states: mapped to a tested Merchant API replacement, deliberately retired, or explicitly unresolved with an owner and a missing-evidence note. Here are seven failure modes that such an inventory should catch. 1. Endpoint search is mistaken for dependency discovery A search for shoppingcontent.googleapis.com is useful, but it is not a complete inventory. Legacy exposure can also sit behind a generated client library, a wrapper function, the ShoppingContent Advanced Service in Google Ads Scripts, or a scheduled job that nobody remembers until it fails. The inventory should connect each callsite to its job or trigger, runtime, owner, request shape, response dependency, and retirement or replacement decision. A residual scheduled job matters just as much as a direct endpoint string. This is especially important in Google Ads Scripts. Google's current Advanced APIs documentation lists Merchant API sub-APIs individually. The script creator controls those dependencies, while calls run with the permissions of the user who authorized the script. A correct method rewrite can therefore fail because a sub-API was not enabled, the authorizing user lacks Merchant Center access, or ownership changed. 2. A method name is treated as the whole contract Some operations look familiar across the two APIs, but product writes now go through productInputs while processed state is read through products. Google's product migration map also shows that productstatuses is not a service to carry forward and that customBatch must be replaced by individual asynchronous calls or HTTP batching. Each inventory row should map the legacy request, response fields, error semantics, status source, and tests—not just the nearest method name. A hostname replacement with no golden request and response fixtures is not a migration proof. 3. Resource names and data sources are rebuilt from memory Merchant API resources use names and parent relationships that should be stored from Google's responses, not reconstructed from assumptions. Product writes also require an intended API data source. An integration that points at a file or UI-managed data source can fail even if the product payload itself is valid. Google's API data-source guide is the contract to test. The migration suite should round-trip full resource names, preserve contentLanguage~feedLabel~offerId, test reserved-character encoding, and verify that the selected data source is writable by the API. 4. Decimal prices are converted with binary floating point Merchant API represents price values in micros: one currency unit is 1,000,000 micros. A copied floating-point conversion can silently create an off-by-one amount, especially for fractional or large values. Golden transformations should cover zero, fractional, large, and currency-mismatch cases. They should also test nested product attributes, currencyCode, update masks, persistent patch behavior, and unknown future enum values. Google's Merchant API design guidance is a better source than copying a legacy JSON shape. 5. The outer batch response is treated as universal success Removing customBatch changes more than syntax. HTTP batching or asynchronous fan-out still needs an identity, result, and retry decision for every operation. A successful outer HTTP response does not prove that every product mutation succeeded. The migration test should include a mixed-result batch fixture and demonstrate that failed calls can be retried without replaying successful ones. It should also keep concurrency bounded and preserve idempotency evidence. 6. Pagination and quota accounting are tested only on the happy path The first page is not a reconciliation. Every nextPageToken must be consumed, and a 500-product insert run must be budgeted as 500 insert calls rather than one logical batch. Google's quota documentation should be linked to the exact method keys in the inventory. Multi-page fixtures, 429 backoff with jitter, bounded concurrency, and per-call telemetry should exist before a production canary. 7. A successful input write is reported as product approval ProductInput acceptance is not the same as a processed Product being approved or served. After the documented processing delay, the integration should read the processed Product and inspect productStatus, destination status, and item-level issues. Google's data-issues guide describes the state that needs to be reconciled. A safe cutover therefore moves from an isolated test to a small production canary with predetermined stop and rollback thresholds. It does not leave an indefinite dual-write in place or infer approval from a successful mutation response. What a compact audit receipt looks like A useful receipt does not need to become a large architecture document. For each observed call, it can keep the owner, callsite, trigger, legacy method, Merchant sub-API and method, fixture ID, canary segment, rollback trigger, status, and evidence URL. The important result is that every observed call is labelled mapped, retired, or unresolved. An unresolved row should name the evidence gap and the next decision instead of disappearing into a general risk paragraph. The first pass can now be reproduced with the open-source lineageproof merchant-scan command. It reads an authorized local source tree without credentials or network access and emits only relative paths, line numbers, contract labels, migration hints, and line hashes—never source snippets, Merchant IDs, or API responses. The control page below links a five-finding synthetic JSON run with the exact output and its static-evidence boundary. I published a compact control design with a blank method inventory and a five-call-site synthetic receipt on the Merchant API migration controls page. The sample deliberately includes mapped, retired, and unresolved rows. It did not access a Merchant Center account, migrate a live catalog, or prove product approval. A fixed review for custom integrations For teams that maintain direct Content API calls in a backend, PIM, ERP, feed service, or Google Ads Script, MicroStudio Evidence offers a USD 249 source-code dependency review. The fixed opening scope covers one authorized source snapshot, up to 25 observed callsites, three scheduled jobs, three Merchant sub-APIs, and one review round, with a three-business-day target after scope acceptance. The output is a completed inventory, ranked migration risks, and a source cutover checklist. It does not include credentials, live Merchant Center access, API calls, developer registration, catalog upload, or production cutover. A public, metadata-only fit form is available; the GitHub username is visible, and the form is not an order or payment request. The goal is not to make the migration look complete. It is to make every remaining assumption visible before the deadline turns it into an outage.