About the eCommerce Catalog Service Plugin

The Catalog service plugin lets you become a Wix catalog provider. This means you can integrate any external repository of sellable items with the Wix eCommerce platform. Wix calls the Catalog service plugin to get up-to-date information about items whenever a cart or checkout is updated, and when an item is added to an order.

With the Catalog service plugin, you can:

  • Build a comprehensive business solution offering functionality that differs from Wix's in-house solutions like Wix Stores or Wix Bookings, and integrate your solution with the Wix eCommerce platform to handle transactional capabilities. For example, develop an app to manage equipment rentals, online courses, subscriptions, or vouchers.
  • Integrate an externally managed repository of sellable items with the Wix eCommerce platform to meet specific business needs. For example, if your business handles pricing or availability in a unique way, or if you sell items that aren't easily categorized as physical or digital products or services.
  • Create a Wix app to integrate an existing eCommerce repository on a different platform with Wix's eCommerce platform.

Why an external catalog?

The Catalog service plugin enables you to maintain a complex and dynamic external catalog while being confident Wix can retrieve the latest information for every action.

For example, after a customer adds a particular item to their cart, one of the following details might change in your dynamic catalog:

  • The name of the item might be changed.
  • The price might be adjusted.
  • The item might go out of stock.

With the Catalog service plugin, you can be sure that when the customer moves the item from their cart to their checkout, Wix will retrieve the updated details from your catalog automatically.

Before you begin

It's important to note the following points before starting to code:

  • Existing solutions may already provide the catalog functionality that you need. Check out Wix Stores and Wix Bookings, which provide built-in catalogs. If they cater to your needs, you probably don't need to implement the Catalog service plugin.
  • Create a database of items on the platform of your choice.
  • Learn how to handle item variants with the Catalog service plugin.
  • For some items, you might not need an external catalog. Learn more about catalog and custom items.
  • For an overview of the Wix eCommerce platform and its capabilities, take a look at the Wix eCommerce Platform Handbook.
  • We are constantly updating functionality. Check the documentation regularly to see the latest capabilities. Currently, external catalog integration has a few limitations:
    • Coupons and subscriptions aren't yet supported.
    • Preview mode in the Wix editor doesn't reflect full functionality.
    • Integration with external sales channels isn't yet available.

Get started

Follow these steps to begin implementing your service plugin.

Choose a framework

You can implement this service plugin with the following frameworks:

Configure your service plugin

To configure and customize your plugin, you need to provide important information in the service plugin configuration file. You can configure your plugin in the Wix App Dashboard. For details, see Catalog Extension Configuration.

Define handler functions

Use catalog.provideHandlers() to define the following handler function that implement your custom business logic.

FunctionRequired
getCatalogItems()Yes

Code examples

Below is an example for implementing the Catalog service plugin in your code.

CLI: Basic code structure

This is the basic code structure for implementing the Catalog service plugin with the Wix CLI:

Copy

Self-hosted: Basic code structure

This is the basic code structure for implementing a self-hosted Catalog service plugin:

Copy

Terminology

  • Catalog: A repository containing items for sale. Wix business solutions, such as Wix Bookings and Wix Stores, provide built-in catalogs. External business solutions can provide the Wix eCommerce platform with access to their catalogs via the Catalog service plugin. This enables robust integration of the platform’s cart and checkout functionalities with diverse business types.
  • Item: An item in a catalog can be anything sellable, including physical products, services, gift cards, pricing plans, and custom items created for individual transactions like specialized project work.
  • Cart: A customer's cart holds information about a potential transaction, including details about selected items, prices, and discounts, as well as the potential buyer. Site visitors can see their cart on the cart page. Developers can access and manage a customer's cart with the Cart API. When an item is added to a cart, Wix calls the Catalog service plugin to retrieve current details for the item.
  • Checkout: Checkout is the page where a buyer finalizes a purchase. Each checkout holds information about the items to be purchased, price and tax summaries, shipping and billing information, any applied discounts, and more. Developers can access and manage checkout details and trigger checkout-related events with the Checkout API. When an item is added to a checkout, Wix calls the Catalog service plugin to retrieve current details for the item.
  • Order: Once a customer has committed to a purchase, an order is created. An order holds information about purchased items, price and tax summaries, shipping and billing information, any applied discounts, and the status of payment and fulfillment. In the dashboard, business staff can create new orders, view and edit existing orders, track fulfillment, and manage the payments cycle. The Orders API enables apps or site owners to customize management of the order lifecycle, including viewing, editing, approving, canceling, and charging. When an item is added to an order, Wix calls the Catalog service plugin to retrieve current details for the item.

See also

Did this help?

Handle Item Variants

This article explains how to handle item customization and variants when implementing the Catalog service plugin.

The catalogReference object

When Wix calls the Get Catalog Items method, it includes a catalogReference object containing the reference details for each item to retrieve from your catalog. This object includes the following properties:

  • catalogItemId: The ID of the item in the catalog it belongs to. You can use any system you like for generating and storing unique item IDs. You may wish to expose an API so your app can query and retrieve item IDs.
  • appId: ID of the app providing the catalog. You can get your app's ID from your app's dashboard.
  • options: Additional item details in key:value pairs. Use this optional field to specify a variant of the item or add custom details. See below for more information.

The options field

In some cases, your catalog might need more than just the item ID and app ID in order to return all of the correct item details. On a site's item page, visitors can often choose variants of the item or add custom details. For example:

  • T-shirt size
  • Recipient information for a gift
  • Time and date of an appointment
  • Donation or gift card amount
  • Custom text for a necklace

There are several ways you can use the options object for handling item variants. Here are two different approaches to implementing it. Decide which approach to take based on your technical requirements, existing system architecture, and business needs.

Approach 1 | Pass variant details in options

You can pass specific information about the item in the options object as key:value pairs. You can choose how to structure the information and what keys and values to support.

For example, you can specify item variant details in any of the following ways:

  • T-shirt size and color: "options": {"Size": "M", "Color": "Red"}
  • Custom text for a necklace: "options": {"customText": "Natalie"}
  • Recipient information: "options": {"recipientName": "Omar", "message": "Happy anniversary!"}

If you take this approach, make sure that:

  • Your Catalog service plugin implementation handles the expected options properties, processes them, and returns the correct item details.
  • When your app adds an item to a cart, checkout, or order, the options property of the item's catalogReference only includes key:value pairs that your catalog supports.

Use this approach if:

  • You prefer not to store details for every variant a client selects, unless they result in a purchase.
  • You don't mind handling validation of the options object's properties in your implementation of Get Catalog Items.

Approach 2 | Pass a variant ID in options

You can create a separate API that processes item variants and returns a unique variant ID. Then your app can pass an options object containing only the item variant ID. When Wix calls Get Catalog Items, your Catalog service plugin retrieves the correct details for the item variant on the basis of this ID and returns them.

For example, suppose you are creating an app for processing donations that can be added to a customer's transaction. You could implement this as follows:

  1. Create an API called Create Donation for generating the specific details for a given donation. The request body might include properties that vary between donations, such as organizationId, campaignId and amount. It returns a unique donationId.
  2. Create an API called Get Donation for retrieving the details of a donation based on its unique donationId.
  3. When a site visitor makes a donation, they specify their preferred organization, campaign, and donation amount. The app then sends these details to the Create Donation API, which creates a donation entry and stores the details in your catalog's database. It then returns a unique donationId.
  4. When your app adds a donation to a cart, checkout, or order, include the unique donation ID in the catalogReference object's options property. For example: "options": { "donationId": "bf3b953d-d0b7-4755-a54e-13c167fc4484"}.
  5. When Wix calls your Get Catalog Items method to retrieve current information on the donation, it provides the catalogReference for the item, including the unique donationId. On the basis of this ID, the method returns the full details for the specific donation, which can then be added to the cart, checkout, or order.

If you take this approach, make sure that:

  • You implement an API for creating item variants. Your API must receive the required variant details, store them, and generate a unique ID for each item variant.
  • When your app adds an item to a cart, checkout, or order, the options property of the item's catalogReference contains a field with the item variant ID your API generated.
  • Your Catalog service plugin implementation expects and handles the unique item variant IDs it receives in the options object, and returns the correct item details.

Use this approach if:

  • You don't mind storing details for every variant a client selects, including those that don't result in a purchase.
  • You prefer to implement a formal API that enforces structure and validates all variants before they are included in a request to the catalog.
Did this help?

Did this help?