canonical: https://jentic.com/apis/crunchydata.com/crunchydata

# Crunchydata Crunchy Bridge API

Jentic publishes the only available OpenAPI specification for Crunchy Bridge API, keeping it validated and agent-ready. This Crunchy Data surface covers cluster lifecycle (create, update, delete, fork), runtime actions (suspend, resume, restart, backup, HA toggles), account management, access token issuance, network configuration, and Postgres role management across 26 endpoints. Authentication uses a bearer token - either a long-lived cbkey_ API key or a short-lived access token.

## For AI agents

Manage managed PostgreSQL clusters, networks, access tokens, and per-cluster Postgres roles on Crunchy Bridge.

## Scope

Does not handle SQL execution, query monitoring, or schema migrations - use for cluster, network, role, and access-token administration only.

## Capabilities

- Create, update, delete, and fork managed PostgreSQL clusters
- Suspend, resume, restart, and back up clusters via dedicated action endpoints
- Toggle high availability per cluster with enable-ha and disable-ha
- Issue and revoke short-lived access tokens that scope agent or CI access
- Inspect and update network configurations attached to clusters
- List, create, update, and delete Postgres roles within a specific cluster

## Use cases

### Postgres Role Management at Scale

Automate creation and rotation of per-cluster Postgres roles by calling the role endpoints from a script or agent. Useful when issuing scoped credentials for downstream services or when offboarding employees who held read-write access.

Example prompt: POST `/clusters/{cluster_id}/roles` with the role name and password policy, then PUT `/clusters/{cluster_id}/roles/{role_name}` to grant the necessary privileges.

### Cluster Lifecycle Automation

Drive the full cluster lifecycle - create, fork for testing, suspend overnight, resume on demand, and finally delete - from CI or an ops agent without anyone touching the dashboard. Crunchy Bridge exposes every action as a dedicated PUT verb.

Example prompt: POST /clusters to create the cluster, run integration tests, PUT `/clusters/{cluster_id}/actions/suspend` afterwards, and DELETE `/clusters/{cluster_id}` when the run finishes.

### Short-Lived Access Tokens for Agents

Issue narrowly scoped, time-limited access tokens for AI agents or external services so the long-lived cbkey_ key never leaves the secure vault. Revoke the token immediately when the workflow completes.

Example prompt: POST /access-tokens to mint a scoped token, hand it to the downstream service, then DELETE `/access-tokens/{access_token_id}` once the run finishes.

### Network Configuration Updates

Inspect and update Crunchy Bridge network resources to control which CIDR blocks, peering connections, or private endpoints can reach a cluster. Patching the network record propagates rule changes without re-creating the cluster.

Example prompt: GET /networks to list networks, then PATCH `/networks/{network_id}` with the updated CIDR allowlist.

### Agent-Driven Database Ops

Allow an AI agent to handle the routine PostgreSQL chores - provisioning, role creation, suspend/resume, token rotation - through Jentic so the cbkey_ token stays in the vault and only short-lived scoped tokens enter the runtime context.

Example prompt: Search Jentic for 'create a postgres role', load the create-role operation, and execute it for the target cluster.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/clusters` | Create a managed PostgreSQL cluster |
| POST | `/clusters/{cluster_id}/forks` | Fork a cluster |
| PUT | `/clusters/{cluster_id}/actions/suspend` | Suspend a cluster |
| PUT | `/clusters/{cluster_id}/actions/start-backup` | Trigger a backup |
| POST | `/access-tokens` | Mint a short-lived access token |
| POST | `/clusters/{cluster_id}/roles` | Create a Postgres role |
| PATCH | `/networks/{network_id}` | Update a network configuration |

## Key resources

- **Clusters** — Create, read, update, delete, fork, and read status on managed PostgreSQL clusters.
- **ClusterActions** — Suspend, resume, restart, ping, backup, and toggle HA on a cluster.
- **Accounts** — Read or delete the authenticated Crunchy Data account.
- **AccessTokens** — Issue and revoke short-lived access tokens.
- **Networks** — List, read, and update network configurations attached to clusters.
- **PostgresRoles** — Manage Postgres roles within a cluster - list, create, get, update, delete.

## Why Jentic

- **Setup:** Wiring the Crunchy Bridge API by hand means setting its bearer auth with a cbkey_ token or short-lived access token and threading cluster, network, role, and access-token calls yourself. Through Jentic you install once, import the Crunchy Bridge API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Crunchy Bridge puts the cluster id and network id in the URL path (`/clusters/{cluster_id}/roles`, `/networks/{network_id}`), so a rule can pin your agent to one cluster or network: it can create roles or start a backup for that cluster and nothing else. You choose the operations it may call, so minting access tokens is not included unless you add it.
- **Credential handling:** Your Crunchy Bridge cbkey_ token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a postgres role' or 'fork a cluster', and Jentic returns the matching Crunchy Bridge operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Crunchy Bridge API** — Sister Crunchy Bridge surface - narrower endpoint set covering similar lifecycle operations.
- **Crusoe Cloud API** — Cloud compute API; useful for workloads that talk to Crunchy Bridge clusters.
- **Crustdata API** — External data enrichment to populate downstream Postgres tables.

## FAQ

### Why is there no official OpenAPI spec for Crunchy Bridge API?

Crunchy Data does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Crunchy Bridge API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Crunchy Bridge API use?

The API uses bearer-token authentication. The token can either be a long-lived cbkey_ API key or a short-lived access token issued via POST /access-tokens. Through Jentic the token is held in the encrypted vault.

### Can I create Postgres roles inside a cluster with this API?

Yes. POST `/clusters/{cluster_id}/roles` creates a new Postgres role on the target cluster. Subsequent PUT `/clusters/{cluster_id}/roles/{role_name}` calls update privileges, and DELETE removes the role when the access is no longer needed.

### How do I issue a short-lived access token through the Crunchy Bridge API?

Call POST /access-tokens to mint a scoped token, hand it to the downstream service, and call DELETE `/access-tokens/{access_token_id}` to revoke it when the workflow completes.

### What are the rate limits for the Crunchy Bridge API?

The OpenAPI specification does not document specific rate limits. Inspect HTTP 429 responses on bursty traffic and contact Crunchy Data support for production quotas.

### How do I provision a cluster through Jentic?

Run pip install jentic, search 'provision a postgres cluster', load the create-cluster operation, and execute it with your plan and region. Jentic resolves auth automatically.

### Can I limit what my agent is allowed to do with the Crunchy Bridge API?

Yes. Because you run Jentic One yourself, your own rules decide which Crunchy Bridge operations and which credential the agent may use. Since the cluster and network IDs sit in the URL path (for example `/clusters/{cluster_id}/roles` and `/networks/{network_id}`), you can pin the agent to a single cluster so it can only create Postgres roles or trigger a backup there and nothing else. You choose the exact operations it may call, so sensitive actions like minting access tokens via POST /access-tokens stay off-limits unless you explicitly allow them.