Do You Need a Google Ads Developer Token to Use ChatGPT or Claude?

You do not need a Google Ads developer token to use ChatGPT or Claude with Google Ads. Google sunset developer tokens on September 9, 2026. Google Ads API access is now associated with a Google Cloud project instead.

If you use a hosted MCP server such as HireOtto, you also do not need to create or manage that Cloud project. You connect the hosted server to your AI client, complete Google OAuth, select the Google Ads accounts you want to use, and work within the permissions of the Google login you authorized.

If you build directly on the Google Ads API – or self-host Google’s official MCP server – you still need a Google Cloud project with an appropriate Google Ads API access level and OAuth credentials. The missing piece is no longer a developer token.

Before September 9, Google Ads API applications used a developer token as part of API onboarding and access management. Google has now retired that model.

API access levels are assigned to Google Cloud projects. New developers enable the Google Ads API in a Cloud project, receive Test access, and can apply for a production access level in Google Cloud Console. A Google Ads manager account is no longer required merely to start using the API.

Older integrations may still send a developer token header. Google says that header is optional and ignored by the API servers. Teams maintaining legacy code should update their client library and configuration when practical, but the old token no longer determines access.

One narrow exception remains: Google directs developers using the App Conversion Tracking API to continue its separate developer-token signup process. That exception does not apply to ordinary Google Ads reporting, campaign management, or the typical ChatGPT and Claude workflows discussed here.

ChatGPT and Claude are the AI clients. They do not become Google Ads API applications merely because you ask them a campaign question. A connector or MCP server sits between the AI client and Google Ads.

Who operates that connection determines what you need to configure:

“Developer token,” “OAuth,” and “Google Ads access” are often bundled together in setup advice. They solve different problems.

This controls whether an application’s Google Cloud project can call the Google Ads API, and at what access level. Since September 9, 2026, the project – not a developer token – carries that access.

You manage this yourself when you build a direct integration or self-host Google’s official MCP server. With a hosted service, the provider manages the application-side integration.

OAuth lets a Google user authorize an application to access Google Ads on their behalf. It is still required for user-authenticated workflows. Retiring developer tokens did not retire OAuth.

In a hosted setup, you complete an authorization flow without creating your own OAuth client credentials. In a self-hosted or direct setup, your team configures the OAuth client – or an appropriate service-account workflow – inside its Cloud project.

OAuth cannot grant access that the Google login does not already have. The connected identity must be able to open the relevant advertiser or manager account, and its Google Ads role constrains what it can read or change.

This is why a successful connector login can still return no accounts, reject a write, or expose only part of an MCC hierarchy. API access, user authorization, and advertiser permissions are separate gates.

A hosted MCP server removes the application setup from the marketer’s to-do list. The provider operates the server and the platform integration; the user connects it to an AI client and authorizes an eligible Google login.

For a marketer, the practical checklist is:

You do not paste a developer token, API key, client secret, JSON credential, or Google password into the chat. You should still vet the server, review its tool list and permissions, and supervise important write actions.

Self-hosting changes the ownership boundary. Google’s current official Google Ads MCP server does not require a developer token, but it does require a Google Cloud project with an approved production access level and OAuth credentials or application default credentials.

Your team must also configure and run the server, protect credentials, keep dependencies current, and maintain compatibility with the Google Ads API and the AI client.

Google’s current official server is read-only. It is useful for natural-language analysis, but it does not modify campaigns in its present release. A different self-hosted server can expose write tools if its implementation, API access, and account permissions support them.

A direct API integration is appropriate when you are building a product, internal application, deterministic pipeline, or custom workflow that should not depend on an MCP client.

You no longer need a developer token, but you do need to own the full integration:

The distinction is operational, not cosmetic. Direct API access gives you control over the application. MCP gives an AI client a standard tool interface. A hosted MCP service also transfers much of the connection and maintenance work to the provider.

You do not need to rotate, resubmit, or attach the token to a new project for standard Google Ads API access. Google transferred qualifying access levels to the Cloud projects that had been using approved tokens before the sunset.

Check the Google Ads API Overview page in Google Cloud Console to confirm the project’s current access level. If a different or previously unused project needs production access, apply for the appropriate access level for that project. The historical token itself cannot be used to grant the new project access.

If a legacy application fails after an access-level change, diagnose the project’s Google Ads API approval and authorization errors rather than assuming the old token needs replacement.

None of these paths requires a standard Google Ads developer token after September 9, 2026. Only the latter two require your own Google Cloud project and API access setup.

HireOtto is a hosted remote MCP service. A marketer can connect its Google Ads server to a supported AI client, sign in to HireOtto, and authorize a Google login without building a developer application, configuring a Cloud project, supplying API credentials, or running a local server.

After authorization, HireOtto can discover the Google Ads accounts available to that login, run supported reporting and analysis workflows, and perform documented account actions when the connected role allows them. It does not bypass Google Ads permissions or act as an autonomous media buyer. Start with a read request, confirm the exact customer ID, and keep a human review gate before consequential or bulk changes.

Read What is HireOtto?, review Google Ads OAuth and account access, then follow the connection guide for Claude, ChatGPT, and other AI clients to get started.

After connecting, use a read-only verification prompt before requesting analysis or changes:

Confirm the returned advertiser before continuing. If the correct account does not appear, fix the Google login or account permission rather than changing API credentials blindly.

No. HireOtto users do not create or provide a developer token. They connect the hosted server and authorize Google Ads through OAuth.

No. HireOtto manages the hosted application-side integration. You need a compatible AI client, a HireOtto account, and a Google login with access to the advertiser accounts you want to use.

No. The latest server uses the Google Cloud project’s API access level. You still need to configure that project and suitable authorization credentials.

Yes, for user-authenticated access. OAuth authorizes the application to work on behalf of a Google identity. The project access level and the user’s Google Ads role remain separate gates.

Only accounts discoverable through the connected Google identity and the connector’s account-routing behavior. Manager hierarchies, multiple logins, plan limits, and account roles can affect what appears.

No. The application still needs Google Ads API access, the user still needs to authorize it, and Google Ads still enforces advertiser roles and platform rules.

No. The retired Google Ads developer token was an API-access credential associated with an application’s access level. OAuth identifies and authorizes the user. Google Ads does not use a simple API key as a substitute for account authorization.