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

# Google Firebase Rules API

The Firebase Rules API creates and manages the security rules that determine when a Firebase Rules-enabled service such as Cloud Firestore, Realtime Database, or Cloud Storage should permit a request. It exposes operations to manage rulesets (immutable rule documents), releases (named pointers to rulesets), fetch the executable form of a release, and run rule tests against synthetic requests. Use it to deploy and validate security rules from CI rather than the Firebase console.

## For AI agents

Create rulesets, publish releases, and test Firebase security rules against synthetic requests so an agent can deploy and validate Firestore, Realtime Database, and Storage authorisation from CI.

## Scope

Does not authenticate end users, store data, or replace App Check attestation - use for managing and testing Firebase security rulesets and releases only.

## Capabilities

- Publish a new ruleset for Firestore, Realtime Database, or Cloud Storage
- Promote a ruleset by creating or updating a named release such as cloud.firestore
- Retrieve the compiled executable representation of a Firebase Rules release
- Run rule unit tests against a ruleset with synthetic request contexts
- List historical rulesets and releases for an audit trail of authorisation policy changes

## Use cases

### CI-Driven Security Rule Deployments

Wire a CI pipeline to publish a new Firebase Rules ruleset on every merge to main and update the cloud.firestore release to point at it via PATCH /v1/{+name}. The Firebase Rules API replaces the firebase deploy --only firestore:rules CLI flow with a deterministic REST chain, ideal when rules deploys must be gated by additional approvals before reaching production.

Example prompt: Call POST /v1/{+name}/rulesets to create a ruleset from the rules.firestore source, then PATCH /v1/{+name} on projects/PROJECT/releases/cloud.firestore to point at the new ruleset name.

### Automated Rule Unit Testing

Run rule tests in CI by sending synthetic request contexts through POST /v1/{+name}:test against a candidate ruleset before promoting it. The endpoint reports whether each test case is allowed or denied, so a regression in security policy fails the build instead of reaching production. Test integration takes a few hours per project.

Example prompt: Call POST /v1/{+name}:test on the new ruleset name with a testSuite that includes a denied unauthenticated read and an allowed owner write, and fail the CI step if any expected outcome does not match.

### Authorisation Policy Audit Trail

Use GET /v1/{+name}/releases and GET /v1/{+name}/rulesets to build an audit trail of every Firebase Rules version deployed to a project, including who promoted which ruleset to which release. This supports compliance reviews and post-incident investigations where you need to know which security policy was active at a given moment.

Example prompt: Call GET /v1/{+name}/releases for projects/PROJECT and pair each release.updateTime with the rulesetName it pointed at to produce a chronological audit log.

### Agent-Driven Rule Reviews via Jentic

An AI agent connected through Jentic can review pending changes to Firebase Rules, run synthetic tests against the candidate ruleset, and recommend whether to promote it to a release. Jentic exposes the 9 Firebase Rules endpoints, the agent loads test, ruleset, and release operations, and OAuth 2.0 credentials remain inside your Jentic One instance.

Example prompt: Through Jentic, search for test firebase security rules, load the projects.test operation, and execute it with a testSuite that exercises the change set against the candidate ruleset name.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/{+name}/rulesets | Create a new Firebase Rules ruleset |
| GET | /v1/{+name}/rulesets | List rulesets under a project |
| POST | /v1/{+name}/releases | Create a new Firebase Rules release |
| GET | /v1/{+name}/releases | List releases under a project |
| PATCH | /v1/{+name} | Update a release to point at a different ruleset |
| POST | /v1/{+name}:test | Run rule tests against a ruleset |
| GET | /v1/{+name}:getExecutable | Retrieve the executable representation of a release |

## Key resources

- **Rulesets** — Create, list, and retrieve immutable Firebase Rules ruleset documents
- **Releases** — Create, list, get, patch, and delete named releases such as cloud.firestore that point at a ruleset
- **Rule Tests** — Run synthetic rule tests against a ruleset to verify allowed and denied request behaviour
- **Executables** — Retrieve the compiled executable representation of a release for inspection

## Why Jentic

- **Setup:** Wiring the Firebase Rules API by hand means standing up Google OAuth 2.0 with a service account and coding the ruleset, release, and test calls against Google's spec. Through Jentic you install once, import the Firebase Rules API from the API Directory, store the service-account credential once, and your agent calls it.
- **Permission scoping:** The Firebase Rules API puts the project resource in the URL path (/v1/{name}/rulesets, /v1/{name}/releases), so a rule can pin your agent to one project: it can create and test rulesets there and nothing else. You choose the operations it may call, so release changes 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 'deploy Firebase security rules' or 'test a ruleset', 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 App Check API** — Attests that traffic comes from a genuine app before security rules even run.
- **Firebase Realtime Database Management API** — Provisions the Realtime Database instances whose access is governed by Firebase Rules.
- **Google Identity Toolkit API** — Authenticates end users that Firebase Rules can then authorise.

## FAQ

### What authentication does the Firebase Rules API use?

The API uses Google OAuth 2.0 with the firebase.readonly, firebase, or cloud-platform scope depending on whether the call is read-only or mutating. Through Jentic the OAuth credentials are stored in the encrypted vault and a scoped access token is supplied per request.

### Can I deploy Firestore security rules with the Firebase Rules API?

Yes. POST /v1/{+name}/rulesets creates a new ruleset from your rules source, then PATCH /v1/{+name} on the cloud.firestore release pointer flips production traffic to it. This is the same flow that firebase deploy --only firestore:rules uses underneath.

### What are the rate limits for the Firebase Rules API?

Google enforces standard googleapis.com project-level quotas for the Firebase Rules API. Ruleset creation is rate-limited because each ruleset is immutable and persisted; pipelines should avoid creating one ruleset per file change and instead bundle changes per release.

### How do I run a Firebase Rules test through Jentic?

Run pip install jentic, search for test firebase security rules, load the projects.test operation, and execute it with the candidate rulesetName and a testSuite of synthetic request expectations. Get started with Jentic One, the self-hosted execution layer.

### Does the Firebase Rules API support Cloud Storage rules and Realtime Database rules?

Yes. The same ruleset and release machinery covers Cloud Firestore, Cloud Storage, and Realtime Database; the release name (such as cloud.firestore or firebase.storage) determines which Firebase service the ruleset is bound to.

### Is the Firebase Rules API free?

Firebase Rules is included with Firebase at no extra charge. Rule evaluation cost is incurred only when a Firebase service evaluates the rules during a request, and that cost is billed under the underlying service such as Firestore or Cloud Storage.

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

Yes. Because Jentic One is self-hosted, you write the rules that decide which operations and credentials your agent may use. The Firebase Rules API carries the project resource in the URL path (/v1/{name}/rulesets and /v1/{name}/releases), so you can pin the agent to one project and let it only create and test rulesets there. If you do not grant release operations such as PATCH /v1/{+name}, the agent cannot promote a ruleset or change production traffic.