Google Shopping APIs: Merchant API Guide for 2026

Google Shopping APIs are the interfaces that let your systems manage product data in Google Merchant Center and read how those products perform.

The first call is easy. The hard part is keeping SKUs, processed products and performance joined on one offer ID, within a call budget that fills fast. Every endpoint, limit and date here comes from Google’s documentation, read on 6 November 2026.

What are the Google Shopping APIs?

The Google Shopping APIs are the Merchant API, which reads and writes your Merchant Center data, and the Google Ads API, which reports what Shopping and Performance Max campaigns did with it. The old Content API for Shopping is being shut down.

The Merchant API is a collection of sub-APIs, each versioned separately. Version 1 has been generally available since July 2025. A Shopping integration uses these:

Google’s Merchant API design overview lists the rest, such as Notifications and Order tracking. v1beta stopped working on 28 February 2026, so beta code needs moving too.

Why does an accepted product write not mean the product is live?

An accepted write means Google received your input, not that the product is live. The Merchant API splits a product in two: the ProductInput you submit and the Product Merchant Center builds from it after processing.

The read-only Product carries the effective values, status and item issues. Attribute rules, supplemental sources and automatic updates sit in between, so what you sent can differ from what Google uses.

Automatic updates for price, sale price, availability and condition come from your landing page and are on by default. Google’s product guide for the old Content API already said Google “can help maintain certain attributes of your products automatically”.

Is the Content API for Shopping still available?

No, not reliably. Content API for Shopping reached its sunset on 18 August 2026, according to Google’s Merchant Center migration guidance and its developer notice.

An integration still on v2.1 is a migration to finish. Porting requests is only the start, because four things work differently:

How do you set up Merchant API access?

You set up Merchant API access in seven steps: a Google Cloud project, credentials, a one-time registration with Merchant Center, the account link, a data source, one test product and a read-back. In that order, the first product call is a test, not a debugging session.

Access problems look like product-data errors, so read the status code before you touch a feed attribute:

Which product fields do you have to send?

Every product needs an ID, title, description, landing page, image, price and availability. Country and category rules add more, such as condition for used goods or GTIN for branded products. Google’s product data specification sets the limits:

Give each size or colour its own id and a shared item_group_id.

Check required fields per country and category before the write; the Merchant Center errors guide traces the common rejections to their source.

How do you update products without running out of quota?

You update products safely with one combined write per changed product, then a check of the processed result. Treat the Merchant API as state synchronisation, not a remote control for campaigns.

Google’s Merchant API quota guidance sets the budget:

What does the quota mean for a 20,000-product account?

For example, an account with an offer quota of 20,000 products gets about 40,000 calls a day. Three separate writes for price, stock and label would need 60,000.

Show the dataHide the data

Daily Merchant API calls for a 20,000-product account

Write pattern	Calls per day
Separate price, stock and label writes	60,000
One combined write per product	20,000
Combined write plus read-back	40,000
Changed products only, plus read-back	10,000

Send only the products that changed: at 25% a day, writes plus read-backs come to 10,000 calls. Checking processed state in bulk through the product_view report cuts the read-backs further.

A price patch rejected at 11:00 and retried at 15:00 means four hours of ads on a stale price. Log when each write was accepted, not just when it was sent.

How do you write a price change safely?

Say product 10482 drops from £49.00 to £44.00 and moves into a lower margin band. One patch sets both fields:

Keep a fixed map from SKU to offer ID that survives renames and system changes; without it, updates land on the wrong offer. Store each response with both IDs, and compare processed products with what you expected on a schedule.

Don’t push product writes every few minutes to chase auction signals: that burns quota and still reacts too slowly. Labels suit slower-moving segments; this guide to when to automate feed labels separates the two.

How do you join product data to performance data?

You join product data to performance data on the offer ID. A product read says what exists now; a performance read says what happened to products that were shown, and neither fails when they disagree.

Ad revenue and cost per product come from shopping_performance_view, segmented by segments.product_item_id.

A product that never served is in Merchant Center but missing from performance: a launch or eligibility problem. One that earned clicks last month can be gone from Merchant Center today: history, not zero spend.

A mismatched ID never throws an error; it attaches revenue and cost to the wrong SKU, or to none.

How does API data become a product decision?

API data becomes a decision only after you add what neither API knows: margin, stock cover, returns and competitor prices. Split the work into three parts:

Say a product gets plenty of clicks but its POAS is below 1: after ads, it loses money. Your model gives it a low-return custom label, and the campaign reading that label gives it lower priority on the next sync.

POAS is ROAS times contribution margin, so break-even POAS is 1.0.

POAS vs ROAS explains the difference, and the break-even ROAS calculator gives each product’s floor.

Make the change reversible, so one label update undoes it, and plan for the usual failure modes:

By hand, this join works for a short product list. Across thousands of products, with margins and stock moving daily, it stops scaling.

At Product Metrics, we do that join for every product: ad performance, margin, stock, product journeys and competitor prices. Product Segmentation then writes each segment to a Merchant Center supplemental feed as a custom label, with no product write.

How do you migrate from Content API without silent drift?

You migrate by running both paths in parallel on a small scope and comparing the resulting products, not the response codes. Both APIs can return success while producing different product state.

Start with one country, keep IDs identical on both paths and widen the cutover only when the diff is clean:

Because the old path now fails intermittently, a rollback to v2.1 only holds while you have an extension. Make the rollback an API data source you can switch off instead.

Keep the comparison running after cutover, because drift after a clean migration is common:

Our guide to product feed syncs covers ID mapping and fetch schedules, and PIM to Merchant Center the route from a PIM.

Should you build on the Merchant API or use a platform?

Build on the Merchant API yourself when you have a manageable number of products, infrequent updates and a team that can own the joins. Choose a platform when the scale outgrows that team.

Two or more signals in the right-hand column usually settle it. Either way, compare a vendor’s labels with your own profitability model on a connected account first.

Our ecommerce performance analytics guide covers the joins between ad results and product-level business measures.

Final thoughts

The Merchant API tells you what Google accepted and shows, never what a product is worth. The integration that pays off keeps SKU, offer ID and margin joined every day.

Start small: one data source, one country, one label you can reverse. Then let the row counts tell you when to widen it.

If you’re writing the sync yourself, this guide to API patterns for scalable apps covers retries, idempotency and configuration beyond the first connection.

Magnitude Marketing’s ecommerce API integration guide gives a broader view of connecting commerce systems, beyond Merchant Center.

For AI on top of these joins, Kagool’s piece on AI-driven retail analytics looks at where automated analysis is heading. Test it like a label: on a few products, over a full conversion cycle.