Skip to main content

marketing-toolbox

Command-line tools for the official Google APIs:

  • ga4datactl — Google Analytics Data API v1beta
  • ga4adminctl — Google Analytics Admin API v1beta
  • gtmctl — Google Tag Manager API v2

They require Python 3.11+ and uv.

Install and run

Run a tool without installing it persistently:

uvx ga4datactl --help
uvx ga4adminctl --help
uvx gtmctl --help

Or install individual tools:

uv tool install ga4datactl
uv tool install ga4adminctl
uv tool install gtmctl

To install all three commands together:

uv tool install marketing-toolbox

marketing-toolbox provides ga4datactl, ga4adminctl, and gtmctl; it does not provide a marketing-toolbox executable.

Authentication

Commands resolve credentials in this order: GOOGLE_SERVICE_ACCOUNT_JSON, an explicit GOOGLE_APPLICATION_CREDENTIALS file, a matching local native OAuth record, then ambient Application Default Credentials (ADC). The explicit file and ambient ADC may be service-account, user, workload, or other Google-supported credential types. This preserves service-account compatibility and supports externally managed ADC on servers and CI (for example, attached identity, workload identity, or a provisioned ADC file). Credentials are never command-line arguments or output.

Native user OAuth

Follow Google's guidance to create a Cloud project, enable APIs, configure OAuth consent and test users, and create a Desktop OAuth client and download its JSON. For an External project in Testing, add the signing-in user as a test user when applicable. Each native record requests exactly one access tier:

Tool Access tiers
ga4datactl read
ga4adminctl read, edit
gtmctl read, users, accounts, containers, versions, publish, delete

For a desktop login, run (replace the tool and tier as needed):

ga4datactl auth login --client-secrets ~/Downloads/client_secret.json --access read

The same command family manages the record:

ga4datactl auth status --access read
ga4datactl auth forget --access read
ga4datactl auth revoke --access read --apply --acknowledge-project-wide-revocation

forget deletes only that local record. It does not attempt remote revocation and cannot determine whether the Google grant remains valid. It verifies secure storage deletion before removing its recovery marker; if cleanup is incomplete, rerun forget after fixing local storage. revoke revokes the user's grant across the OAuth project, then conditionally removes the selected unchanged local record; it is not a per-tier remote logout. You can instead revoke access in Google Account permissions and run forget.

Native records retain only the refresh material and the selected access-tier scope binding in an approved encrypted OS keyring (macOS Keychain, Windows Credential Locker, or Linux Secret Service); access tokens are refreshed only in memory. The stored scope is not proof of the scope Google granted. Native records are unavailable when that secure keyring is unavailable—common on headless Linux—so use externally managed ADC instead; this tool never falls back to plaintext files. On Windows, a native record is limited to Credential Locker's 2,560-byte UTF-16LE value limit. Externally managed ADC (including gcloud-managed files) is outside this native encrypted-keyring guarantee and must be secured by the operator. An external consent screen left in Testing can issue refresh tokens that expire after seven days.

Before changing a native record, the tool durably writes a non-secret marker in its private application directory. An interrupted login can therefore leave a marked missing or invalid secret; it will fail closed rather than select ADC. Run auth forget to recover, then log in again. Native lifecycle operations coordinate through a persistent, non-secret per-user lock file shared by all three tools and tiers. Its canonical OS-profile location is intentionally independent of configurable marker roots; a busy lock waits up to five seconds for acquisition only (not for keyring, filesystem, browser, or network work) and then fails safely. An absent selected marker needs neither a lock nor a keyring lookup. Unsafe or unwritable canonical profiles fail closed rather than falling back to another location. Ordinary storage failures are best-effort compensated, but abrupt interruption during a replacement can leave either the previous or new valid secret. On POSIX, each storage attempt re-syncs configured-base and application directory entries before marker or keyring mutation, then syncs marker data and its containing directory. Windows uses flushed temporary data and a write-through replacement under the OS profile's inherited ACLs; neither platform promise covers every filesystem, redirect, storage device, or power loss scenario. revoke performs remote revocation outside the local lock, then removes the selected local record only if it is unchanged; a concurrent replacement is preserved and reported for review. Coordination is advisory for updated cooperating binaries—older or noncooperating binaries do not use it.

For a remote browser over SSH, forward one fixed loopback port before logging in on the server:

ssh -L 127.0.0.1:8765:127.0.0.1:8765 -o ExitOnForwardFailure=yes user@server
ga4datactl auth login --client-secrets /secure/client_secret.json --access read \
  --no-open-browser --port 8765

The login prints its loopback URL to stderr; no copy/paste authorization-code or public listener is used. If native secure storage is unavailable, bootstrap ADC with your owned client instead:

gcloud auth application-default login --client-id-file=/secure/client_secret.json \
  --scopes="https://www.googleapis.com/auth/analytics.readonly" --no-browser

Shared ADC must include the union of scopes required by every tool and access tier it serves. Consent and credential selection do not grant access to Analytics or Tag Manager resources. Grant the authenticated principal the required Google Analytics, Tag Manager, and IAM resource permissions separately.

Discover commands and schemas

Use <tool> --help for the current commands and options. sdk schema --command "<eligible leaf path>" prints the locally derived request descriptor without loading credentials or calling Google.

Reads execute normally. Writes require --apply; supported dry runs do not call mutation endpoints. Sensitive or high-impact commands can require an additional acknowledgement. API, schema, and version results use structured JSON on stdout; diagnostics use stderr, while --help uses normal help text.

Metadata

Release files for marketing-toolbox 0.5.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for marketing-toolbox 0.5.1
File Size Uploaded
marketing_toolbox-0.5.1.tar.gz 237.2 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for marketing-toolbox 0.5.1
File Interpreter ABI Platform
marketing_toolbox-0.5.1-py3-none-any.whl Python 3 none any Details

Total release size: 355.4 kB

Release files / marketing_toolbox-0.5.1.tar.gz

Download URL marketing_toolbox-0.5.1.tar.gz
Size 237.2 kB
Tags Source
SHA-256 checksum
How to use checksums
25b69e4cfe046dad1b96cb5e067844bc0471e34680226cb90a11bf084c44c6dc
BLAKE2b-256 checksum
How to use checksums
44f7a7a538e81bfe126bc8a4b18e6660bb8cd950447c6cd8a8d7fe48795d8ade
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.

Transparency log

Release files / marketing_toolbox-0.5.1-py3-none-any.whl

Download URL marketing_toolbox-0.5.1-py3-none-any.whl
Size 118.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
d6ad6cf5fb122f91a7c67258e994df4389c7824fb9c4d2cf6736b6fc8683dd36
BLAKE2b-256 checksum
How to use checksums
034d2d4717eaf07d73a209bb117678f214f3a12cfa65765319a12c5e97e78b20
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.

Transparency log

Release history Release notifications | RSS feed

0.6.0

2 release files

This release

0.5.1 This release

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page