September 17, 2026 · 8 min read
Playbooks

Automating a Google Merchant Center product feed with an AI agent

TL;DR

Feed work is unglamorous and expensive to get wrong: a disapproved product earns nothing, and a price that disagrees with your landing page is a policy violation rather than a typo. This is what that workflow looks like when an agent does the reading and drafting and you approve the changes.

The four jobs a feed actually needs

  • Triage disapprovals — which products are rejected, for what reason, and which fixes recover the most impressions.
  • Keep price and availability truthful, because a mismatch with the landing page is what gets a whole account warned rather than one product dropped.
  • Improve titles and images on products that serve but underperform.
  • Keep the feed itself healthy — a source that fetched but did not process is a silent outage.

The rule that shapes every Merchant Center write

Merchant API has no "products" write. You do not update a product; you insert a product INPUT into a DATA SOURCE, and Google computes the served product from it. That sounds like a technicality until you try to script it, at which point every call built on the obvious mental model returns a 400.

The practical consequence is that data-source tools are part of the capability rather than extras. An agent that can insert a product but cannot create or inspect the source it goes into can only work inside feeds someone else set up by hand.

Upsert semantics matter here too: the writes are safe to re-run, which is what makes a nightly push a schedule rather than a risk.

Walkthrough: a disapproval sweep

  1. 1Ask for the disapproved products and group them by reason rather than listing them — a hundred rejections is usually four causes.
  2. 2Have the agent rank the groups by impressions lost, so the fix order follows money rather than row count.
  3. 3For fixable attributes — title, description, image — the agent drafts the corrected product inputs and you approve them as a batch.
  4. 4For price and availability, expect the strictest gate. That is deliberate: a feed price that disagrees with the landing page is a policy problem, not a data problem.
  5. 5Re-read after the push. "Accepted" is not "processed", and the difference is the whole point of checking.

Two failures that look like permissions and are not

  • An advanced (multi-client) account returns 403 on product and issue queries — "only subaccounts and standalone accounts" — while a plain account lookup on the same credentials succeeds. Re-authorizing cannot fix it, because it is not about permission. Name a sub-account instead.
  • Merchant API refuses every call from an unregistered Google Cloud project, including the call whose own job is to report an existing registration. It reports one; it cannot create one. That registration is a one-time step and it blocks everything until it is done.
One more for anyone scripting directly: the sub-account listing is a colon verb, `accounts/{id}:listSubaccounts`. The RESTful-looking `/subaccounts` path is a 404.

What to put on a schedule

  • A nightly feed health check — sources fetched, sources processed, and the gap between them.
  • A weekly disapproval digest grouped by cause and ranked by lost impressions.
  • An alert on availability drift, since out-of-stock products still serving is the failure that costs money in both directions.
  • A Shopping performance read joined to Google Ads spend, which needs both platforms in the same run.
Setting this up from Claude or Codex rather than the app? The configuration is in the Merchant Center MCP server guide.

Frequently asked questions

Can an AI agent fix disapproved products in Merchant Center?
It can read the disapprovals, group them by cause, rank them by lost impressions and draft the corrected product inputs. The changes themselves pause for your approval, and price or availability edits sit behind the strictest gate.
Why can't the agent just update a product?
Merchant API has no direct products write. A product is updated by inserting a product input into a data source, and Google computes the served product from that — so the data source is part of the operation rather than a setting.
Is a nightly product push safe to re-run?
Yes, the writes use upsert semantics. Re-running the same push updates rather than duplicating, which is what makes it safe to schedule.
Why does my Merchant Center account return 403 on products?
Most often because it is a multi-client parent account, which refuses product and issue queries — those belong to sub-accounts or standalone accounts. It is not a permissions problem and re-authorizing will not help.
Run your ad ops with an agent you can trust

Start free — 2,500 credits a month, no credit card. Every write waits for your approval.

Keep reading