canonical: https://jentic.com/apis/googleapis.com/bigtableadmin

# Google Cloud Bigtable Admin API

The Cloud Bigtable Admin API manages Bigtable instances, clusters, app profiles, tables, authorized views, column families, and backups. It is the control plane for Bigtable - used to provision and resize clusters, create tables and column families, define app profiles for routing, and back up and restore data - while the data plane API handles reads and writes. Operators use it to script cluster scaling, capacity changes, and DR. It also exposes IAM policy management on instances, tables, and authorized views.

## For AI agents

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

## Scope

Does not read or write Bigtable rows, run analytics queries, or manage GCE infrastructure - use for Bigtable instance, cluster, table, and backup administration only.

## Capabilities

- 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
- Create app profiles to route traffic between clusters with single- or multi-cluster routing
- Back up tables and restore them into the same or a different instance
- Manage IAM policies on instances, tables, and authorized views
- Check table consistency with consistency tokens for replicated workloads

## Use cases

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

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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 your Jentic One instance.

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

## Key endpoints

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

## Key resources

- **Instances** — Create, get, list, and delete Bigtable instances.
- **Clusters** — Manage cluster nodes, storage type, and region per instance.
- **Tables** — Create tables, modify column families, drop row ranges, and check consistency.
- **App Profiles** — Define routing policies between clusters in an instance.
- **Authorized Views** — Scope readers to a subset of rows and columns of a table.
- **Backups** — Create and manage table backups and trigger restores.

## Why Jentic

- **Setup:** Wiring the Cloud Bigtable Admin API by hand means setting up its Google OAuth 2.0 flow, exchanging refresh tokens for scoped access tokens, and driving instance, cluster, table, and backup admin calls through the long-running operations model yourself. Through Jentic you install once, import the Cloud Bigtable Admin API from the API Directory, store the OAuth credentials once, and your agent calls it.
- **Permission scoping:** The API puts the project, instance, and cluster in the URL path (/v2/{+parent}/clusters, /v2/{+name}:dropRowRange), so a rule can pin your agent to one instance: it can create clusters and tables there and nowhere else. You choose the operations it may call, so destructive ones like dropping a row range are not included unless you add them.
- **Credential handling:** Your Google OAuth client credentials and refresh token are stored once, encrypted, by your own Jentic One instance and injected at execution time. The agent receives only short-lived scoped access tokens and never sees the refresh token in its prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Bigtable cluster' or 'back up a Bigtable table', and Jentic returns the right Admin API operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Cloud Datastore API** — Document-style NoSQL database for transactional app data.
- **Cloud Spanner API** — Globally consistent relational database service.
- **BigQuery API** — Analytical warehouse that often consumes Bigtable export or live federation.

## FAQ

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

### Can I limit what my agent is allowed to do with the Cloud Bigtable Admin API?

Yes. Because Jentic One is self-hosted, your own rules decide which operations and credentials the agent may use. Since this API puts the project, instance, and cluster in the URL path (for example /v2/{parent}/clusters and /v2/{name}:dropRowRange), you can pin the agent to a single instance so it creates clusters and tables there and nowhere else. You also choose the exact operations it may call, so a destructive one like dropping a row range stays out of reach unless you explicitly add it.