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 errorProblemFix
API name + “enable it by visiting” linkAPI not enabledgcloud services enable API_NAME —project=PROJECT_ID
Specific permission name (e.g. storage.objects.get)Missing IAM roleGrant the correct IAM role
API enable link, but you already enabled itWrong project or propagation delayVerify gcloud config get project and wait 60 seconds

Quick fix

One-liner 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_ID

Replace 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 project

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

Think of it like a building with locked rooms

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.com appears in the URL. This is the identifier you pass to gcloud services enable.
  • The project reference: my-project tells 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 meansThe service is switched off for this projectThe API is on, but your identity lacks a required permission
Typical fixgcloud services enable API_NAMEGrant the correct IAM role to the identity
Clue in the messageAPI name + console URL to enable itSpecific 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

  1. Open the Cloud Console.
  2. Select the correct project from the project picker at the top of the page.
  3. Go to APIs & Services > Library.
  4. Search for the API name (for example, “Cloud SQL Admin API”).
  5. Click Enable.
  6. 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.

Watch the project picker

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

Using —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
}
Propagation delay

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 often cloudbuild.googleapis.com and artifactregistry.googleapis.com for building and storing images.

  • Pushing images to Artifact Registry: needs artifactregistry.googleapis.com.

  • Connecting to Cloud SQL: needs sqladmin.googleapis.com, plus servicenetworking.googleapis.com if 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

  1. 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_ID explicitly, and double-check which project your tool or SDK is targeting.

  2. Having the wrong project in your local gcloud config. Run gcloud config get project to see what gcloud thinks the active project is. If it does not match the project in the error message, that is the problem.

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

  4. Forgetting billing or org prerequisites. Some APIs require an active billing account on the project before they can be enabled. If gcloud services enable itself fails, check billing first.

  5. Enabling one API but missing a dependent API. Some services require multiple APIs. Cloud Run deployments typically need run.googleapis.com, cloudbuild.googleapis.com, and artifactregistry.googleapis.com together.

  6. Assuming API enablement is instant. There is a 30 to 60 second propagation delay. Retrying immediately after enabling usually fails. Wait a minute.

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

Real-world scenario

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"
Team projects

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.

Last verified: 27 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.