Install Jentic One Beta

Connect the Crunchy Bridge API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Crunchy Bridge 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://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcrunchydata.com%2Fcrunchydata" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcrunchydata.com%2Fcrunchydata" | 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 Crunchy Bridge API.

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

GET STARTED

Start building with Crunchy Bridge API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Crunchy Bridge API for, with concrete tasks.

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

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.

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.

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.

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.

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

Key Endpoints

26 endpoints — jentic publishes the only available openapi specification for crunchy bridge api, keeping it validated and agent-ready.

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

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

Why Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

Intent-based discovery

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.

FAQs

Specific to using Crunchy Bridge API through Jentic.

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.

Crunchydata Crunchy Bridge API

Name: Crunchy Bridge API
Brand: Crunchy Bridge API
Availability: InStock

Agent-ready OpenAPI document · curated by JenticStorageDatabasebearer26 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

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

Use for: Provision a new PostgreSQL cluster on Crunchy Bridge, Suspend my dev cluster after hours to reduce billing, Fork the production cluster for a load test, Create a Postgres role with read-only permissions on cluster cl_xyz

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

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.

Jentic One on Github View OpenAPI Document

Connect the Crunchy Bridge API to your agent

Capabilities

Start building with Crunchy Bridge API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Crunchydata Crunchy Bridge API