On this page · 9 sections
Summary. Content API for Shopping is shut down on 18 August 2026, confirmed verbatim in a banner carried across Google's Shopping Content and Merchant API documentation and stated once as a shutdown in Merchant Center Help. The more useful finding is what Google has not published. Its Merchant API release notes page, itself last updated on 11 August 2026, carries no July 2026 and no August 2026 entry at all, and no Google source anywhere states what happens to Content API traffic after the date: no status code, no grace period, no phased rollout. Merchant API has been generally available since July 2025 at v1, and v1beta was already discontinued on 28 February 2026, so teams still on beta missed a deadline six months ago. Two framings circulating this week are both wrong: listings do not vanish from Google Shopping at sunset, and Google has not confirmed that existing listings are unaffected. The sentence being quoted for that reassurance is about running both APIs concurrently, not about the shutdown. Anyone starting the migration today should know that registerGcp is mandatory before any v1 call succeeds and that OAuth verification alone typically takes 3 to 5 business days.
This is a working engineer's map of what actually breaks, updated on 17 August 2026, including three places where Google's own documentation contradicts itself.
What Google has confirmed, and what it has not
The date appears as a banner on every relevant documentation page: "Content API for Shopping will be sunset on August 18, 2026."
The only primary sentence that describes it as a shutdown rather than a sunset is in Merchant Center Help: "In conjunction with this launch, we are also announcing the future sunset of the Content API for Shopping. We are committed to making this transition as smooth as possible and will provide access to the Content API until August 18, 2026, after which the Content API will be shut down."
That is the entire published record of the mechanics. Google's Merchant API release notes, last updated 11 August 2026, has no entry for July or August 2026; its newest section is May 2026. With the shutdown a day away, the release-notes page says nothing about it.
So treat the following as unsourced, whoever is repeating them: that requests will start returning a particular error code, that there is a grace period, that the shutdown is phased by region, and that there is a published cutover time of day. None of it appears in a Google source.
The two framings to stop repeating
The alarming version, that product listings disappear from Google Shopping when the API shuts down, is unsupported. The API is a submission channel. Manual file uploads, scheduled fetches and Google Sheets feeds are separate mechanisms and are not being sunset.
The reassuring version is also wrong, and it is the one worth correcting because it comes from misreading a real Google sentence. The compatibility overview says: "As you start using Merchant API, your existing Content API for Shopping integration continues to function without interruption." That sentence sits under the heading "Backward compatibility". It means adopting Merchant API does not break your Content API integration, so you can run both side by side during migration. It is not a statement about what survives 18 August.
What Google does say plainly is that most merchants have nothing to do: "If you are a merchant using a third-party technology partner to sync your product data, such as the Google & YouTube app on Shopify, you don't need to do anything. Your provider will handle the API migration for you."
If you are on Shopify, BigCommerce or a similar platform, that is the answer. The rest of this article is for teams running their own integration.
The gate before any code change
Migration guides tend to open with field mappings. The blocking item is access.
Merchant API requires registerGcp, and Google's wording on the v1beta to v1 migration page is unambiguous: "You won't be able to use any v1 or v1alpha API until this step is completed." Two failure modes are enumerated, GCP_NOT_REGISTERED and GCP_NOT_REGISTERED_NO_CONTACT, the second meaning the project "lacks a user with the API_DEVELOPER role".
It also requires a dedicated Cloud project. Google states you cannot register with shared projects, which rules out the OAuth Playground and the APIs Explorer as a shortcut. On top of that: "Apps that access the Merchant API must go through the OAuth verification review process", which typically takes 3 to 5 business days.
Add those together and a team starting from scratch today cannot be live before the shutdown. That makes the extension request form the first action rather than the last. Google links it from both doc sets with the line "If you need additional time to migrate to Merchant API, apply for extended access to Content API for Shopping." Note that Google publishes no application deadline, no eligibility criteria and no stated length of extension, so plan on the assumption that it may be refused.
The OAuth scope itself has not changed. It remains https://www.googleapis.com/auth/content, the same scope Content API used.
Version status: v1 is GA and v1beta is already dead
Merchant API reached general availability in July 2025. Merchant Center Help states it "is now generally available and is set to become the primary interface for programmatic access to Merchant Center."
The deadline most teams missed is on the versioning page: v1beta was discontinued on 28 February 2026 across Accounts, Conversions, Data sources, Inventories, Issue resolution, LFP, Notifications, Order tracking, Products, Promotions, Quota, Reports and Reviews. The release notes put it plainly: "The Merchant API v1beta version discontinued. All API calls must now be directed to the v1 or v1alpha versions."
Two sub-APIs have no stable version at all. Product Studio is v1alpha only, and Reviews is v1alpha plus the discontinued v1beta. Google's stability commitment differs sharply between them: "We commit to a 12-month deprecation window for stable major versions (vX)", against alpha versions that "have no defined lifespan and can be changed or discontinued with a notice period of 30 days."
Versioning is per sub-API, not per API, so the endpoint shape is https://merchantapi.googleapis.com/{SUB_API}/{VERSION}/{RESOURCE_NAME}:{METHOD} and different sub-APIs can sit at different versions simultaneously.
The breaking changes that cost the most time
| Change | Content API | Merchant API v1 | Type of work |
|---|---|---|---|
| Price amount | value:string |
amountMicros:int64 |
Every price read and write |
| Price currency | currency:string |
currencyCode:string |
Rename |
| Batch operations | customBatch |
Removed, no equivalent | Rewrite of the upload path |
| Product identifier | channel:contentLanguage:feedLabel:offerId |
contentLanguage~feedLabel~offerId |
Every ID construction site |
| Product statuses | productstatuses service |
Folded into Product.productStatus |
Read path rewrite |
| Writes | products.insert |
productInputs.insert |
Read/write split |
| Datafeeds | datafeeds |
dataSources, no auto-creation |
Provisioning rewrite |
Prices become integers, and that is a correctness change
Google's compatibility overview is explicit: "The Price amount is now recorded in micros, where 1 million micros is equivalent to your currency's standard unit." In Content API, "Price was a decimal number in the form of a string". The amount field name changes from value to amountMicros, and the currency field from currency to currencyCode, with the format still ISO 4217.
This is not a rename. A price of 19.99 becomes the integer 19990000. Anything that was doing string comparison, decimal parsing or rounding on the old field needs revisiting, and any currency with a different minor-unit convention needs checking against the micros rule rather than against a two-decimal assumption.
customBatch is gone from four places with no replacement
Google states it directly: "Merchant API doesn't support the customBatch method featured in the Content API for Shopping. Instead, see Send multiple requests at once or execute your calls asynchronously." The concurrent requests guide repeats it: "Merchant API does not offer custom batch methods. Instead, you can arrange parallel execution of individual requests."
The removal hits products.custombatch, productstatuses.custombatch, datafeeds.custombatch and datafeedstatuses.custombatch.
There is a generic HTTP batch endpoint at batch/{sub-api}/v1, documented with a 2,000 nested-request cap and Google's own advice not to exceed 100. Exceeding the limits returns 400 Bad Request and rejects the entire request, and ordering is not guaranteed. The part that changes cost models: batching saves no quota. Google's wording is that "a batch request containing 500 insert requests is charged as 500 individual insert method requests."
For throughput, Google's guidance is parallel async calls over gRPC channel pools, noting that a single gRPC channel caps at roughly 100 concurrent streams. Its Java sample uses ChannelPoolSettings.staticallySized(30) with the rule of thumb to estimate concurrent requests and divide by 50.
Worth flagging separately: "The Merchant API client libraries require gRPC." REST still works, but the supported client-library path is gRPC only, which is a genuine refactor for anyone currently on a plain REST HTTP client.
The product identifier, and the contradiction in Google's own docs
The compatibility overview describes the change: "In Content API for Shopping, a colon (:) denotes a delimiter in product name whereas in Merchant API, a tilde (~) performs this function. The Merchant API identifier does not contain the channel part."
The authoritative format is on the products compatibility page: accounts/{account}/products/{product} where {product} is contentLanguage~feedLabel~offerId, giving names like accounts/12345/products/en~US~sku123. The same page notes that "the channel field is no longer present in Merchant API" and that products previously on the LOCAL channel "should instead set legacy_local field to true."
Three things trip teams up here.
First, the overview page's own worked example is wrong. It renders a URL as products/v1/accounts/4321/products/online~en~US~1234, carrying an online~ channel segment, two lines after the prose says the channel part is gone.
Second, Reports genuinely does keep four segments. The reports compatibility page states three separate times that "the field format changes from channel:language:targetCountry:offerId to channel~language~feedLabel~offerId". So Product.name has three segments without a channel, while product_view.id in Reports has four segments with one. Google's own Python reports sample builds f"accounts/{_ACCOUNT_ID}/products/{row.product_view.id}", feeding a four-segment report ID straight into a three-segment product resource name. Copy that pattern and the lookup fails.
Third, encoding is mandatory in cases most teams will hit. Google allows unpadded base64url encoding for ProductInput.name and Product.name, and states that "in case the product names contain characters used by Merchant API or URL-reserved characters, encoding is mandatory." The reserved list is % . + / : ~ , ( * ! ) & ? = @ # $. Any SKU containing a period, a plus or a slash needs encoding, which covers a lot of real catalogues.
Reads and writes split apart
Reads happen on products, writes on productInputs. products.insert becomes productInputs.insert, products.update becomes productInputs.patch with Google noting "the behavior is significantly different", and products.delete becomes productInputs.delete. Every productInputs write requires a dataSource query parameter.
The productstatuses service is removed entirely: "Product validation issues and destination statuses are now directly included in the Product resource within the productStatus field." Status polling collapses into products.get and products.list.
Attributes moved too. Title, price and link "are no longer top-level fields. They are now grouped within the productAttributes object." Product.gtin becomes the array Product.gtins; taxes and taxCategory are removed; and availability, condition, gender, includedDestinations and excludedDestinations change from strings to enums.
Google also names a failure mode that has no Content API equivalent. "Offer stealing occurs when a product identified by its unique key (language, feedlabel, offerID) is inserted into a different primary data source than the one it belongs to. This effectively deletes the product from the old source and moves it to the new one, where different data source rules and ownership settings may apply." A migration that writes the same offer from two code paths into two sources can silently move products between them.
Data sources are a different model, not a renamed one
The data sources compatibility page carries the change most likely to break a first deploy: "The API no longer automatically creates a 'Content API' data source on your first product insertion. In Merchant API, you explicitly create data sources before you can upload products to them."
The rest of the differences are each small and each capable of causing a silent regression:
datafeedstatuses.listhas no equivalent. You calldataSources.list, thenfileUploads.getwith thelatestalias per source, turning one call into an N plus 1 fan-out.
datafeeds.updatebecomesdataSources.updateand "usesPATCHsemantics instead ofPUT". A payload shaped for PUT no longer clears unset fields.
- The pause flag inverts.
fetchSchedule.pausedbecomesfileInput.fetchSettings.enabled, and Google spells out that "the logic is inverted.paused: trueis equivalent toenabled: false."
processingStatusstrings become enums, and the separateerrorsandwarningslists merge into oneissueslist carrying aseverity.
- The
formatblock coveringfileEncoding,columnDelimiterandquotingModeis removed, with those now auto-detected.
- Feed rules cannot be migrated programmatically at all: "Rule migrations can't be executed through the API and you must perform them manually in the Merchant Center UI."
Reporting changes shape and loses some fields
Table names move from CamelCase to snake_case, so MerchantPerformanceView becomes product_performance_view, and field prefixes are no longer required, so segments.offer_id becomes offer_id. The casing trap is documented: "Field names are in snake_case when used in API requests. Responses will always return field names in CamelCase."
Three things have no equivalent: Buy On Google metrics, the Price Insights gross-profit-change fields, and filtering on item_issues. One rename is lossy, with FREE_PRODUCT_LISTING and FREE_LOCAL_PRODUCT_LISTING both collapsing into ORGANIC, so historical series that distinguished them cannot be reproduced.
Page size, and a number that is often quoted backwards
The maximum pageSize increased from 250 to 1000 rows per API call. The paging guide then adds the detail that is usually dropped: pageSize "defaults to the maximum page size of 1000 rows."
So the default equals the maximum. Descriptions of Merchant API as "default 250, maximum 1000" are describing nothing that exists; 250 was the old Content API ceiling. The 1000 figure is confirmed for accounts.reports.search and, through Google's own code samples, for accounts.products.list.
Quotas and error handling
Google publishes no per-sub-API quota table. The quotas page says "the specific daily and per-minute limits vary significantly between different quota groups" and that quotas "are subject to elimination, reduction, or change at any time, without notice." Any article giving you a default per-minute number per sub-API invented it.
What is documented as behaviour is worth knowing:
- Daily quota resets at 12:00 midday UTC, not midnight.
- The per-minute limit is a rolling window measured from your first call.
- "By default, you can update your products up to twice per day", with the products daily call quota "generally set to 2 times the number of offer quota the merchant has".
- A
listreturning 250 items counts as one call.
- Exceeding quota returns HTTP 429 with
RESOURCE_EXHAUSTED, split byREASONmetadata intoQUOTA_REQUEST_RATE_TOO_HIGHfor the per-minute limit andQUOTA_TOO_MANY_REQUESTSfor the daily one.
- Permanent increases are refused for products, accounts and data sources: "We don't accept permanent quota increases for these types of resources."
Error handling follows AIP-193. Parse details[] for @type: type.googleapis.com/google.rpc.ErrorInfo and branch on details.metadata.REASON. Google's instruction is explicit: "Do not write code that parses or relies on the text content of the message field."
There is a caveat that decides how much of your error handling you can write today: "This error response structure is being rolled out gradually across Merchant API. Only errors returned by the Products, Reports and Data sources sub-APIs follow the format described here. Errors from other sub-APIs might still be in a legacy format and might not include the ErrorInfo metadata."
What to do today
- If a platform or agency manages your feed, confirm that in writing and stop. Google says explicitly that you do not need to act.
- If you run your own integration and are not already on
v1, submit the extension request form now.registerGcpplus OAuth verification at 3 to 5 business days cannot complete before tomorrow.
- Check whether you are on
v1beta. It was discontinued on 28 February 2026, so a working integration today is already onv1orv1alpha.
- Grep the codebase for
customBatch, for colon-joined product IDs, and forPrice.value. Those three account for most of the mechanical work.
- Create data sources explicitly before the first
productInputswrite, and passdataSourceon every write.
- Re-test the fetch schedule after migrating, because
paused: truebecomesenabled: falseand an inverted boolean fails quietly.
- Export any Reports series that distinguishes
FREE_PRODUCT_LISTINGfromFREE_LOCAL_PRODUCT_LISTINGbefore you lose the distinction.
Teams running this alongside their storefront roadmap may also want our notes on local inventory ads and default Shopping campaigns and on AI shopping agents in agentic commerce, since both depend on the same feed being healthy after the cutover.
FAQ
How eCorpIT can help
We migrate product-feed integrations as an engineering job with a code audit first, because the effort is decided by how many places construct a product ID and parse a price rather than by catalogue size. eCorp Information Technologies Private Limited has built ecommerce systems from Gurugram since 2021, is assessed at CMMI Level 5, MSME certified and ISO 27001:2022 certified, and is a Google and Shopify partner. The work usually runs across our ecommerce app development and API development teams, with regression cover from software testing because feed defects surface as lost impressions rather than as exceptions. If you are still on Content API today, contact us at /contact-us/ and we will scope the cutover against the extension you request.
References
Last updated: 17 August 2026.
