The Platform operates within a structured governance framework that ensures clarity in the relationships between Organizations, Groups, Applications, digital products, Subscriptions, Key Sets, Policies and IP addresses. These entities interact within a well-defined governance model that supports multi-tenancy, access control, and lifecycle management.

The model can be read from two points of view: the producers, who create, govern and publish digital products, and the consumers, who discover them and use them through their applications. The sections below describe each entity and how it connects the two.

Organizations and Groups

Organizations and Groups define how users interact with digital products and applications:

• Organizations: Represent business units or external partners that manage digital products and applications.

• Groups: Allow for granular access control within an organization by assigning specific roles and permissions to users.

Applications

In the Platform, an Application is a representation of a digital system that either exposes or consumes one or more digital products. Applications are always associated with an Organization.

• A Producer Application provides digital products to consumers.

• A Consumer Application subscribes to digital products provided by others in order to use them.

Applications ensure governance rules are enforced while maintaining a structured subscription model.

Digital products

Digital products are what producers publish and consumers use. All digital products are described in the workspace, follow a lifecycle and are shown in the Active Catalog according to their visibility settings.

The Platform differentiates APIs between Products and Assets to provide flexibility in governance:

• API Products: Business-level APIs that are consumable and designed for application integration.

• API Assets: Technical backend services that power API Products but are not directly exposed to external consumers.

API Products are often linked to one or more API Assets, which handle the actual execution of API requests.

An API Product is exposed by a Producer Application and can be subscribed by multiple Consumer Applications across different environments.

Besides APIs, the Platform can manage other types of digital products:

• MCP servers: expose tools, prompts and resources to LLMs through the Model Context Protocol.

• AI Agents: communicate and collaborate with other AI agents through the A2A protocol.

• Custom digital product types: defined by the administrator through digital product types and templates, to describe any other kind of digital product of the ecosystem.

Assets and digital products other than APIs (MCP servers, AI Agents and custom types) are available if enabled for your installation.

Each digital product belongs to an Organization and a Group, has its own documentation and attachments, and is governed by role permissions and visibility settings, in the same way as API Products.

Subscription: Relationships Between Applications and digital products

A Subscription links a Consumer Application to one or more API Products exposed by Producer Applications in a given environment.

Key characteristics:

• It expresses intent to consume from the Consumer Application.

• It is environment-specific (e.g., you subscribe to the DEV version of the API).

• It is governed by policies that define the authentication and access behavior.

• It can include the IP addresses from which the Consumer Application will call the API, when this option is enabled by the administrator (see Network: IP addresses and lists below).

For the other digital products, the catalog shows the information a consumer needs to integrate them, such as the configuration of an MCP server or the card of an AI Agent.

Diagrams

Simple Scenario

One asset many products

Application consuming a Product and an asset from the same provider application

The full picture : relationships among different organizations and groups

Key Sets : credentials management within Subscriptions

Each Subscription results in the assignment of a Key Set, which contains the credentials used to invoke the APIs. These Key Sets are generated automatically and governed by the associated Policy Template.

Key Sets are not standalone entities, but logical constructs created and managed as part of Subscription workflows. They serve as the credential container used by a Consumer Application to access one or more subscribed APIs under a unified security policy.

Key behavior:

• Key Sets are shared across Subscriptions only if:

  • They belong to the same Consumer Application,

  • They operate in the same environment,

  • Their target APIs governed by the same Policy Template.

• Otherwise, separate Key Sets are generated.

Example Scenarios:

• Same Application, same environment, same policy template → shared Key Set

• Same Application, different environment → separate Key Sets

• Same Application, same environment, different policies → separate Key Sets

Policy Templates

Policies govern the lifecycle of credentials associated with Subscriptions (i.e., Key Sets). Each API must be assigned a Policy Template, which defines:

• Authentication method (e.g., API Key, OAuth2)

• Key expiration (e.g., 30 days)

• Rotation behavior (e.g. 15 days)

• Key regeneration options (manual/automatic)

If no Policy Template is assigned to an API, a default policy applies (no expiration, no rotation).

The Policy Template is evaluated at the time of Subscription, and determines how the credentials are managed throughout the Subscription lifecycle.

Network: IP addresses and lists

The Network section of the workspace keeps a central registry of the IP addresses used by consumer applications to call the APIs, and of the lists (for example allowlists) they belong to.

• An IP address can be requested in one or more Subscriptions and can belong to one or more lists.

• Each association between an IP address and a list has its own state (Proposed, Approved, Rejected) and is approved or rejected centrally, independently from the single Subscription.

• The IP addresses requested in a Subscription are visible both to the requester and to the approver. Adding or removing IP addresses on an active Subscription follows the same approval rules.

The IP field in Subscriptions is configured by the administrator for each type of user and is disabled by default. Who can manage IP addresses depends on the role permissions configured in your installation.

Entity Relationships Summary

The Platform models the interactions between digital products and Applications through subscriptions. For APIs, these interactions are always scoped to a specific environment and governed by policies.