Registry API

Name: Registry API API
Brand: Apigee Registry API
Availability: InStock

✓ Official Vendor SpecDeveloper ToolsPackage Registrynone35 EndpointsREST

For Agents

Catalogue, version, and tag internal API descriptions across an organization through 35 endpoints covering APIs, deployments, and revisions.

Connect the Registry API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Registry 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.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | 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 Registry API API.

Create deployments that bind a specific spec revision to an environment such as staging or production

List, tag, and roll back revisions of an API deployment to recover a known-good description

Patch API and deployment metadata in place without disturbing the underlying revision history

GET STARTED

Start building with Registry API API

Explore with Jentic

View OpenAPI Document

The Apigee Registry API is a Google-managed service for cataloguing and versioning API descriptions inside an organization. It models APIs, deployments, and revisions as first-class resources under /v1/projects/{project}/locations/{location}/apis, so teams can attach OpenAPI documents, GraphQL schemas, and Protobuf definitions to a stable identity over time. The Registry exposes 35 endpoints for CRUD on APIs and deployments, listing and tagging revisions, and rolling back to earlier versions. It is typically used to build internal API catalogs and to track which spec is live in each environment.

Use Cases

Patterns agents use Registry API API for, with concrete tasks.

★ Internal API catalog of record

Use the Registry as the single source of truth for which APIs exist inside an organization, who owns them, and where they are deployed. Teams register each API once with POST /v1/projects/{project}/locations/{location}/apis, then attach revisions and deployments as the spec evolves. Engineering portals and governance tooling read /v1/.../apis and /v1/.../deployments to render an accurate, machine-generated catalog instead of a hand-edited wiki.

POST /v1/projects/acme/locations/global/apis with apiId=payments and a body containing displayName and description, then list /v1/projects/acme/locations/global/apis to confirm.

Spec versioning with rollback

Track every change to an API description as a revision, then promote or roll back specific revisions per environment. The Registry's :listRevisions and :deleteRevision actions on a deployment let CI/CD systems publish a new revision on each merge and a rollback workflow can re-tag an earlier revision without rebuilding artefacts. This protects consumers from breaking changes and gives auditors a complete history of contract changes.

GET /v1/projects/acme/locations/global/apis/payments/deployments/prod:listRevisions, pick a revision, then PATCH the deployment to point at it.

Governance and compliance reporting

Compliance teams query the Registry to prove which API contracts are in production, who owns them, and when they last changed. Because every API and deployment carries createTime, updateTime, and labels, simple reads of /v1/.../apis and /v1/.../deployments give auditors the evidence they need without polling individual gateways. New APIs that bypass the catalog are easy to spot when the registry is the gating control.

List all APIs and deployments under /v1/projects/acme/locations/global/apis and join updateTime with labels.owner to produce an ownership report.

Agent-driven catalog maintenance

An AI agent that watches pull requests can register new APIs and create new deployment revisions automatically when a spec file lands on main. Through Jentic the agent calls Registry_CreateApi and Registry_CreateApiDeployment without holding Google credentials directly, and the registry stays in step with the codebase with no human curation. This converts the catalog from a wiki to a continuously generated artefact.

Through Jentic, search 'register an internal api', load Registry_CreateApi, then call it with apiId and metadata derived from the merged spec file.

Key Endpoints

35 endpoints — the apigee registry api is a google-managed service for cataloguing and versioning api descriptions inside an organization.

METHOD

PATH

DESCRIPTION

GET

/v1/projects/{project}/locations/{location}/apis

List APIs in a project and location

POST

/v1/projects/{project}/locations/{location}/apis

Create a new API entry

PATCH

/v1/projects/{project}/locations/{location}/apis/{api}

Update API metadata

GET

/v1/projects/{project}/locations/{location}/apis/{api}/deployments

List deployments for an API

POST

/v1/projects/{project}/locations/{location}/apis/{api}/deployments

Create a deployment revision

GET

/v1/projects/{project}/locations/{location}/apis/{api}/deployments/{deployment}:listRevisions

List revisions of a deployment

GET

/v1/projects/{project}/locations/{location}/apis

List APIs in a project and location

POST

/v1/projects/{project}/locations/{location}/apis

Create a new API entry

PATCH

/v1/projects/{project}/locations/{location}/apis/{api}

Update API metadata

GET

/v1/projects/{project}/locations/{location}/apis/{api}/deployments

List deployments for an API

POST

/v1/projects/{project}/locations/{location}/apis/{api}/deployments

Create a deployment revision

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Apigee Registry inherits Google Cloud authentication. Jentic stores the service-account credential in its vault and signs each request from the agent with a scoped Jentic token, so the raw Google credential never appears in the agent context.

Intent-based discovery

Agents search for intents like 'register an internal api' or 'rollback an api deployment' and Jentic returns the relevant Registry_* operations with their full path and body schemas.

Time to first call

Direct Registry integration involves Google Cloud SDK setup, IAM scoping, and gRPC or REST glue, typically a day's work. Through Jentic the same operations are usable in under an hour.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

SwaggerHub API

SmartBear's hosted API design and registry product.

Choose SwaggerHub when teams need design-time collaboration features like comments and standards linting, not just a runtime catalog.

Alternative

Stoplight

Spec-first API design and documentation hub.

Choose Stoplight when documentation rendering and style governance matter more than the deployment-revision model.

Complementary

GitHub API

Source of truth for spec files often pushed into the Registry.

Use the GitHub API to detect spec changes in pull requests, then call the Registry to register a new revision automatically.

FAQs

Specific to using Registry API API through Jentic.

What authentication does the Apigee Registry API use?

The OpenAPI spec does not declare a securityScheme, but the Registry runs on apigeeregistry.googleapis.com and inherits Google Cloud authentication, which means OAuth 2.0 or service-account credentials in production. When called through Jentic, those Google credentials are stored in the Jentic vault and never reach the agent.

Can I version API specs and roll back to a previous revision?

Yes. Each ApiDeployment under /v1/projects/{project}/locations/{location}/apis/{api}/deployments tracks revisions. Call GET .../{deployment}:listRevisions to see history, then PATCH the deployment to point at an earlier revision or DELETE .../{deployment}:deleteRevision to remove a specific one.

How do I register a new API through Jentic?

Search Jentic for 'register an internal api', load the Registry_CreateApi operation, and execute with the parent /v1/projects/{project}/locations/{location}, an apiId, and a body containing displayName and description. The new entry is immediately listable via Registry_ListApis.

What are the rate limits for the Apigee Registry API?

The OpenAPI spec does not declare specific limits. Apigee Registry runs on Google Cloud and is subject to per-project quotas configurable in the Google Cloud Console. Watch for HTTP 429 and apply exponential backoff.

Does the Registry support managing API deployments per environment?

Yes. The /v1/projects/{project}/locations/{location}/apis/{api}/deployments collection lets you create distinct deployment resources, typically one per environment. Each deployment has its own revision history so staging and production can move independently.