Catalogs & Spaces

Partition your Hrida AI Studio instance into isolated, access-controlled AI environments for different business units, clients, or teams.

A Catalog is an isolated AI environment with its own LLM provider configuration, its own set of Spaces, and its own access rules. A Space is a collaborative workspace inside a catalog — it has members, roles, and can override the catalog's LLM settings for even more fine-grained control.

This two-level hierarchy — Catalog → Spaces — lets you run a single Hrida AI Studio instance that simultaneously serves multiple business units or client organizations, each with their own models, API keys, and users, without any cross-contamination.

Enterprise feature

Catalogs are typically enabled for enterprise deployments with multiple departments or client tenants. Contact your admin if you don't see the Catalogs section.

Not the same as API Builder's Catalogs & Spaces

API Builder has its own, completely separate "API Catalog → API Space" hierarchy (see API Catalogs, Spaces & Roles) used only to govern API definitions. It shares a name and a two-level shape with this feature by convention, nothing else — membership in one grants no access in the other.

Architecture

Instance
 └─ Catalog A  (e.g., "Finance Department")
     ├─ LLM Provider: Azure OpenAI (Finance subscription key)
     ├─ Space: "Quarterly Reports"  — members: finance team
     │    └─ LLM override: GPT-4o (higher tier)
     └─ Space: "Helpdesk"  — members: support staff
 └─ Catalog B  (e.g., "Engineering")
     ├─ LLM Provider: Anthropic (Engineering API key)
     └─ Space: "Code Review"  — members: all engineers

Catalogs

A catalog defines the top-level isolation boundary. Admins create and configure catalogs; non-admin users only see catalogs where they have at least one space membership.

Catalog settings

Field	Description
Name	Human-readable label for the catalog
Slug	URL-safe unique identifier (e.g., `finance-dept`) — immutable after creation
LLM Providers	One or more LLM provider configs scoped to this catalog (API keys stored encrypted at rest)
Execution env	Optional environment variables injected at runtime for tools run inside this catalog

LLM provider configuration

Each catalog can have its own set of LLM provider entries. API keys are encrypted with the instance's HRIDAAI_SECRET_KEY before storage — plaintext keys never persist to the database.

Supported provider types mirror the instance-level provider list: OpenAI-compatible, Anthropic, Azure OpenAI, Ollama, and any custom endpoint.

Spaces

A space is a collaborative area inside a catalog. Every space has:

Members — users assigned to the space with a specific role
LLM override — optional per-space model and provider override that takes precedence over the catalog default
Node LLM config — fine-grained per-workflow-node configuration for spaces that run agent workflows

Space roles

Role	Access
`viewer`	Read access to resources inside the space
`editor`	Create and edit resources
`admin`	Full control including member management

Adding members

Space admins can add members from the space settings panel. Members must already have a Hrida AI Studio user account.

LLM Provider Resolution

Every feature that calls an LLM — Agent Builder workflow nodes, the Agent Skill Test panel, the Inbox "ask agent" action — resolves which provider, model, and API key to use through the same four-level priority chain:

Node        node.config.llm            per-node override in a workflow graph
Space       space llm override          scoped to one Space
Catalog     catalog.llm_providers[]     the catalog's default provider
Global      Admin → Models connections  instance-wide fallback

Each level only applies if the one above it doesn't specify a value — a node with no LLM override falls through to its space, which falls through to its catalog's default provider, which falls through to the global connections configured in Admin → Models. Resolution stops at the first level that supplies a provider.

The global tier requires both a catalog and a space

Catalog- and space-level resolution only runs when a resource (a skill, a workflow node, etc.) is actually scoped to a catalog and a space. A resource with no catalog/space association (for example, an Agent Skill created outside an active space) skips straight to the global tier — there is no catalog/space context to resolve against.

Checking what will actually resolve

Rather than guessing, fetch the effective config directly:

GET /api/v1/catalogs/{catalog_id}/spaces/{space_id}/llm-config/effective

The response includes a resolution_source map telling you exactly which tier supplied the provider and model — "node", "space", "catalog", or "global" — so you can see why a particular provider was chosen without reverse-engineering the chain by hand.

Troubleshooting "No LLM provider configured"

This error means none of the four tiers resolved to a provider. Checklist:

Does the resource (skill, workflow) have a catalog_id/space_id? If not, only the global tier is checked.
If it does, does that catalog have at least one entry in LLM Providers, and is one marked default?
Does the space override point at a provider that still exists on the catalog?
If none of the above apply, does Admin → Models have at least one enabled connection?

Access Control

Who	What they see
Instance admin	All catalogs and all spaces
Catalog admin	All spaces in their catalog
Space member	Only the spaces they belong to
No membership	The catalog is invisible

API

Catalog endpoints

Method	Path	Description
`GET`	`/api/v1/catalogs/`	List accessible catalogs
`POST`	`/api/v1/catalogs/`	Create a catalog (admin only)
`GET`	`/api/v1/catalogs/{id}`	Get catalog details
`PATCH`	`/api/v1/catalogs/{id}`	Update a catalog (admin only)
`DELETE`	`/api/v1/catalogs/{id}`	Delete a catalog (admin only)

Space endpoints

Method	Path	Description
`GET`	`/api/v1/catalogs/{id}/spaces`	List spaces in a catalog
`POST`	`/api/v1/catalogs/{id}/spaces`	Create a space
`GET`	`/api/v1/catalogs/{id}/spaces/{sid}`	Get space details
`PATCH`	`/api/v1/catalogs/{id}/spaces/{sid}`	Update a space
`DELETE`	`/api/v1/catalogs/{id}/spaces/{sid}`	Delete a space
`GET`	`/api/v1/catalogs/{id}/spaces/{sid}/members`	List space members
`POST`	`/api/v1/catalogs/{id}/spaces/{sid}/members`	Add a member
`PATCH`	`/api/v1/catalogs/{id}/spaces/{sid}/members/{uid}`	Update member role
`DELETE`	`/api/v1/catalogs/{id}/spaces/{sid}/members/{uid}`	Remove a member

LLM configuration

Method	Path	Description
`GET`	`/api/v1/catalogs/{id}/llm-providers`	List LLM providers configured on a catalog
`PUT`	`/api/v1/catalogs/{id}/llm-providers`	Replace the catalog's LLM providers (at most one `is_default`)
`GET`	`/api/v1/catalogs/{id}/spaces/{sid}/llm-config`	Get the space-level LLM override
`PUT`	`/api/v1/catalogs/{id}/spaces/{sid}/llm-config`	Set the space-level LLM override
`GET`	`/api/v1/catalogs/{id}/spaces/{sid}/llm-config/effective`	Resolve the full node → space → catalog → global chain; response includes `resolution_source`

Security notes

LLM provider API keys are encrypted at rest using Fernet encryption keyed from HRIDAAI_SECRET_KEY. They are never returned in plaintext through the API — the response redacts each key to has_api_key: true.
The slug of a catalog is immutable after creation to avoid breaking references.
Deleting a catalog removes all its spaces and member assignments. This action is irreversible.

Architecture​

Catalogs​

Catalog settings​

LLM provider configuration​

Spaces​

Space roles​

Adding members​

LLM Provider Resolution​

Checking what will actually resolve​

Troubleshooting "No LLM provider configured"​

Access Control​

API​

Catalog endpoints​

Space endpoints​

LLM configuration​

Security notes​