Google Cloud Bigtable Admin API

Name: Cloud Bigtable Admin API
Brand: Cloud Bigtable Admin API
Availability: InStock

✓ Official Vendor SpecStorageDatabaseoauth229 EndpointsREST

For Agents

Provision and manage Cloud Bigtable instances, clusters, tables, app profiles, and backups. Agents can create tables, modify column families, and manage authorized views.

Install Jentic One Beta

Connect the Cloud Bigtable Admin API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cloud Bigtable Admin API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Cloud Bigtable Admin API.

Create and resize Bigtable instances and their clusters across regions

Manage tables including modifying column families and dropping row ranges

Define authorized views that scope readers to a subset of rows and columns

GET STARTED

Start building with Cloud Bigtable Admin API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Cloud Bigtable Admin API for, with concrete tasks.

★ Provision a Replicated Cluster

Provision a Bigtable instance with two clusters in different regions for HA and multi-region reads. Instances are created at /v2/{parent}/instances and clusters at /v2/{parent}/clusters with the desired serveNodes and storageType. Combined with multi-cluster app profiles, this gives applications transparent failover.

Create instance prod with two clusters: prod-c1 in us-central1 with 5 SSD nodes and prod-c2 in us-east1 with 5 SSD nodes.

Schema and Table Lifecycle

Create tables, define column families, and evolve schemas with modifyColumnFamilies. Tables are managed at /v2/{parent}/tables and column families via /v2/{name}:modifyColumnFamilies. dropRowRange supports targeted cleanup of obsolete prefixes without rewriting the table.

Create table events in instance prod with a column family cf_metrics that has a maxAge of 30 days.

Backup and Restore

Schedule and trigger table backups with /v2/{parent}/backups and restore them into the same or a different instance. Backups are anchored to a cluster and can be retained for up to 90 days. Used for DR runbooks and accidental-delete recovery.

Create a backup of table events in cluster prod-c1 with expireTime 30 days from now, then restore it into instance staging as table events_restored.

Authorized View Access

Create authorized views over a table to expose a row-key prefix and a subset of columns to specific principals, then bind IAM roles to the view. Authorized views are managed at /v2/{parent}/authorizedViews. This avoids granting full table access for narrow read use cases.

Create authorizedView region_us on table events that exposes only rows with prefix US# and columns from family cf_public, then grant roles/bigtable.user to data-readers@example.com on the view.

Agent-Driven Cluster Ops

Let an AI agent take a request like 'add 5 nodes to prod-c1 for the holiday window' and update the cluster through Jentic. The agent loads PATCH /v2/{name} with the new serveNodes value, watches the operation, and reports back when the cluster has scaled. OAuth credentials never leave the Jentic vault.

Scale cluster projects/myproj/instances/prod/clusters/prod-c1 to 10 serveNodes and wait for the long-running operation to complete.

Key Endpoints

29 endpoints — the cloud bigtable admin api manages bigtable instances, clusters, app profiles, tables, authorized views, column families, and backups.

METHOD

PATH

DESCRIPTION

POST

/v2/{+parent}/instances

Create a Bigtable instance

POST

/v2/{+parent}/clusters

Create a cluster in an instance

POST

/v2/{+parent}/tables

Create a table in an instance

POST

/v2/{+name}:modifyColumnFamilies

Modify column families on a table

POST

/v2/{+name}:dropRowRange

Drop a row range from a table

POST

/v2/{+parent}/backups

Create a backup of a table

POST

/v2/{+parent}/authorizedViews

Create an authorized view on a table

POST

/v2/{+parent}/appProfiles

Create an app profile for cluster routing

POST

/v2/{+parent}/instances

Create a Bigtable instance

POST

/v2/{+parent}/clusters

Create a cluster in an instance

POST

/v2/{+parent}/tables

Create a table in an instance

POST

/v2/{+name}:modifyColumnFamilies

Modify column families on a table

POST

/v2/{+name}:dropRowRange

Drop a row range from a table

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Google OAuth 2.0 client credentials and refresh tokens are stored encrypted in the Jentic vault (MAXsystem). The agent only receives short-lived, scope-limited access tokens at execution time.

Intent-based discovery

Agents search Jentic with intents like 'create a Bigtable cluster' or 'back up a Bigtable table' and Jentic returns the right Admin API operation with its full input schema.

Time to first call

Direct integration: 2-3 days for OAuth, the operation polling pattern, and the instance/cluster/table model. Through Jentic: under an hour — search, load schema, execute.

FAQs

Specific to using Cloud Bigtable Admin API through Jentic.

What authentication does the Cloud Bigtable Admin API use?

The Bigtable Admin API uses Google OAuth 2.0 with the cloud-platform and bigtable.admin scopes. Through Jentic, the OAuth refresh token sits encrypted in the vault and the agent receives short-lived scoped access tokens at call time.

Can I create and resize a Bigtable cluster with this API?

Yes. POST /v2/{parent}/clusters creates a new cluster, and PATCH /v2/{name} with serveNodes updates the node count of an existing cluster. Both return long-running operations under /v2/{name}/operations that you poll until done.

What are the rate limits for the Cloud Bigtable Admin API?

Quotas are project-level: typically a small write QPS on the same instance/table and bursty read QPS for list and get operations. Heavy admin churn (rapid create/delete loops) is rate-limited per instance. Check the Google Cloud quotas console for current values.

How do I back up a Bigtable table through Jentic?

Search Jentic for 'create a Bigtable backup', load the schema for POST /v2/{parent}/backups, and execute with sourceTable and expireTime. Jentic forwards the OAuth token; the response is a long-running operation you can poll via /v2/{name}/operations.

Does this API read or write rows?

No. The Admin API only manages instances, clusters, tables, and views. Use the Bigtable data API (bigtable.googleapis.com) to read and write rows in a table.

Can I expose only some rows of a table to a specific service account?

Yes. Create an authorizedView via POST /v2/{parent}/authorizedViews that defines a row-key prefix and column subset, then setIamPolicy on the view to grant roles/bigtable.user to the target principal. The principal can read only what the view exposes.

Google Cloud Bigtable Admin API

Connect the Cloud Bigtable Admin API to your agent

Capabilities

Start building with Cloud Bigtable Admin API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs