Skip to content
Ascend GTM Ops — Docs

Google Ads custom auth_config routed through Ascend GCP project

ADR-055 — Google Ads custom auth_config routed through Ascend GCP project

Status: Accepted 2026-05-18 Context: ADR-053 (Lean stack: Composio + Mem0 + Anthropic) — Composio is canonical OAuth-SaaS layer

Context

Google Ads API requires the OAuth client_id used at consent time to be tied to a GCP project that has been allowlisted with a Google Ads developer token. Composio’s default Google OAuth auth_config for the googleads toolkit uses Composio’s own shared GCP project, which is not on Ascend’s developer-token allowlist. Result: OAuth flows complete cleanly (connection lands ACTIVE), but every subsequent Google Ads API call returns DEVELOPER_TOKEN_PROHIBITED.

This is a known Composio limitation for Google Ads specifically — confirmed during Kahuna onboarding 2026-05-09. Other Google toolkits (googlesuper, googleads_billing for non-API operations) work fine on the shared GCP project because they don’t require a developer token.

Decision

Use a custom Composio auth_config (ac_p9jMpo3Mmfk2) that points at the Ascend-owned GCP project 705816965171 (already allowlisted for developer token pm0K7c-AsPVrU8K3MNDQNQ, basic-access tier). All googleads connections for both tenants (Ascend + Kahuna) and all future tenants route through this auth_config.

Concrete implementation:

  • scripts/composio/auth-configs.json pins googleads → ac_p9jMpo3Mmfk2.
  • The onboarding CLI (scripts/onboard-client.ts) reads from that file — no per-tenant special-casing.
  • Tenants whose Google Ads accounts are not on the Ascend MCC’s developer-token allowlist receive a DEVELOPER_TOKEN_PROHIBITED 403 on every API call. Resolution path documented in docs/composio/manual-tools.md (Google Ads section).

Alternatives considered

  1. Composio’s default auth_config. Rejected — developer-token allowlist failure on every call. Verified empirically during Kahuna onboarding.
  2. One custom auth_config per tenant. Rejected — N tenants × manual GCP-side OAuth client registration = does not scale. Single shared auth_config is the same trust model as Composio’s own shared project, just gated on Ascend’s developer token instead of Composio’s.
  3. Move off Composio for Google Ads only and call the API directly from a Worker. Rejected — re-introduces token-write path that ADR-053 explicitly killed (invariant 5). Composio handling 99% of providers and us bypassing it for one is worse than configuring Composio correctly.

Consequences

Positive:

  • Single auth_config_id pinned in auth-configs.json. New tenants onboard with zero special-casing.
  • Developer token consumed against Ascend’s GCP project, where we can monitor quota and request standard-access upgrades.
  • Composio still owns the OAuth lifecycle (refresh, revocation) for googleads connections — invariant 5 preserved.

Negative:

  • New tenants whose ad accounts are not yet on the Ascend MCC’s allowlist still need to be added (1–4 weeks for basic access from Google). This is unavoidable and documented in docs/composio/manual-tools.md.
  • Ascend’s GCP project 705816965171 becomes load-bearing for every client’s Google Ads OAuth. Loss of access to that project = onboarding outage for googleads tool only. Acceptable because (a) it’s on Mishaal’s primary Google account, (b) recovery is to issue a new OAuth client from a sibling project and re-register one Composio auth_config — minutes, not days.

Triggers for re-evaluation

  • Composio adds first-class support for tenant-supplied OAuth clients (would let us drop the shared model entirely).
  • Google Ads tightens developer-token rules to require per-tenant tokens (would force us to revisit anyway).
  • Ascend GCP project quota becomes the bottleneck (low likelihood for OAuth alone).