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

# Neon API

The Neon API is the management plane for Neon, the serverless Postgres platform with database branching. The 138 endpoints cover projects, branches, compute endpoints, databases, roles, operations, API keys, and the advisor and shared-projects features. With this API a team can spin up a Postgres branch in seconds, create read replicas, manage scoped roles, and automate copy-on-write previews for every pull request.

## For AI agents

Manage Neon Postgres projects, branches, compute endpoints, roles, and API keys, and inspect long-running operations and advisor findings.

## Scope

Does not handle direct SQL execution, in-database row reads, or schema migrations - use for Neon platform management of projects, branches, and compute endpoints only.

## Capabilities

- Provision and destroy Neon projects with regions and Postgres versions chosen at create time
- Create branches off any project for preview environments, restore from a point in time, or fork production data
- Spin up compute endpoints (read-write and read replicas) attached to a branch
- Create roles and databases inside a branch, and rotate or fetch role passwords
- Mint and revoke scoped API keys for service accounts and CI runners
- Track long-running operations through `/projects/{project_id}/operations` and check advisor warnings

## Use cases

### Per Pull Request Database Branches

Engineering teams script `/projects/{project_id}/branches` so every pull request gets its own isolated Postgres branch off the production schema and data. The branch is a copy-on-write fork - provisioning takes seconds, the preview environment runs migrations against real data, and the branch is deleted when the PR closes. This replaces the slow restore-from-dump pattern most CI pipelines previously used.

Example prompt: Create a branch named pr-1234 off the main branch of project shadowy-snow-12345, then return the connection string for the new compute endpoint.

### Read Replica Provisioning

Backend services need read scaling for analytics and dashboards without slowing the write path. Neon supports adding read-replica compute endpoints to a branch, so an agent can attach a replica through the endpoints API and route a BI workload there while the primary endpoint serves transactional traffic. Replicas spin up in seconds and scale to zero when idle.

Example prompt: Create a read-replica compute endpoint on the main branch of a Neon project and return its connection string for the BI dashboard.

### Service Account Key Management

Platform teams use /api_keys to mint scoped tokens for CI, agents, and ops scripts, and to revoke them when a service is decommissioned. Combined with /projects scoping, the result is least-privilege access where each automation has its own key and the audit trail shows which key took which action.

Example prompt: Mint a new Neon API key named ci-runner-prod and return the token, then list existing keys to confirm it appears.

### Restore from Point in Time

Operations engineers respond to bad migrations by calling `/projects/{project_id}/restore` against a recent timestamp. Neon resolves the request to a fresh branch with the data state at that timestamp, and `/projects/{project_id}/operations/{operation_id}` reports progress. The recovery window is bounded by the project history retention setting.

Example prompt: Restore the main branch of a Neon project to its state from 2 hours ago and poll the operation until it reports finished.

### AI Agent Integration via Jentic

An AI agent uses Jentic to provision Neon resources during a deploy or test workflow. Jentic exposes /projects, /branches, and /endpoints by intent, and the agent supplies the project, region, and Postgres version. The Neon bearer key never enters the agent context - it stays in your Jentic One instance.

Example prompt: Use Jentic to search for create a neon project, load the schema, and create a project named agent-demo in the us-east-2 region.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/projects` | List Neon projects |
| POST | `/projects` | Create a new Neon project |
| GET | `/projects/{project_id}` | Get a project by id |
| POST | `/projects/{project_id}/restore` | Restore a branch to a point in time |
| GET | `/projects/{project_id}/operations/{operation_id}` | Get operation status |
| GET | `/api_keys` | List API keys |
| POST | `/api_keys` | Mint an API key |
| DELETE | `/api_keys/{key_id}` | Revoke an API key |

## Key resources

- **Projects** — Create, list, update, and delete Neon projects
- **Branches** — Create branches, restore to a point in time, and manage branch settings
- **Compute Endpoints** — Create read-write and read-replica endpoints on a branch
- **Databases and Roles** — Manage Postgres databases and roles inside a branch
- **API Keys** — Mint and revoke API keys for service accounts
- **Operations** — Track long-running asynchronous operations
- **Advisors** — Read project-level advisor findings

## Why Jentic

- **Setup:** Wiring the Neon API by hand means passing the bearer key on every request, polling the operations endpoint until asynchronous project and branch actions settle, and managing your own API keys through the console host yourself. Through Jentic you install once, import Neon from the API Directory, store the bearer key once, and your agent calls it.
- **Permission scoping:** Neon puts the project id in the URL path (`/projects/{project_id}/...`), so a rule can pin your agent to one project: it can read that project and its operations and nothing else. You choose the operations it may call, so project restore or API key deletion is not included unless you add it.
- **Credential handling:** Your Neon bearer key 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 'create a Neon branch' or 'check a project operation status', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Supabase API** — Postgres-based backend platform with auth, storage, and edge functions on top of the database
- **PlanetScale API** — Serverless MySQL platform with database branching
- **Cockroach Cloud API** — Distributed SQL database compatible with Postgres wire protocol
- **Vercel API** — Frontend cloud that triggers preview deploys, often paired with a Neon branch per pull request

## FAQ

### What authentication does the Neon API use?

The Neon API uses bearer tokens (BearerAuth in the spec) for programmatic clients, and supports cookie-based session auth for the console. Mint a key in the Neon console or via /api_keys, store it in your Jentic One instance, and pass it as Authorization: Bearer in every request.

### Can I create a database branch with the Neon API?

Yes. POST to the branches endpoint under `/projects/{project_id}` with a parent_id and an optional point-in-time. Neon returns the new branch immediately and a compute endpoint can be attached to it for read-write access.

### How do I provision a Neon project through Jentic?

Search Jentic for create a neon project, load the schema for POST /projects, then execute with the project name, region, and Postgres version. The full flow is pip install jentic, search, load, execute.

### What are the rate limits for the Neon API?

Neon enforces account-level concurrency and rate limits that vary by plan. The spec does not include numeric per-second caps, so treat heavy automation (mass branch creation, full project lists) as bursty and back off when 429 responses appear. Long-running actions return an operation id you can poll under `/projects/{project_id}/operations.`

### Can I restore a Neon branch to a previous point in time?

Yes. POST `/projects/{project_id}/restore` with the source branch and a timestamp inside the project history retention window. Neon creates a new branch at that state and returns an operation id for status tracking under `/projects/{project_id}/operations/{operation_id}.`

### Is the Neon API free?

Neon's free plan includes a project with limited storage and compute time and the API is included; programmatic access is not paywalled. Paid plans raise storage, history retention, and compute limits but use the same 138 endpoints.

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

Yes. Because Jentic One is self-hosted, you write the rules that decide which Neon operations and which credential your agent may use. Neon puts the project id in the URL path, so you can pin the agent to a single project and let it read only that project and its operations under `/projects/{project_id}/operations.` You choose the exact operations it may call, so destructive actions like POST `/projects/{project_id}/restore` or DELETE `/api_keys/{key_id}` stay off limits unless you explicitly allow them.