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%2Fcrunchybridge.com%2Fcrunchybridge" | 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%2Fcrunchybridge.com%2Fcrunchybridge" | 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.

Provision a new managed PostgreSQL cluster on Crunchy Bridge

Update cluster size, plan, or configuration via PATCH on the cluster resource

Fork an existing cluster to create a point-in-time copy for testing or analytics

Toggle high availability on a cluster with the enable-ha and disable-ha actions

Suspend, resume, restart, and ping a cluster to control runtime cost and state

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.

★ Cost-Aware Cluster Lifecycle

Reduce cloud spend by suspending non-production clusters outside business hours and resuming them on demand. Crunchy Bridge exposes suspend, resume, and ping actions as first-class API verbs so a scheduler or agent can drive the lifecycle without going through the dashboard.

PUT /clusters/{cluster_id}/actions/suspend at 7pm and /clusters/{cluster_id}/actions/resume at 7am for every staging cluster tagged 'office-hours'.

Production Forks for Safe Testing

Create a forked copy of a production cluster before running a risky schema migration or load test. The fork is a point-in-time copy that lets the team validate the change against realistic data without touching the live database.

POST /clusters/{cluster_id}/forks with a target plan and name 'migration-test', then run the migration against the new fork.

On-Demand Backup Before Deploys

Trigger an on-demand backup as part of a CI/CD pipeline immediately before any production deploy, then continue only if the backup completes. Provides a fast rollback target without waiting for the next scheduled backup window.

Call PUT /clusters/{cluster_id}/actions/start-backup, poll GET /clusters/{cluster_id}/status until backup completes, then proceed with deploy.

Team and Access Management

Manage which teams have access to which clusters by creating teams, updating membership, and tearing them down via the teams endpoints. Useful when onboarding contractors or rotating engineering pods between projects.

POST /teams to create a 'data-platform' team, then PATCH /teams/{team_id} to update its members and clusters.

Agent-Driven Database Operations

Allow an AI ops agent to handle routine PostgreSQL chores - provisioning a temporary cluster, suspending it after the work, triggering backups - through Jentic so the cbkey_ token stays in the vault and out of agent context.

Search Jentic for 'provision a postgres cluster', load the create-cluster operation, and execute it with the requested plan and region.

Key Endpoints

23 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

GET

/clusters

List clusters

PATCH

/clusters/{cluster_id}

Update a cluster

POST

/clusters/{cluster_id}/forks

Fork an existing cluster

PUT

/clusters/{cluster_id}/actions/suspend

Suspend a cluster

PUT

/clusters/{cluster_id}/actions/resume

Resume a suspended cluster

PUT

/clusters/{cluster_id}/actions/start-backup

Trigger an on-demand backup

POST

/teams

Create a team

POST

/clusters

Create a managed PostgreSQL cluster

GET

/clusters

List clusters

PATCH

/clusters/{cluster_id}

Update a cluster

POST

/clusters/{cluster_id}/forks

Fork an existing cluster

PUT

/clusters/{cluster_id}/actions/suspend

Suspend a cluster

PUT

/clusters/{cluster_id}/actions/resume

Resume a suspended cluster

PUT

/clusters/{cluster_id}/actions/start-backup

Trigger an on-demand backup

POST

/teams

Create a team

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 and threading cluster create, fork, suspend, resume, and backup 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 in the URL path (/clusters/{cluster_id}/actions/...), so a rule can pin your agent to one cluster: it can suspend, resume, or start a backup for that cluster and nothing else. You choose the operations it may call, so cluster deletion or team creation 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 'provision a postgres cluster' or 'suspend 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 Bridge 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 a bearer token in the Authorization header. Tokens are issued from the Crunchy Bridge account settings page in the format cbkey_[your_api_key]. Through Jentic the token is stored encrypted in the vault and never enters the agent prompt.

Can I fork a Crunchy Bridge cluster through the API?

Yes. POST /clusters/{cluster_id}/forks creates a point-in-time copy of an existing cluster on a target plan. The new cluster appears in /clusters once the fork completes.

How do I suspend a Crunchy Bridge cluster to save cost?

Call PUT /clusters/{cluster_id}/actions/suspend. The cluster stops billing for compute while suspended. Resume with PUT /clusters/{cluster_id}/actions/resume when you need it again.

What are the rate limits for the Crunchy Bridge API?

The OpenAPI specification does not document specific numeric rate limits. Watch for HTTP 429 responses on bursty traffic and throttle requests accordingly. Contact Crunchy Bridge 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 injects the cbkey_ bearer token 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 credentials the agent may use. Since the cluster id sits in the URL path, such as /clusters/{cluster_id}/actions/suspend, you can pin the agent to a single cluster and allow only suspend, resume, or start-backup on it. Operations you do not grant, like deleting a cluster or creating a team via POST /teams, stay off limits.

Crunchy Bridge API

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

Agent-ready OpenAPI document · curated by JenticStorageDatabasebearer23 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

Provision, scale, fork, suspend, and resume managed PostgreSQL clusters on Crunchy Bridge, plus manage account and team membership.

Use for: Provision a new PostgreSQL cluster on Crunchy Bridge, Suspend my idle staging cluster overnight to save cost, Fork the production cluster for a one-off analytics workload, Enable high availability on cluster cl_abc123

Not supported: Does not handle in-database SQL execution, query monitoring, or schema migration - use for cluster lifecycle, account, and team management only.

Jentic publishes the only available OpenAPI specification for Crunchy Bridge API, keeping it validated and agent-ready. Crunchy Bridge is a managed PostgreSQL service, and the API exposes 23 endpoints for account management, cluster lifecycle, cluster forks, high-availability toggles, suspend and resume, backups, Tailscale connectivity, and team administration. Authentication uses a bearer token issued from the Crunchy Bridge account settings page in the cbkey_ prefix format.

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

Crunchy Bridge API