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

# Google Firebase Realtime Database Management API

The Firebase Realtime Database Management API enables programmatic provisioning and lifecycle management of Realtime Database instances inside a Firebase project. It exposes operations to create, list, get, disable, re-enable, delete, and undelete instances across regional locations. Use it to automate the creation of additional database instances for multi-region apps or environment-per-branch workflows without clicking through the Firebase console.

## For AI agents

Provision, disable, re-enable, and delete Firebase Realtime Database instances so an agent can automate database environment setup across regions.

## Scope

Does not read or write data inside the database, manage security rules, or expose realtime listeners - use for Realtime Database instance lifecycle management only.

## Capabilities

- Provision a Firebase Realtime Database instance in a chosen Google Cloud region
- Disable a Realtime Database instance to stop reads and writes without deleting data
- Re-enable a previously disabled Realtime Database instance
- Soft-delete a Realtime Database instance and undelete it within the recovery window
- List all Realtime Database instances within a Firebase project location

## Use cases

### Per-Environment Realtime Database Provisioning

Stand up a fresh Realtime Database instance for each preview branch or staging environment using POST /v1beta/{+parent}/instances. Once provisioned, the instance has its own database URL that the application can target via Firebase SDKs, isolating test data from production. Provisioning is asynchronous and typically completes within seconds.

Example prompt: Call POST /v1beta/{+parent}/instances with parent=projects/PROJECT/locations/us-central1 and instanceId=staging-rtdb to create a new Realtime Database instance for the staging environment.

### Cost Control via Disable and Re-enable

Temporarily disable a Realtime Database instance during long inactive periods to halt billable reads and writes without losing data. POST /v1beta/{+name}:disable suspends access while keeping the data intact, and POST /v1beta/{+name}:reenable restores access on demand. This is suited to seasonal apps and CI environments that idle outside business hours.

Example prompt: Call POST /v1beta/{+name}:disable on instance projects/PROJECT/locations/us-central1/instances/sandbox-rtdb to pause it overnight and POST /v1beta/{+name}:reenable to bring it back the next morning.

### Soft-Delete Recovery Workflow

Recover from accidental deletion by undeleting a Realtime Database instance within the recovery window via POST /v1beta/{+name}:undelete. The instance must first be deleted using DELETE /v1beta/{+name}, after which it remains in a recoverable state. This avoids the need to restore from external backups for short-window mistakes.

Example prompt: Call POST /v1beta/{+name}:undelete on a recently deleted instance and confirm via GET /v1beta/{+name} that its state reads ACTIVE.

### Agent-Managed Database Environments via Jentic

An AI agent using Jentic can manage the full lifecycle of Realtime Database instances on behalf of a developer team - provisioning new ones for branches, disabling idle ones, and undeleting accidentally removed ones. Jentic exposes all 7 management endpoints, the agent strings them together, and OAuth 2.0 credentials stay inside your Jentic One instance.

Example prompt: Through Jentic, search for provision a firebase realtime database instance, load the instances.create operation, and execute it with parent=projects/my-project/locations/us-central1 and instanceId=preview-42-rtdb.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1beta/{+parent}/instances | Create a new Realtime Database instance |
| GET | /v1beta/{+parent}/instances | List Realtime Database instances under a location |
| POST | /v1beta/{+name}:disable | Disable a Realtime Database instance |
| POST | /v1beta/{+name}:reenable | Re-enable a previously disabled instance |
| POST | /v1beta/{+name}:undelete | Undelete a previously deleted instance within the recovery window |
| DELETE | /v1beta/{+name} | Delete a Realtime Database instance |

## Key resources

- **Database Instances** — Create, list, get, delete, disable, re-enable, and undelete Firebase Realtime Database instances under a project location

## Why Jentic

- **Setup:** Wiring the Firebase Realtime Database Management API by hand means standing up Google OAuth 2.0 with a service account and coding the instance lifecycle calls, including the async create and undelete operations. Through Jentic you install once, import the Firebase Realtime Database Management API from the API Directory, store the service-account credential once, and your agent calls it.
- **Permission scoping:** This API puts the database instance in the URL path (/v1beta/{parent}/instances, /v1beta/{name}:disable), so a rule can pin your agent to one instance and nothing else. You choose the operations it may call, so destructive ones like disable or delete are not included unless you add them.
- **Credential handling:** Your Google service-account credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'provision a Firebase Realtime Database instance' or 'reenable a database', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Firebase Management API** — Sets up the Firebase project that hosts Realtime Database instances.
- **Firebase Rules API** — Manages security rules controlling reads and writes inside Realtime Database instances.
- **Firebase Storage API** — Manages object-storage buckets rather than realtime database instances.

## FAQ

### What authentication does the Firebase Realtime Database Management API use?

The API uses Google OAuth 2.0 with the firebase or cloud-platform scope. Through Jentic the OAuth credentials live in your encrypted Jentic One instance and a scoped access token is supplied per request without exposing the service-account key.

### Can I create a new Firebase Realtime Database instance with this API?

Yes. POST /v1beta/{+parent}/instances with parent=projects/PROJECT/locations/REGION and an instanceId creates a new Realtime Database instance. The response includes the instance name and database URL that client SDKs can connect to.

### What are the rate limits for the Firebase Realtime Database Management API?

Google enforces standard googleapis.com per-project quotas for management endpoints, typically a few hundred requests per minute. Provisioning is also bounded by per-project instance quota, which can be raised via a Google Cloud quota increase request.

### How do I disable a Realtime Database instance through Jentic?

Run pip install jentic, search for disable a firebase realtime database, load the instances.disable operation, and execute it with name=projects/PROJECT/locations/REGION/instances/INSTANCE. Get started with Jentic One, the self-hosted execution layer.

### Does the Firebase Realtime Database Management API let me read or write data inside the database?

No. This API only provisions and manages instance lifecycle. To read and write data inside a Realtime Database use the Firebase Realtime Database REST endpoints exposed at the instance's database URL, or the platform Firebase SDKs.

### Is the Firebase Realtime Database Management API free?

The management API itself has no per-call charge under typical usage. The Realtime Database instances it provisions are billed by simultaneous connections, storage, and downloaded bandwidth at standard Firebase pricing.

### Can I limit what my agent is allowed to do with the Firebase Realtime Database Management API?

Yes. Because you run Jentic One yourself, your own rules decide which of the seven instance operations the agent may call and which credential it uses. This API puts the database instance in the URL path, so you can pin the agent to a single instance and expose only safe calls like create, list, get, and reenable while leaving out destructive ones such as disable and delete. The Google OAuth 2.0 service-account credential stays in your self-hosted instance and is injected only for the operations you have allowed.