14 days to the 18 August 2026 Content API sunset: the Merchant API migration, and the micros bug that silently

14 days to the 18 August 2026 Content API sunset: the Merchant API migration, and the micros bug that silently misprices a catalogue

Summary. Google's Merchant API migration guide, last updated 22 July 2026, carries one line at the top: "Content API for Shopping will be sunset on August 18, 2026." That is 14 days from today, 4 August 2026. Two claims repeated across almost every write-up of this deadline are wrong, and both change what your team should do this week. First, it is not a hard cutoff with no way out: Google links an extended-access application form from the top of that same guide. Second, not everyone has to act. Google states that merchants syncing product data through a third-party technology partner, naming the Google and YouTube app on Shopify, "don't need to do anything". If you do hand-build the migration, the change that costs real money is not the base URL. It is Price: the amount field moves from value:string to amountMicros:int64, where 1,000,000 micros equals one unit of your currency. Get that multiplier wrong and the API returns HTTP 200 on every call while your entire catalogue goes live at 1,000,000 times or one-millionth of the correct price. eCorpIT runs this migration for D2C and marketplace teams in India. This article is the substance of how we do it.

What Google actually says, and what everyone gets wrong

Start with the primary source rather than the summaries. The Merchant API migration guide carries two notices above the fold.

The first is the deadline: "Content API for Shopping will be sunset on August 18, 2026."

The second is the part the summaries drop. Immediately below it: "If you need additional time to migrate to Merchant API, apply for extended access to Content API for Shopping", linked to a Google Form. An extension is not guaranteed and applying is not a substitute for planning, but the widely repeated framing of 18 August as an absolute wall with no recourse does not match what Google publishes on its own page. If your engineering calendar genuinely cannot absorb this in 14 days, the form is the correct first action, submitted this week rather than on the 17th.

The second correction matters even more, because it can save a team the entire project. From the same guide: "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." Manual and spreadsheet uploads through Merchant Center are equally unaffected. The migration is for teams that call shoppingcontent.googleapis.com from their own code.

So before anyone writes a line of migration code, answer one question: does your product data reach Merchant Center through your own API client, or through a platform app? A meaningful number of Indian D2C brands on Shopify are in the second group and are about to spend a sprint on a problem they do not have.

Dora Sun of the Google Ads API Team set the date out in a post dated 9 April 2026: "The Content API for Shopping will sunset on August 18, 2026, to be replaced by the Merchant API." The same post confirmed that "the Google Ads scripts editor will begin rolling out Merchant API support on April 22, 2026", and that "The Merchant API will be available as an Advanced API in the Google Ads scripts editor, just as the Content API is." (Google Ads Developer Blog)

The five breaking changes, ranked by how much they can cost you

Not all of these are equal. Ranked by blast radius rather than by where Google lists them.

Change	Content API for Shopping	Merchant API	Failure mode if you get it wrong
Price amount	value:string, a decimal as a string	amountMicros:int64	HTTP 200, whole catalogue mispriced
Price currency	currency:string	currencyCode:string	Request rejected, loud and obvious
Product identifier	channel:contentLanguage:feedLabel:offerId	contentLanguage~feedLabel~offerId	Silent 404s on updates, stale catalogue
Batching	customBatch	Removed, use concurrent async calls	Throughput collapse under load
Developer registration	Not required	developerRegistration:registerGcp	Nothing works at all

1. Price in micros is the one that hurts

This is the change to brief your team on first, because it is the only one on the list that fails quietly.

Google's table is unambiguous. The amount field name changes from value to amountMicros, and the type changes from a decimal string to an int64. The currency field name changes from currency to currencyCode, and the format remains ISO 4217. The guide states the rule directly: "The Price amount is now recorded in micros, where 1 million micros is equivalent to your currency's standard unit."

Google's own Java sample shows the shape:

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

That is $33.45. Not $33,450,000, and not $0.03345.

Now consider the two ways a migration gets this wrong. A team that ports value: "1499.00" straight across as amountMicros: 1499 publishes a product at 0.001499 of a rupee. A team that multiplies twice publishes it at 1,499,000,000 micros, or ₹1,499,000. Neither request is malformed. Both are valid int64 values in a valid field. The API accepts both and returns success.

The failure surfaces later, in Merchant Center disapprovals, in price-mismatch policy violations against your landing page, or in Shopping ads serving at a price you never set. On a catalogue of any size, the recovery is a full re-push plus whatever the account picked up in policy strikes in the interim.

The mitigation is not clever code. It is an assertion in the migration script that refuses to publish when a converted price falls outside a sane band for the catalogue, and a diff of the first 100 converted products against the source feed before the full run. We treat that diff as a mandatory gate, not a nice-to-have.

2. the product identifier changes shape, and Google's own example is inconsistent

Content API used a colon as the delimiter and included a channel segment. Merchant API uses a tilde and drops the channel: channel:contentLanguage:feedLabel:offerId becomes contentLanguage~feedLabel~offerId.

Read Google's worked example carefully, because it is worth knowing before your team hits it. The guide gives this request:

GET https://merchantapi.googleapis.com/products/v1/accounts/4321/products/online~en~US~1234

and then states that for that call, "{name} equals accounts/4321/products/en~US~1234". The URL carries an online~ segment that the stated name value does not. A developer trying to derive the rule from the example will build the wrong string.

Google anticipates exactly this and gives the instruction twice on the same page: "we recommend using the value from the name field directly in your calls, instead of parsing or manually constructing a resource's name." The guide goes further and prescribes the pattern: "do implement a getName() method to retrieve a name from a resource, and store the output as a variable. Don't construct the name from the merchant and resource IDs yourself."

Take that literally. Any code in your migration that does string concatenation to build a product name is a defect waiting for a feed label change. Read it, store it, use it.

The wider identifier change follows Google's API improvement principles: resources are addressed by a hierarchical name rather than by loose IDs, and {name} equals accounts/{account}/products/{product}. Child resources get a parent field, so listing local inventories for a product means passing the product's name as parent rather than passing the whole parent resource.

3. customBatch is gone, and the replacement needs tuning

Merchant API does not support customBatch. Google's guidance is to use parallel asynchronous calls, and it is specific about how to size them.

The relevant note in Google's own sample: a single gRPC channel handles roughly 100 concurrent requests, and a channel pool manages several underlying connections to get past that. The sizing rule from the guide is to "estimate the number of concurrent requests you'll make, divide by 50 (50% utilization of channel capacity), and set the pool size to that number." The sample uses ChannelPoolSettings.staticallySized(30).

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

The practical consequence for anyone running a large catalogue: a naive one-request-at-a-time port of a customBatch loop will be dramatically slower than what it replaced, and the team will conclude the new API is slow when the real problem is that batching moved from the payload to the transport. Plan the concurrency work as part of the migration, not as a follow-up.

Note also that Merchant API supports both gRPC and REST, that you can run gRPC on Merchant API and REST on Content API at the same time during the transition, and that Google's client libraries require gRPC.

4. Developer registration is a hard prerequisite

One call gates everything else. You must link the Merchant Center account to the Google Cloud project:

POST https://merchantapi.googleapis.com/accounts/v1/accounts/{ACCOUNT_ID}/developerRegistration:registerGcp

{
  developer_email:"[e-mail]"
}

Until that succeeds, nothing in Merchant API works. On multi-account structures, particularly marketplaces and agencies running many sub-accounts, this is the step that consumes calendar time rather than engineering time, because it involves whoever holds Merchant Center access. Start it today, before the code work.

5. Everything else is a URL and a field-name change

The base URL format becomes https://merchantapi.googleapis.com/{SUB_API}/{VERSION}/{RESOURCE_NAME}:{METHOD}. So the Content API call GET https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products/{productId} becomes GET https://merchantapi.googleapis.com/products/v1/{name}.

Google is explicit that backwards compatibility is not guaranteed: "We can't guarantee full backwards compatibility for similar features between the Content API for Shopping and the Merchant API due to the improved design. For example, field names or method availability might differ for the same resource." Treat each sub-API as its own small migration with its own field-mapping review.

What you get in return

A deadline-driven migration is easier to fund when the destination is better than the origin. Several of these are worth planning to use rather than merely surviving.

Capability	Content API for Shopping	Merchant API
Report page size	250 rows per call	1000 rows per call
Data source types	Primary only	Primary, supplemental, local inventory, regional inventory, promotion, product review, merchant review
Product updates	Full ProductInput required	ProductsUpdate patches individual fields
Reviews	Not available	Reviews API for product and seller reviews
Account change alerts	Polling	Push notifications for account data changes
Data source delay after creation	Delay on insert	Fixed
Transport	REST	gRPC and REST

The pageSize increase from 250 to 1000 is a straight fourfold cut in report pagination calls, which matters if you pull performance data daily across a large catalogue. ProductsUpdate removes the requirement to resend every required field to change one attribute, which shortens both the payload and the failure surface on frequent updates such as price and availability.

Two capabilities are exclusive to Merchant API and will never appear in the old one: the Reviews API for product and seller ratings, and push notifications for account data changes. Google also notes a reporting change worth knowing about: the clickPotentialRank definition in the productView table is now normalised to values between 1 and 1000.

Google is direct about the strategic position: "Future features will appear only in Merchant API", with a small number of exceptions such as the 2025 annual feed spec. There is no long tail here.

A 14-day plan

Fourteen days is tight but workable for a single-account integration, and tight-but-workable is what most teams are facing on 4 August 2026.

Days 1 to 2. Determine whether you are in scope at all. If a platform app syncs your feed, stop. If you call the API yourself, inventory every caller: the feed job, the inventory sync, any price-update worker, reporting pulls, and the internal tools nobody documented. Submit the extended-access form in parallel if the inventory looks larger than the window.

Days 2 to 3. Run developerRegistration:registerGcp for every account and sub-account. This depends on other people, so it starts first.

Days 3 to 6. Port the product write path. Convert Price to amountMicros with an assertion band and a 100-product diff against the source feed before any full run. Replace all constructed product names with values read from the name field.

Days 6 to 9. Replace customBatch with concurrent async calls and a sized channel pool. Load-test against your real catalogue size, not a sample.

Days 9 to 11. Port reporting to the new page size, and the account, inventory and promotions sub-APIs you actually use. Skip the ones you do not.

Days 11 to 13. Run both paths in parallel. Content API keeps working until the sunset, so a shadow run comparing outputs is free insurance.

Day 14. Cut over. Keep the old code path behind a flag until the account has been clean for a full data-source processing cycle.

India-specific considerations

Three points change the shape of this work for teams selling in India.

Currency handling is the first and it compounds the micros risk. A rupee catalogue priced at ₹1,499 becomes amountMicros: 1499000000 with currencyCode: "INR". Indian price points carry more digits before the decimal than the dollar examples in Google's documentation, so an off-by-one-thousand error is less visually obvious in a log line. Assert on the converted value, not on the source string.

Marketplace and multi-seller structures are the second. Google notes that AccountIdAlias in the AccountRelationship resource lets marketplaces use a user-defined alias instead of the merchant's internal account ID, which is directly useful for Indian marketplaces mapping their own seller IDs onto Merchant Center sub-accounts. If you run seller sub-accounts, this is worth designing in during the migration rather than retrofitting.

Data handling is the third. Product feeds are usually commercial rather than personal data, but the moment your integration carries seller contact details, customer reviews with names, or loyalty identifiers, the pipeline falls inside the Digital Personal Data Protection Act 2023. The Reviews API in particular introduces user-generated content into a flow that previously carried none. Treat consent, retention and access control for that path as a design question during the migration, not a cleanup afterwards.

For teams also handling the GST e-invoicing and ship-to GSTIN integration work this year, the two projects touch the same order and catalogue systems and are usually worth sequencing together rather than running in parallel across the same engineers.

Where this sits in your 2026 Google surface changes

The Content API sunset is not happening in isolation. The Google Ads target bidding change of August 2026 lands in the same window, and the migration of Local Services Ads into Google Ads affects the same accounts team. Our earlier technical write-up of the Content API to Merchant API migration covers the sub-API mapping in more depth, and for brands whose Shopping feed also has to answer to AI shopping surfaces, the agentic commerce readiness work is the adjacent project. If you are selling on ONDC as well as Google, the ONDC D2C seller scale playbook sets out how the two channels' catalogue models differ.

FAQ

When exactly does the Content API for Shopping stop working?

Google's migration guide states that Content API for Shopping will be sunset on 18 August 2026. The same date appears in the Google Ads Developer Blog post of 9 April 2026 by Dora Sun of the Google Ads API Team. The guide was last updated on 22 July 2026 and still carries that date.

Is there any way to get more time?

Yes. Google links an application form for extended access to Content API for Shopping directly from the top of its own migration guide, for developers who need additional time. An extension is an application rather than an entitlement, so submit it early rather than close to the deadline, and continue the migration work in parallel.

Do all merchants have to migrate?

No. Google states that merchants using a third-party technology partner to sync product data, naming the Google and YouTube app on Shopify, do not need to do anything because the provider handles the migration. Merchants uploading through Merchant Center manually are also unaffected. Only teams calling the API from their own code must act.

What is the most dangerous change in the migration?

The Price type. The amount field changes from value:string to amountMicros:int64, where one million micros equals one unit of your currency. A wrong multiplier is still a valid integer in a valid field, so the API accepts it and returns success while the catalogue publishes at the wrong price. Every other change fails loudly.

Why did my product update stop working after the migration?

Most likely the identifier. Content API used channel:contentLanguage:feedLabel:offerId with colons. Merchant API uses contentLanguage~feedLabel~offerId with tildes and drops the channel segment. Google recommends reading the value from the name field directly rather than constructing it, and even its own worked example is inconsistent on this point.

What replaces customBatch?

Nothing, directly. Merchant API does not support customBatch. Google's guidance is concurrent asynchronous calls with a gRPC channel pool, since a single channel handles about 100 concurrent requests. The documented sizing rule is to estimate concurrent requests, divide by 50, and set the pool to that number.

Is Merchant API actually better, or is this just a forced move?

Both. Report page size rises from 250 to 1000 rows per call, ProductsUpdate allows partial product updates, multiple data source types become available, and the Reviews API and push notifications exist only in Merchant API. Google states that future features will appear only in Merchant API.

How long does a migration take in practice?

For a single account with a straightforward feed job, a focused two-week window is realistic. Multi-account marketplace structures take longer, mostly because developer registration and Merchant Center access depend on people rather than code. The concurrency rework replacing customBatch is usually the largest single engineering item.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy founded in 2021, with senior engineering teams working across ecommerce, cloud and application development. We are CMMI Level 5, ISO 27001:2022 certified and MSME registered, and we are a Google partner and a Shopify partner. If you are running a Content API integration and need it on Merchant API before 18 August 2026, we scope the caller inventory, run the developer registration across your account structure, rebuild the write path with price assertions and a pre-publish diff, and replace customBatch with a load-tested concurrent client. We also build the ecommerce applications these feeds run behind. Tell us your account structure and catalogue size at /contact-us/ and we will tell you honestly whether 14 days is enough or whether you should file the extension form first.

References

1. Migrate from Content API for Shopping to Merchant API: the 18 August 2026 sunset notice, the extended-access form link, the third-party partner exemption, the Price micros change, the tilde identifier change, the customBatch removal and the channel-pool sizing rule. Last updated 22 July 2026.
2. Merchant API is coming to Google Ads scripts starting April 22, 2026: Dora Sun, Google Ads API Team, 9 April 2026, confirming the sunset date and the Google Ads scripts rollout.
3. Overview of Merchant API: Google's Merchant API overview, linked from the migration guide for request URL format and identifiers.
4. Merchant API design: Google's design and sub-API reference, linked from the migration guide.
5. Send multiple requests at once: the page the migration guide points to as the replacement for customBatch.
6. Refactor code for concurrent requests: the channel-pool page the migration guide links for bulk-operation throughput.
7. Migrate products management: the Products sub-API migration page linked from the guide's identifier section.
8. Paginate query results: the pagination page the migration guide links when stating the pageSize increase.
9. API improvement principles, AIP-122 resource names: the external naming standard the migration guide cites for its name identifiers.
10. Introducing Merchant API: the Merchant Center Help entry for merchants rather than developers.
11. Content API for Shopping release notes (v2.1): the outgoing API's release history.
12. Latest updates, Merchant API: the aggregated update feed the migration guide points migrators at.

Last updated: 4 August 2026.