The Catalog refers to a store’s collection of physical and digital products. The Catalog includes all the information about a product such as MPN, warranty, price, and images.
For more information on OAuth Scopes and authentication, see our Guide to API Accounts.
Products are the primary catalog entity, and the primary function of the ecommerce platform is to sell products on the storefront and other channels.
Products can be physical or digital:
Physical - Exist in a physical form, have a weight, and are sold by merchants to ship to customers.
Digital - Non-physical products, including downloadable files (for example, computer software, ebooks, or music) and services (for example, haircuts, consulting, or lawn care).
Only one product can be created at a time.
Below is an example POST request for creating a simple product without variant options or modifiers.
To create a complex product with variant options selectable by shoppers, include a variants array in the request body.
When you create options via /products, display_type defaults to a radio button (displayed as selectable boxes in some themes).
To create a digital product (like an ebook), set type to digital.
Files can only be added to digital products via control panel or WebDav — attaching via the API is not supported. You can also set additional settings such as file description and maximum downloads in the control panel.
To add an image to a product, send a POST request to /v3/catalog/products/{{product_id}}/images.
image_file, set Content-Type header to multipart/form-data — otherwise, you will be unable to add subsequent requests.is_thumbnail to true to set the image as the thumbnail used on product listing pages.To add a video hosted on YouTube as a product video, send a POST request to /v3/catalog/products/{{product_id}}/videos.
video_id corresponds to the v parameter in the URL (Ex: https://www.youtube.com/watch?v=R12345677).To add custom fields to a product, send a POST request to /v3/catalog/products/{{product_id}}/custom-fields.
Custom field values are limited to 250 characters. For additional information on custom fields and their use cases, see Custom Fields.
To add bulk quantity-based pricing to products, send a PUT request to /v3/catalog/products/{{product_id}}/bulk-pricing-rules.
For general information and use cases for product bulk pricing, see Bulk Pricing.
BigCommerce pricing is precise up to 4 decimal places. For example:
"$ 10.99999 rounds up to $ 11"$ 10.99994 rounds down to $ 10.9999Currency display settings allow for more than four decimal places. In such cases, the additional decimal places will display as 0s.
Metafields are key-value pairs intended for programmatically storing data against a product or other entity. Data stored in metafields does not appear in the storefront or the control panel. Data not appearing in the storefront or control panel is useful when information needs to be passed back and forth between an app and BigCommerce.
To add metafields to a product, send a POST request to /v3/catalog/products/{{product_id}}/metafields.
To add product reviews to a product, send a POST request to /v3/catalog/products/{{product_id}}/reviews.
You cannot create reviews in the control panel.
Variant options are any choices that the shopper needs to make that will result in selecting a variant. Color and size are typical examples of variant options. A t-shirt can have different combinations of sizes and colors.
Example:
This example results in selecting a combination of small and red on the storefront and correlates to a product variation, also called a SKU.
Variant options:
Creating a variant option does not automatically create SKUs or build out variants. You can build out SKUs later using the Create product variants endpoint.
The following request will create options that will show on the storefront as choices selected by the customer. In a separate request, you could build out SKUs based on these variant option values or a combination of variant option values. You can use a similar request to add new choices to an existing variant.
Variants represent an item as it sits on the shelf in the warehouse or a particular saleable product. A product might be a t-shirt, while the variant would be “a small, red t-shirt.” Shoppers select variants on the storefront via product options. In the case where a product is simple, meaning it does not have any options, the product is its own variant - called a base variant. Everything you can buy should be a variant.
Creating SKU rules via the V2 API or via CSV import will alter or override any variant price or sale price added to a product via the control panel, V3 API, or Price Lists UI.
You can create variants in two ways:
From existing variant options, using Create a Product Variant endpoint.
By adding variants with options and SKUs, using Create a Product endpoint.
The example below will go over using existing variant options to create the variants.
To fetch variant information, send a GET request to /v3/catalog/products/{{product_id}}/options.
In the above response, there are two variant options of size and color with three values each.
To combine the variant option values into variants and build out SKUs use the following endpoint:
https://api.bigcommerce.com/stores/{{store_hash}}/v3/catalog/products/{{product_id}}/variants
The option_values array combines the options small and blue to create the SKU SMALL-BLUE. The ID in the option_values array is the ID from the variant option response option_values > id. The option_id is the ID of the option.
The following example creates a base product, variant options, and variants in a single call to the Products endpoint. Use this method to create a product and variants in a single call without creating variant options first (option display will default to rectangles).
Modifier options are any choices that the shopper can make to change how the merchant fulfills the product. Examples include:
Critically, the modifier will not change the SKU/variant fulfilled, and you cannot track inventory against combinations of modifier values. Modifiers typically would not change which product is “picked off the shelf” in the warehouse, but they change what happens to that product before sending it to the shopper, or how a merchant can send it.
Modifier options:
You can add an adjuster to a modifier option to change things, such as increasing the price, changing the weight, or shipping rules. You cannot apply adjusters to all modifier types.
Swatch, radio button, rectangle list, drop-down, product list, and product list with images.
The following example shows how to add a modifier and a checkbox with a price adjuster to increase the product’s price by five dollars.
Creating a checkbox with an adjuster requires two separate calls: one to create the checkbox and another one to add the adjuster. You can define adjusters within the option_values array, but option_values are not allowed in the request to create a checkbox modifier because creating a checkbox automatically generates two mandatory option values: Yes and No. Once you have created the checkbox and its option values, you can update the modifier to add an adjuster.
Swatch, radio button, drop-down, rectangle list, product list, product list with images, and checkbox.
To create a modifier, send a POST request to /v3/catalog/products/{{product_id}}/modifiers.
Since this is a checkbox with two states, you create two option values. The default adjuster_value is null.
To update the modifier value, send a PUT request to /v3/catalog/products/{{product_id}}/modifiers/{{modifier_id}}/values/{value_id}.
To fix this error:
Complex rules allow merchants to set up conditions and actions based on shopper option selections on the storefront. You can use them to vary the following based on the shopper’s option selections:
Adjustments made by complex rules are displayed to shoppers in real-time on the storefront.
For most merchant use cases, best practice will be to either assign values (such as a price) directly to a variant or use adjusters on the modifier option itself. However, complex rules exist for rare cases where a rule condition is too complex to express in those forms easily.
Use complex rules when an adjustment should be triggered by:
Complex rules must have a combination of two or more modifiers, such as two checkboxes. The following example will add $10 to the product price when you check both boxes.
Complex rules must consist of multiple conditions that trigger the rule adjustment. If multiple conditions are not specified, the request will return a 422 error.
To create a Brand, send a POST request to /v3/catalog/brands.
For general information on brands and their use cases, see Managing Brands.
Categories are a hierarchy of products available on the store, presented in a tree structure. A store’s category structure determines the primary menu structure of most storefront themes directly tied to it.
BigCommerce’s V3 REST API does not require products to be associated with a category during creation. You can add new products to a catalog without a category, which can be assigned later if desired. A store’s category can contain multiple products or no products at all and still be valid.
You can associate products with multiple categories. A product associated with categories does not currently have any priority or weighted order (there’s no “primary category”). The absence of priority or weighted order makes it difficult to integrate with some external systems that might wish to use a product’s categories to map to a category structure.
Category Tree returns a simple view of the parent > child relationship of all categories in the store. You can use this endpoint to fetch the categories if building out a custom navigation for a store.
To get an understanding of the scale of your catalog and its current contents, the Get a Catalog Summary endpoint is provided as part of the Catalog API. It provides a high level summary of all products in a store to include current inventory count, total products and variants, price ranges, and basic category data.
Product Sort Order allows you to manage the sort order of products displayed on any given category page. Products assigned to multiple storefront categories can have different sort order values per category.
The Catalog API supports two manually managed methods of product sorting: on a category level and a product level. If a user combines both sorting methods on a storefront, products with sort order values on a category level take priority. If there is no sort order value on a category level, the Catalog API sorts products by values on a product level.
Product sorting methods:
0 by default.Products with the same sort order value either on a category or a product level are sorted by product id as a second criterion.