Product model

Our product model offers a flexible framework for handling product data and attributes. It helps you find, update, and manage product details easily and consistently.

This topic describes the product model in detail, as used in our APIs. Understanding the structure of the product model makes handling product data easier.

Conceptual model

The conceptual model provides an entry point to understand how to work with products in an AppDirect marketplace. This will give you an idea of how the system works and what are the relationships between concepts. For a detailed view of the objects and fields that make up a product, refer to the GraphQL schema documentation for Product.

A product's data can be classified into four major categories:

• Core data: Defines the core behavior. Typically, these details cannot be modified once a product is created.
• Profile and listing information (branding): This refers to information about a product that is presented on profile and listing pages. It provides essential details, such as product descriptions, features, and so on.
• Editions and pricing: Defines specific configurations of a product and their corresponding prices.
• Integration configuration: Defines how a vendor or a vendor system is contacted to provision a product.

Each category is represented by a diverse set of fields and objects that can be created and modified in the marketplace using APIs. This model provides vendors and marketplace owners with the flexibility and control they need.

Core data

Core data forms the immutable part of the product data model. Once created, it cannot be modified and serves as the foundational information layer for the product.

You can create a product shell using the API. However, you can only publish it after completing other data points, such as listing and profile information, editions and pricing, and integration configuration.

You can create a product shell using our API. However, you cannot publish it until all other areas are completed: listing and profile info, editions and pricing, and integration configuration.

The components of the core data are:

• Product Type: This identifies the type of product. It can range from tangible goods to digital or service-based offerings.
• Usage Type: This parameter defines how the product is meant to be used. It indicates whether only the subscription owner can be assigned to the subscription or if multiple seats can be bought and assigned to users other than the subscription owner.
• Allow multiple purchases: Indicates whether the product is stackable. In other words, can customers buy different editions or instances of the product or buy only a single subscription for a single edition?
• Referable: Indicates whether the product is purchasable or referable (customer can be directed to the product website).
• Add-on: Add-ons are products designed to complement other products. For example, if you offer a standalone database product, you might offer customers a report generation add-on.

Listing and profile information

Listing and profile information includes all the product specifications, which could be updated from time to time. This data is used to provide comprehensive information on the product, its features, and its value proposition.

The following objects can access product listing and profile information:

• Name
• Description
• Overview
• Vendor's name
• Support information
• Features
• Benefits
• Media sources

The values can be specified as part of the createProduct or updateProduct mutations.

Editions and pricing

Editions

An Edition refers to the different levels of product functionality designed to cater to different user needs. A product edition can have multiple pricing plans.

For example, a marketplace might sell two editions of Microsoft Visual Studio: the Professional edition and the Enterprise edition. The product is still Microsoft Visual Studio, but each edition offers a distinct set of features and can be priced differently. When viewing a product, a buyer can choose an edition and purchase a subscription to that edition.

For more information on how to create an edition using APIs, see Create editions.

Pricing Plans

A pricing plan is used to define a payment structure associated with a product edition. A product edition can have one or more pricing plans.

A pricing plan includes the following:

• Pricing strategy - tiered, volume, or unit-based.
• Billing frequency - monthly, quarterly, annually, etc.
• Fee types - set up fee, termination fee, fee for different units of measure (pricing units).
• Unit of measures and corresponding prices - Per User/Per Licenses, Per Gigabyte, etc.
• Contract terms and corresponding configurations

For more information on how to create pricing plans using APIs, see [Create pricing plans].

Integration Configuration

The product integration configuration defines how to contact a vendor when certain events occur in the marketplace, such as purchase, subscription update, user assignment, and so on.

Whenever a product is purchased, upgraded, assigned, unassigned, etc. on the marketplace, the vendor is notified by using the integration event URLs defined in the integration configuration.

For more information, see Create integration configuration.