Registry

Reference for the Imperal Cloud Registry API — extension discovery, tool manifests, app settings, and catalog metadata used by the web-kernel at session start.

The Imperal Cloud Registry is the platform's source of truth for installed extensions, tool manifests, and app settings. The web-kernel reads from it at the start of every chat session to populate the tool catalog and derive skeleton sections. Extension authors interact with the Registry indirectly — the Developer Portal's deploy pipeline (POST /v1/developer/apps/{app_id}/deploys) pushes manifests to it automatically.

Spec

	Link
Downloadable spec	`/openapi/registry.json`

The Registry runs on an internal host (not publicly reachable by default). The spec is provided for integration reference.

Paths (15 total)

The Registry surface is small and purpose-built:

Method	Path	Description
`GET`	`/v1/apps`	List all published apps in the catalog
`GET`	`/v1/apps/{app_id}`	App metadata (name, description, version, category)
`POST`	`/v1/apps`	Register a new app (Developer Portal deploy pipeline)
`PUT`	`/v1/apps/{app_id}`	Update app metadata
`DELETE`	`/v1/apps/{app_id}`	Remove an app from the registry
`GET`	`/v1/apps/{app_id}/tools`	Full tool manifest for an app — `@chat.function` definitions + skeleton sections
`PUT`	`/v1/apps/{app_id}/tools`	Push a new tool manifest version
`GET`	`/v1/apps/{app_id}/settings`	Per-app runtime settings
`PUT`	`/v1/apps/{app_id}/settings`	Update per-app runtime settings
`GET`	`/v1/catalog`	Aggregated catalog — all apps with their tools (web-kernel session start payload)
`GET`	`/v1/catalog/tools`	All tool definitions across all installed apps
`GET`	`/v1/users/{user_id}/extensions`	Extensions installed for a user
`POST`	`/v1/users/{user_id}/extensions`	Register an extension install for a user
`DELETE`	`/v1/users/{user_id}/extensions/{app_id}`	Remove an extension install
`GET`	`/v1/health`	Registry health probe

Key usage patterns

Session start — tool catalog population

At the start of every chat session the web-kernel calls GET /v1/catalog with the user's imperal_id. The response is the full aggregated manifest of all extensions installed for that user, including every @chat.function definition and every @ext.skeleton section descriptor. This is what the intent classifier uses to build its tool list.

Deploy pipeline — manifest push

When you deploy an extension via the Developer Portal, the pipeline calls PUT /v1/apps/{app_id}/tools with the full tool manifest. The manifest includes all @chat.function entries and @ext.skeleton sections. Both the Registry and the auth-gateway developer_apps.tools_json column must be updated on every manifest rebuild — if only one is updated, the web-kernel will not see the change.

Extension discovery from a client

To list the extensions available to a user (including install state and function manifests), use the Auth Gateway's GET /v1/me/extensions route — that is the user-facing discovery surface. The Registry's GET /v1/users/{user_id}/extensions is the underlying data store it reads from.