How do I stop an agent touching the wrong client's Merchant account?

Map the Merchant account ID to the workspace. A request naming a different Merchant account is refused before the credential is read, so no Google call is made. One agency Google identity can therefore serve many client Merchant accounts without them reaching each other.

Can agents change Merchant account settings or users?

No. Account-administration calls are blocked by runtime policy and return ACCOUNT_ADMIN_BLOCKED. That is a hard block, not a capability you can toggle on from the agent side.

Are write operations verified?

No, and we will not claim otherwise. Only a read-only proof has been run through Outloop against a live Merchant account — deliberately, because it is a production account with real product data. Write operations are supported by the API and permitted through bridge policy when authorized, but they are not runtime-verified here.

My account list came back empty. Is the connection broken?

Not necessarily. Listing reachable accounts is resource discovery, not the identity check — identity is verified separately through Google OIDC. An empty list is still a valid connection; sub-accounts under an advanced account need a separate call to enumerate.

Can the agent see the OAuth credential?

No. The refresh token is minted and stored host-side in the macOS Keychain and used on the wire at request time. Every request is audited with secret_exposed: false, and the raw value never reaches chat, prompts, logs, or project files.

Learn · Setup guides

Connect Google Merchant Center to Outloop

Last updated: August 14, 2026

In short

Connecting Google Merchant Center to Outloop means signing in to Google once from Outloop in your browser, then mapping each client's Merchant account to its own workspace.

Outloop mints and stores the refresh token host-side in the macOS Keychain — there is no token to copy. Agents then work only the Merchant account mapped to their workspace; a request naming another account is denied before any call reaches Google, account-administration calls stay blocked, and every request is audited with secret_exposed:false.

Summarize this setup guide with AI ChatGPT Claude Perplexity

What this setup gives you

One agency Google identity across many client Merchant accounts, with the account boundary decided by configuration rather than by whatever the prompt happens to say.

✓Each client workspace is pinned to its own Merchant account ID.
✓A request naming a different Merchant account is refused before any call reaches Google.
✓Account-administration calls are blocked outright, not left to the agent's judgement.
✓The refresh token is minted host-side and never appears on your clipboard or in a prompt.

What you need before starting

✓Access to a Google Cloud project with the OAuth consent screen configured.
✓A Client ID and Client Secret for your first Google connector. After that, Outloop reuses the saved Google OAuth app and never asks for the secret again.
✓The Google account with access to the client's Merchant Center — you will sign in as it in your browser.
✓The Merchant account ID this workspace should be allowed to use.
✓Outloop installed and activated, with a workspace selected.

1. Enable the Merchant API

In Google Cloud Console, open APIs & Services → Library, search Merchant API, and click Enable. Outloop calls it at merchantapi.googleapis.com.

2. Create the OAuth client (once, for all Google connectors)

In Google Auth Platform → Clients, create a Web application OAuth client and copy the Client ID and Client Secret. The scopes this connector requests are:

https://www.googleapis.com/auth/content
openid
email

There is no read-only Merchant scope. Google does not publish one, so this connection requests the content scope and the restriction happens inside Outloop instead — through the capabilities you approve, the workspace account pin, and the actions Outloop blocks outright. If a guide tells you to pick a read-only Merchant scope, it is describing something that does not exist.

The openid and email scopes are how Outloop verifies which Google account you actually connected. That identity check is Google OIDC and involves no Drive scope.

You only enter the Google OAuth app once

The first Google connector you set up asks for the Client ID and Client Secret from your Google Cloud OAuth client. Tick save as my default Google OAuth app and every later Google connector — Google Ads, Gmail, Drive, Sheets and Analytics GA4 — picks it from the Google OAuth app dropdown with no Client Secret to re-enter. When a saved profile supplies the app, Outloop shows “Using <client-id> — no Client Secret needed. This connector still signs in separately and gets its own access.”

Reusing the app does not mean sharing one login. Each connector still opens its own browser sign-in and gets its own refresh token, its own scopes and its own connected account — so you can revoke or re-authenticate one connector without touching the others.

3. Add Merchant Center in Outloop

In Outloop, open API Keys & Access → Add Access and choose Google Merchant Center. The panel opens on Connect in your browser, with the Cloud Console detail in the collapsed Setup details — Google Cloud OAuth client, scopes and caveats and Before you connect disclosures. Check the Google OAuth app dropdown — a saved profile supplies the app with no Client Secret to re-enter.

Read the storage line before you continue. Where Outloop says the credential will be stored in the SHARED slot, it also warns that it replaces whatever is already there. If another workspace relies on that slot, change the scope before connecting rather than after.

4. Connect the account in your browser

Click Connect Google Merchant Center in your browser. Google's own sign-in opens, you sign in as the account with Merchant Center access, and you approve the consent screen there. Outloop mints and stores the refresh token host-side.

Nothing to copy or paste. There is no refresh token on your clipboard, so there is nothing to leak into a screenshot, a chat, or a .env file.

5. Confirm the account and capabilities

Outloop shows Connected as the Google account you just used — check it before an agent touches live product data. Under Agents will be able to (change any time in the Access profile), practical capabilities are pre-checked and destructive ones are prefixed ⚠ and left unchecked. Then click Confirm — this is the approved account.

6. Map the Merchant account to the workspace

This is the step that separates clients. Enter the Merchant account ID this workspace is allowed to use:

workspace_001
→ allowed merchant_id: <MERCHANT_ID>

A request naming a different Merchant account is denied before the credential is read. That is what makes one agency Google identity safe to use across a roster of client Merchant accounts.

7. Run the first proof

Ask the agent for a safe read of the approved account:

{
  "tenant": "<WORKSPACE_ID>",
  "service": "google_merchant_center",
  "verb": "api_bridge.request",
  "method": "GET",
  "path": "/accounts/v1/accounts/<MERCHANT_ID>"
}

Success criteria:

decision: allow
HTTP 200
the account returned is this workspace's approved Merchant account
secret_exposed: false
audit entry exists

An empty account list is not a failure. Listing reachable accounts at /accounts/v1/accounts is resource discovery only — it is never the identity check, which is done separately through Google OIDC. An empty list is still a valid connection; sub-accounts under an advanced account need their own call to enumerate.

What stays blocked

→A different Merchant account — refused before the credential is read; no Google call is made.
→Account administration — blocked by runtime policy with ACCOUNT_ADMIN_BLOCKED. This is a hard block, not a capability you can enable from the agent side.

Verified vs not claimed yet

Verified A read-only proof through Outloop against a live Merchant account: decision: allow, HTTP 200, secret_exposed: false.
Supported, not verified yet Write operations — feed and product changes. Supported by the API and permitted through bridge policy when authorized, but not runtime-verified. Only a read proof was run, deliberately, because the account was a real production account with live product data.
Not claimed Account administration. Blocked by runtime policy — this guide makes no claim that agents can perform it.
Not claimed Anything on a machine other than the Mac this was proven on. Outloop is at controlled design-partner stage.

Why writes carry no Verified badge here. Other connectors on this site mark writes runtime-verified because a safe write was actually run and audited. For Merchant Center it was not — running a test write against a live product feed is not a safe first proof. That gap is deliberate and will be closed by evidence, not by wording.

Troubleshooting

The account list came back empty

Expected in some setups, and not a broken connection — see the note in step 7. Sub-accounts under an advanced account need their own call to enumerate.

A call returns ACCOUNT_ADMIN_BLOCKED

The agent attempted account administration, which is blocked by runtime policy. This is not a configuration problem and cannot be enabled from the agent side.

Why did my refresh token stop working after a week?

If the Google Cloud OAuth consent screen is in Testing with an External user type, Google revokes refresh tokens after 7 days. Publish the app to In production (or use an Internal user type inside a Google Workspace organisation) and connect again.

Outloop is an independent tool and is not affiliated with or endorsed by Google. See the security model, the Google Ads setup guide, or the full guide index.