GCP API Not Enabled Error: Fix SERVICE_DISABLED (403)
If you just hit a 403 error that says an API “has not been used in project” or is “disabled,”
the fix is straightforward: the API needs to be turned on for your
GCP project. This is not a permissions
problem with your account. It means the service itself is switched off at the project level.
If the error message mentions a specific permission like storage.objects.get instead
of an API name, that is an IAM
permission issue, not an API enablement issue.
Diagnose the problem in 30 seconds
| What you see in the error | Problem | Fix |
|---|---|---|
| API name + “enable it by visiting” link | API not enabled | gcloud services enable API_NAME —project=PROJECT_ID |
Specific permission name (e.g. storage.objects.get) | Missing IAM role | Grant the correct IAM role |
| API enable link, but you already enabled it | Wrong project or propagation delay | Verify gcloud config get project and wait 60 seconds |
Quick fix
Copy the API name from the error message (it looks like sqladmin.googleapis.com)
and run:
gcloud services enable sqladmin.googleapis.com --project=PROJECT_IDReplace PROJECT_ID with the project where the error occurred. Wait about 60
seconds for propagation, then retry your operation. That is usually all you need.
If you are not sure which project your gcloud CLI is targeting, check:
gcloud config get projectSimple explanation
Every Google Cloud project starts with most APIs turned off. Before you can use a service like Cloud SQL, BigQuery, or Cloud Run, you need to enable its API for that specific project.
Your GCP project is the building, and each API is a room inside it. Having a key card
(your IAM permissions) is not enough if the room itself is locked shut (API disabled).
You need the building manager to unlock the room first (gcloud services enable),
and then your key card decides what you can do inside.
This is a per-project setting, not a per-user setting. The same user account or service account can work perfectly in Project A (where the API is enabled) and fail in Project B (where it is not). That catches people off guard when they start working across multiple projects.
For the full picture of how the API activation model works and which APIs are enabled by default, see Google Cloud APIs Explained.
What the error looks like
The error message is distinctive. It names the specific API and includes a direct link to enable it:
Error 403: Cloud SQL Admin API has not been used in project my-project
before or it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=my-project
then retry. If you enabled this API recently, wait a few minutes for the action
to propagate to our systems and retry.The key clues in this message are:
- The API name:
sqladmin.googleapis.comappears in the URL. This is the identifier you pass togcloud services enable. - The project reference:
my-projecttells you which project is affected. Confirm this is the project you intended. - The activation link: clicking it opens the Cloud Console directly to the enable page.
- The propagation note: Google includes this because enablement is not instant.
SERVICE_DISABLED vs PERMISSION_DENIED
Both errors return HTTP 403, which makes them easy to confuse. Here is how to tell them apart:
| SERVICE_DISABLED (API not enabled) | PERMISSION_DENIED (IAM) | |
|---|---|---|
| What you see | ”API has not been used in project” + enable link | ”Permission X denied on resource Y” |
| What it means | The service is switched off for this project | The API is on, but your identity lacks a required permission |
| Typical fix | gcloud services enable API_NAME | Grant the correct IAM role to the identity |
| Clue in the message | API name + console URL to enable it | Specific permission name like compute.instances.create |
If you are troubleshooting an IAM error instead, see GCP Permission Denied Errors or IAM AccessDenied Fixes for a walkthrough.
How to fix it
Enable the API in the Console
- Open the Cloud Console.
- Select the correct project from the project picker at the top of the page.
- Go to APIs & Services > Library.
- Search for the API name (for example, “Cloud SQL Admin API”).
- Click Enable.
- Wait about 60 seconds before retrying your operation.
Alternatively, click the enable link directly from the error message. It takes you straight to the right page.
Before clicking Enable, check the project picker at the top of the Console. If it shows a different project than the one in the error message, switch projects first. Enabling the API in the wrong project is the number one reason people say “I already enabled it and it still does not work.”
Enable the API with gcloud
# Enable a single API
gcloud services enable sqladmin.googleapis.com
# Enable multiple APIs at once
gcloud services enable \
sqladmin.googleapis.com \
run.googleapis.com \
cloudbuild.googleapis.com \
artifactregistry.googleapis.com
# Always specify the project explicitly when managing multiple projects
gcloud services enable sqladmin.googleapis.com \
--project=my-project-id
# Verify the API is now enabled
gcloud services list --enabled --filter="name:sqladmin.googleapis.com"
# List all enabled APIs for the current project
gcloud services list --enabledUsing —project=PROJECT_ID explicitly is safer than relying on your
gcloud config default, especially if you
switch between projects. For the full guide to enabling APIs, see
How to Enable APIs in GCP.
Enable required APIs with Terraform
Declaring APIs in Terraform makes your project setup reproducible and prevents the “API not enabled” surprise when someone deploys to a new project:
# apis.tf
locals {
required_apis = [
"compute.googleapis.com",
"container.googleapis.com",
"run.googleapis.com",
"cloudbuild.googleapis.com",
"artifactregistry.googleapis.com",
"sqladmin.googleapis.com",
"secretmanager.googleapis.com",
"monitoring.googleapis.com",
"logging.googleapis.com",
]
}
resource "google_project_service" "apis" {
for_each = toset(local.required_apis)
project = var.project_id
service = each.value
# Prevent Terraform from disabling APIs on terraform destroy
disable_on_destroy = false
}API enablement takes 30 to 60 seconds to propagate. If Terraform enables an API and
immediately creates a resource that depends on it in the same apply, the resource
creation may fail. Add an explicit depends_on reference to the
google_project_service resource for anything that uses the newly enabled API.
For more on structuring Terraform for GCP, see
Terraform Permission Errors.
Common situations where this happens
You will most often hit this error when working in a project where the service has never been used before. Here are the scenarios that catch people most:
Deploying to Cloud Run: needs
run.googleapis.com, and oftencloudbuild.googleapis.comandartifactregistry.googleapis.comfor building and storing images.Pushing images to Artifact Registry: needs
artifactregistry.googleapis.com.Connecting to Cloud SQL: needs
sqladmin.googleapis.com, plusservicenetworking.googleapis.comif using private IP.Running BigQuery queries: needs
bigquery.googleapis.com.Creating GKE clusters: needs
container.googleapis.com.Publishing to Pub/Sub: needs
pubsub.googleapis.com.Configuring private IP or VPC peering: needs
servicenetworking.googleapis.com.
When to use this guide
This page is for you if:
- You got a 403 error during your first deployment to a new project
- Terraform fails while creating resources with “API not enabled” in the error
- A service account works in one project but gets 403 in another
- A Google client library throws an error saying the API is disabled
- You see a console URL in the error message that says “enable it by visiting”
If the error references a specific permission name (not an API name), head to the permission denied guide instead. If the error is about authentication rather than authorization, see troubleshooting authentication errors.
Common mistakes
Enabling the API in the wrong project. This is the number one cause of “I already enabled it but I still get the error.” Always use
—project=PROJECT_IDexplicitly, and double-check which project your tool or SDK is targeting.Having the wrong project in your local gcloud config. Run
gcloud config get projectto see what gcloud thinks the active project is. If it does not match the project in the error message, that is the problem.Confusing API enablement with IAM permissions. Enabling an API makes the service available to the project. Granting an IAM role gives a specific identity permission to use it. You often need both.
Forgetting billing or org prerequisites. Some APIs require an active billing account on the project before they can be enabled. If
gcloud services enableitself fails, check billing first.Enabling one API but missing a dependent API. Some services require multiple APIs. Cloud Run deployments typically need
run.googleapis.com,cloudbuild.googleapis.com, andartifactregistry.googleapis.comtogether.Assuming API enablement is instant. There is a 30 to 60 second propagation delay. Retrying immediately after enabling usually fails. Wait a minute.
Disabling APIs that live workloads still use. Disabling an API does not delete resources, but makes them inaccessible. In production, always confirm nothing depends on an API before disabling it.
A developer enables sqladmin.googleapis.com in their dev project.
The deploy pipeline targets the staging project. The API is not enabled there.
The deploy fails. The developer says “but I already enabled it!” and spends 30 minutes
before realizing they enabled it in the wrong project. Always check which project you
are targeting.
Prevent this in new projects
The fastest way to avoid API-not-enabled errors is to enable every API you need as part of project setup, before you deploy anything. Chasing APIs one at a time as errors pop up turns a five-minute deployment into a frustrating cycle of enable-wait-retry.
A simple shell script handles this for new projects:
#!/bin/bash
PROJECT_ID="my-new-project"
gcloud config set project $PROJECT_ID
gcloud services enable \
compute.googleapis.com \
container.googleapis.com \
run.googleapis.com \
cloudfunctions.googleapis.com \
cloudbuild.googleapis.com \
artifactregistry.googleapis.com \
sqladmin.googleapis.com \
secretmanager.googleapis.com \
monitoring.googleapis.com \
logging.googleapis.com \
iam.googleapis.com \
iamcredentials.googleapis.com \
serviceusage.googleapis.com \
cloudresourcemanager.googleapis.com
echo "APIs enabled for $PROJECT_ID"For infrastructure-as-code environments, declare APIs in Terraform (as shown above) so every new project gets the same set of APIs automatically. This is especially important for teams where multiple people create projects. You cannot rely on everyone remembering the right APIs to enable manually.
Frequently asked questions
Why does Google Cloud require APIs to be enabled per project?
GCP uses an API-activation model so each project only runs the services it actually needs. This controls billing, enforces quotas, and gives you a clear inventory of active services. New projects start with a small default set of APIs enabled, and you explicitly enable additional ones as needed.
Does enabling an API cost money?
Enabling an API is free. You are charged only when you use the service behind that API. Some APIs create a default service agent when enabled, but those agents have no cost until they perform billable work.
Why do I still get the error after enabling the API?
API enablement can take 30 to 60 seconds to propagate. If you retry immediately after enabling, the call may still fail. Wait a minute and try again. Also confirm you enabled the API in the correct project. Enabling it in the wrong project is one of the most common causes of this confusion.
What is the difference between SERVICE_DISABLED and IAM permission errors?
Both return HTTP 403, but the error messages differ. SERVICE_DISABLED includes the API name and a link to enable it. Fix it with gcloud services enable. PERMISSION_DENIED names a specific IAM permission like storage.objects.get and the calling identity. Fix it by granting the correct IAM role.
What happens if I disable an API that existing resources use?
Disabling an API makes its resources inaccessible through that API, but does not delete them. For example, disabling the Cloud Storage API does not delete your buckets, but you cannot read or write objects until you re-enable it. Some APIs block disabling when active resources exist. Never disable APIs in production without confirming no workloads depend on them.