---
title: "Products"
description: "A non-technical ecosystem overview of Products in RevCent, focused on why Products are a core feature, how a Product can behave as a standard item, shippable item, subscription, trial, bundle, third-party shop product, imported catalog item, synced catalog item, WooCommerce change-notified catalog item, or product-listing record, and how Products connect to Product Groups, Subscription Profiles, Sales, Product Sales, Shipping, Fulfillment, Trials, Subscriptions, automation, and reporting."
type: "feature"
company: "RevCent"
canonical: "https://revcent.com/documentation/markdown/ecosystem/feature/Product.md"
relationships:
  - name: "Product Group"
    url: "https://revcent.com/documentation/markdown/ecosystem/feature/ProductGroup.md"
  - name: "Subscription Profile"
    url: "https://revcent.com/documentation/markdown/ecosystem/feature/SubscriptionProfile.md"
  - name: "Sale"
    url: "https://revcent.com/documentation/markdown/ecosystem/item/Sale.md"
  - name: "Product Sale"
    url: "https://revcent.com/documentation/markdown/ecosystem/item/ProductSale.md"
technical_links:
  web_app: "https://kb.revcent.com/en/product"
  api:
    section: "https://revcent.com/docs/api/v2#section-products"
    operations:
      - name: "Get Products"
        operation_id: "GetProducts"
        operation: "https://revcent.com/docs/api/v2#operation-GetProducts"
        schema: "https://revcent.com/documentation/files/api/operation/GetProducts.json"
      - name: "Create A Product"
        operation_id: "CreateProduct"
        operation: "https://revcent.com/docs/api/v2#operation-CreateProduct"
        schema: "https://revcent.com/documentation/files/api/operation/CreateProduct.json"
      - name: "Get A Product"
        operation_id: "GetProduct"
        operation: "https://revcent.com/docs/api/v2#operation-GetProduct"
        schema: "https://revcent.com/documentation/files/api/operation/GetProduct.json"
      - name: "Edit A Product"
        operation_id: "EditProduct"
        operation: "https://revcent.com/docs/api/v2#operation-EditProduct"
        schema: "https://revcent.com/documentation/files/api/operation/EditProduct.json"
      - name: "Enable A Product"
        operation_id: "EnableProduct"
        operation: "https://revcent.com/docs/api/v2#operation-EnableProduct"
        schema: "https://revcent.com/documentation/files/api/operation/EnableProduct.json"
      - name: "Disable A Product"
        operation_id: "DisableProduct"
        operation: "https://revcent.com/docs/api/v2#operation-DisableProduct"
        schema: "https://revcent.com/documentation/files/api/operation/DisableProduct.json"
      - name: "Delete A Product"
        operation_id: "DeleteProduct"
        operation: "https://revcent.com/docs/api/v2#operation-DeleteProduct"
        schema: "https://revcent.com/documentation/files/api/operation/DeleteProduct.json"
      - name: "Search Products"
        operation_id: "SearchProducts"
        operation: "https://revcent.com/docs/api/v2#operation-SearchProducts"
        schema: "https://revcent.com/documentation/files/api/operation/SearchProducts.json"
      - name: "Sync Products"
        operation_id: "SyncProducts"
        operation: "https://revcent.com/docs/api/v2#operation-SyncProducts"
        schema: "https://revcent.com/documentation/files/api/operation/SyncProducts.json"
      - name: "Get Product Sync"
        operation_id: "GetProductSync"
        operation: "https://revcent.com/docs/api/v2#operation-GetProductSync"
        schema: "https://revcent.com/documentation/files/api/operation/GetProductSync.json"
  mcp:
    overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewProduct.md"
    operations:
      - name: "Get Products"
        operation_id: "GetProducts"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetProducts.md"
        available_via_ai: true
      - name: "Create A Product"
        operation_id: "CreateProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/CreateProduct.md"
        available_via_ai: true
      - name: "Get A Product"
        operation_id: "GetProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetProduct.md"
        available_via_ai: true
      - name: "Edit A Product"
        operation_id: "EditProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/EditProduct.md"
        available_via_ai: true
      - name: "Enable A Product"
        operation_id: "EnableProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/EnableProduct.md"
        available_via_ai: true
      - name: "Disable A Product"
        operation_id: "DisableProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/DisableProduct.md"
        available_via_ai: true
      - name: "Delete A Product"
        operation_id: "DeleteProduct"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/DeleteProduct.md"
        available_via_ai: true
      - name: "Search Products"
        operation_id: "SearchProducts"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/SearchProducts.md"
        available_via_ai: true
      - name: "Sync Products"
        operation_id: "SyncProducts"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/SyncProducts.md"
        available_via_ai: true
      - name: "Get Product Sync"
        operation_id: "GetProductSync"
        markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetProductSync.md"
        available_via_ai: true
  bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json"
  bigquery_tables:
    - "product"
---

# Products

Products are one of the most important features in RevCent because they define what a business sells.

A Product is more than a name, SKU, and price. In RevCent, a Product can control how a sale behaves, whether something ships, whether a subscription is created, whether a trial is created, whether a bundle is decomposed into other products, how fulfillment should be notified, how storefront products map into RevCent, and how product-level revenue can be reported.

The Product feature is a core part of the RevCent ecosystem because nearly every commerce workflow begins with a Product.

## Why Products Are a Feature

Products are a feature because they are reusable business configuration.

A business creates or imports a Product once, then that Product can be sold many times across many Sales, Customers, Campaigns, Shops, Subscriptions, Trials, Bundles, Fulfillment workflows, and reporting views.

The simplest distinction is:

- Product: the reusable catalog definition.
- Product Sale: the purchased instance of a Product inside a Sale.
- Sale: the customer purchase attempt or purchase event that contains one or more Products.

A Product tells RevCent what can be sold. A Product Sale tells RevCent what was actually purchased.

## Where Products Fit in RevCent

Products sit at the center of the revenue graph.

A Product can connect to:

- Product Groups for organization and segmentation.
- Subscription Profiles for recurring billing behavior.
- Sales when customers purchase products.
- Product Sales when the purchased line items are created.
- Trials when a product has a trial period.
- Subscriptions when a product renews over time.
- Shipping when a product is shippable.
- Fulfillment Accounts when a shippable product needs a fulfillment provider.
- Third-party Shops when products are imported or mapped from an external store.
- Metadata, Notes, Email Templates, Events, Functions, AI Assistants, and AI Voice Agents through downstream commerce activity.
- BigQuery for product-level reporting and relationship analysis.

A Product is therefore both a catalog object and a behavior-defining feature.

## Core Business Purpose

The Product feature gives ecommerce businesses a flexible way to describe what they sell and how each item should behave after purchase.

A Product can answer business questions such as:

- What is being sold?
- What is the price?
- Is it physical or digital?
- Does it need to ship?
- Does it create a subscription?
- Does it create a trial?
- Is it a bundle of other products?
- Does it belong to a Product Group?
- Is it mapped to a third-party shop product?
- How should this product appear in reporting?
- How should this product be handled by fulfillment, support, automation, and AI?

This is why Products are a foundational part of RevCent rather than a simple catalog list.

## Product Versatility

One of the most important ideas in RevCent is that a Product can be versatile.

A Product can be:

- A standard one-time product.
- A shippable physical product.
- A digital or non-shippable product.
- A subscription product.
- A trial product.
- A usage or metered product.
- A bundle product.
- A parent product with child or variation products.
- A product imported from a third-party shop.
- A product synced from WooCommerce through API or MCP.
- A product updated from WooCommerce through direct store-to-RevCent change notifications.
- A product prepared for product listings or agentic commerce experiences.

These behaviors can also combine.

For example:

- A physical product can be shippable.
- A subscription product can also be shippable.
- A trial product can also be shippable.
- A bundle product can contain multiple shippable products.
- A subscription product can itself be a bundle.
- A trial product can itself be a bundle.
- A product imported or synced from a third-party shop can still become part of RevCent reporting, fulfillment, subscriptions, and bundles.
- A WooCommerce product can continue changing in WooCommerce while RevCent receives product-change notifications and updates the matching Product context.

This versatility is one of the reasons Products are a core component of RevCent as a whole.

## Products and Sales

Every Sale in RevCent requires at least one Product.

The Product defines what the customer is trying to buy. The Sale records the purchase event. The Product Sale records the purchased line item.

Conceptually:

```text
Product exists in the catalog
    ↓
Customer attempts or completes a purchase
    ↓
Sale is created
    ↓
Product Sale is created for each product purchased
    ↓
Additional records may be created depending on product behavior
```

Depending on the Product configuration, a Sale can also lead to Shipping records, Trials, Subscriptions, Subscription Renewals, Tax, Discounts, Transactions, Offline Payments, PayPal Transactions, Pending Refunds, and other related items.

## Product vs Product Sale

A Product is the reusable definition. A Product Sale is the record of that Product being purchased.

This distinction matters because changing a Product definition does not mean every past purchase becomes a different purchase. Past Product Sales are historical purchase records. Products are catalog and behavior configuration.

Example:

```text
Product:
Monthly Coffee Subscription

Product Sale:
Jane purchased Monthly Coffee Subscription on March 1.
```

The Product is reusable. The Product Sale is the purchased instance.

## Product Groups

Product Groups help organize Products.

A Product can belong to one or more Product Groups. Product Groups can be useful for organizing products by brand, category, offer, funnel, business unit, fulfillment strategy, reporting segment, or customer experience.

Product Groups help answer questions such as:

- Which products belong to this business line?
- Which products are part of this offer family?
- Which products should be analyzed together?
- Which products should be grouped for reporting?
- Which products are related for support, automation, or segmentation?

In the ecosystem graph, Product Groups are a feature that helps organize Products, while Products are the sellable definitions that appear in Sales and Product Sales.

## Subscription Products

A Product can be configured as a subscription product.

A subscription product is useful when the customer buys something that should renew over time. The Product defines what is being sold, while the Subscription Profile defines the renewal pattern.

The relationship is:

```text
Product = what the customer buys
Subscription Profile = how and when the subscription renews
Subscription = the active customer-specific recurring record
Subscription Renewal = a renewal cycle created from that subscription
```

This separation is powerful because it lets the business reuse subscription timing logic across products while still letting each Product define its own identity, pricing, shipping, grouping, and bundle behavior.

## How RevCent Handles Subscriptions

When a customer purchases a subscription product, RevCent can create a Subscription tied to that customer, Sale, Product, and Product Sale.

The Subscription becomes the ongoing customer-specific record. Over time, the Subscription Profile tells RevCent when renewals should happen. Each renewal can create Subscription Renewal activity and related payment, product, shipping, tax, and reporting context.

This allows RevCent to represent recurring revenue as a connected graph rather than a disconnected charge schedule.

A subscription product can support use cases such as:

- Monthly replenishment products.
- Membership products.
- Continuity programs.
- Subscription boxes.
- Recurring digital access.
- Autoship products.
- Recurring physical bundles.

The Product remains the catalog definition, while the Subscription and Subscription Renewals represent the customer-specific recurring lifecycle.

## Subscription Pricing Flexibility

A subscription Product can have an initial sale price and a renewal price.

This is useful for offers such as:

- Introductory first-month pricing.
- Discounted first shipment.
- Trial-to-subscription offers.
- Promotional acquisition pricing followed by standard renewal pricing.
- Bundle starter offers that renew differently over time.

For example, a customer may purchase a subscription product for a lower first price, then renew at a higher recurring price. The ecosystem idea is that the Product can support both acquisition pricing and renewal pricing without needing a separate business concept outside RevCent.

## Trial Products

A Product can also be configured as a trial product.

A trial product is useful when the customer receives a product or offer now, but billing or fulfillment behavior depends on a later trial expiration.

A trial product can help support business models such as:

- Try-before-you-buy offers.
- Delayed billing offers.
- Promotional trial kits.
- Trial-to-subscription funnels.
- Physical trial shipments.
- Trial bundles.

When a trial product is sold, RevCent can create Trial context that connects back to the Product, Sale, Product Sale, Customer, and any related shipping or payment activity.

## Trial Shipping Flexibility

Trial products can be especially flexible when they are also shippable.

A business may want shipping to happen:

- When the trial is created.
- When the trial expires.
- Both when the trial is created and when it expires.

This matters for ecommerce offers where the customer receives something at the start of a trial and may receive something else after the trial ends.

For example:

- A sample kit ships immediately, then a full-size product ships after trial expiration.
- A trial product ships only after the customer completes the trial period.
- A trial bundle ships at creation and again at expiration.

This flexibility lets RevCent model trial commerce in a way that matches the business offer instead of forcing every trial into the same fulfillment pattern.

## Shippable Products

A Product can be shippable.

A shippable Product connects the catalog to the fulfillment ecosystem. When a shippable Product is sold, RevCent can create Shipping records and notify the correct fulfillment process.

Shippable Products can connect to:

- Shipping records.
- Fulfillment Accounts.
- Shipping Profiles.
- Sales.
- Product Sales.
- Trials.
- Subscriptions.
- Subscription Renewals.
- Bundles.
- PayPal tracking updates when applicable.

This is important because physical-product businesses need RevCent to understand not only what was sold, but also what needs to be shipped, when it should ship, and which fulfillment provider should handle it.

## Products and Fulfillment

When a Product is shippable, fulfillment context becomes part of the Product's business meaning.

A shippable product should be configured so RevCent knows how fulfillment should be handled. This can include fulfillment provider context, product dimensions, weight, and related shipping behavior.

For a normal shippable Product, fulfillment may be straightforward: one product is sold and one shipment is created.

For a subscription, trial, or bundle Product, fulfillment can become more advanced:

- A subscription product may need to ship every renewal.
- A trial product may need to ship at creation, expiration, or both.
- A bundle product may need fulfillment to receive the child products rather than only the parent bundle.
- A bundle may contain products that require separate fulfillment handling.

This is where Product configuration becomes operationally important.

## Bundle Products

A Product can be a bundle of other Products.

A bundle Product is the customer-facing product being sold. The bundled Products are the child products contained inside that bundle.

Example:

```text
Bundle Product:
Starter Wellness Kit

Bundled Products:
Vitamin Pack
Protein Powder
Shaker Bottle
```

The customer may think they bought the Starter Wellness Kit, but the business may need RevCent and the fulfillment provider to understand the actual component products inside that kit.

## Why Bundling Matters for Ecommerce

Bundling can help ecommerce businesses in several ways.

It can help a business:

- Sell multiple products as one offer.
- Create starter kits, sample kits, stacks, bundles, boxes, or multi-product promotions.
- Increase average order value.
- Simplify customer-facing offers.
- Preserve component-level fulfillment logic.
- Ship the correct items to the customer.
- Support product-level refund and reporting needs.
- Build subscription boxes or recurring kits.
- Create trial kits that later become subscriptions or full-product offers.

Bundles allow the customer experience to stay simple while the operational backend remains precise.

## Bundle Product vs Bundled Products

RevCent distinguishes between the parent bundle Product and the child bundled Products.

The bundle Product is the sellable offer. The bundled Products are the components contained inside the offer.

This distinction matters because support teams, fulfillment teams, reporting tools, and automation workflows may need to know whether they are looking at the customer-facing bundle or the individual components inside it.

## Bundle Price Allocation

A bundle should have a consistent relationship between the parent bundle price and the prices assigned to the bundled child products.

The business reason is simple: RevCent needs to understand how value is distributed across the components so fulfillment, refunds, reporting, and item-level visibility remain accurate.

If a bundle sells for $100, the component product values should also explain that $100 in a way that makes sense for the business.

This avoids confusion when teams later ask:

- What was actually sold?
- What product should be refunded?
- What product should be shipped?
- Which component contributed to revenue?
- Which product should appear in product-level reporting?

## Unbundle Methods

A bundle Product can be handled in different ways depending on the business need.

RevCent supports the concept of unbundling either at sale or at fulfillment.

This is one of the most important Product decisions for bundle businesses because it affects how Sales, Product Sales, fulfillment notifications, customer service views, and reporting behave.

## Unbundle at Fulfillment

Unbundle at fulfillment means the Sale can preserve the parent bundle Product, while fulfillment receives the component products that need to be shipped.

This is commonly useful when the customer-facing offer should remain a bundle, but the warehouse or fulfillment provider needs the individual items.

This approach is often useful for:

- Physical kits.
- Subscription boxes.
- Trial bundles.
- Customer-facing bundles where emails should show the parent bundle.
- Businesses that want the sale to remain centered around the bundle offer.

For many businesses, this is the simpler bundle model because it keeps the customer-facing purchase easy to understand while still letting fulfillment ship the right products.

## Unbundle at Sale

Unbundle at sale means the bundle is decomposed into its child Products when the Sale is created.

This is useful when the business wants the child products to appear more directly in the Sale and Product Sale graph.

This approach can be useful when:

- Product-level reporting needs the component products immediately.
- Product-level refunds should be tied to child products.
- Child products have different fulfillment centers.
- A bundle contains subscription or trial products that need to become their own active records.
- Automation needs to see the component products right away.

This method can be more powerful, but it can also make customer service views more complex because the customer bought a bundle while the internal Sale may show the child products.

## Choosing an Unbundle Method

The right unbundle method depends on what the business wants the ecosystem to preserve.

A practical way to think about it:

- Choose fulfillment-oriented unbundling when the customer-facing bundle should remain the main purchased item, but fulfillment needs the components.
- Choose sale-oriented unbundling when the business needs component Products to become visible as purchased items immediately.

Questions to consider:

- Should the customer see the parent bundle in emails and support conversations?
- Should reporting focus on the parent bundle or the component products?
- Do the bundled products need separate fulfillment centers?
- Should refunds happen at the bundle level or component level?
- Does the bundle contain a subscription product or trial product?
- Do AI Assistants, Functions, or Events need to react to the parent bundle or to the child components?

The unbundle method is not only a fulfillment choice. It affects the entire RevCent relationship graph.

## Subscription and Trial Bundles

A subscription Product can be a bundle. A trial Product can also be a bundle.

This is a powerful ecommerce pattern.

Examples include:

- Monthly supplement box.
- Recurring skincare kit.
- Trial starter kit that later bills or renews.
- Subscription coffee bundle with rotating or grouped products.
- Physical membership box containing multiple products.

When a subscription bundle renews, RevCent can notify fulfillment about the bundled products. When a trial bundle expires, RevCent can also use bundle logic to determine what should ship.

This allows a business to sell a clean customer-facing offer while still giving RevCent the structure needed for recurring fulfillment and reporting.

## Multiple Bundles in One Sale

A Sale can include multiple bundle Products.

Each bundle follows its own bundle settings. This is important because a single customer purchase may contain multiple parent bundles, each with different child products, quantities, prices, and fulfillment behavior.

For support and reporting, this means teams should avoid assuming that all bundled products came from the same bundle. The relationship between parent bundles and child products matters.

## Customer Communication and Bundles

Customer-facing communication should usually preserve what the customer believes they purchased.

If the customer bought a Starter Kit, the customer email should not make it look like they purchased unrelated component products instead. RevCent bundle behavior helps preserve the customer-facing bundle while still allowing internal systems to understand the components.

This is especially important for support clarity.

A customer may ask about the bundle they bought. The support team may need to understand both:

- The parent bundle the customer saw.
- The child products that shipped or were reported internally.

## Product Imports and Product Sync

Products can be created manually, programmatically, imported through the web app, or synced automatically from a connected shop.

This matters because many ecommerce businesses already have product catalogs in systems like WooCommerce or another storefront. RevCent does not require those businesses to rebuild every Product one at a time before the catalog can participate in the RevCent ecosystem.

At a high level, RevCent supports three broad product onboarding and alignment patterns:

- Manual import in the web app.
- Automated product sync through API or MCP using the `SyncProducts` operation.
- Direct WooCommerce product-change notifications from a connected WooCommerce store to RevCent.

These patterns help move external catalog data into RevCent and keep product records aligned so Products can connect to Sales, Product Sales, fulfillment, subscriptions, trials, bundles, automation, and reporting.

## Manual Product Import in the Web App

The web app supports product importing for users who want a guided, human-reviewed process.

Manual import is especially useful when:

- Products are being loaded from a CSV file.
- A user wants to review product rows before importing them.
- Certain remote products need cleanup before they become RevCent Products.
- The user wants to make adjustments during the import process.
- The business is doing a one-time catalog migration or cleanup project.

In the ecosystem view, manual import is a bridge between an existing product catalog and the RevCent Product feature. It gives a human user the opportunity to review product names, SKUs, prices, shop mappings, product groups, fulfillment readiness, and other business details before those Products become part of the broader RevCent graph.

## Automated Product Sync with `SyncProducts`

RevCent can also sync products automatically from a remote WooCommerce shop using the `SyncProducts` operation, available through both the API and MCP.

This operation is useful when a business wants RevCent to pull products from a connected shop and keep the RevCent catalog aligned with that external storefront.

At a business level, `SyncProducts` can:

- Create RevCent Products that exist in the remote shop but do not yet exist in RevCent.
- Update RevCent Products that already exist but have changed in the remote shop.
- Help reduce duplicate manual entry for WooCommerce catalogs.
- Keep shop-linked Products connected to RevCent Sales, Product Sales, fulfillment, subscriptions, trials, bundles, automation, and reporting.

This makes product sync especially valuable for ecommerce businesses that manage their catalog in WooCommerce but want RevCent to become the connected commerce, payment, fulfillment, automation, and reporting layer.

## Automatic WooCommerce Product Change Notifications

For users running WooCommerce, RevCent can also keep product records aligned through direct WooCommerce product-change notifications.

This is separate from manually importing products in the web app and separate from calling `SyncProducts` through API or MCP. In this pattern, WooCommerce notifies RevCent when a product changes in the WooCommerce store, and RevCent can use that one-to-one notification to update the matching Product context in RevCent.

Conceptually:

```text
Product changes in WooCommerce
    ↓
WooCommerce notifies RevCent of the product change
    ↓
RevCent updates the connected Product record or product context
    ↓
RevCent commerce, fulfillment, automation, and reporting stay aligned with the store catalog
```

This matters because WooCommerce may remain the day-to-day catalog management system for the business. A merchant may update product names, descriptions, prices, images, availability, or other product details in WooCommerce, while RevCent needs the connected Product records to stay current for payments, Sales, Product Sales, fulfillment, subscriptions, trials, bundles, AI workflows, and reporting.

At an ecosystem level, this creates a more direct connection between WooCommerce and RevCent:

- WooCommerce remains the storefront and product editing source.
- RevCent receives a product-change signal from WooCommerce.
- The related RevCent Product remains connected to Sales, Product Sales, Product Groups, Subscription Profiles, fulfillment, automation, and BigQuery reporting.

This direct WooCommerce notification flow is especially useful for ongoing catalog maintenance after products have already been imported or synced. It helps reduce catalog drift between WooCommerce and RevCent without requiring a user to manually re-import products or start a bulk sync each time a WooCommerce product changes.

## Manual Import vs Automated Sync vs WooCommerce Change Notifications

Manual import, automated sync, and WooCommerce product-change notifications serve different business needs.

Manual import is best when a user wants direct review and control over what is being imported. It is useful for CSV imports, cleanup work, catalog migrations, or cases where product data needs human attention.

Automated `SyncProducts` sync is best when products already live in a connected WooCommerce shop and the business wants RevCent to create or update matching Products in bulk without manually re-entering the catalog.

Direct WooCommerce product-change notifications are best for ongoing store maintenance after the catalog is already connected. Instead of a user starting a manual import or an API/MCP sync, WooCommerce notifies RevCent when a specific product changes, helping RevCent keep the matching Product context aligned with the WooCommerce store.

All three approaches still require business review. An imported, synced, or change-notified Product may still need additional RevCent-specific configuration for fulfillment, subscription behavior, trial behavior, Product Groups, images, listing readiness, or bundle settings.

## Third-Party Shop Products

A Product can be associated with a third-party shop.

This helps RevCent connect external storefront catalog data to internal RevCent commerce records.

This relationship is useful for:

- WooCommerce products.
- External store products.
- Marketplace-style product mappings.
- Product imports.
- Keeping RevCent Products connected to external product IDs.
- Reporting across shops and campaigns.

For ecosystem understanding, the important idea is that RevCent can act as the connected commerce layer even when the original product catalog comes from a third-party shop.

## Product Images and Customer-Facing Data

Products can also contain customer-facing information such as descriptions, product URLs, images, brand, identifiers, availability, and display details.

This matters because Products can power more than checkout. They can support:

- Customer Portals.
- Email Templates.
- AI product summaries.
- Storefront or product-listing experiences.
- Agentic commerce readiness.
- Support workflows.
- Product recommendations and analysis.

A Product that is fully configured is easier for customers, support teams, fulfillment teams, reporting tools, and AI workflows to understand.

## Products and Agentic Commerce

Products can also become important for agentic commerce and product-listing experiences.

At the ecosystem level, this means Product data may need to be accurate enough for an AI or external listing experience to understand what the product is, whether it is available, what it costs, what image represents it, and whether it can actually be fulfilled.

A Product existing in RevCent does not automatically mean it is ready for every channel. Product readiness depends on whether the Product has the right business information, images, availability, pricing, fulfillment setup, and customer-facing details.

## API, MCP, and AI Context

The API and MCP/AI links exist so Products can participate in automated catalog and commerce workflows.

At the ecosystem level, this means Products can be created, reviewed, imported, updated, and connected to other records by approved automation.

This is useful when a business wants an AI or MCP workflow to help with:

- Creating a new product.
- Reviewing product readiness.
- Importing products from a third-party shop.
- Syncing products automatically from a connected WooCommerce shop using `SyncProducts`.
- Checking product relationships.
- Preparing products for subscriptions, trials, bundles, or fulfillment.
- Summarizing product performance.
- Explaining how a Product connects to Sales, Product Sales, Subscriptions, Trials, and Shipping.

The important concept is not the technical operation details. The important concept is that Product configuration can be managed through multiple channels and then reused throughout the RevCent ecosystem.

## BigQuery Reporting and Relationship Visibility

The `product` BigQuery table represents Product records for reporting and relationship analysis.

For ecosystem understanding, the most important use of the `product` table is that it helps show how Products relate to other RevCent records.

Products can appear in or connect to reporting around:

- Product Groups.
- Product Sales.
- Sales.
- Customers.
- Subscriptions.
- Subscription Renewals.
- Trials.
- Shipping.
- Tax.
- Discounts.
- Transactions.
- PayPal Transactions.
- Offline Payments.
- Pending Refunds.
- Chargebacks.
- Third-party Shops.
- Metadata.

This supports business-level reporting such as:

- Revenue by Product.
- Revenue by Product Group.
- Quantity sold by Product.
- Subscription performance by Product.
- Trial performance by Product.
- Bundle performance.
- Product refunds and dispute exposure.
- Shipping or fulfillment issues by Product.
- Product performance by Campaign or Shop.
- Products that may need better configuration, images, fulfillment setup, or grouping.

BigQuery should be treated here as the reporting and relationship layer, not as a place to document table schemas or query examples.

## Product as an Ecosystem Hub

Products are an ecosystem hub because one Product can influence many downstream records.

A Product can cause or connect to:

- Product Sale records when purchased.
- Sale records when included in a purchase.
- Shipping records when shippable.
- Trial records when configured as a trial.
- Subscription records when configured as a subscription.
- Subscription Renewal activity over time.
- Bundle decomposition when configured as a bundle.
- Fulfillment notifications when physical products need to ship.
- Reporting views that connect revenue, refunds, customers, products, and campaigns.
- AI and automation workflows that react to product-driven Events.

Because of this, Product configuration has a direct impact on how the rest of RevCent behaves.

## Common Product Patterns

### One-Time Physical Product

A customer buys a physical item once. RevCent creates the Sale and Product Sale, then shipping and fulfillment logic can handle delivery.

### One-Time Digital Product

A customer buys a digital product or access item. RevCent creates the Sale and Product Sale, but no physical shipping is needed.

### Subscription Product

A customer buys a recurring product. RevCent creates the Sale, Product Sale, and Subscription. Renewals then follow the Subscription Profile.

### Trial Product

A customer enters a trial offer. RevCent creates trial context and can delay billing or shipping behavior until the trial lifecycle requires it.

### Bundle Product

A customer buys one bundle, but RevCent understands the child products contained inside it for fulfillment, reporting, refunds, or automation.

### Subscription Bundle

A customer buys a recurring bundle, such as a monthly kit or box. RevCent can preserve the subscription lifecycle while notifying fulfillment of the bundled products when needed.

### Trial Bundle

A customer buys or enters a trial kit. RevCent can preserve the trial lifecycle while still understanding the bundled products involved.

### Imported Store Product

A Product comes from a third-party shop, such as WooCommerce. RevCent connects the external catalog item to internal commerce, fulfillment, reporting, and automation.

### Synced Store Product

A Product is created or updated automatically from a connected WooCommerce shop through `SyncProducts`. This pattern is useful when the external shop remains the source catalog, while RevCent keeps the product records needed for payments, fulfillment, subscriptions, trials, bundles, automation, and reporting.

### WooCommerce Change-Notified Product

A Product is updated because WooCommerce directly notifies RevCent that a specific WooCommerce product changed. This is a one-to-one store notification path, separate from API/MCP sync, and is useful for keeping RevCent aligned with ongoing catalog edits made inside WooCommerce.

## Common Mistakes to Avoid

Avoid treating Products as only a name and price.

A Product may also define subscription behavior, trial behavior, shipping behavior, bundle behavior, fulfillment behavior, third-party shop mapping, and reporting relationships.

Common mistakes include:

- Creating a shippable Product without thinking through fulfillment.
- Creating a subscription Product without understanding the Subscription Profile.
- Creating a trial Product without deciding when shipping should happen.
- Creating a bundle without deciding whether to unbundle at sale or fulfillment.
- Ignoring how bundle choices affect reporting and customer service.
- Importing, syncing, or change-notifying products from a third-party shop but not reviewing their RevCent readiness.
- Treating Product Sales as the same thing as Products.
- Forgetting that Products are required for Sales.
- Forgetting that a Product can create or affect multiple downstream records.

## Ecosystem Relationship Summary

Products connect to the RevCent ecosystem like this:

- Product → Product Group: Products can be organized into reusable product groupings.
- Product → Subscription Profile: subscription Products use a Subscription Profile to define renewal behavior.
- Product → Sale: every Sale requires at least one Product.
- Product → Product Sale: each purchased Product becomes a Product Sale line item.
- Product → Trial: trial Products can create Trial lifecycle records.
- Product → Subscription: subscription Products can create customer-specific Subscription records.
- Product → Subscription Renewal: subscription Products can generate renewal activity over time.
- Product → Shipping: shippable Products can create Shipping records.
- Product → Fulfillment: shippable and bundled Products can determine what fulfillment receives.
- Product → Bundle: a Product can be a parent bundle containing child Products.
- Product → Third-Party Shop: Products can be imported from, synced from, directly change-notified from, or mapped to external shops such as WooCommerce.
- Product → BigQuery: Products can be analyzed across revenue, sales, trials, subscriptions, bundles, refunds, fulfillment, and customer behavior.

## Summary

Products are one of the most central features in RevCent.

They define what a business sells, but they also define how the rest of RevCent should respond when that product is purchased. A Product can be standard, shippable, subscription-based, trial-based, bundled, manually imported, automatically synced from a connected shop, updated through direct WooCommerce product-change notifications, prepared for customer-facing listings, or a combination of these.

The versatility of the Product feature is what allows RevCent to model many ecommerce business models in one connected ecosystem. Products connect the catalog to Sales, Product Sales, Product Groups, Subscription Profiles, Trials, Subscriptions, Shipping, Fulfillment, Bundles, AI workflows, automation, and BigQuery reporting.


---
Document Parent Directory
* [Features](https://revcent.com/documentation/markdown/ecosystem/feature/index.md) - Non-technical markdown documentation for features within the RevCent ecosystem. A feature is a part of the RevCent ecosystem that a user can create and configure.