how a call runs
what it reaches
Tag Manager API
server to server · straight to the platform’s API
access granted once · OAuth · scoped to this account
no browser session · no password sharing · no scraping
what you get
read-only by default · Every question is answered without touching the container. Drafting a tag or publishing a version is a separate, deliberate step with its own guards, its own record and its own way back.
a change is checked against what was actually there · A change is applied only against the container as it was when a person reviewed it. If anything moved in between, the change fails instead of landing on top of something nobody saw.
nothing is lost if something crashes mid-change · Every change is recorded before it is attempted and again once it is confirmed. A change that reached the container without being accounted for is raised the next time the system starts, never forgotten.
| tool | type of access | what it does | why it exists |
|---|---|---|---|
| container.read | reads only | reads the whole container | the complete measurement map, every tag, trigger and variable in one read |
| tag.status | reads only | shows what fires on which page | a tracking audit in one read |
| versions.diff | reads only | compares two publishes | names what changed |
| workspace.preview | reads only | tests a change before it ships | a change proven before it goes live |
| tag.create | adds new | drafts a new tag for your approval | a tag drafted for review, never published on its own |
| version.publish | changes or removes | ships a container version once you approve | the release goes live only on your yes, with the version on record |
covers
All 106 methods of the Tag Manager API v2: accounts, containers, workspaces, tags, triggers, variables, templates, versions and environments. Nothing is left out. The surface is a small closed list, which is why every method can be covered here and not elsewhere.
how it operates · alone, or with the rest of the fleet
alone
container audits in minutes · before every release
01
you ask · “What fires on the checkout pages?”
02
it picks · the container read · tags, triggers, and the version history
03
comes back · what fires where, and what the last publish changed
04
lands · the map of your measurement, in plain words · the container untouched
with GA4
The container decides which events are sent; GA4 records which events arrived. Read together, a tag that fires is proven as an event that landed, page by page. That is the check that catches measurement breaking silently after a deploy, before the weekly report notices.
01
you ask · “Before we release: does every tag that fires land as an event?”
02
it picks · the container read in Tag Manager and the key-event and realtime reads in GA4 · reads only
03
comes back · what fires on each page, beside what GA4 received from each page
04
lands · a fired-versus-landed list · any tag that fires and never lands, named before the release
with Google Ads
The conversion tags in the container feed the bidding in Google Ads. The Tag Manager server shows which conversion tags fire, on which pages, and what the last publish changed to them. Read beside the Google Ads record, a drop in reported conversions is traced to the tag, the page and the version, not guessed at from the campaign.
01
you ask · “Reported conversions dropped. Is it the ads or the tags?”
02
it picks · the container read and version history in Tag Manager, then the conversion read in Google Ads · reads only
03
comes back · which conversion tags fire on which pages, what the last publish changed, and when the platform’s count fell
04
lands · the tag, the page and the version behind the drop, or a clean bill for the container · no guess from the campaign