How to Enable APIs in GCP: Console, gcloud, and Terraform

Simple explanation

Every Google Cloud service is exposed as an API: Compute Engine, Cloud Run, BigQuery, Cloud Storage, all of them. An API is a URL that accepts requests and returns responses. When you create a VM, your request goes to the Compute Engine API. When you upload a file, it goes to the Cloud Storage API.

By default, those APIs are switched off in a new project. Enabling an API is literally flipping a switch: you tell Google Cloud “this project is allowed to call this service.” That is all it does. It does not create any resources. It does not immediately cost anything. It just unlocks access.

Once enabled, the API stays on until you explicitly disable it. You do not re-enable it every session. You enable it once per project, and then it is available whenever that project needs it.

How API enablement works in GCP

When you create a new GCP project, it comes with only a small set of core platform APIs already active. Almost every specific service starts disabled: Compute Engine, Cloud Run, BigQuery, Secret Manager, and so on.

When you enable an API, GCP registers that the project is now permitted to call that service. Requests that were previously blocked at the service layer are allowed through. But two things remain true after enablement, and confusing them causes most post-enablement errors:

Some services automatically enable their dependencies when you enable them. Enabling the GKE API (container.googleapis.com) will also activate Compute Engine if it is not already on. This is convenient interactively, but in automation and scripts always declare every API you need explicitly. Relying on implicit dependencies makes setup fragile and harder to audit.

Every enable and disable action is recorded in Cloud Audit Logs under Admin Activity. You can trace exactly when an API was enabled and by which account, which matters for security and compliance reviews.

When you need to enable an API

You will run into API enablement in several common situations:

• Using a service for the first time in a project. You try to create a Cloud Run service and get a 403 error. The fix is enabling run.googleapis.com.
• Bootstrapping a new project. Before writing any setup, list all the services the project will use and enable them up front.
• Seeing an “API not enabled” error. The error names the missing API. Enable it and retry.
• Preparing Terraform-managed infrastructure. Infrastructure-as-code should declare API enablement alongside the resources that depend on those APIs.
• Onboarding a new environment. A new staging or production project needs the same APIs as the existing one. A setup script makes this repeatable.
• Enabling supporting services. Workflows that use Cloud Build typically also need Artifact Registry. CI/CD pipelines often require several APIs enabled together.

Enabling via the Console

Best for: beginners, one-off changes, and exploring what is available.

1. Open the Cloud Console and confirm the correct project is selected in the project picker at the top of the page

2. Use the search bar at the top and type the service name (for example, “Cloud Run”)
3. Click the service in the search results to reach its API overview page
4. Click Enable
5. Wait a few seconds for the activation to complete, then proceed

You can also browse the full catalogue by going to APIs & Services > Library in the left navigation. This shows all available Google Cloud APIs grouped by category, which is useful when you are not sure of the exact service name.

Enabling via gcloud

Best for: quick manual setup, scripting, and working in the terminal.

If you have the gcloud CLI installed, enabling an API is a single command. If you have not set it up yet, see Installing the gcloud CLI.

# Enable a single API in the current project
gcloud services enable run.googleapis.com

# Enable a specific project explicitly (safer in scripts)
gcloud services enable run.googleapis.com --project=my-project-id

# Enable multiple APIs at once (they activate in parallel)
gcloud services enable \
  compute.googleapis.com \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  --project=my-project-id

# Verify whether a specific API is already enabled
gcloud services list --enabled \
  --filter="name:run.googleapis.com" \
  --project=my-project-id

# List every enabled API in a project
gcloud services list --enabled --project=my-project-id

Enabling via Terraform

Best for: repeatable infrastructure, team environments, and version-controlled project setup.

When managing infrastructure as code, declare API enablement alongside the resources that depend on those APIs. Use the google_project_service resource. The critical setting is disable_on_destroy = false: without it, running terraform destroy disables the API and potentially breaks anything else in the project that depends on it.

resource "google_project_service" "run" {
  project            = var.project_id
  service            = "run.googleapis.com"
  disable_on_destroy = false
}

resource "google_project_service" "artifact_registry" {
  project            = var.project_id
  service            = "artifactregistry.googleapis.com"
  disable_on_destroy = false
}

resource "google_project_service" "cloud_build" {
  project            = var.project_id
  service            = "cloudbuild.googleapis.com"
  disable_on_destroy = false
}

For larger projects, a for_each loop keeps the code concise:

locals {
  required_apis = [
    "run.googleapis.com",
    "artifactregistry.googleapis.com",
    "cloudbuild.googleapis.com",
    "secretmanager.googleapis.com",
    "sqladmin.googleapis.com",
  ]
}

resource "google_project_service" "apis" {
  for_each           = toset(local.required_apis)
  project            = var.project_id
  service            = each.value
  disable_on_destroy = false
}

Console vs gcloud vs Terraform

All three methods produce the same result. The right choice depends on your context.

For learning and exploration, use the Console. For setting up a single project quickly, use gcloud. For any environment that will be created more than once, use Terraform or a setup script.

API names you will enable most often

Every API is identified by a service name following the pattern service.googleapis.com. These are the ones you will reach for most in day-to-day GCP work:

compute.googleapis.com               # Compute Engine (VMs)
storage.googleapis.com               # Cloud Storage (buckets)
bigquery.googleapis.com              # BigQuery (data warehouse)
run.googleapis.com                   # Cloud Run (containerised services)
cloudfunctions.googleapis.com        # Cloud Functions
container.googleapis.com             # Google Kubernetes Engine
sqladmin.googleapis.com              # Cloud SQL (managed databases)
pubsub.googleapis.com                # Pub/Sub (messaging)
secretmanager.googleapis.com         # Secret Manager (credentials storage)
artifactregistry.googleapis.com      # Artifact Registry (container images)
cloudbuild.googleapis.com            # Cloud Build (CI/CD)
cloudresourcemanager.googleapis.com  # Resource and project management
iam.googleapis.com                   # Identity and Access Management
logging.googleapis.com               # Cloud Logging
monitoring.googleapis.com            # Cloud Monitoring

When you start a new project, enable everything you know you will need in one command. It takes seconds and saves interruptions later.

Enabling a full app stack at once

Rather than enabling APIs one at a time as you hit errors, enable everything a project needs at the start. Here is a typical web app with Cloud Run, Cloud SQL, and a CI/CD pipeline:

#!/bin/bash
# Bootstrap a web app project: enable all required APIs up front

PROJECT_ID="my-app-prod"

gcloud services enable \
  run.googleapis.com \
  sqladmin.googleapis.com \
  secretmanager.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  logging.googleapis.com \
  monitoring.googleapis.com \
  --project="${PROJECT_ID}"

echo "All APIs enabled for ${PROJECT_ID}"

What to do when you see “API not enabled”

The error message usually looks like this:

ERROR: (gcloud.run.deploy) FAILED_PRECONDITION: Cloud Run API has not been used in
project 123456789 before or it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/run.googleapis.com/overview?project=123456789
then retry. If you enabled this API recently, wait a few minutes for the action to
propagate to our systems and retry.

Work through this checklist:

1. Read the error carefully. The message names the exact API you need to enable, usually in the format run.googleapis.com. Copy it from the error before doing anything else.

2. Confirm you are in the right project. Run gcloud config get-value project to see the active project. Enabling an API in the wrong project is the most common source of “I already enabled that” confusion.

3. Enable the API. Run gcloud services enable SERVICE_NAME.googleapis.com —project=PROJECT_ID using the exact service name from the error message.

4. Wait for propagation. There is a short delay (usually under 60 seconds) after enablement before the change is fully active across all GCP systems. If the command still fails immediately after enabling, wait 30-60 seconds and try again. This is normal behaviour, not a configuration problem.

5. If the error persists, check other causes. After propagation time has passed, the problem may no longer be the API itself:

   • IAM permissions: does the calling identity have the right IAM role for the operation? Enabling the API does not grant access.

   • Billing: is a billing account linked to the project? Many services will not run without it even if the API is enabled.

   • Organisation policies: your organisation may have an organisation policy that restricts which APIs can be enabled or what resources can be created.

Auditing API enablement

Every API enable and disable action is recorded in Cloud Audit Logs under Admin Activity. You can trace exactly when an API was enabled and by which account:

# Show the last 10 API enable/disable events in a project
gcloud logging read \
  'protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"' \
  --limit=10 \
  --format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.request.name)" \
  --project=my-project-id

The APIs & Services > Dashboard in the Console shows real-time usage metrics per API: requests per second, error rates, and latency. If an application suddenly starts failing, this dashboard gives you a fast signal before you dig into logs.