Set up Google Cloud for integrations

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.

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.

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.

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.

Open Google Cloud Console 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. 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.

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.

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.

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 and no additional cost for standard Sheets API use. 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 below, then return to Step 4.

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.

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.

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 describes these settings.

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.

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.

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:

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.

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.

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. 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.

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.

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.

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.

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.

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. 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.

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.

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.

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 for the fields shown to you.

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.

For billable services, set an appropriate budget under Billing → Budgets & alerts. An alerts-only budget sends notifications; it doesn't automatically stop spending.

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.