Content API for Shopping sunsets 18 August 2026: the Merchant API migration guide

Summary. Google sunsets the Content API for Shopping on 18 August 2026, 14 days from 4 August 2026, and replaces it with the Merchant API. This is a redesign rather than a rename: request URLs move to merchantapi.googleapis.com with a sub-API and version segment, resources are addressed by an AIP-style name such as accounts/4321/products/online~en~US~1234 instead of a merchantId plus productId pair, the product ID delimiter changes from a colon to a tilde, prices move from decimal strings to amountMicros int64 values where 1,000,000 micros equals one unit of currency, so $33.45 is sent as 33450000, and customBatch is gone with no direct replacement. Two things soften the deadline. Google publishes an extended-access form for merchants who need longer, linked from the top of its own migration guide, which contradicts the "no extensions" line circulating in secondary write-ups. And if your product data syncs through a technology partner such as the Google & YouTube app on Shopify, Google states plainly that you do not need to do anything, because the provider handles the migration. Everyone still calling shoppingcontent.googleapis.com/content/v2.1 from their own code has a fortnight. Reporting pageSize also rises from 250 to 1000 rows per call, which is the one change that makes your nightly jobs faster rather than slower.

If your listings stop flowing, they stop appearing. That is the whole risk profile of this migration: it is not a crash, it is an inventory that quietly goes stale and then goes dark.

What actually happens on 18 August 2026

Google's Merchant API migration guide, last updated on 22 July 2026, carries the sunset notice at the top of every page in the section, and immediately below it a second notice: if you need additional time to migrate to the Merchant API, apply for extended access to the Content API for Shopping. The form is a standard Google Form and it is linked from the guide itself.

Take that as a safety net rather than a plan. An extended-access request is discretionary, it needs a reason, and it does not stop the underlying API from being on a retirement path. Teams treating it as a substitute for the work will discover in September that they filed for an extension to a system Google has already stopped investing in.

Before you scope anything, check whether you are actually in scope. Three groups are not.

Merchants who upload product data by file or Google Sheets are untouched. The migration is about programmatic interfaces, not about feeds you upload manually.

Merchants who sync through a technology partner are handled by that partner. Google's guidance is explicit: if you use a third-party technology partner such as the Google & YouTube app on Shopify, you do not need to do anything. Confirm it with the partner in writing, then move on.

Everyone else is in scope. That means custom feed generators, PIM-to-Merchant-Center pipelines, in-house repricers, inventory sync jobs, and anything that authenticates to shoppingcontent.googleapis.com on a schedule.

The five changes that break your code

Google describes the Merchant API as built on its API improvement principles, and the practical consequence is that almost every line of your request-building code changes shape even where the business meaning does not.

Request URLs gain a sub-API and a version

The Merchant API is modular. Instead of one endpoint surface, you call the sub-API you need, and each sub-API carries its own version. Google documents the shape as https://merchantapi.googleapis.com/{SUB_API}/{VERSION}/{RESOURCE_NAME}:{METHOD}.

Operation	Content API for Shopping	Merchant API
Get a product	GET https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products/{productId}	GET https://merchantapi.googleapis.com/products/v1/{name}
List local inventories	Not addressable by parent	GET https://merchantapi.googleapis.com/inventories/v1/{parent}/localInventories
Insert regional inventory	Product-scoped call	POST https://merchantapi.googleapis.com/inventories/v1/{parent}/regionalInventories:insert
Register your project	Not required	POST https://merchantapi.googleapis.com/accounts/v1/accounts/{ACCOUNT_ID}/developerRegistration:registerGcp
Batch several writes	customBatch	No equivalent; use concurrent calls
Read a report page	Max pageSize 250	Max pageSize 1000

That fourth row catches teams out on day one. To use the Merchant API you must link your Merchant Center account and your Google Cloud project through Developer Registration, sending a developer_email in the body. It is a one-time call, it is easy, and nothing else works until you have made it.

Resources are addressed by name, not by ID pairs

Content API identified things with a merchant ID and a resource ID. Merchant API uses a single name that carries the resource and its parents, so a product is accounts/{account}/products/{product} and a local inventory hangs beneath that.

Google's advice here is worth following literally, because ignoring it is the most common source of avoidable breakage: use the value from the name field directly rather than parsing it or building it yourself. Implement a getName() accessor, store the result, and pass it around. Do not concatenate account and product IDs into a string that looks right.

The product ID delimiter changed, and the channel segment disappeared

This one is small, mechanical, and will corrupt an entire catalogue if you miss it. In Content API a product ID looked like channel:contentLanguage:feedLabel:offerId. In Merchant API it becomes contentLanguage~feedLabel~offerId. The delimiter is a tilde, and the channel part is gone from the identifier entirely.

# Content API for Shopping
online:en:US:SKU-1234

# Merchant API
en~US~SKU-1234

# In a full resource name
accounts/4321/products/online~en~US~1234

Any regex, string split, or database column that assumes colons needs revisiting. So does any join key you built from the old format.

Price is now an integer in micros

The Price type changed in both of its fields.

Field	Content API for Shopping	Merchant API
Amount	value:string, a decimal number as a string	amountMicros:int64
Currency	currency:string	currencyCode:string, still ISO 4217
Meaning of 1 unit	"33.45"	33450000 micros

One million micros equals one unit of your currency. A price of 33.45 becomes 33450000. A price of ₹1,299 becomes 1299000000.

This is the change most likely to reach production undetected, because a wrong conversion still produces a valid request. Multiply by a thousand instead of a million and every item in your catalogue lists at a thousandth of its price, and Google will accept it. Write the conversion once, in one helper, with a unit test that asserts both directions. Do not let each service do its own arithmetic.

customBatch is gone

Merchant API does not support the customBatch method. Google's replacement guidance is to send multiple requests concurrently rather than in one envelope, and to use asynchronous calls with the client libraries.

For teams doing bulk work at volume, Google's own concurrency guidance is specific and unusually useful. A single gRPC channel handles roughly 100 concurrent streams, so throughput comes from a channel pool rather than a single connection. Google's Java sample configures the pool explicitly, and its sizing rule is to estimate your concurrent request count, divide by 50 for 50% channel utilisation, and set the pool to that number.

InstantiatingGrpcChannelProvider channelProvider =
    InstantiatingGrpcChannelProvider.newBuilder()
        .setChannelPoolSettings(ChannelPoolSettings.staticallySized(30))
        .build();

ProductInputsServiceSettings settings =
    ProductInputsServiceSettings.newBuilder()
        .setCredentialsProvider(FixedCredentialsProvider.create(credential))
        .setTransportChannelProvider(channelProvider)
        .build();

The same sample builds a price the new way, which is the clearest statement of the micros change in Google's own code:

Price price = Price.newBuilder()
    .setAmountMicros(33_450_000)
    .setCurrencyCode("USD")
    .build();

Google supports both gRPC and REST, and says gRPC is the recommended integration path. The client libraries require gRPC and use it as the default transport. If your feed pipeline is a Python or Node service that only speaks JSON over HTTPS today, budget for that transport decision rather than discovering it mid-cutover.

What you get in return

A forced migration is easier to fund when it carries features you actually wanted. Several of these are Merchant API only, and Google has said future features will appear there with few exceptions.

Reviews move into the API. Product reviews and merchant reviews can be uploaded and managed programmatically, through dedicated data source types.

Push notifications exist. You can subscribe to notifications for changes to an account's product data instead of polling for state.

Data sources became plural and typed. Beyond the primary product source, you can create supplemental product, local inventory, regional inventory, promotion, product review and merchant review data sources.

Issue resolution and order tracking became sub-APIs. Issue resolution exposes the diagnostic content and support actions that were previously only in the Merchant Center interface, and order tracking signals feed shipping estimates and the free and fast shipping annotations.

Omnichannel settings, LFP providers and Google Business Profile links are first-class resources under the Accounts sub-API, alongside OnlineReturnPolicy for creating and updating return policies.

Product updates got lighter. A ProductsUpdate method lets you update individual products without supplying every field that a full ProductInput requires, which for a repricer is the difference between a small patch and a full document rewrite.

Reporting got faster. Maximum pageSize rose from 250 to 1000 rows per call, and Google fixed a delay that previously affected product, promotion and review insertion after a data source was created.

There is also a Google Product Studio API exposing generative features, which Google's Ads developer team called out when it announced the scripts timeline.

Google Ads scripts already moved

If your Shopping automation lives in Google Ads scripts rather than in your own services, this migration reached you in April. Dora Sun of the Google Ads API Team wrote in the announcement on 9 April 2026: "For Google Ads scripts users, the Google Ads scripts editor will begin rolling out Merchant API support on April 22, 2026." The Merchant API is available there as an Advanced API, the same way the Content API was.

The same post flags a compatibility detail worth knowing if your catalogue predates omnichannel: the Merchant API is designed around omnichannel, and provides backward compatibility for the older separate online and local offer structures through a legacy_local flag.

A 14-day cutover plan

You have a fortnight. This is the order that fails cheapest, and it front-loads the two steps that block everything else.

Days	Action	Exit criterion
1	Register the Google Cloud project via developerRegistration:registerGcp and confirm account access	A successful authenticated products.get against a test account
2 to 4	Write the identifier and price adapters: name handling, tilde delimiter, micros conversion	Unit tests pass in both directions on a sample of real SKUs
5 to 8	Replace customBatch with concurrent async calls and a sized channel pool	Bulk write throughput matches or beats the old batch job
9 to 11	Run both pipelines in parallel against a test Merchant Center account	Product counts, prices and availability match field by field
12 to 13	Cut over the primary data source, keeping the old job disabled but deployable	Zero new account issues after a full sync cycle
14	Decommission Content API calls and remove credentials	No traffic to shoppingcontent.googleapis.com in logs for 24 hours

Two notes on that table. Google states that the Merchant API is designed to work alongside Content API for Shopping, so days 9 to 11 are genuinely available to you rather than theoretical. And Google also warns that it cannot guarantee full backwards compatibility for similar features, because field names or method availability might differ for the same resource. Comparing counts is not enough. Compare fields.

If day 11 arrives and parity has not landed, that is the moment to file the extended-access request, not day 18.

India-specific considerations

Indian sellers hit this deadline through a slightly different door. A large share of Indian D2C catalogues reach Merchant Center through Shopify, WooCommerce plugins or a marketplace integrator rather than through code the brand owns, and those are the cases Google explicitly excludes from developer action. The first task for most Indian brands is not engineering at all. It is establishing which of your channels are partner-managed and which are a script someone wrote in 2023 and left running on a scheduler. Brands running an ONDC seller and D2C scale playbook alongside Google Shopping usually have more of these orphaned jobs than they expect, because each channel was onboarded by a different team.

Where the code is yours, two local details matter more than they do elsewhere.

Currency conversion is where the micros change bites hardest for rupee catalogues, because Indian price points carry more digits before the decimal and fewer after it. A price of ₹1,299 is 1299000000 micros. A price of ₹1,299.50 is 1299500000. Integer overflow is not a realistic risk at int64, but a truncating cast in a language that defaults to 32-bit integers absolutely is. Check the type of the variable, not just the arithmetic.

Multi-region catalogues get simpler and then more complex. Regional inventory as a typed data source is a genuine improvement for brands running different prices across Indian states or fulfilment zones, but it is also new surface area to model. If you have been faking regional pricing with duplicate SKUs, this migration is the moment to stop, and it belongs in the same conversation as your broader retail and D2C technology decisions.

On privacy, product feeds are usually not personal data, but the Merchant API also carries account, user access and review resources. Reviewer identifiers and any customer data you attach to reviews or loyalty features fall under India's Digital Personal Data Protection Act 2023, and a migration is the cheapest moment to get the retention rules right rather than the most expensive one later.

The mistake that costs the most

The expensive failure in this migration is not a missed endpoint. It is a successful sync of wrong data.

Content API rejected a malformed request loudly. Merchant API will happily accept a correctly shaped request carrying a price that is a thousand times too small, a product name you constructed by hand that resolves to the wrong SKU, or an availability value written into a supplemental source that quietly overrides your primary one. Every one of those returns a 200.

So the acceptance test for this work is not "does it run". It is a field-level diff between what your database says and what Merchant Center reports, run on real SKUs, before the old pipeline is switched off. Build that diff first. It is the only artefact from this migration you will still be using next year.

FAQ

What exactly happens to Content API for Shopping on 18 August 2026?

Google sunsets it. The replacement is the Merchant API, and Google has published the sunset date consistently across its migration guide and its Ads developer blog since April 2026. Programmatic integrations that still call the Content API after the sunset stop being a supported path for sending product data to Merchant Center.

Is there any extension available?

Yes. Google links an extended-access form directly from its Merchant API migration guide for merchants who need additional time. That contradicts secondary write-ups describing the date as a hard cutoff with no extensions. Treat it as a fallback rather than a plan, because it is discretionary and the underlying API is still retiring.

I upload my feed through Shopify. Do I need to do anything?

No. Google states that merchants using a third-party technology partner to sync product data, such as the Google & YouTube app on Shopify, do not need to act, because the provider handles the API migration. Confirm the position with your partner in writing, then check whether any secondary script of your own also touches the API.

What is the biggest code change in the Merchant API?

Prices. The amount field moved from value, a decimal number held as a string, to amountMicros, an int64 where one million micros equals one unit of currency. The currency field moved from currency to currencyCode. A wrong multiplier produces a valid request and a catalogue priced incorrectly, so test both conversion directions.

How do product identifiers change?

Content API used channel:contentLanguage:feedLabel:offerId with colons. Merchant API uses contentLanguage~feedLabel~offerId with tildes and drops the channel segment from the identifier. Resources are then addressed by a full name such as accounts/4321/products/online~en~US~1234, which Google recommends you read from the response rather than construct yourself.

What replaces customBatch?

Nothing directly. Merchant API does not support customBatch. Google's guidance is to send requests concurrently using asynchronous calls, and for bulk work to configure a gRPC channel pool, since a single channel handles about 100 concurrent streams. Google's sizing rule is concurrent requests divided by 50, set as the pool size.

Did anything get better, or is this purely migration cost?

Several things improved. Maximum reporting pageSize rose from 250 to 1000 rows per call, reviews and push notifications became available through the API, data sources became typed and plural, and a ProductsUpdate method allows partial product updates without resupplying every required field.

Does this affect Google Ads scripts?

Yes, and it already happened. Google began rolling out Merchant API support in the Google Ads scripts editor on 22 April 2026, where it is available as an Advanced API alongside the Content API. Scripts still calling the Content API need the same migration work as any other integration.

How eCorpIT can help

eCorpIT is a Gurugram-based, ISO 27001:2022 certified engineering organisation, and our senior teams build and maintain the product-data pipelines that sit between a PIM or ERP and Google Merchant Center. For this migration we map every Content API call in your stack, write the identifier and micros adapters with tests, replace batch jobs with sized concurrent calls, and run a field-level parity diff before anything is switched off. If 18 August is closer than your sprint board suggests, talk to us, or read how we approach ecommerce app development and the Google Ads changes landing in the same month.

References

1. Migrate from Content API for Shopping to Merchant API, Google for Developers, last updated 22 July 2026.
2. Merchant API overview, Google for Developers.
3. Merchant API design and sub-APIs, Google for Developers.
4. Migrate products management, Google for Developers.
5. Refactor code for concurrent requests, Google for Developers.
6. Send multiple requests at once, Google for Developers.
7. Paginate query results, Google for Developers.
8. Subscribe to push notifications, Google for Developers.
9. Merchant API is coming to Google Ads scripts starting April 22, 2026, Dora Sun, Google Ads Developer Blog, 9 April 2026.
10. Google Product Studio API overview, Google for Developers.
11. AIP-122: Resource names, Google API Improvement Proposals.
12. Merchant API client libraries, Google for Developers.
13. Manage data sources, Google for Developers.
14. Quotas and limits, Google for Developers.

Last updated: 4 August 2026.