Google Merchant API: Submitting product data and keeping it current

A peak-season scenario: on Black Friday at 14:00, you cut the price of your best-selling product by 20% to match a competitor. Your shop shows the new price immediately. But the product feed for Google Shopping doesn't update until 3:00 the next morning. Google checks the landing page, detects a mismatch between the ad price and the shop price and disapproves the product, right in the busiest sales period of the year. Or the product keeps being advertised even though it's out of stock. The result: cancellations, bad reviews and, if mismatches keep recurring, in extreme cases a suspended Merchant Center account.

Google's Merchant API solves this timing problem. As the official successor to the Content API for Shopping, it lets you move from one update per day to real-time control. In this guide, we explain how the Merchant API is structured, how the technical integration works and which use cases make it pay off commercially.

The Content API for Shopping has been shut down; the Merchant API is the new standard

Google made the Merchant API (v1) generally available in July 2025. The v1beta preview was retired on February 28, 2026. The Content API for Shopping reached end of life on August 18, 2026, and since September 1, 2026, requests to the old API have been failing more and more often. If you need more time, you can request an extension from Google.

What this means for you: every shop plugin, repricing tool and custom script that still calls the Content API puts your Shopping campaigns at risk. File-based feeds in CSV or XML are not affected and remain available as a data source in the Merchant Center.

Your product data becomes a stream of events

Many people think of product data as a file that sits on a server somewhere, waiting to be fetched. The API changes that: product data is not a static state but a sequence of events.

The classic feed works on a pull model: Google fetches the data on a fixed schedule. If you change a price at 10:00 and the next fetch is at 16:00, your ads and your shop are out of sync for six hours.

The Merchant API works on a push model: your system, whether that's the shop, the ERP or the product information management system (PIM), sends each change to Google as soon as it happens. Stock changes, a price changes, a title gets optimized: each time, a request goes to Google. The delay drops from hours to minutes.

The Merchant API is modular and works with data sources

Google has restructured the API. Instead of a single endpoint, there are separate sub-APIs, including ones for products, inventories, data sources, accounts, reports and notifications. The URLs follow the pattern merchantapi.googleapis.com/{Teil-API}/{Version}/{Ressource}. Instead of individual IDs, the API uses a name field, such as accounts/123/products/de~DE~SKU-1001.

Primary and supplemental data sources separate master data from price and stock

The key concept is the data source. Instead of one large main feed that contains everything, you layer several sources:

• Primary data source: the base record with data that rarely changes, such as ID, title, description, image URL and GTIN. It often comes from the PIM.
• Supplemental data source: an additional source containing only price and stock, updated very frequently via the API.

The benefit: your PIM doesn't need to generate a full export every ten minutes, which is often impossible anyway. A lean script detects price changes in the ERP or shop and sends only those. Google merges the data in the Merchant Center. Important: the API can only insert products into data sources of the “API” type, so create this data source before your first upload.

The Merchant API also has dedicated data sources for local and regional inventory, promotions and reviews.

Accounts and sub-accounts can be managed via the API

For companies with multiple brands or country stores, account structure is critical. With the Accounts sub-API, you create sub-accounts for new countries or brands, assign user permissions and configure settings such as time zone, language and shipping. Instead of clicking through the interface for 50 country stores, a well-written script sets up the structure quickly and without errors, and links the Google Ads account.

The API reports errors instantly, so you can act before revenue is lost

One of the most underrated benefits is not sending data, but receiving feedback. With a classic feed, it often goes like this: you upload in the morning, in the afternoon someone notices in the Merchant Center that 500 items were disapproved because of broken image URLs, and only then does troubleshooting begin.

The Merchant API turns this process around:

• Instant error messages: If a record is technically invalid, for example with an invalid date or a missing currency, the API says so directly in its response. Since 2026, it also returns machine-readable error details. Your middleware can fix the error automatically or alert the team right away.
• Notifications on status changes: Google often detects policy violations only after review. For this, the Merchant API offers notifications on changes to product and account data, something the Content API never had. You can query the current status of every product via the Products sub-API.

You can use this to build a dashboard or a team chat alert: “Show all products that were active yesterday and are disapproved today.” That way, you fix problems before revenue drops.

It also affects bidding. Smart Bidding and Performance Max can only advertise products that are approved and correctly priced. Up-to-date data prevents outages and landing page bounces, because the ad price matches the shop price.

How to integrate the Merchant API

This section is for developers. The integration is straightforward, but authentication and error handling need care. A poorly written script can quickly burn through quotas or push incorrect prices live.

Step 1: Set up and register a Google Cloud project

• Create a project: In the Google Cloud Console, create a dedicated project with a unique name and enable the Merchant API.
• Register the project: Developer registration is new. It links your Merchant Center account to the Cloud project via the call developerRegistration:registerGcp.
• Create a service account: For server-to-server communication, use a service account rather than a user login. Download the JSON key and store it securely. It must never end up in a public repository.
• Grant access: Add the service account's email address as a user in the Merchant Center under “People and access”. Without this step, the API rejects every request with “403 Forbidden”.

Step 2: Use client libraries

Don't build the HTTP requests yourself: authentication and token handling are error-prone. Google provides client libraries for Python, Java, PHP and other languages. For Python:

pip install google-shopping-merchant-products google-auth

Step 3: Transfer products

At the core is the method productInputs.insert. It creates a product in an API data source, or replaces it if one with the same identifiers already exists. A simplified example, based on Google's official samples:

from google.oauth2 import service_account
from google.shopping import merchant_products_v1
from google.shopping.type import Price

KEY_FILE = 'pfad/zum/dienstkonto-schluessel.json'
ACCOUNT_ID = '123456789'      # Ihre Merchant-Center-ID
DATA_SOURCE_ID = '987654321'  # ID Ihrer API-Datenquelle

credentials = service_account.Credentials.from_service_account_file(
    KEY_FILE, scopes=['https://www.googleapis.com/auth/content'])
client = merchant_products_v1.ProductInputsServiceClient(credentials=credentials)

product_input = merchant_products_v1.ProductInput(
    offer_id='SKU-1001-BLUE',
    content_language='de',
    feed_label='DE',
    product_attributes=merchant_products_v1.ProductAttributes(
        title='Hoodie Navy Blue',
        link='https://www.example.com/hoodie-blue',
        image_link='https://www.example.com/images/hoodie-blue.jpg',
        availability=merchant_products_v1.Availability.IN_STOCK,
        condition=merchant_products_v1.Condition.NEW,
        price=Price(amount_micros=49_990_000, currency_code='EUR'),  # 49,99 EUR
    ),
)

request = merchant_products_v1.InsertProductInputRequest(
    parent=f'accounts/{ACCOUNT_ID}',
    data_source=f'accounts/{ACCOUNT_ID}/dataSources/{DATA_SOURCE_ID}',
    product_input=product_input,
)

try:
    response = client.insert_product_input(request=request)
    print(f'Produkt übermittelt: {response.name}')
except Exception as e:
    print(f'Fehler beim Upload: {e}')

Two differences from the Content API stand out right away: prices are given in micros (amount_micros, 49,990,000 equals 49.99), and every product is assigned to a data source. It can take a few minutes before the final product, with all checks applied, can be retrieved.

Step 4: Update price and inventory selectively

A common mistake: resending the entire record, including description and images, just to change a price. The Merchant API offers the method patchfor this, which sends only the changed fields. In 2026, Google also announced faster price and availability updates via patch , initially for approved merchants. For per-store stock, there is the Inventories sub-API with local and regional inventory.

So distinguish clearly between a full update, when the product changes fundamentally, and a transactional update, when only price or stock changes.

Step 5: Transfer many products in parallel

Sending one request per product, one after another, is too slow for 50,000 items. The Content API solved this with custombatch. The Merchant API no longer supports custombatch anymore. Instead, you send several requests in parallel or work asynchronously, for example with gRPC and a connection pool. Check the response to each request so you know which products arrived and which didn't.

Step 6: Handle errors and respect quotas

Google protects its infrastructure with quotas. If you exceed them, you'll usually get “429 Too Many Requests” or “503 Service Unavailable”. Firing off new requests immediately only makes things worse. Exponential backoff is the proven approach:

• Request fails: wait 1 second, then retry.
• Fails again: wait 2 seconds.
• Then 4 seconds, then 8 seconds.

The client libraries handle some of these retries out of the box. Even so, your scripts should be robust enough to ride out network hiccups without crashing.

Three use cases that turn real-time data into profit

Technology is a means to an end. Getting data to Google within seconds only matters if it creates a commercial advantage.

Use case A: Dynamic pricing without disapprovals

In competitive markets such as electronics or fashion, prices change several times a day. With a feed, that creates a problem: you cut the price of a laptop in your shop from €999 to €899, but the feed doesn't run for another six hours.

• Case 1: The ad still shows €999. The user clicks, sees €899 and buys. But you paid for a click on an ad showing the less attractive price.
• Case 2: You raise the price again. The ad shows €899, the shop €999. The user feels misled and leaves. Google spots the mismatch and disapproves the product.

With the API, a price change in the shop immediately triggers a request to Google. Ads and shop stay in sync, even for promotions that last only a few hours.

Use case B: Bidding by margin

Most merchants only submit selling prices. The bigger lever is custom labels for margin. If your purchase price fluctuates, your margin changes daily, even when the selling price stays the same. With a static feed, keeping a margin label up to date is a chore.

With the API, you can build simple logic:

• Margin above 30%: label 0 set to “High_Margin”.
• Margin below 10%: label 0 set to “Low_Margin”.

The change goes to Google immediately. Campaigns separated by these labels bid more on products that bring more profit today and pull budget away from products whose purchase price has risen. This lets you take product margins into account when managing your Shopping campaigns.

Use case C: Local inventory and in-store pickup

Buy online, pick up in store only works with reliable stock data. Nothing is more frustrating than driving to a store because it said “In stock”, only to find an empty shelf. With the Inventories sub-API, you update stock for each store. When the last pair of shoes sells in Munich, the POS system reports zero stock and the “Available in Munich” ad disappears. You save on click costs and avoid disappointed customers. Read more in our article on Local Inventory Ads.

We migrate step by step, without risking revenue

No one should switch over a live system overnight. The risk is too high. The proven approach is step by step, keeping the existing feed as a safety net.

Phase 1: The API as a supplement for price and availability

The existing XML feed remains the primary data source, supplying titles, descriptions, images and GTINs. At first, you only send price and availability via the API, into a supplemental data source.

• If the API connection fails, Google still has the feed data. It may be a few hours old, but the product doesn't disappear.
• The first project stays manageable, because only two fields need to be mapped.

Phase 2: Optimize content via the API

Once phase 1 is running reliably, you also update titles and descriptions via the API. This is especially useful for teams that want to test titles without waiting for IT to produce a new feed export.

Phase 3: API first

The XML feed is switched off or kept only as an emergency fallback. Your PIM or shop becomes the single source of truth and talks directly to Google.

If you still run processes on the Content API, you no longer have this leeway. The rule here: migrate the existing calls to the Merchant API first, then build out from there.

Product data is also the foundation for AI search

In its guide to generative search, Google states that AI answers can include product offers and product information, and that Merchant Center data helps products appear there and across the rest of the search results. Complete, up-to-date product data therefore matters as much for visibility in AI Mode as it does for ads.

Google keeps expanding the Merchant API for this purpose. Additions in 2026 included attributes for conversational product information, settings for checkout directly within Google's AI interfaces via the Universal Commerce Protocol (UCP), and initial read-only access for AI assistants via the Model Context Protocol. Our article on Google UCP explains how the Universal Commerce Protocol works.

Conclusion: automate your product data and you steer toward profit faster

The Merchant API is core infrastructure for any online retailer that wants to grow. With the Content API retired, it is mandatory anyway for anyone who sends product data via an API.

Increasingly, algorithms are bidding against algorithms: your repricing against your competitor's, your Smart Bidding against everyone else's. These systems are only as good as the data they receive. The more current and accurate your prices, stock levels and margin labels, the better the decisions. A feed from last night is like yesterday's newspaper: informative, but too late for fast decisions.