canonical: https://jentic.com/apis/googleapis.com/tagmanager

# Google Tag Manager API

The Google Tag Manager API gives programmatic access to GTM accounts, containers, workspaces, tags, triggers, variables, environments, and version history. It lets ops and analytics teams script tag deployments, audit container configurations, replicate environments across properties, and publish container versions without using the GTM web UI. Every change made through the API is captured in workspace history and can be promoted through environments for staged rollouts.

## For AI agents

Programmatically create and publish Google Tag Manager containers, tags, triggers, variables, and workspaces, and manage user permissions across GTM accounts.

## Scope

Does not handle event collection, report querying, or destination platform configuration - use for managing GTM containers, tags, triggers, and versions only.

## Capabilities

- Create, update, and publish container versions across GTM workspaces
- Provision tags, triggers, and variables programmatically across containers
- Replicate environments and promote container versions between staging and production
- Audit user permissions and assign roles at the account or container level
- List and inspect built-in variables, clients, and destinations attached to a container
- Reauthorize, sync, or resolve workspace conflicts before publishing

## Use cases

### Programmatic Tag Deployment Across Properties

Marketing engineering teams managing tags across dozens of brand properties use the Tag Manager API to standardise tag definitions, push the same conversion-pixel configuration into every container, and audit drift. Instead of clicking through the GTM UI per property, the team scripts the create-tag, create-trigger, and create-version flow and runs it as part of their release pipeline.

Example prompt: Iterate over a list of GTM container IDs and POST to /tagmanager/v2/{parent}/tags to create the same Google Ads conversion tag in each, then create a version and publish.

### Staged Environment Promotion

Large publishers run tags in a staging environment before promoting to production. The API lets engineering create a new workspace, modify tags, create a container version, and reauthorize a staging environment to point at it. Once QA passes, the same version is republished to the live environment in a single API call rather than reconfiguring tags by hand.

Example prompt: Create a workspace, add or modify tags via /tagmanager/v2/{parent}/tags, call workspace create_version, then reauthorize the production environment with the new container_version_id.

### Container Configuration Audit

Compliance and privacy teams need an inventory of every tag firing on a property and which user has permission to modify them. The API exposes complete tag, trigger, and variable listings plus user-permission resources, enabling automated audit reports that flag unauthorised tags, third-party scripts without consent triggers, or stale custom HTML.

Example prompt: List all containers under an account, then for each container list tags, triggers, and user_permissions, and emit a CSV flagging any custom-HTML tag without an associated consent trigger.

### Agent-Driven Tag Updates via Jentic

An AI agent embedded in a marketing workflow receives a request to swap an analytics tag's tracking ID across all brand containers. Through Jentic, the agent searches for the tag-update operation, loads the schema, iterates over container IDs, and publishes a new version per container. Jentic handles the OAuth refresh and credential isolation across the multi-step workflow.

Example prompt: Through Jentic, search 'update a Google Tag Manager tag', load the PUT tag operation, and execute it for each container ID, then publish a new version.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /tagmanager/v2/accounts | List GTM accounts the user has access to |
| GET | /tagmanager/v2/{parent}/containers | List containers under an account |
| POST | /tagmanager/v2/{parent}/containers | Create a new container |
| POST | /tagmanager/v2/{parent}/clients | Create a client in a workspace |
| GET | /tagmanager/v2/{parent}/built_in_variables | List built-in variables enabled in a workspace |
| GET | /tagmanager/v2/{parent}/destinations | List destinations linked to a container |

## Key resources

- **Account** — Top-level GTM account containing one or more containers
- **Container** — Container holding tags, triggers, variables, and versions for a specific property
- **Workspace** — Editable working copy of a container; changes are batched and published as a version
- **Tag** — Tracking snippet (Google Ads, GA4, custom HTML) fired on matching triggers
- **Trigger** — Rule defining when tags should fire (page view, click, custom event)
- **Variable** — Reusable value resolved at firing time (cookie, dataLayer, constant)
- **Environment** — Named target (staging, production) pointing at a specific container version

## Why Jentic

- **Setup:** Wiring the Tag Manager API by hand means setting up Google OAuth, picking the right narrow scope from readonly through publish and delete.containers, building the account and container path templates, and refreshing tokens yourself. Through Jentic you install once, import the Tag Manager API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Tag Manager puts the account and container in the URL path (/tagmanager/v2/{parent}/containers), so a rule can pin your agent to one container: it can read and edit tags and triggers there and nothing else. You choose the operations it may call, so destructive ones like container deletion or version publishing are not included unless you add them.
- **Credential handling:** Your Tag Manager OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a GTM trigger' or 'list tag manager containers', and Jentic returns the matching Tag Manager v2 operation with its input schema, including the parent path template, so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Google Analytics API** — Read reporting data from the analytics destinations that GTM tags send events to
- **Google Analytics Admin API** — Manage GA4 properties, data streams, and accounts that GTM tags target
- **Google Analytics Data API** — Run GA4 reports against the data collected via GTM-deployed tags

## FAQ

### What authentication does the Tag Manager API use?

Google Tag Manager API uses OAuth 2.0 with seven scopes including tagmanager.edit.containers, tagmanager.publish, tagmanager.manage.accounts, and tagmanager.manage.users. Pick the narrowest scope your workflow needs - read-only audits should use tagmanager.readonly. Through Jentic, OAuth tokens and refresh tokens are stored encrypted and rotated automatically; the agent never sees the raw token.

### Can I publish a new container version with the Tag Manager API?

Yes. Create or modify entities in a workspace under /tagmanager/v2/{parent}, then call the workspace create_version action and finally publish the resulting version. The publish operation activates the version in the live environment and increments the container's published version pointer.

### What are the rate limits for the Tag Manager API?

Google enforces a per-project quota of 25 read requests per second and 25 write requests per second by default, plus a separate per-user limit. Bulk operations should be paginated and back off on 429 responses; quota increases can be requested through the Google Cloud Console for high-volume publishers.

### How do I create a tag through Jentic?

Search Jentic for 'create a Google Tag Manager tag', load the schema for POST /tagmanager/v2/{parent}/tags, and execute it with your account, container, and workspace IDs plus the tag definition. Jentic handles the OAuth flow and returns the created tag resource. Get started with Jentic One, the self-hosted execution layer.

### Does the Tag Manager API support server-side tagging containers?

Yes. Server-side containers are managed through the same v2 API surface - the container's usageContext field indicates whether it is a web, iOS, Android, AMP, or server container. Tags, triggers, and variables specific to server-side templates are configured via the standard tag and trigger endpoints under the workspace.

### Can I manage user permissions for a GTM account via the API?

Yes. The user_permissions resource under /tagmanager/v2/accounts/{accountId}/user_permissions supports listing, creating, updating, and revoking access at both the account and container level. This is the recommended way to script onboarding and offboarding when many editors share a GTM property.

### Can I limit what my agent is allowed to do with the Google Tag Manager API?

Yes. Because you run Jentic One yourself, your own rules decide which Tag Manager operations and OAuth credentials the agent may use. Since the account and container sit in the URL path (/tagmanager/v2/{parent}/containers), you can pin the agent to a single container so it reads and edits only that container's tags and triggers. You also pick the exact operations it may call, so destructive actions like container deletion or version publishing stay off limits unless you explicitly grant them.
