How can you connect Google Merchant Center to AI for daily checks on disapprovals, feeds, and traffic?

If you run cross-border ecommerce, lead an independent store, or manage operations, you may have seen this: a product has been disapproved for days before anyone notices, or free product traffic has already fallen while nobody has opened the dashboard. Once Google Merchant Center is connected to AI, it can check products, feeds, shipping, and traffic every day, then notify operations only when something is wrong.

Google Merchant Center, often shortened to GMC, sends product information into free listings and Shopping placements. Think of the API as a controlled data window: AI can inspect the account, but it cannot change settings at will. I will cover what Merchant API can read, how to connect it from scratch, how to turn it into daily monitoring, and which changes still need human approval.

Copy this prompt first and have AI build it from zero

If you would rather skip the technical details for now, send the prompt below directly to Codex, an AI assistant that can write and run code. Claude Code, Cursor, and OpenCode can also do this. It should confirm the environment first, then move from permission setup to daily automated checks.

You are my Google Merchant Center API automation setup assistant.
Goal: starting from zero, complete Google permission setup, Merchant API connection,
read-only auditing, daily anomaly checks, and weekly reporting. Verify each stage
before moving to the next one.
Before you begin, ask me:

Am I using Windows, macOS, or Linux? Can I run Python locally?
Can I sign in to Google Merchant Center? Am I an admin or a standard user?
Will this manage only my own company’s Merchant Center, or will it serve clients/external merchants?
What is the Merchant Center account ID? Do not ask me to put any token, private key, client secret, or password into chat.
Do I already have a Google Cloud project? If yes, what is the project ID?
Where should the daily digest be saved, and how should it notify me?

Work through the following stages:
Stage 1: permissions and project

Check Merchant Center account permissions. If they are insufficient, tell me what the account owner needs to do.
Create or select a Google Cloud project.
Follow Google’s current official guidance when choosing authentication: for an account that only manages its own company, prefer a service account;
for clients or external merchants, use OAuth 2.0.
Service-account path: create a service account and JSON private key, add its email to Merchant Center users;
registration requires Admin permission.
OAuth path: configure the consent screen and OAuth client, then download the client-secret JSON.
Both paths use https://www.googleapis.com/auth/content.
Tell me to store credential JSON in a local private directory and add it to .gitignore.
Enable merchantapi.googleapis.com.
If GCP_NOT_REGISTERED is returned, explain the account impact of registerGcp, stop, and request approval;
perform developer registration only after approval.

Stage 2: read-only client

Build a client with no resource writes. Read account, data source, product, and shipping resources with GET;
Performance may use POST queries through the official Reports API, but it must not modify account resources.
Do not implement creating, updating, or deleting products or settings.
The OAuth path supports automatic token refresh; the service-account path reads its private key safely.
Keep tokens and private keys local and do not print them in logs.

Stage 3: audit

Read account, autofeedSettings, dataSources, processed products,
itemLevelIssues, shippingSettings, and product performance.
Output product count, feed count, Autofeed count, disapproved product count, issue codes,
affected countries, product links, price, currency, availability, and the latest check time.
Deduplicate the same product across reporting contexts.
Generate a redacted audit.json. Do not store tokens, client secrets, email addresses, or complete account identifiers.

Stage 4: automated monitoring

Provide four commands: authorize, audit, daily, and weekly.
daily saves a dated snapshot and latest.json, then alerts only when product count, feeds, disapprovals,
countries, or fields are abnormal.
weekly compares historical trends and excludes the most recent two-day backfill window from Performance.
Create a runnable scheduled task for my system and perform one smoke test.

Stage 5: acceptance

Demonstrate on the spot: it can read product count, disapproval reasons, affected countries, feed sources,
and most recent successful time; it can save historical snapshots and trigger a notification with a simulated anomaly.
For SERVICE_DISABLED, check whether the API is enabled. For GCP_NOT_REGISTERED,
explain developer registration. Do not guess that every error is an expired token.
Finish with a README, commands, file list, acceptance results, unverified scope, and a way to revoke authorization.

Safety boundary:

Any action that disables Autofeed or changes shipping, products, or account settings must stop first.
Give the intent, scope, pre-state, version marker, verification plan, and rollback plan, then wait for my separate approval.
Never ask me to paste a complete credential into chat, upload it to Git, or put it in a screenshot.

Now ask me the six preflight questions first. Do not dump every later step on me at once.

Why does manual GMC review miss problems so easily?

GMC problems rarely come looking for you. A product may be disapproved, a country may be missing shipping, or an availability field may disappear. Usually, someone has to open the dashboard and drill into “Needs attention” before seeing it.

For a cross-border ecommerce team, the effect lands directly on exposure, traffic, and investigation time:

• A product that fails review can lose free-listing exposure and Shopping traffic.
• A sudden drop in feed or product-record count may mean that a language, market, or data source has broken.
• A mismatch in price, currency, availability, or shipping country can keep products from appearing in part of the market.
• The later a team notices, the longer the investigation window becomes and the harder it is to tell which day traffic began to fall.

One typical case looks like this: a product shows Not approved. The page has stock, but the GMC record lacks availability, meaning the availability status. The product link also points to a language homepage rather than the correct product page. This came from one of my real Shopify stores.

If I only send a screenshot to AI, it can see only the screenshot layer. After connecting the API and checking all data sources alongside processed-product records, I found that the official Shopify feed was fine. The extra Autofeed source was the problem.

A feed is the product list that a store submits to Google. Autofeed is another list Google extracts from the site automatically. A processed product is the record Google actually reviews and displays after combining data and rules.

The useful part of this experience is not that I fixed one product. It exposed the blind spot in manual review: the dashboard shows a result, while the API lets you inspect the sources behind that result at the same time.

What can AI actually inspect after Merchant API is connected?

Merchant API is Google’s current interface for reading and managing Merchant Center. Read-only mode already covers most routine operations checks.

GMC covers products, feeds, review status, and Shopping performance. GSC covers web pages, queries, organic-search clicks, and rankings. In my actual data, GMC had far fewer clicks than GSC because it covers product and shopping contexts, while GSC also includes pages such as blog posts. You can compare trends across the two, but their objects and definitions differ, so do not add them together or treat them as channel-attribution shares.

When I review GMC performance, I use this order:

1. Impressions fall: Check whether products were disapproved, target countries shrank, or feed and product records dropped suddenly.
2. Impressions hold but clicks fall: Then check whether the title, main image, price, and search intent still match.
3. Clicks hold but orders fall: Go back to Shopify, GA4, and onsite conversion checks. GMC data alone cannot prove where a sales decline occurred.

How do you connect Google Merchant Center to AI?

The code itself is manageable. The part that usually blocks people is the three layers of authorization. Miss one, and the request fails, but the error can mean something completely different.

1. Decide the use case. Use a service account for an internal account; use OAuth 2.0 when external merchants need to authorize access.
2. Prepare the project and credentials. A service account needs a downloaded JSON private-key file, a local identity credential, and its email must be added to Merchant Center. OAuth needs a consent screen and client. Credentials do not belong in Git or chat.
3. Set the scope. Both paths use https://www.googleapis.com/auth/content. There is currently no separate read-only scope.
4. Enable the API. Enable merchantapi.googleapis.com in Google Cloud. If you receive SERVICE_DISABLED, check the service switch first.
5. Register the project. If you receive GCP_NOT_REGISTERED, register the GCP project that calls the API:

POST accounts/YOUR_MERCHANT_ID/developerRegistration:registerGcp

registerGcp adds API developer identity at the account level. The account owner must approve it before the first execution, and the request needs an Admin identity.

Next, build a client that performs no resource writes. Read accounts, feeds, products, and shipping through GET. Use POST only to query performance reports, not to change account resources.

from google.auth.transport.requests import AuthorizedSession
from google.oauth2 import service_account

SCOPE = "https://www.googleapis.com/auth/content"
merchant_id = "YOUR_MERCHANT_ID"
creds = service_account.Credentials.from_service_account_file(
    "service-account.json",
    scopes=[SCOPE],
)

session = AuthorizedSession(creds)
url = f"https://merchantapi.googleapis.com/products/v1/accounts/{merchant_id}/products"
response = session.get(url, params={"pageSize": 1000}, timeout=45)
response.raise_for_status()

for product in response.json().get("products", []):
    print(product.get("offerId"), product.get("productStatus", {}))

This code demonstrates authentication and product reading for an internal account only. Use OAuth 2.0 for external merchants. A complete client also needs pagination, error handling, field redaction, and the other endpoints.

An operations lead does not need to inspect the code line by line. At handoff, I look for six things: total product count, disapproval reasons and countries, feed sources, latest successful time, historical snapshots, and whether a simulated anomaly triggers a notification.

One query is not enough. How do you turn it into a daily automated check?

When a script prints a result once, operations still has to run it every day. The time-saving approach is to save a daily snapshot, meaning a record of that day’s state, and compare it with the previous day.

My daily check saves these signals:

• Total processed products.
• Counts for the Shopify API feed and Autofeed.
• Disapproved-product count, issue codes, and affected countries.
• Product-link, price, availability, and target-country anomalies.
• The most recent check time and whether the task succeeded.

latest.json feeds the Daily Digest, while historical snapshots support the weekly report. Four operational details matter while it runs:

• The same product issue can return in more than one reporting context, so deduplicate by product.
• GMC Performance has delayed backfill. The weekly report should exclude the most recent two days to avoid a false crash alert.
• A processed product is not the same thing as a physical product count. One product can produce multiple records across language or market feeds.
• A scheduled task returning code 0 only means that run ended. You still need to monitor expired authorization, empty API responses, and notification failures.

Schedule the job away from the Shopify feed-sync window, at a time when the team can still handle an anomaly that day. Keep quiet when numbers have not changed. Notify operations only when product count, feeds, or concentrated disapprovals are abnormal.

AI can check every day, but it should not make changes on its own

Merchant API has a broad authorization scope. Even when the current code only reads, a private key or refresh token could be used for writes by other code. The safety boundary belongs in the workflow.

Routine reads can run automatically. Live changes, such as disabling Autofeed, changing shipping, or archiving a data source, need separate approval.

When a change is genuinely needed, I follow this sequence:

1. State the scope of the change and save the full state plus the etag version marker.
2. After the account owner approves it, change only the target fields.
3. Read again after the write and compare the previous settings. Wait for asynchronous processing rather than resubmitting.
4. Keep a rollback method that restores the pre-change state.

One real fix makes the boundary concrete:

• A batch of products was disapproved only in one European country. The eventual cause was a missing GMC Shipping Settings configuration.
• After I completed the shipping rule, the other settings stayed unchanged and the relevant disapprovals disappeared. This is one successful sample, not a remedy for every disapproval.
• Titles, prices, and availability should usually be changed at the Shopify source so the next sync does not create the same conflict again.

Which stores should do this, and where should they start?

If you have only a few products, sell in one market, and review GMC once a month, manual review may cost less. API access brings permission, script, and maintenance costs. More integration is not automatically better.

Read-only monitoring begins to make sense when any two of these are true:

• You operate feeds across multiple countries or languages.
• Product disapprovals have gone unnoticed for several days before.
• Nobody on the team has a fixed GMC review routine.
• Product count, feed count, or free-product traffic needs weekly reporting.
• You already use AI for daily reporting and want GMC in the same workflow.

Do not start by changing settings automatically. Start with four actions, authorize, audit, daily, and weekly, and make them reliably answer four questions: products, feeds, disapprovals, and affected countries.

Get the read-only checks stable first. Remove missing records, false alerts, and notification failures before considering write access. For most teams, seeing disapprovals and traffic anomalies on the same day already solves one of GMC’s most difficult operational problems.

What could I write about next?

I also connect GSC, GA4, Shopify, and Google Ads into the same automation dashboard, updating it each day instead of copying numbers across separate backends. If there is interest, I can write about connecting GSC or GA4 next.

Official Google resources

• Merchant API Overview
• Merchant API authentication
• Register a GCP project
• List processed products
• Search Merchant Center reports