iPolloWork Docs

Configuration resources

Manage versioned configuration, plugins, skills, marketplaces, and provider metadata through their own APIs.

iPolloWork uses separately addressable configuration resources instead of folding all workspace configuration into a single opaque object. This supports explicit version history, access grants, plugin relationships, and reusable organization state.

System flowConfiguration resource lifecycle

A resource can be created, versioned, granted, resolved into use, archived, restored, or removed according to its API family.

  1. 01Create

    Create a configuration object or reusable capability record.

  2. 02Version

    Read versions and address the latest version explicitly.

  3. 03Grant

    Assign access through the resource-specific access route.

  4. 04Resolve

    Fetch the materialized state intended for use by a workspace or runtime.

Main resources

ResourceCommon routes
Configuration objects/v1/config-objects, versions, archive, restore, delete, access, and plugins
Plugins/v1/plugins, archive, restore, resolved, access, and configuration objects
Skills and Skill Hubs/v1/skills, /v1/skill-hubs, access, and hub skill membership
Marketplaces/v1/marketplaces, access, plugins, archive, restore, and resolved
Model providers/v1/llm-provider-catalog, /v1/llm-providers, connect, and access

Integration guidance

  1. Use the resource ID returned by creation, not a display name, for subsequent writes.
  2. Read the latest or resolved representation when the client needs a usable runtime configuration.
  3. Use archive and restore when the business action is reversible. Reserve delete for a permanent removal.
  4. Change access with the matching resource access route instead of embedding access in unrelated payloads.
  5. Treat provider credentials as secrets. Read only the metadata intended for clients.

Query and lifecycle detail

GET /v1/config-objects is designed for resource discovery, not a one-time full export. It supports cursor pagination, limit from 1 through 100, type, status, sourceMode, plugin and connector instance filters, deleted-resource selection, and a text query. Use those server filters before adding broad client-side scans.

Resolved configurationSeparate a stored record, its version history, and the usable runtime representation

A display record is not always the configuration material the runtime should consume. Read the specific latest, version, or resolved route required by the operation.

  1. 01Record

    Create or list a stable configuration object ID and its descriptive metadata.

  2. 02Version

    Read version history when the caller needs a pinned or auditable revision.

  3. 03Resolved form

    Request the route that materializes a configuration for workspace or runtime use.

  4. 04Reversible state

    Archive and restore when the intent is reversible. Delete only for a permanent removal.

When a resource includes an access sub-route, update that route independently of the resource payload. This keeps versioned capability content, access policy, and organization membership as distinct auditable concerns.

The OpenAPI document is the source of truth for payload fields and status codes. This page only establishes the resource model.

On this page

Main resourcesIntegration guidanceQuery and lifecycle detail