Connect Google Ads

Create the Cloud project and request Explorer access

Everything on this page happens inside one Google Cloud project. Keep the project picker at the top of the console on it throughout; a service account from any other project would sign in at that project’s access level instead.

1. Note your advertiser account’s customer id: the 10-digit number shown top-right in Google Ads next to the account name. You’ll enter it in Abaxar at the end.
2. Open the Google Cloud Console. In the project picker top-left, create a new project for the business (a plain brand-based name is fine), or select the one GA4 setup already uses. Don’t reuse a project that another tool’s Google Ads integration already runs in; Google asks for one project per integration.
3. Enable the API: open this enable link with that project selected and click Enable. (The long way: APIs & Services → Library, search Google Ads API, Enable.)
4. Open the project’s Google Ads API page (APIs & Services → Enabled APIs & services → Google Ads API). The Current access level card shows the project’s level; a fresh project reads Test.
5. Expand Upgrade access level under the card. Next access level should read Explorer. Click Apply for access. There is no form: the page shows “Your application for explorer-level access is currently under review. Please check back in a few minutes.”
6. Wait a couple of minutes and reload. The card now reads Explorer, and Google emails you an Explorer Access Approval notice naming the project number. Keep that email; it’s your record of access.

What the card should say now

• Explorer is the finish line, not a stepping stone. It reads production accounts and allows 2,880 API operations a day; a full Abaxar sync is about 19, so hourly syncing plus a deep backfill fits in one day with room to spare. Once the card reads Explorer, the panel below it offers Basic as the next level with a brand-verification note. Leave it alone.
• If the card already read Explorer, Basic or Standard before you clicked anything, the project already has access: skip straight to the service account.
• If Next access level reads Basic instead of Explorer, or the card is still Test after fifteen minutes, Explorer isn’t on offer for this project. Carry on with the service account below (it’s needed either way), then use the Basic Access section at the end of the page.

The service account

1. Still in the same project, open IAM & Admin → Service Accounts and create a reporting service account with a plain name such as ads-reporting, or reuse the one GA4 uses.
2. Open it, then Keys → Add key → Create new key → JSON. The key file downloads; keep it on this machine. Copy the service account’s email address too.
3. If a dialog headed “Service account key creation is disabled” appears instead of a download, jump to the last section on this page. It is a one-time fix with its own short video; come back here once the key has downloaded.

Grant the service account access in Google Ads

1. Open Google Ads as an admin on the advertiser account, and go to Admin → Access and security.
2. Under Users, click + and add the service-account email with Read only access. Not Email access.
3. If you granted access on a manager account rather than directly on the advertiser, note that manager account’s id: it goes in the optional login customer id field in Abaxar. On the normal path (direct grant) that field stays empty.

Enter the values in Abaxar and verify

1. In Abaxar, open Settings → Connectors and scroll to the Google Ads card.
2. Enter your advertiser customer id from the first step.
3. Drop the downloaded JSON key file on the recommended field; Abaxar stores only the service account’s email and private key, never the raw file. If GA4 shares the identity, tick Apply to both.
4. Leave the optional login customer id empty unless the service account’s access comes through a manager account. A stale or wrong value there fails every call with a permission error even though the key is fine.
5. Click Save Google Ads keys, then Verify. “Connected to” your account name proves the key, the project’s access level and the customer id together. Delete the downloaded .json key file once it’s verified.
6. Choose the backfill window and click Run backfill now. Only a project still on Test access waits for the Basic Access review before production syncs work.

Only if Explorer wasn’t granted: brand verification first

Most setups never reach this section. You’re here because the Google Ads API page offered Basic instead of Explorer, or left the project on Test, or you’re on Explorer and want the quota lift from 2,880 to 15,000 operations a day.

Basic Access is gated on brand verification of your Cloud project: the page says so inline and offers a Start brand verification link next to Apply for access. Verification compares the branding you enter in the console with your public website, so the site must be live, with a real privacy policy and terms page, a contact email on the business domain, and a domain you can prove you own. Do the verification first, then the application.

1. In the Cloud Console for the same project, open APIs & Services → OAuth consent screen (a first-time setup walks you through a short Get Started flow).
2. On the Branding tab: app name is your brand name exactly as your homepage shows it, character for character; Google compares the two and rejects a mismatch, so no “Dashboard” suffix. Support email is an address on your business domain (sign in as that Google user; the dropdown only offers the signed-in user), home page / privacy policy / terms links point at your site, and add your domain under Authorised domains (Google sends you to Search Console here if the domain isn’t verified yet). Skip the logo, then Save. Branding has to come first: the console blocks the next step as “configuration incomplete” until it’s filled in.
3. On the Audience tab, set the user type to External and the publishing status to In production. Google requires both, even though Abaxar signs in with the service account rather than OAuth users.
4. Click Verify Branding, complete any domain-ownership check Google asks for, and wait. Once verified, click Publish branding straight away: an unpublished verified result expires after 7 days.
5. Copy the project’s numeric Project number from the Project info card on the Cloud Console dashboard (also under IAM & Admin → Settings). It’s the 11- or 12-digit number, not the alphanumeric project ID; the design document and any project question on the form want the number.

Then apply for Basic Access

Back on the Google Ads API page, expand Upgrade access level: Next access level now reads Basic and the brand-verification warning is gone. Read the consent line and click Apply for access. If Google presents application questions, the blocks and notes below answer them.

• Capabilities: Reporting only, none of the creation or management options. Who has access: Internal users, for most founders. App Conversion Tracking and Remarketing API: No.
• Tool developed by someone else: Yes. Abaxar is a tool you bought, so answer honestly and give its page, https://therichstack.com/abaxar, in the URL field that appears. What compliance actually checks is whether you run and control the tool (hosted services the applicant doesn’t manage get bounced), which is why the summary above says the full source code runs on your own machine. Keep those sentences in.
• Campaign types: the box asks which types the tool supports. Abaxar reports on every campaign type in the account, so paste the third block above as-is.
• If the form asks you to upload documentation of the tool (.pdf, .doc or .rtf only), don’t write it by hand: paste the second block above into your AI assistant and it fills in Abaxar’s ready-made template, dashboard screenshots already included.
• Submit. Google describes the review as automated once the project is brand-verified: expect hours rather than days, with five business days as the published ceiling. The card reads Basic when approved and Google emails a confirmation. Everything else on this page is already done, so the review is the only thing outstanding.

If something looks wrong

• You’re looking for a developer token, API Center or a manager account to sign up with: none of those exists any more. The access level is on your Cloud project’s Google Ads API page, and Abaxar’s card has no token field.
• The card says Test and nothing changes with time: there is no automatic upgrade. Expand Upgrade access level and click Apply for access; it takes minutes.
• Syncs fail while a Basic Access application is pending on a Test project: expected. Everything is wired; Google just hasn’t opened the tap yet. On Explorer nothing is pending and syncs work immediately.
• Verify fails with “Google Ads API is not enabled in the Cloud project behind these credentials”: the API was enabled in a different project from the one that issued the key. Enable it there and wait a few minutes.
• Verify fails with a permission error: with the login customer id set, clear it, the grant was direct. Without it, the service account isn’t added in Google Ads yet, or the customer id is wrong (the manager id is not the customer id).
• Verify names CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION or ACTION_NOT_PERMITTED: the project is still on Test. Go back to the Google Ads API page and request Explorer.
• Brand verification reports issues: it’s almost always the app name not matching the homepage exactly, a personal-Gmail support email, or a privacy-policy or terms link that isn’t live.

If you see “Service account key creation is disabled”

The dialog has that title, a red banner reading “An organisation policy that blocks service accounts key creation has been enforced on your organisation”, and an Enforced organisation policy IDs line naming iam.disableServiceAccountKeyCreation. It is expected on any business-domain (Google Workspace) Google account: Google switches this policy on for every Cloud organisation created since May 2024, so it is a default, not a fault. A personal Gmail account never sees it.

The fix is a one-time override on your Abaxar project. It covers both Google Ads and GA4, and you can put enforcement back afterwards. The override needs a role your Google user doesn’t hold yet, even as the project owner and the only person on the account, so the steps grant that role first and then make the override. The dialog’s own “disable” link only opens Google’s documentation, so close it and follow the video or the steps below, then carry on with the setup where you left off.

Watch the walkthrough

1. Close the dialog. The role you need can only be granted on the organisation itself, and “No organisation” is not your organisation (it is a scope for projects outside any organisation, and IAM won’t open there). Click the project picker at the top of the console and, on the All tab, click the top row of the tree: your domain name with a building icon, not a project under it. The picker button now reads your domain name.
2. Open IAM & Admin → IAM. It reloads for the organisation, with your email already listed as Organisation Administrator and a Grant access button at the top. Click Grant access, add your own email address as the principal, paste the role name below into the role search, pick the exact match (not Organisation Administrator and not OrgPolicy Simulator Admin), and save.

   The console may spell it Organisation; either spelling finds it.

   Organization Policy Administrator

3. Switch the picker back to your Abaxar project. Open IAM & Admin → Organisation policies and paste the policy id below into the filter box.

   Filter by constraint name, ID or type.

   iam.disableServiceAccountKeyCreation

4. Two rows can appear with the same name. Open the one whose ID is exactly iam.disableServiceAccountKeyCreation, the ID the dialog named. Leave the iam.managed.disableServiceAccountKeyCreation row alone.
5. Click Manage policy (enabled now that you hold the role). Under Policy source choose Override parent’s policy, then click Add a rule, set Enforcement to Off, click Done, then Set policy. Back on the list, both rows now show an Enforcement state of Inactive.
6. Give it a minute, then go back to the service account’s Keys tab and create the JSON key again (Add key → Create new key → JSON). It downloads this time. Pick the setup up where you left off.
7. Optional, once the key is downloaded: put enforcement back with Manage policy → Inherit parent’s policy → Set policy. Existing keys keep working; only future key creation needs the override again.

Set up the next connector