- 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
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: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.
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/ownercovers all of them:
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.Open Google Cloud Console and search for Cloud Shell Editor
Authorize Cloud Shell to use your credentials
Select the correct project
Create a new file, copy in the script, and set the variables
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.Open the terminal and run the script
bash setup.shThe script prints the WIF audience and Service account email you need in Step 2.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.
Manual setup in Google Cloud Console
Manual setup in Google Cloud Console
Enable the APIs
iam.googleapis.com, sts.googleapis.com, iamcredentials.googleapis.com, and cloudresourcemanager.googleapis.com.Create a workload identity pool
lovable (or use an existing one).Add an OIDC provider
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.subjecttoassertion.sub, then add a second mapping fromattribute.emailtoassertion.email - Attribute conditions: enter the condition below, which restricts the pool to Lovable’s connector gateway
Create a service account for Google Cloud access
lovable-gcp. This is the identity Lovable impersonates.Grant the service account IAM roles
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.Allow the pool to impersonate the service account
roles/iam.workloadIdentityUser) to this principal, replacing PROJECT_NUMBER with your Google Cloud project number: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.Copy the workload identity provider resource name
//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.Open Google Cloud API in Connectors
Add a connection
Name the connection
Configure the connection
- 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. - Service account email: enter the service account to impersonate for Google Cloud access (for example
lovable-gcp@your-project.iam.gserviceaccount.com). - 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.
Choose who can use this connection
Connect
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.comAPIs 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.
Troubleshooting
Use these checks when connecting fails or a Google Cloud request returns an unexpected status.Connect failed: Google Cloud API did not validate your credentials
Connect failed: Google Cloud API did not validate your credentials
- 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 exactlyassertion.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.comis enabled in the project that owns the service account. IAM changes can take a few minutes to take effect.
A request returned 403 after connecting
A request returned 403 after connecting
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.
A request returned 429 Too Many Requests
A request returned 429 Too Many Requests
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.