Skip to main content
Google Cloud is Google’s cloud platform. The Google Cloud API connector lets your Lovable app call any Google Cloud REST API, such as Resource Manager, Cloud Asset Inventory, Cloud Monitoring, Cloud Logging, Compute Engine, and Cloud Run, as a service account in your Google Cloud organization. It’s designed for internal tools and dashboards that read or administer Google Cloud projects you control. Google Cloud API is available as an app + chat connector: one shared connection that works in Chats, in the project chat while you build, and in your published apps. With Google Cloud API, your app can:
  • List projects, folders, and organizations, and search the resources in them with Cloud Asset Inventory
  • Read Cloud Monitoring metrics and Cloud Logging entries for dashboards and reports
  • List Compute Engine instances, Cloud Run services, and Cloud Storage buckets
  • Read billing accounts, project billing settings, and service pricing from Cloud Billing
  • Inspect the Identity and Access Management (IAM) policy of a project
  • Create, change, or delete resources when you ask for it, within the roles granted to the service account
This is a connector for apps you build with Lovable. It integrates your app with your Google Cloud projects. It does not deploy or host your Lovable app on Google Cloud. To publish a Lovable app, use Lovable’s own publish flow.
For SQL analytics on data in BigQuery, including cost and spend analysis from a Cloud Billing export, use the BigQuery connector, which supports the same Workload Identity Federation setup. Google Cloud API reads billing accounts and pricing, not your spend.

Common use cases and example apps

These examples show what you can build with Google Cloud API, each with a prompt to start from.

How Google Cloud API connections work

The connector authenticates with Workload Identity Federation, Google’s keyless way to let an outside system act as a service account. You configure Google Cloud to trust identity tokens for a workspace-specific audience, restricted to Lovable’s connector gateway service account, and Lovable impersonates the service account you specify. Each connection uses one workload identity provider and one service account, and multiple projects in the workspace can share it. No service account key is created, and Lovable stores no Google secret: the connection consists of the provider’s resource name and the service account’s email address. Lovable’s connector gateway exchanges its own identity token for a short-lived access token for the service account through Google’s Security Token Service, refreshes it in the background, and forwards each request to the Google Cloud API your app names. The token stays on the server and is not exposed to your published app. The connector does not restrict which Google Cloud services or operations a connection can reach, and it does not distinguish reads from writes. The IAM roles granted to the service account are the control: whatever the service account may do, apps built on the connection can do. Grant the narrowest roles at the narrowest scope (project, folder, or organization) that covers your app, and make them read-only where possible. One exception applies. Five Google Cloud services return credentials or secret values, and the connection’s Scopes setting decides whether apps can reach them at all: All five are selected when you create a connection. Deselect a service to block it: the gateway then rejects every request to that service, including its regional endpoints, with a 403 whose error type is sensitive_service_not_enabled, and Lovable tells you which service to enable instead of retrying. IAM still applies to the services you leave selected, so a selected service grants nothing by itself. Connecting verifies the federation but not the access. Lovable only confirms that Google exchanges its identity for a token for the service account, so a connection can verify and still receive 403 responses until the roles exist and the APIs are enabled. See Troubleshooting. When you build with the connection in the project chat, Lovable works this way:
  • Lovable builds read-only features by default and adds calls that create, change, or delete resources or IAM bindings only when you ask for them by name.
  • Before generating code for a call that changes a project, Lovable states the exact project, resource, and change and asks you to confirm. For deletions, role changes, calls that incur cost, and calls that create or return credentials, Lovable also explains what else the change affects and whether it can be undone, and asks a second time.
  • Lovable builds resource creation as a single action that you confirm, rather than a loop, schedule, or per-user trigger.
  • Lovable keeps every call server-side and does not place Google access tokens or the connector’s credentials in frontend code or chat. Secret values, keys, and tokens a call returns stay on the server too.
  • Lovable declines to create a downloadable service account key and recommends Workload Identity Federation instead.
  • When Google denies a call, Lovable names the missing role or the API to enable instead of retrying.
These rules cover the code Lovable writes for your app. When Lovable uses the connection directly from the project chat to make a change, it pauses on an approval card first. Your Agent approval for this connection setting applies to you and that connection and controls whether Lovable keeps asking. See Approving connector actions in the project chat.

How to connect Google Cloud API

Who can create Google Cloud API connections depends on your plan and workspace settings. App + chat connectors are available by default on Free, Pro, and Business plans. On Enterprise plans, they are effectively disabled at first: Who can create connections and clients defaults to No one until an admin changes it in Connectors → Admin settings → App + chat connectors. You can create multiple Google Cloud API connections using different service accounts, which is useful for separating organizations, projects, or environments (for example, development and production). When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in the project chat to link their project to it.

Prerequisites

Before connecting Google Cloud API, make sure you have:
  • A Google Cloud project to hold the workload identity pool and the service account. The service account can then be granted roles on this project, on other projects, or on folders and organizations.
  • Your Lovable workspace ID, shown under Configure connection in the connection form
  • Permission to create connections in your Lovable workspace (see Who can create connections and clients)
  • These roles on the Google Cloud project. roles/owner covers all of them:
API actions can create or change cloud resources and incur costs, and you are responsible for all of them. Google bills your Cloud Billing account directly for everything your app uses or creates, not Lovable. Set a Cloud Billing budget with an alert before you connect, verify what Lovable builds, and confirm that cleanup and teardown succeed.

Step 1: Configure Workload Identity Federation in Google Cloud

You need a workload identity pool and an OpenID Connect (OIDC) provider that trusts Google-issued ID tokens sent by Lovable’s connector gateway for your workspace, a service account for Lovable to impersonate, and the IAM roles that decide what your app can do. You can complete this setup by running a setup script directly in Google Cloud Shell Editor, or through manual steps in Google Cloud Console (see Manual setup in Google Cloud Console). For background on the underlying Google Cloud features, see Workload Identity Federation and Best practices for using Workload Identity Federation.
1

Open Google Cloud Console and search for Cloud Shell Editor

In the Google Cloud Console, search for Cloud Shell Editor and open it.
2

Authorize Cloud Shell to use your credentials

When prompted, authorize Cloud Shell to use your Google credentials.
3

Select the correct project

Make sure the correct Google Cloud project is selected in the Cloud Shell session.
4

Create a new file, copy in the script, and set the variables

Create a new file (for example, setup.sh), paste the script below into it, and fill in the values at the top. Your workspace ID is shown under Configure connection in the Lovable connection form.
5

Open the terminal and run the script

In the Cloud Shell terminal, run: bash setup.shThe script prints the WIF audience and Service account email you need in Step 2.
The script grants the roles in ROLES on the project you selected, Viewer (roles/viewer) by default. To grant roles on other projects, on a folder, or on an organization, or to grant Billing Account Viewer (roles/billing.viewer) on a billing account, use IAM & Admin → IAM in the console with that resource selected. Avoid Owner and Editor, and avoid roles that manage IAM, because a service account that can grant roles can grant itself more access. Also enable each API your app calls, for example the Cloud Asset, Cloud Monitoring, and Cloud Logging APIs, under APIs & Services → Enabled APIs & services in the project that owns the service account. When the app reads or manages another project, Google can also require the API to be enabled there. A request to an API that is not enabled fails with 403 and the reason SERVICE_DISABLED, whatever roles the service account has, and the error names the project to fix.
1

Enable the APIs

In the Google Cloud console, open APIs & Services → Enabled APIs & services and enable iam.googleapis.com, sts.googleapis.com, iamcredentials.googleapis.com, and cloudresourcemanager.googleapis.com.
2

Create a workload identity pool

Open IAM & Admin → Workload Identity Federation and create a pool named lovable (or use an existing one).
3

Add an OIDC provider

Add an OIDC provider named lovable-gateway to the pool with:
  • Issuer (URL): https://accounts.google.com
  • Audience: select Allowed audiences and enter https://connector-gateway.lovable.dev/workspaces/<WORKSPACE_ID>, replacing <WORKSPACE_ID> with your Lovable workspace ID
  • Attribute mapping: map google.subject to assertion.sub, then add a second mapping from attribute.email to assertion.email
  • Attribute conditions: enter the condition below, which restricts the pool to Lovable’s connector gateway
Do not leave Attribute conditions empty. It is the setting that limits this provider to Lovable’s connector gateway. A provider that trusts https://accounts.google.com with no attribute condition accepts identity tokens from any Google account or service account.
4

Create a service account for Google Cloud access

Open IAM & Admin → Service accounts and create a service account, for example lovable-gcp. This is the identity Lovable impersonates.
5

Grant the service account IAM roles

Select the project, folder, or organization your app works with, open IAM & Admin → IAM, click Grant access, enter the service account email as the principal, and choose the least-privileged predefined role that covers your app: Browser (roles/browser) to list projects and folders, Viewer (roles/viewer) for read-only inventory, monitoring, and logging, or a service-specific role only when the app must change resources. For billing reads, grant Billing Account Viewer (roles/billing.viewer) on the billing account. Avoid Owner and Editor, and avoid roles that manage IAM.Then enable each API your app calls under APIs & Services → Enabled APIs & services.
6

Allow the pool to impersonate the service account

On the service account, grant Workload Identity User (roles/iam.workloadIdentityUser) to this principal, replacing PROJECT_NUMBER with your Google Cloud project number:
This grants impersonation only to the identity carrying Lovable’s connector gateway email, which is why the provider maps attribute.email above. A pool-wide /* principal would work too, but it would also cover any other provider you later add to the same pool.
7

Copy the workload identity provider resource name

Open the provider and copy its resource name. It looks like //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/lovable/providers/lovable-gateway. This string is the WIF audience value Lovable expects.

Step 2: Connect Google Cloud API to Lovable

With the federation set up and the roles granted, create the connection in Lovable.
1

Open Google Cloud API in Connectors

Open Connectors and select Google Cloud API. For the other places to open the catalog from, see Where to find connectors. The connector page shows a Use responsibly notice about the cost and resource impact of API actions.
2

Add a connection

Click Add connection and select App + chat connector. The form is split into collapsible sections, Details, Configure connection, and Sharing.
3

Name the connection

Under Details, Lovable fills in a name for the connection, which you can change. The name is only used inside Lovable to identify the connection.
4

Configure the connection

Under Configure connection, the form shows a Workspace ID copy field with the value Step 1 uses. Below it, enter:
  1. WIF audience: paste the Workload Identity Provider resource name from Google Cloud (the full //iam.googleapis.com/projects/.../providers/... string). It contains your project number, not the project ID, and Lovable rejects any other format.
  2. Service account email: enter the service account to impersonate for Google Cloud access (for example lovable-gcp@your-project.iam.gserviceaccount.com).
  3. Scopes: the five credential- and secret-returning services described in How Google Cloud API connections work, all selected by default. Deselect any that apps built on this connection must not reach. You can change the selection later.
5

Choose who can use this connection

Under Sharing, the connection is private to you by default and shows a Private label. To share it, click Share with others. Then add workspace members by email, or click Invite entire workspace to make the connection available to everyone in your Lovable workspace.Everyone you share the connection with can build features that use the full access of the service account.See Who can use connections and clients for more information.
6

Connect

Click Connect. Lovable validates the federation setup through the gateway before saving the connection: it asks Google to exchange Lovable’s identity for a short-lived token for the service account. The check confirms that the provider trusts Lovable for your workspace and that the service account allows the impersonation, and nothing about roles or enabled APIs. If verification fails, see Troubleshooting.
When connected, anyone building in a project can ask Lovable in the project chat to link their project to Google Cloud API (based on configured connection-level access). Your Lovable apps can then call Google Cloud APIs through the connector gateway, within the roles granted to the service account.

Limitations

The Google Cloud API connector cannot:
  • Restrict a connection to read-only operations or to specific Google Cloud services from inside Lovable, apart from blocking the five credential- and secret-returning services under Scopes. IAM roles are the only other control over what apps built on a connection can do.
  • Authenticate with a service account key file, a user’s Google sign-in, or an API key. The connection needs Workload Identity Federation.
  • Call Google Workspace APIs such as Gmail, Drive, or Sheets. The token carries only the Google Cloud scope. Use the Google Workspace connectors for that data.
  • Call your own Cloud Run services, Cloud Functions, or App Engine apps at their own URLs. The connection reaches Google Cloud’s googleapis.com APIs only, so it can manage a Cloud Run service but not send requests to it.
  • Receive events from Google Cloud, such as Pub/Sub push deliveries or Eventarc events. The connection only makes outbound calls.
  • Support per-end-user Google login. Each connection represents a single service account shared across all projects linked to it.
If you delete the service account, remove its Workload Identity User binding, or delete the pool or provider, requests fail until you restore them. To point the connection at a different provider or service account, open the connection, change the values under Configure connection, and click Update. Lovable verifies the federation again before saving.

Troubleshooting

Use these checks when connecting fails or a Google Cloud request returns an unexpected status.
Lovable asks Google for a token when you click Connect. Click Show error in the alert. The error text names the step that failed:
  • sts exchange failed: Google did not accept Lovable’s identity at the provider named in WIF audience. Check that the audience is the provider’s full resource name with your project number, that the provider’s Allowed audiences contains https://connector-gateway.lovable.dev/workspaces/<WORKSPACE_ID> with the workspace ID shown in the form, and that its attribute condition is exactly assertion.email == 'connector-gateway@lovable-core-prod.iam.gserviceaccount.com'. A disabled or deleted pool or provider also fails here.
  • impersonation failed: Google accepted Lovable’s identity but did not issue a token for the service account. Check that Service account email is spelled correctly and the account exists, that the service account grants Workload Identity User to the principal from Step 1, and that iamcredentials.googleapis.com is enabled in the project that owns the service account. IAM changes can take a few minutes to take effect.
Connecting verifies the federation and grants nothing. A 403 has three causes with different fixes:
  • The response comes from Lovable with the error type sensitive_service_not_enabled: the service is deselected under Scopes on the connection. Ask a workspace admin or owner to open the connection, select the service under Configure connection, and click Update. This is a Lovable setting, not a Google denial, so granting roles does not help.
  • Google returns PERMISSION_DENIED: no role on the service account allows the operation at that scope. Grant the role in IAM & Admin → IAM on the project, folder, or organization. Google evaluates access on every request, so you do not need to reconnect. When this happens in the project chat, Lovable names the missing role.
  • Google returns SERVICE_DISABLED: the API is not enabled. Enable it under APIs & Services as described in Step 1, then retry.
The connector gateway applies its general per-project limit and returns 429 with a Retry-After header before the request reaches Google. Google Cloud APIs also enforce their own per-project quotas and return 429 with the reason RESOURCE_EXHAUSTED.Ask Lovable to cache reads, poll on demand rather than on a frequent fixed timer, and retry throttled calls with increasing delays.

Manage your Google Cloud API connection

Connections are managed from Connectors: select Google Cloud API, then open the connection.
  • Unlink projects to remove Google Cloud API access from specific projects while keeping the connection available for others. See Unlink projects from a connection for the steps.
  • Delete the connection to remove it from the workspace entirely. Deleting is permanent. It removes the credentials from all linked projects, and app features that use Google Cloud API stop working until a new connection is added. See Delete a connection for the steps and who can delete.