# Set up Google Cloud for integrations

Create a Google Cloud project, enable APIs and configure OAuth to get a client ID and client secret for your integration.

Last updated: 2026-10-21

You're connecting a Google service to another tool, and it asks for a **Client ID** and
**Client secret**. You get those from Google Cloud Console, after creating a project and configuring
how your integration will ask for access.

This guide walks through that setup for workflow tools, dashboards and AI agents. It works for
personal Google Accounts and managed work accounts. You don't need to write code or deploy a server
in Google Cloud to register this kind of integration.

## Before you start

Open your integration tool's Google connection settings or documentation. Find these three things:

- **Authentication method:** this guide covers a custom OAuth 2.0 connection that asks for a client
  ID and client secret. API keys and service accounts use different setup paths.
- **Required APIs and permissions:** which Google services the integration uses, and the access it needs.
- **Redirect URL:** sometimes called a callback URL or OAuth redirect URI. Your tool supplies this
  address; you'll copy it into Google later.

Some hosted tools offer a ready-made **Sign in with Google** connection. If yours does, you may
be able to connect without registering your own app. Use this guide when you need your own credentials.

### What you're creating

In Google's settings, **app** means the integration you're registering to ask for account access.
The **OAuth client** is its registration for a particular connection, with an ID and secret your
tool uses. You can register these settings for an existing tool without building an app yourself.

| Item | What it means |
| --- | --- |
| Google Account | The identity you sign in with, whether personal or managed by your company |
| Google Cloud project | A container for enabled APIs, app settings and credentials |
| Cloud Billing account | Pays for billable usage in projects linked to it; separate from your Google Workspace subscription |
| Enabled API | Makes a particular Google service available to your project |
| OAuth consent screen | Describes the app requesting access and who can authorize it |
| OAuth client | The registration that supplies the client ID and client secret your tool needs |
| Scope | A specific permission the integration requests, such as reading calendar events |

Creating credentials doesn't authorize access to your files, email or other data. That happens
later, when you sign in and approve the connection. It also doesn't give your Google Account access
to resources it couldn't already use.

## Step 1: Open Google Cloud Console

Open [Google Cloud Console](https://console.cloud.google.com/) and sign in with the Google Account
you want to manage the integration. Accept first-use terms if prompted, and complete two-step
verification if Google requires it.

Already use Gmail or Google Workspace? Use that login. You don't need a second email address or
another password for Cloud Console.

If your email uses a different provider, you can
[create a Google Account using your existing email address](https://support.google.com/accounts/answer/27441?hl=en).
A Google Account with a work address isn't automatically a managed Google Workspace account.

If you're setting this up for a company with an existing Cloud setup, ask which account and project
to use. Access to Gmail or a shared spreadsheet doesn't necessarily include permission to configure
Google Cloud.

### If you land on a free-trial signup page

Google supports exploring Cloud Console without joining the free trial. Start with the Console
link above. **Start free** is a separate signup flow that asks for payment details.

You don't need the trial just to create OAuth credentials. If an API requires billing, follow
Step 3. If you choose the trial, review Google's [trial terms and signup details](https://cloud.google.com/signup-faqs).

## Step 2: Create or select a project

1. Open the project selector in the top bar of Cloud Console.
2. Choose **New project**.
3. Enter a recognizable name, such as **Workflow integrations**.
4. If prompted for an organization or folder, choose your company's approved location. For a
   personal setup, **No organization** may be available.
5. Click **Create**, then select the project in the project selector.

You can reuse an approved project if you have permission to configure it. Check the selected project
before every step: an API enabled in one project won't configure an OAuth client in another.

If project creation is unavailable or denied, ask your Cloud administrator to create a project or
grant the appropriate access. See Google's [project creation guide](https://docs.cloud.google.com/resource-manager/docs/creating-managing-projects).

## Step 3: Set up billing if your API requires it

Creating a client ID and client secret doesn't itself require billing. Billing requirements come
from the API you're using. Some Google APIs are free; others require
billing even when they include a free allowance. For example, Google documents
[no charge for Search Console API usage](https://developers.google.com/webmaster-tools/pricing)
and [no additional cost for standard Sheets API use](https://developers.google.com/workspace/sheets/api/limits).
Don't extend those pricing rules to every Google service.

Check the API's pricing and your tool's setup instructions, then choose your path:

- **Billing isn't required, or is already enabled on this project:** continue to Step 4.
- **Billing is required but isn't enabled:** follow [Set up billing](#if-your-api-requires-billing)
  below, then return to Step 4.

## Step 4: Enable the required APIs

1. Select your project.
2. Open **APIs & Services → Library**.
3. Search for the API named in your integration's documentation.
4. Open its page and click **Enable**. If already enabled, continue.
5. Repeat for any additional APIs the integration requires.

| The integration works with | API to look for |
| --- | --- |
| Spreadsheets | Google Sheets API |
| Files and folders | Google Drive API |
| Email | Gmail API |
| Calendar events | Google Calendar API |
| Search performance | Google Search Console API |

This table is a starting point. A spreadsheet integration might also use Drive API to find files.
Follow the tool's complete requirements rather than enabling every API in the list.

Enabling an API makes it available to the project. It doesn't authorize your integration to read
anyone's data. If Enable is unavailable, ask your administrator for help with
[service-enablement permissions](https://docs.cloud.google.com/service-usage/docs/enable-disable).

## Step 5: Configure the OAuth consent screen

The consent screen is the Google page people see when your integration asks for account access.
You're registering the app that asks; you'll approve its access separately later.

Open **Google Auth Platform** in your project. An older **APIs & Services → OAuth consent screen**
link may redirect you there. For a new setup, choose **Get started**:

1. Enter an **App name**, such as **Workflow integrations**, and a **User support email**.
2. Choose the **Audience** using the guidance below.
3. Enter a developer **contact email** you monitor.
4. Review and acknowledge Google's User Data Policy, then create the configuration.

If a configuration already exists, review **Branding** and **Audience** instead. Google's
[consent setup guide](https://developers.google.com/workspace/guides/configure-oauth-consent)
describes these settings.

### Personal or work account: Internal versus External

| Who will authorize Google accounts? | Audience |
| --- | --- |
| You, using personal Gmail or an unmanaged Google Account | External |
| Only members of the project's Google Workspace or Cloud Identity organization | Internal, when available |
| Clients, contractors or other accounts outside that organization | External |

Internal is tied to the project's Google organization. A work-looking email, an invitation to your
automation tool, or permission to manage the Cloud project doesn't establish audience membership.
If Internal is missing for a company setup, ask your administrator to check the project's ownership.
Personal onboarding can also create a standalone organization; that alone doesn't establish a
Google Workspace or Cloud Identity organization for this choice.

External doesn't expose your account's data publicly. People must still sign in, approve the
requested access and have permission to use the underlying data. Company administrators may
restrict which apps can connect regardless of the audience setting.

### Branding and authorized domains

For your first personal test in **Testing**, check the support and contact emails under **Branding**.
You can leave optional logo and website fields empty; you don't need to build a website just to
try the connection. If Google marks a field as required, resolve it before continuing.

Before moving an External app into production or submitting it for verification, review Google's
requirements for homepage, privacy-policy and terms links. Use accurate app information; don't
enter your integration provider's pages as though they describe an app you own.

If your tool's instructions require an **Authorized domain**, enter a domain such as
`example.com`, without a scheme or callback path. This setting is separate from the full redirect
URI you'll enter for the client. Hosted tools may specify a provider domain; self-hosted setups
use the domain for that installation. Follow the tool's instructions rather than guessing.

If Google asks you to verify a domain you own, follow its ownership-verification instructions.
If it asks you to verify your hosted tool's domain, check that tool's custom-OAuth instructions or
contact its support. You can't prove ownership of someone else's domain. See
[Google's branding guidance](https://support.google.com/cloud/answer/15549049?hl=en).

## Step 6: Configure scopes and publishing status

### Add the permissions your integration needs

**Internal app used only within your Google Workspace organization:** you don't need to list scopes
on this screen. Continue to Step 7. Your tool must still request the appropriate permissions when
connecting Google, and company restrictions still apply.

**External app:** find the exact scope values in your tool's service-specific credential instructions.
They often look like URLs. For example, this is a scope for reading spreadsheets:

```text
https://www.googleapis.com/auth/spreadsheets.readonly
```

That's an example, not a scope every integration needs. Use the values your tool requires:

1. Open **Google Auth Platform → Data Access → Add or remove scopes**.
2. Find and select each required scope in the list. If a scope is missing, check that its API is
   enabled, or enter the exact value under **Manually add scopes**.
3. Click **Update**, then **Save** on the Data Access page if shown. Confirm that your scopes appear
   in the saved list.

Don't select every permission for an API. If your tool doesn't identify the scopes it needs,
check its service-specific setup guide before continuing. A generic OAuth connection may also
need those values entered in the tool itself; built-in connections often request them for you.

A scope is a permission, not an API switch. Enabling Drive API and asking to read Drive files are
separate steps. Where the integration supports it, choose the narrowest access that does the job.

Google groups scopes into non-sensitive, sensitive and restricted categories. Read-only scopes
can still be sensitive or restricted. Requirements depend on the exact scopes and audience;
Gmail and Drive connections shouldn't inherit another service's verification assumptions.
See [Manage App Data Access](https://support.google.com/cloud/answer/15549135?hl=en).

### External: Make your first connection

For your first test, leave the app in **Testing**:

1. Open **Audience → Test users → Add users**.
2. Enter the exact Google email address you'll use to connect your data, then click **Save**.
   The project owner isn't automatically a test user. You can list up to 100 test users.
3. Continue to Step 7 to create the client, then test the connection in Step 8.

If the app is already **In production**, don't switch it back to Testing. Continue to Step 7.

> [!WARNING]
> Testing connections can expire after seven days
> External apps in Testing have seven-day authorizations and refresh tokens when requesting data beyond Google's basic identity scopes. Plan for reconnection while testing.

### External: Keep the connection working

After your test succeeds, return here before relying on the connection for ongoing work.

For example, if only you use the app to connect your own Google account to a private workflow,
Google describes a [personal-use verification exemption](https://support.google.com/cloud/answer/13464323).
Review your saved app information and any required fields, then choose **Audience → Publish app**
to move to **In production**. Publishing isn't the same as submitting the app for verification;
an applicable unverified-app warning may remain.

If you're distributing the app to clients or a wider audience, don't assume that personal-use
example applies. Check the verification requirements for your exact audience and scopes before
distribution. Some restricted-scope uses also need a
[security assessment](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification).

If Google won't let you publish, resolve the requirements it lists. Don't replace required app
details with invented values or treat a publishing block as an ordinary warning.

After changing from Testing to In production, reconnect any account authorized while Testing.
Production status removes that testing-specific limit, not every reason a connection can expire.
See [Google's audience and publishing rules](https://support.google.com/cloud/answer/15549945?hl=en).

## Step 7: Create the client ID and client secret

Have the **redirect URL from your integration tool** ready. Use the value for your actual hosted,
self-hosted or local installation, including the port and path.

Paste the full URL under **Authorized redirect URIs**, not **Authorized JavaScript origins**.
It must match what your tool sends, including scheme, port, path and trailing slash. Google normally
requires HTTPS, with a localhost exception for development. Use your tool's callback URL rather
than the homepage of the website whose data you're connecting.

1. In **Google Auth Platform → Clients**, choose **Create client**. You can also reach this through
   **APIs & Services → Credentials → Create credentials → OAuth client ID**.
2. Choose **Web application** for a tool that uses a web-server callback. If your tool explicitly
   requires a different type, follow its instructions.
3. Enter a recognizable client name, such as **Reporting connection**.
4. Under **Authorized redirect URIs**, choose **Add URI** and paste the complete redirect URL.
5. Before creating the client, check the optional agent setting below if it appears.
6. Click **Create**.

**Optional: AI-powered agent setting.** Use this designation for a dedicated AI-agent or MCP
connection—a tool that connects an AI assistant to services. An ordinary automation doesn't need
it solely because it runs unattended.

Copy the **Client ID** and **Client secret** into your tool's designated credential fields and save.
Google only displays the full secret when it's created. Keep any separate copy in a password manager
or secret store. If lost, use Google's secret-rotation controls to create a replacement and update
the tool. See [Manage OAuth Clients](https://support.google.com/cloud/answer/15549257?hl=en).

Treat the client secret like a password. Keep it out of chat, shared documents, screenshots and
source code. The client ID identifies the app; neither value is the password for your Google Account.

## Step 8: Authorize and check the connection

In your tool, choose **Connect**, **Authorize** or **Sign in with Google**. Select the Google account
whose data you want to use, check the app name and permissions, and approve the intended access.
The account can differ from the one managing Cloud Console if the audience permits it.

### If Google says the app isn't verified

During your own test, an unverified-app warning can be expected. Check that you started from your
tool's connection screen and that the app or domain shown matches the setup you just registered.
Google may show a domain rather than your chosen app name before brand verification.

For your own test or an eligible personal-use app, if **Advanced** is available, expand it and
choose **Go to [app name or domain] (unsafe)**, then review the permissions. Google documents this
[test continuation](https://developers.google.com/people/v1/troubleshoot-authentication-authorization).
Use it only for your own expected setup, not an unfamiliar app.

If there is no continuation option, or the page says an administrator blocked access, resolve the
restriction shown. Check the test-user list, audience and company policy as applicable; a hard
block isn't the same as a warning you can continue past.

### Confirm access

Google should return you to the tool, which should report a connected account. Run a read-only
check: list calendars, retrieve a known spreadsheet, or list accessible properties, depending on
the integration. Successful sign-in doesn't create access to files, properties or resources that
weren't shared with that Google account.

If the tool needs to keep working while you're away, follow its instructions for offline access
and refreshing tokens. You shouldn't need to manually copy account tokens into workflow steps.

## If your API requires billing

Skip this section if your API doesn't require billing. Otherwise, create or choose a billing account,
link it to your project, then [continue to Step 4](#step-4-enable-the-required-apis).

### Create a billing account

1. Open **Billing → Manage billing accounts** in Cloud Console.
2. Choose **Create account** if you don't already have a suitable account.
3. Enter a billing-account name and choose the organization, if requested.
4. Choose the country matching your billing address.
   Country determines currency and payment options; it isn't the location of your audience or data.
5. Select or create a Google payments profile, enter the requested billing details and payment method,
   and complete Google's verification prompts.

Choose the payments profile's **Individual** or **Business** type to match who is paying. Using a
company email doesn't make that choice for you. Billing country and payments-profile type are
important choices that Google doesn't let you freely change later. Follow Google's
[billing-account instructions](https://docs.cloud.google.com/billing/docs/how-to/create-billing-account)
for the fields shown to you.

### Link billing to the project

1. In **Manage billing accounts**, open **My projects**.
2. Find your project and open its actions menu.
3. Choose **Change billing**, select the approved billing account, then **Set account**.

Creating a billing account alone doesn't link every project to it. If the account isn't selectable,
you may need access to both the project and billing account. Ask the company administrator rather
than adding a personal card. See [Google's linking instructions](https://docs.cloud.google.com/billing/docs/how-to/modify-project).

For billable services, set an appropriate budget under **Billing → Budgets & alerts**. An alerts-only
[budget](https://docs.cloud.google.com/billing/docs/how-to/budgets) sends notifications;
it doesn't automatically stop spending.

## Common setup problems

| What you see | What to check |
| --- | --- |
| Can't create a project, enable an API or edit OAuth settings | Check company policy and Cloud permissions with your administrator |
| Billing account missing from the list | You need permission to link the project to that billing account |
| API disabled or never used | Enable the named API in the project that owns this OAuth client; check additional APIs the tool needs |
| `redirect_uri_mismatch` | Copy the complete callback URL from the current tool installation; don't swap a domain for a full URL |
| `invalid_client` | Check the client ID and secret belong to the same client and are saved without extra spaces |
| Account isn't an allowed test user | Add its exact email under Audience → Test users, or review publishing status |
| `org_internal` | The connecting Google account is outside the Internal app's organization |
| Administrator blocked the app | Ask the Workspace administrator to review the client and requested access |
| Connection stops after a week | Check External + Testing, then review publishing status and reconnect |
| Connected, but expected data is missing | Check the connected account, resource sharing and requested scopes |

Your project, enabled APIs and OAuth client are now ready for your integration. Return to the
tool's service-specific instructions for the exact operations and permissions it supports.