Can one Outloop workspace use more than one Google Tag Manager container?

Yes. Under Approved containers, list every container path the workspace may use — one per line, or comma-separated — and save with Update approved containers. An agency with a container for example.com and another for app.example.com approves both paths in the same workspace. You do not need a separate workspace or a separate Google credential per container.

Why does Outloop reject my GTM-XXXXXXX ID?

GTM-XXXXXXX is the public ID used in the website snippet. The Tag Manager API does not address containers by it. Outloop approves the container's API path (accounts/…/containers/…) — the numeric Account ID and Container ID from Tag Manager → Admin. Use Find my containers with your numeric Account ID to see each container's public ID next to its API path, then approve the right one.

Does saving the approved containers turn access on?

No. Saving records which containers the workspace may use. Runtime access turns on only after Run access check succeeds — Outloop reads an approved container with the stored credential and arms the workspace only if that read works.

Does the access check test every approved container?

No. It reads the first container in your approved list. That proves the credential and the Google account work against a real approved container. For every other container you approve, make sure the connected Google account has access to it in Tag Manager — Outloop limits which containers an agent may use, but it cannot give a Google account access Google has not granted.

Is there a separate "proof container"?

No. The access check runs against a real approved container — the first one in your list. There is nothing extra to create.

Can my agent see the Google token?

No. Outloop keeps the OAuth credential in macOS Keychain on your Mac, mints short-lived access tokens host-side, and returns a redacted result. The agent uses the credential's capability without ever seeing the refresh token, access token or Authorization header.

Can an agent create a new container or list all containers in the account?

No. Container create and delete are account administration, which this connector refuses. Listing the account's containers is refused too, because in a shared agency account that list is your client roster. Create the container in Tag Manager yourself, then add its path to Approved containers and rerun the access check.

Guides · Setup

How to Connect Google Tag Manager to AI Agents with Outloop

Last updated: September 18, 2026

In short

Google Tag Manager connects to Outloop with Google OAuth, and each workspace approves the exact containers its agents may use.

Connect Tag Manager once with your saved Google OAuth app, then approve one or more containers per workspace by their API path (accounts/…/containers/…), not the GTM-XXXXXXX ID. Run the access check. Agents can then work only in those containers, and never see the Google token.

Summarize this setup guide with AI ChatGPT Claude Perplexity

Setting up Google for the first time? The Google Cloud side — project, APIs, scopes and one OAuth client — is the same for every Google connector, and you only do it once. Follow Set up one reusable Google Cloud OAuth app first (it lists the three Tag Manager scopes), then come back here. Already have a saved Google OAuth app? Start at step 1.

What this setup gives you

Agents in a workspace can read and work on the Tag Manager containers you approved for that workspace — tags, triggers, variables, workspaces and versions — through the Outloop API Bridge. One Google login can serve many workspaces, and each workspace keeps its own list of approved containers.

✓Agents can use only the containers approved for their workspace. A request for any other container is refused before the credential is read.
✓The Google refresh token, access token and Authorization header never reach the agent. Outloop keeps the credential in macOS Keychain and uses it host-side.
✓Every request is tied to the workspace and written to the redacted audit log.

What you need before starting

✓A Google Cloud project with an OAuth web app — ideally one already saved in Outloop as a Google OAuth app.
✓A Google account with access to the Tag Manager container(s) you want agents to use.
✓The numeric Account ID of the GTM account that holds them (Tag Manager → Admin → Account Settings).
✓Outloop installed and activated, with the workspace you want to set up.

Which Google account connects what

Three separate identities — keep them apart

Most failed Google Tag Manager setups are one confusion: assuming the Google account that manages the Cloud project is also the account that can open the client's Tag Manager containers. It does not have to be, and often should not be.

1

The Google Cloud project and OAuth app

This owns the Client ID and Client Secret. It can belong to your agency or to your client — Outloop does not care which, and cannot tell the difference.

cloud-admin@agency.example — manages the Google Cloud project
2

The connected Google account

This is the account you pick in Google's own chooser during the browser sign-in. It is the account that must actually own or be able to open the client's Tag Manager containers.

data-owner@client.example — is chosen at sign-in because it owns the client's Tag Manager containers
3

Outloop workspace access

This decides which workspace may use the stored credential, which resources it may reach, and which capabilities agents get. It is set in the Access Profile, after the sign-in succeeds.

In that example, cloud-admin@agency.example created the OAuth app once, and every connector after it reuses that app — but the account you actually sign in as is data-owner@client.example, because that is the identity Google Tag Manager will check when an agent asks for a file.

The connected account still has to be allowed in. Four things can block it, and all four are set on the OAuth app, not in Outloop:

→If the app's audience is External and it is still in Testing, the account must be added as a Test user first.
→If the audience is Internal, only accounts inside that Google Workspace organisation can sign in at all.
→The Tag Manager API must be enabled in the Google Cloud project the app belongs to.
→The account must genuinely have access to the client's Tag Manager containers. A successful sign-in proves identity, not reach.

GTM-XXXXXXX is not the container ID Outloop uses

Every Tag Manager container has two identifiers. The one you see everywhere — in the website snippet and at the top of Tag Manager — is the public ID, GTM-XXXXXXX. The Tag Manager API does not accept it. The API addresses a container by its path: a numeric Account ID plus a numeric Container ID. That path is what you approve in Outloop:

accounts/{ACCOUNT_ID}/containers/{CONTAINER_ID}

e.g.  accounts/1234567890/containers/111111111

Do not paste GTM-XXXXXXX into Approved containers. Outloop rejects it, because it cannot be used to address the API. Use Find my containers (step 4) to see each container's public ID next to its API path, and pick the right one from there.

The path has two parts on purpose. The same container number under a different account is a different client, so Outloop approves the account and the container together.

Tip: when a container is open in Tag Manager, the browser address bar usually contains accounts/…/containers/… — those are the two numbers you need.

1. Enable the Tag Manager API

In the Google Cloud project that owns your OAuth app, open APIs & Services → Library, search for Tag Manager API, and click Enable. If you skip this, the first call fails with Google's accessNotConfigured error.

2. Connect Google Tag Manager in Outloop

In Outloop, open the workspace you are setting up, then go to API Keys & Access → Add an API key and choose Google Tag Manager. Pick your saved Google OAuth app, choose the access level to request from Google, and click Connect Google Tag Manager in your browser. Sign in as the Google account that can reach the containers, approve Google's consent screen, check the Connected as address, and confirm it.

You are not asked for a container here — that is intentional. One agency Google login can see many clients' containers, so containers are approved per workspace afterwards, on the key row. A shared (agency-global) credential never carries a container, so one client's container can never be copied into another workspace.

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 this Google OAuth app so other Google connectors can reuse it and every later Google connector — Search Console, Analytics GA4, Google Ads, Drive and Sheets — picks it from the Google OAuth app dropdown with no Client Secret to re-enter. The saved app is then listed under Authentication Profiles. When a saved profile supplies the app, Outloop shows “Using <client-id>. Its Client Secret comes from the saved app — nothing to paste. 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.

Shared agency app or workspace-dedicated?

Which setup should I choose?

There are two reasonable answers for Google Tag Manager, and the right one depends on who owns the Google Cloud infrastructure — not on how many clients you have.

Agency-global (shared OAuth app)

One OAuth app your agency owns, reused by every Google connector you add. This is the default and the right choice for most agencies.

✓Client ID and Client Secret entered once, then picked from a dropdown.
✓Every connector still runs its own Google sign-in.
✓Each one gets its own scopes, its own refresh token, its own connected account and its own revocation.
✓Reusing the app grants no data access by itself — workspace grants and Access Profiles stay explicit.

Workspace-dedicated

A separate OAuth client — or a separate Google Cloud project — for one workspace or one client.

→The client owns the Google Cloud infrastructure and wants to keep owning it.
→They need stronger administrative separation, or their own consent branding and audience rules.
→They want separate quotas and their own lifecycle control.
→The client owns the GTM account and wants the OAuth app inside their own Google Cloud project.

A separate Google Cloud project is the strongest operational separation. A separate OAuth client inside the same project is lighter separation — useful, but the project is still shared.

Outloop cannot verify which you chose. It sees a Client ID and a Client Secret. It has no way to infer — and no way to enforce — how you organised your Google Cloud projects. If the separation matters to a client contract, it has to be real on the Google side; Outloop enforces the workspace boundary, not the Cloud-project boundary.

Sharing a stored credential is a third, different thing. Reusing the OAuth app is not the same as granting one stored Google Tag Manager credential to several workspaces. You can do the latter deliberately — but then replacing that credential affects every workspace assigned to it. When Outloop says a credential will be stored in the shared slot and replaces whatever is already there, read that line before you continue, not after. Granting the app to a workspace does not automatically grant it data access either — that is still the Access Profile's job.

3. Confirm the access level

There are two separate settings. Check both before an agent touches a live container.

What Google allows — chosen when you connect

→Full container access — edit, version, and publish (recommended)
→Edit and version, never publish — Google itself refuses the publish call.
→Read only — containers, tags, triggers, variables and versions.

What Outloop allows — on the key row

The row shows Access: Full API access or Access: Read-only. Click Restrict to read-only to refuse every write before any credential is read, or Enable full API access to allow writes again. Deleting is a separate row, Destructive actions (delete / archive), which stays Disabled until you click Enable destructive actions and confirm. On a container that serves a live site, keep destructive actions off, and consider read-only until you trust the workflow.

Account-wide does not remove the container list for Tag Manager. On some Google connectors, account-wide access lifts the resource list. On Tag Manager, even with the workspace set to account-wide, agents can use only the approved containers. One Google account can see many clients' containers, so every Tag Manager workspace needs its approved containers.

4. Approve one container

On the Google Tag Manager key row in Stored keys & access, expand Approved containers. Until you approve something it reads none yet — agents are blocked.

If you only know the GTM-XXXXXXX ID or the account: Find my containers

Enter the numeric GTM Account ID (digits only). It is under Tag Manager → Admin → Account Settings, and it is not the GTM-XXXXXXX ID.
Click Find my containers. Outloop lists that account's containers, showing each one's name, its GTM-XXXXXXX public ID and its API path.
Find the container whose public ID matches the one on the client's site, and click Use this container. That one click adds the path and saves the approval.

The lookup covers one account at a time on purpose: the Tag Manager API has a low shared quota, and listing every account at once would spend it. Finding a container does not approve it. Only Use this container, or saving the list, approves it.

If you already know the path: paste it

Under Or enter the Account + Container path yourself — one per line, or comma-separated, paste the path and click Approve containers:

accounts/1234567890/containers/111111111

The summary changes to 1 approved ✓, the approved path appears under ✓ Approved:, and Run access check appears right below it. Continue to step 6. Adding a second container comes next.

5. Approve more than one container

A workspace can use several containers. List them all in the same field — one per line or comma-separated — and click Update approved containers (the button is named Approve containers until something is approved). Or run Find my containers again under Add another container and click Use this container on each one. Each click adds to the list and does not replace it.

Example: one client, two sites

An agency manages one client with a GTM container for example.com and a second one for app.example.com, in the same GTM account. Both go into the client's one Outloop workspace:

accounts/1234567890/containers/111111111
accounts/1234567890/containers/222222222

✓One workspace — you do not need a workspace per container.
✓One Google credential — you do not need a credential per container, as long as the connected Google account can access both.
✓No special proof container — the access check uses a real approved container.

Containers in different GTM accounts work the same way — each path carries its own account number. A different client belongs in its own workspace with its own approved list.

6. Run the access check

Click Run access check under the approved list.

Saving the approval does not turn access on. Runtime access for the workspace turns on only after Outloop successfully reads an approved container with the stored credential. Until the check passes, the approved containers are saved but no agent call goes through.

A passing check reads:

Ready — the credential reached this exact container, and runtime access is on for this workspace.

The key row then shows Runtime verified · API bridge. A failed check shows Access check did not pass with a code and HTTP status. The approval stays saved and runtime stays off, so fix the cause (see Troubleshooting) and run it again.

Which container is checked? The first container in your approved list. That proves the credential and the Google account work against a real approved container, and then the whole workspace is switched on. It does not test each additional container separately. Before approving more, make sure the connected Google account can open every one of them in Tag Manager.

Once the check passes, copy the workspace run prompt and give it to your agent. A good first task is a read, such as "read the approved container and list its workspaces". A passing agent read comes back like this:

GET /tagmanager/v2/accounts/1234567890/containers/111111111
decision / code: allow / OK
HTTP status: 200
secret_exposed: false

What the approved list enforces

✕A container not on the list — refused with RESOURCE_ID_NOT_ALLOWED before the credential is read. That includes the same container number under a different account.
✕Listing accounts or containers — refused. In a shared agency account that list is your client roster. Agents learn their boundary from Outloop, not by browsing the account.
✕Looking up a container by GTM-XXXXXXX — refused on every tier, because that lookup has no account in it.
✕Account administration — creating or deleting containers, user permissions, and actions that reach a sibling container (combine, move tag ID, destination link) are refused.
✕No approved container at all — every call is refused with CUSTOMER_RESOURCE_PIN_REQUIRED. Outloop never widens the list on its own.

So a container created in Tag Manager later is not usable automatically. Add its path to Approved containers first.

Verified vs not claimed yet

Verified Reading an approved container, its workspaces and its tags through the real Outloop bridge: HTTP 200, decision allow, secret_exposed: false.
Verified The boundary: a container not on the list, the same container number under another account, the account list and the container list were each refused with RESOURCE_ID_NOT_ALLOWED before any call to Google.
Supported, not verified yet Several approved containers in one workspace: supported and enforced per request by the shipped product. The live proof above used one container.
Supported, not verified yet Writes (tags, triggers, variables), creating versions and publishing: allowed by the bridge under Full API access and the matching Google scope, but not runtime-verified yet. Test on a container that is not serving a live site first.
Not supported Account administration: creating or deleting containers, and managing user permissions.

Troubleshooting

GTM-XXXXXXX does not work in Approved containers

That is expected. It is the public ID, not an API path. Enter the numeric Account ID, click Find my containers, and use the listed path, or type accounts/{ACCOUNT_ID}/containers/{CONTAINER_ID} yourself.

Find my containers says it could not list containers

If it says no Google credential is stored, connect Tag Manager first (step 2). Otherwise, check that you entered the numeric Account ID and that the connected Google account is a user on that GTM account. If the list says more containers exist than are shown, paste the path directly.

The access check fails

Confirm three things: the Tag Manager API is enabled in the OAuth app's Google Cloud project, the connected Google account can open the first approved container in Tag Manager, and that path is exactly right (account and container number). Then click Run access check again. A 403 from Tag Manager can also mean the API quota is exhausted. Wait a minute and retry before changing the credential.

The agent can use one container but not another

If Outloop answers RESOURCE_ID_NOT_ALLOWED, the second path is not in Approved containers. Add it and save. If Google answers 403 or 404, the path is approved but the connected Google account cannot reach that container. Grant the account access in Tag Manager, or check the numbers.

A new container is refused

Agents cannot create containers, and a container you created in Tag Manager is not approved automatically. Add its path to Approved containers, click Update approved containers, and run the access check again.

Google shows an account chooser

Expected. Outloop asks Google for the chooser on purpose, so a sign-in can never silently reuse whichever account your browser happened to be logged into. Pick the account that owns or can open the client's Tag Manager containers — which is often not the account that manages the Google Cloud project.

“Google hasn’t verified this app”

This appears because the OAuth app is your own and has not been through Google's verification. If it is your app and you trust it, expand Advanced and continue. If you do not know who owns the app, stop — that warning is doing its job, and clicking past an unknown app is not a routine step.

Which audience the app uses decides who can get that far at all. An External app in Testing only admits accounts added as Test users. An Internal app only admits accounts inside its Google Workspace organisation. For customer-facing production use, complete Google's verification rather than living in Testing.

The wrong Google account got connected

Use Connect as a different Google account on the connector. It keeps the same Client ID and Client Secret and reopens Google's chooser. The stored token is only replaced once Outloop verifies the new identity is the intended one — if it does not match, Outloop reports the mismatch and keeps the previous credential. Nothing is lost by trying.

A credential that works but sits on the wrong account is deliberately not marked runtime-verified for that workspace. Working and correct are different things.

BACKEND_AUTH_FAILED during connect

Google rejected the sign-in, so the new credential failed Outloop's safe verification. The important part: the previous credential is unchanged. Do not delete the connector, the OAuth app or the workspace as a first move. Check, in this order — that you signed in as the account that can reach the client's Tag Manager containers; that the account is admitted by the app's audience (a Test user on an External+Testing app); and that the API is enabled in the right Cloud project. Then try the connect again.

Reconnecting never asked for the Client ID and Secret

Expected. Disconnecting a Google Tag Manager credential does not delete your saved Google OAuth app profile — that is a separate object, kept on purpose so later connectors do not re-enter a Client Secret. Outloop reused it. If you specifically want a different app, pick another saved profile from the Google OAuth app dropdown, or create a new one and save it alongside. This is reuse working, not a stale credential silently retained.

“Copy workspace run prompt” is not available

The Access Profile has not been saved yet. Open the Access Profile, choose the reach and the capabilities, and click Save Access Profile — the run prompt becomes available once the authorization is recorded. OAuth succeeding is not the same as the workspace being authorized, and this is the step that closes the gap.

The connection stops working after about a week

If the OAuth app's audience is External and its publishing status is still Testing, Google expires refresh tokens for that app after roughly seven days. Two honest options: publish the app to In production, or use an Internal audience if everyone signing in is inside your Google Workspace organisation. Publishing may require Google's verification review depending on the scopes the app requests — that is Google's process and its outcome and timing are not ours to promise.

Change containers, rotate or revoke

→Remove a container from a workspace — delete its line under Approved containers and click Update approved containers. The workspace's reach changes immediately and the credential is untouched.
→Rotate the token — use Re-authenticate on the connector (below).
→Revoke everything — remove the Tag Manager credential in Outloop, then revoke Outloop's access for that account at myaccount.google.com/permissions. Do both: removing the local credential does not revoke the grant at Google.

Changing the account or the credential later

Three controls on the Google Tag Manager connector look similar and do different things. Picking the wrong one is the most common way a working connector gets broken on purpose.

Re-authenticate

Reuses the OAuth app you already selected and refreshes the authorization for the account that is already connected.

When: Use it when the refresh token expired or was revoked and you want the same account back.

Safety: It must not quietly become an account switch. If Outloop finds a different account at the other end, it reports the mismatch and keeps the previous token.

Connect as a different Google account

Keeps the same Client ID and Client Secret and opens Google's account chooser so you can pick another identity.

When: Use it when the wrong account was connected, or when the client moved the data to a different Google account.

Safety: The stored token is replaced only after Outloop positively verifies that the newly connected identity is the one you intended. A mismatch, a missing identity, a failed verification or a cancelled sign-in all leave the previous credential exactly as it was.

Replace the full credential

Swaps the OAuth app itself — a different Google Cloud project, Client ID or Client Secret.

When: Use it when the OAuth app is changing hands, or a client is moving the connector onto their own Cloud project.

Safety: This is not the same as choosing another Google data account. Confirm with "Sign in and replace" only when you actually mean to change the app.

Disconnecting does not delete your saved OAuth app. Removing a Google Tag Manager service credential clears that credential — but the saved Google OAuth app profile is a separate, reusable object and stays. So when you reconnect, Outloop may never ask for the Client ID and Client Secret again. That is the reuse working as designed, not evidence that a stale credential was silently kept. To use a different app, pick another saved profile from the Google OAuth app dropdown, or create a new one and save it alongside the existing one.

Official Google documentation

→Tag Manager API v2 — resources, paths and methods.
→Authorizing Tag Manager API requests — the Tag Manager scopes.
→Using OAuth 2.0 to access Google APIs — refresh-token behaviour.

Outloop is an independent tool and is not affiliated with or endorsed by Google. See the security model, the shared Google Cloud OAuth setup, the Google Analytics GA4 guide, or how agencies use this across clients in AI for marketing agencies.