Skip to content

Make developer_token optional and omit the header when unset - #550

Open
WalkingBad wants to merge 4 commits into
Opteo:masterfrom
WalkingBad:optional-developer-token
Open

WalkingBad wants to merge 4 commits into
Opteo:masterfrom
WalkingBad:optional-developer-token

Conversation

@WalkingBad

Copy link
Copy Markdown

Summary

Makes developer_token optional in ClientOptions and omits the developer-token header when it is not configured.

Since September 2026 the Google Ads API attaches access levels to the Google Cloud project that owns the OAuth client rather than to a developer token (policy page). The API now ignores the token value and states that a future major version will reject the header outright. Because this library always sets the header key, an unset developer_token currently goes out as the string "undefined" (through gax's ${value} stringification) — accepted today, but the wrong long-term shape.

Behaviour

  • developer_token set → unchanged, the header is sent as before.
  • developer_token absent → no developer-token header (gRPC metadata and REST alike, since both read callHeaders).
  • CallHeaders["developer-token"] becomes optional.

Note for reviewers: an empty header is still refused by the API with DEVELOPER_TOKEN_PARAMETER_MISSING, whereas an absent header is accepted. That is why the header is dropped rather than sent empty.

Verification

  • jest: 189/189 (new spec asserts the header is absent when the option is unset).
  • tsc clean; eslint reports only the 4 pre-existing no-explicit-any warnings.
  • Live gRPC against a production MCC with the header absent: listAccessibleCustomers, a GAQL query, and keywordPlanIdeas.generateKeywordHistoricalMetrics all succeed.

🤖 Generated with Claude Code

WalkingBad and others added 4 commits September 14, 2026 17:57
Google Ads API access levels are attached to the Google Cloud project that
owns the OAuth client since September 2026. The API ignores the developer
token value when present and will reject the header in a future major
version, while an empty header is still refused with
DEVELOPER_TOKEN_PARAMETER_MISSING. Send the header only when a value is
configured; existing callers that pass developer_token are unchanged.

Verified against the live API with the header absent: listAccessibleCustomers,
a GAQL query and generateKeywordHistoricalMetrics all succeed.
Resolve conflicts with the v25.1 release:
- CHANGELOG.md: keep the pending entry above the 25.1.0 section
- README.md: keep the developer_token note alongside the new optional
  client settings list
- src/service.spec.ts: take master's ESM imports (.js suffixes); master
  already imports Customer
Docs:
- README: move the note into the optional client settings list and
  correct it (an empty token is omitted too, not only an absent one);
  drop the token from the listAccessibleCustomers snippet
- examples/basic: drop the token from both runnable examples
- CHANGELOG: version the entry as 25.1.1, describe the empty-string
  behaviour accurately, and note the ClientOptions type change under
  Breaking Changes
- client.ts JSDoc: say empty behaves like unset
- service.ts: keep only the comment that justifies the truthiness check

Tests:
- callHeaders: keep login/linked customer ids in the fixture so an early
  return cannot pass, cover unset and empty tokens, use toStrictEqual
- request headers: assert the header on the outgoing REST request, with
  and without a token
@Lewis-Clayton Lewis-Clayton mentioned this pull request Nov 6, 2026
5 of 7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants