How to connect Google Ads to OpenClaw

The ClawHub skill teaches OpenClaw about Google Ads, but the calls run through the ClawLink plugin and your connected account. Make sure Google Ads is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.

Reconnect Google Ads from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Google Ads tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Google Ads call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The agent wrote FROM campaign_performance_report (or keyword_performance_report, or ad_performance_report). Those are AdWords report names that Google retired with the old API, and they appear in a large share of the tutorials models were trained on, so this is the most frequent Google Ads failure on ClawLink. GAQL has no report resources: you select metrics from the entity itself. Replace the resource with campaign, ad_group, ad_group_ad, or keyword_view and keep the metrics.* fields, for example SELECT campaign.name, metrics.impressions, metrics.clicks, metrics.cost_micros FROM campaign WHERE segments.date DURING LAST_30_DAYS. ClawLink catches this before the call leaves, so the fix is one corrected query rather than a debugging session.

Ask the agent to diagnose it:

That query used a legacy AdWords report resource. Rewrite it as GAQL selecting metrics.* from a real resource (campaign, ad_group, or keyword_view) with a segments.date filter, show me the query text before you run it, then run it.

Google rejects the mutate because, by the time the request arrived, the update object was empty. The cause is upstream: the mutate tools accept a fixed set of fields and quietly discard everything else, so an agent that sent budget_amount_micros or a nested bidding-strategy object had those keys stripped, leaving nothing to build a field mask from. Passing update_mask yourself does not help either, because the mask is derived and a supplied one is discarded. Retry with only supported fields: campaign updates take name, status, start_date, end_date, daily_budget, campaign_budget, bidding_strategy_type, and related settings, while ad group updates take just name, status, and resource_name. If the request was to change a target CPA or a bid ceiling, that is not writable through these tools and no retry will land it.

Ask the agent to diagnose it:

Show me the exact operations array you sent. Remove any update_mask, drop every field outside the tool's supported set, and tell me plainly if what I asked for (bid ceilings, target CPA, target ROAS) is unsupported rather than retrying.

The query mixed FROM conversion_action with segments.conversion_action or segments.conversion_action_name. Those segments are incompatible with the conversion_action resource, so Google rejects the combination. There are two valid shapes and you have to pick one. Either keep FROM conversion_action and select the attributes conversion_action.id and conversion_action.name instead of the segments, or keep the segment and move the resource to FROM customer or FROM campaign, remembering that only conversion metrics such as metrics.conversions, metrics.all_conversions, and metrics.conversions_value may be selected next to a conversion segment.

Ask the agent to diagnose it:

Rewrite that as two options: one using FROM conversion_action with conversion_action.name as an attribute, and one using FROM campaign with segments.conversion_action_name and only conversion metrics. Show me both, then run the one that answers my question.

The tool does not exist, and neither do googleads_mutate_campaign_budgets, googleads_search, googleads_mutate_ad_group_ads, or googleads_mutate_campaign_criteria. Agents invent these names because the Google Ads API itself has separate budget and criterion services, so the guess is reasonable and wrong. Budgets are changed through the daily_budget field on googleads_mutate_campaigns, and reporting runs through googleads_search_stream_gaql, not googleads_search. Have the agent list the real catalog before it guesses again.

Ask the agent to diagnose it:

Run clawlink_list_tools for google-ads and show me the exact tool names available. Then redo my request using only names from that list.

Try reconnecting Google Ads and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect OpenClaw to Google Ads: link your Google Ads account once in the browser and OpenClaw can call the Google Ads API through 10 ready-made tools — no custom code or token handling.

Paste the setup prompt from this page into OpenClaw. It installs the ClawLink Google Ads skill from ClawHub, then you click Connect in the dashboard to authorize Google Ads. OpenClaw calls the tools from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to Google Ads in the dashboard, authenticate, and OpenClaw can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for OpenClaw. That is fine if you want to build and maintain the integration yourself. Most teams just want Google Ads working from chat.

Not through ClawLink. This is the step every DIY guide requires and most gloss over: the developer token you receive when you sign up for the Google Ads API is issued at Test Account Access level, which queries test accounts only, so it cannot read the campaigns you actually run. Google's ladder from there has three more rungs. Explorer reaches production but allows 2,880 operations a day against it. Basic lifts that to 15,000 a day and takes about five business days to review. Standard removes the cap and takes around ten. The limits are measured over a sliding 24-hour window rather than resetting at midnight, which is why a heavy afternoon can still be throttling you the next morning. ClawLink connects through hosted OAuth instead, so you approve access on Google's consent screen and never handle a developer token, client secret, or refresh token — and because the hosted connection runs on a Basic-level token, you are not living with the Explorer ceiling either.

Budgets yes, bids mostly no. googleads_mutate_campaigns accepts a daily_budget field, and that is the only budget lever in the toolkit; there is no separate budget tool, so an agent calling googleads_create_campaign_budget is using a name that does not exist. Bidding is more limited: you can set bidding_strategy_type and manual_cpc, but the sub-fields inside a portfolio strategy, such as target_cpa.target_cpa_micros, target_roas.target_roas, and target_spend.cpc_bid_ceiling_micros, are not writable through these tools. Ask for one of those and the correct answer is that it is unsupported.

Almost always the GAQL, not the connection. Six patterns cover most of it: legacy AdWords report names like FROM campaign_performance_report, using FROM device when device is a segment, subqueries with IN (SELECT ...), quoting numeric ids such as campaign.id = '123', selecting metrics.* from ad_group_criterion instead of keyword_view, and asking for metrics.conversion_rate, which is not a field. ClawLink checks for all six before the query reaches Google and returns the corrected form, so the agent can fix the query on the next turn rather than retrying the same broken one.

Usually not. customer_id is optional on googleads_search_stream_gaql, and in production most successful queries omit it, so a missing customer ID is not the reason a call failed. When you manage several accounts, have the agent run googleads_list_accessible_customers first and name the account you mean, since that is what disambiguates the request.

It works, but be explicit about which account you mean. On the do-it-yourself route, requests made through a manager account carry a login-customer-id header naming the manager, and a missing or wrong value there is the classic 403 that Google's own documentation leads with. On a hosted connection there is no header for you to set, so the equivalent step is naming the account: have the agent run googleads_list_accessible_customers, confirm which customer it is about to act on, and pass that as customer_id rather than leaving it implicit. If a call fails against one account while succeeding against another under the same manager, that is the mismatch to look at first, not the query.

The ClawHub skill teaches OpenClaw about Google Ads, but the calls run through the ClawLink plugin and your connected account. Make sure Google Ads is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.