Skip to main content
The /products endpoint provides an interface to manage product data and inventory in our shop system. You can use it to create, edit, filter, retrieve and delete products as well as retrieve, update and delete inventory information for products. It also covers variant attributes, product variants and set products. Bulk endpoints are available for larger volumes of data. The following overview shows which endpoints support which methods. The page then describes the data fields and time-controlled prices. After that, the individual endpoints are described, grouped by products, variant attributes, product variants, inventory and set products.

Supported methods

Data fields

Fields are managed in the configuration and stored as a JSON object in the table. A distinction is made between standard product data fields and user-defined product data fields. User-defined product data fields can be created freely, while standard product data fields are predefined by the shop and are always defined. All user-defined product data fields are found in the custom section. All other entries represent standard product data fields. The fields statistics, statisticsPerPoint and ratingApprovalConfig are only returned by GET products/{productId}. The list query GET products does not contain them.

Example record

Time-controlled prices (promotional prices)

Products can carry prices with a validity period. This allows promotional prices to be maintained in advance, without requiring an import or a manual change at the start of the promotion. This section first describes the format of the price fields in responses, then the permitted format in requests, then the effect in the shop, and finally the validation. If you only want to know what needs to be changed in existing integrations, the short answer is in the following notice.
Breaking change in responses. Every field of type Price is no longer delivered as a string in product responses, but as an object. Affected are the base field price and all custom price fields. Integrations that further process the price directly as a string must be adjusted. The change affects all endpoints that deliver product data, so the query of individual products, list queries, the responses of Create and Update as well as the bulk endpoints.

Price fields in responses

A price field contains the standard price and the list of scheduled promotional prices. The list scheduledPrices is always present. If no promotional prices are maintained, it is delivered as an empty array.

Response (excerpt)

Before this change, at the same location there was a plain string:

Parameter overview

The period is inclusive at both ends. An entry with endDate set to 2026-08-31T23:59:59.000Z is still active at exactly that second.
For product variants, a price field can also be null. The type of a price field for integrations is therefore object | null. When this case occurs is described in the section Methods for product variants.

Price fields in requests

For incoming requests, the interface remains backwards compatible. A price field may still be passed as a plain string. Existing write accesses therefore continue to work unchanged. Adjustments are only needed for anyone who wants to maintain promotional prices via the interface. Alternatively, the interface accepts the object in the same structure in which it delivers it. If the field scheduledPrices is not sent, existing entries are preserved. An empty array passed in deletes all entries.

Request body (excerpt)

Effect in the shop

At any point in time, exactly one price is resolved. The resolution happens anew on every request; no price is pre-calculated and stored. Which price applies is decided by three rules. First, a promotional price only takes effect if it does not exceed the standard price. Entries above the standard price are skipped during resolution. In that case the standard price remains valid. Second, with several entries active at the same time, the lowest price is used. In case of equal price, the entry with the later startDate wins, so an open start loses. If the start times are also equal, the order in the array decides. Third, an own price field on a variant replaces both the standard price and the schedule of the base product together. More on this in the section Methods for product variants.
Validation does not check a promotional price against the standard price. An entry above the standard price is stored and delivered again in the response, but never takes effect. This also applies retroactively. If the standard price is later lowered below an existing promotional price, that entry silently loses its effect.
For the search index, a restriction applies. Price fields are indexed exclusively with their standard price. Scheduled promotional prices are not available in the index and can therefore not be filtered or sorted.

Validation and error keys

Each entry is checked individually. Faulty entries result in 400 Bad Request. The error key contains the index of the affected entry in the array. Only the entry itself is checked. A comparison with the standard price or with other entries does not take place. Overlapping periods and prices above the standard price therefore do not cause an error, but only take effect during resolution. Which entry then applies is described in the section Effect in the shop.

Note on the internal storage format

For tools that operate directly on the stored data blob of a product or category, a special case applies. There, the two wrappers carry a different name than in the REST contract. The inner keys of an entry are identical. Both read paths additionally accept the old format as a plain string. Existing data does not have to be migrated for this.

Methods for products

The endpoints documented here allow read, write, change and delete access to product data in the shop system. They can be used to manage the product catalog, both for initial population and for ongoing updates of content. In addition, endpoints are available to perform product searches based on defined rules. Since each subshop has its own product set, URLs must contain the subshopId parameter. A valid authentication is required for all endpoints. The respective permissions to read, write, create or delete products must be available.

GET products

This endpoint can be used to retrieve a list of all products in the system. Optionally, the result set can be restricted using filter parameters, for example to products assigned to a particular category (inCategory) or to be excluded from a particular category (notInCategory). Both parameters must not be used at the same time. To use this endpoint, the corresponding permissions to read products must be available.

Ordering with inCategory

If inCategory is used and no explicit sort parameter is specified, the endpoint returns the products exactly in the category order maintained in the shop. GET products?inCategory={categoryId} and GET categories/{categoryId}/products are equivalent here: internally, the category endpoint sets nothing other than inCategory and evaluates the same code. So there is no reason to switch to the other endpoint to get the category order.
As soon as you set a sort parameter yourself, the category order no longer applies to either of the two endpoints. Your sorting replaces it completely. If you need the original order, simply omit sort.

Example

Response

Filter fields

All product data fields can be filtered. User-defined fields have the custom. prefix, for example filter_eq[custom.brand]=Barbour.
Filterable does not mean “combinable with every operation”: which filter operations are permitted depends on the data type of the field. On an enum field such as active, for example, only eq and neq are permitted, contains leads to 400 Bad Request with type illegalOperation. The complete matrix can be found in API basics: Permitted operations per field type.
In addition to the product data fields, the following filters are available as plain query parameters (without the filter_ prefix and without brackets): The attributes inCategory and notInCategory, or inSetProduct and notInSetProduct, must not be set at the same time (error invalidCombination). The same applies to notInAnyCategory=true in combination with inCategory or notInCategory.

Sort fields

All product data fields except the types List, Map, Image and Video. Sorting by these types leads to an error message 400 Bad Request with type invalidValue. Syntax: sort=<field-name>:asc or sort=<field-name>:desc. The field name is mandatory. A short form such as sort=asc is a syntax error. Multiple sort criteria are passed via multiple sort parameters. For more information, see API basics: Sorting.

Other parameters

The following query parameters are also available:

Error codes

GET products/{productId}

This endpoint can be used to retrieve the complete data of a single product. Specify the product ID as a path parameter. In addition to the base data, user-defined fields are also returned. To use this endpoint, the corresponding permissions to read products must be available.

Example

Response

Error codes

GET products/{productId}/url

This endpoint can be used to retrieve the full URL of a product. To use this endpoint, read permissions for product data are required.

Example

Response

Error codes

GET products/{productId}/categories

This endpoint lets you retrieve the categories (product groups) to which a product is assigned. The categories are listed in the order in which the assignments were created. The list is not paginated but always contains all categories of the product. Each entry has the structure of a category from the API reference categories. With the withExternData=yes parameter, each entry additionally includes _parent and _children. To use this endpoint, the corresponding permissions to read categories are required.

Example

Response

Error codes

GET products/testRule

This endpoint can be used to selectively retrieve products that match one or more specified rules. The rules are provided as a JSON-formatted array in the query URL and allow flexible filtering by product fields such as activity status, article numbers or price values. The rules may only contain valid fields and allowed operators. To use this endpoint, the corresponding permissions to read product data must be available. The size parameter is mandatory and must contain a value between 1 and 1000. The value of a rule must always be a string, even for numeric values.

Example

The rules are encoded in the URL as a JSON array and passed via the rules parameter. To be interpreted correctly, this parameter must be URL-decoded.
The URL queries products that meet two conditions:
  1. The field active must have the value always.
    Only permanently active products are considered.
  2. The article number (itemNumber) must contain the digit “5”.
    Only products whose article number contains a “5” somewhere are selected (for example 11-2518).
Filters and sortings on price fields access the standard price. Scheduled promotional prices are not taken into account.

Response

Possible values for mode

gt (greater), gte (greater or equal), lt (less), lte (less or equal), eq (equal), neq (not equal), contains (contains), notcontains (does not contain), begins (begins with), ends (ends with), within (list value contained), notwithin (list value not contained)

Error codes

POST products

The /products endpoint can be used to create new products in the shop system. All product information required for creation must be provided in the request body. The response contains the complete product data of the newly created product in JSON format. If the provided product ID is already in use, the shop rejects the request with status 409 Conflict. An existing product is not overwritten. To create a product, the corresponding permissions are required. With the optional parameter updateIndex=yes, the search index for the product is updated immediately. Without this parameter, the next scheduled run performs the update.

Example

Request body

The price may be passed as a string, as in the example. To maintain promotional prices at the same time, use the object form described in the section Price fields in requests.

Response

Error codes

Errors in scheduled promotional prices are reported per entry. The keys are described in the section Validation and error keys. If an entry in the set field refers to a non-existent product, the shop rejects the request with status code 400 Bad Request and type “notFound”. The error key is set[<i>].id, where <i> is the index of the entry in the array.

PUT products/{productId}

The products/{productId} endpoint can be used to update product data. If a product with the given ID is not found, a new product can be created automatically if the createMissing=yes parameter is set. Only the fields that are to be changed need to be specified in the request body. Fields that are not submitted keep their value. The set field replaces the members of a set product as a whole. With the optional parameter updateIndex=yes, the search index for the product is updated immediately. The optional set field can be used to assign other products to a set together with the current one. Alternatively, the set product endpoints can be used. To edit or create a product, the corresponding permissions are required.

Example

Request body

Response

The response does not contain a set price. It is not stored but calculated on demand. How to retrieve it is described in the section POST products/setproducts/preview.

Error codes

DELETE products/{productId}

The products/{productId} endpoint can be used to permanently delete a product with the specified ID. This process completely removes the product, including its variants, from the system. Orders that contain the product retain their data. With the optional parameter updateIndex=yes, the search index is updated immediately. To delete a product, the corresponding permissions are required.

Example

Response

Error codes

Bulk methods for products

This section describes the bulk endpoints that can be used to query or process multiple records in a single request.

POST bulk/products

Allows mass creation and updating of product data in a single request. The request body is a JSON array in which each element describes a product with an ID. Create and write permissions for products are required. By default, only products are updated. If the parameter createMissing=yes is set, products from the request that do not yet exist are automatically created. A maximum of 1000 entries can be processed in one request. This limit applies jointly to all bulk endpoints of the API. For more information, see API basics: Bulk endpoints. Errors at line level do not abort the request. Invalid or skipped entries appear in the response under skippedLines with lineNumber (counted from 0), productId, errorType (for example notFound or invalidParameters) and fieldErrors. The IDs of the written products are listed under items.

Example

Request body

Response

Error codes

Methods for variant attributes

The endpoints in the products/variants/ area let you manage variant attributes and the related options used to form product variants in your shop. You can add new attribute options, adjust existing ones or delete attributes. You can also change the display order of the options (see PUT products/variants/{attributeId}/positions) or query individual options. For all endpoints documented here, a valid authentication is required. In addition, you need the permissions to read, create, edit or delete product variants.

GET products/variants

This endpoint can be used to retrieve a list of all variant attributes defined in the shop system and their available options. The response tells you which attribute names (for example “Size”, “Colour”) are used and which values are available per attribute. This is particularly helpful for creating or editing product variants. A valid authentication is required for this endpoint. You must have permission to read product variants. With the textSearch parameter, you can restrict the list to attributes whose name or options contain the specified text.

Example

Response

Error codes

GET products/variants/{id}

This endpoint can be used to retrieve either a variant attribute with its associated options or a single variant option. If an attribute name (for example “Colour”) is provided in the URL, the response returns all options for this attribute. If an option ID is provided instead, the singleOption=yes parameter must additionally be set in order to retrieve the data of a specific variant option. The search by attribute name is case-insensitive. To use this endpoint, a valid authentication is required. You also need permission to read product variants.

Example (attribute)

Response (attribute)

Example (option)

Response (option)

Error codes

POST products/variants

This endpoint creates a new variant attribute with arbitrary option values. If the attribute already exists (case-insensitive), it is supplemented by the new options that did not exist before. If one of the provided options already exists for the attribute, the operation is aborted with a conflict error (409). To use this endpoint, a valid authentication is required. You also need permission to create product variants.

Example

Request body

Response

Error codes

PUT products/variants/{attributeId}

This endpoint updates an existing variant attribute. The search by attribute name is case-insensitive. New options can be added and existing ones can be edited. An option with an id is renamed, an option without an id is created and placed after the existing options. The renaming is applied to all products that use the option. Renaming the attribute is possible via the optional newAttributeName field in the request body. Existing options not included in the request body remain unchanged and keep their position. With the query parameter complete=true, you specify that options is the complete list of all options of the attribute. In that case, the following also applies:
  • Options missing from the request are removed.
  • All options are placed in the order of the request.
  • If an option to be removed is still used by a product, the shop rejects the entire request without changing anything. The response lists the affected products.
To change only the order, use PUT products/variants/{attributeId}/positions. To use this endpoint, a valid authentication is required. You also need permission to write product variants. With complete=true, you additionally need permission to delete product variants, because options can be removed in the process.

Query parameters

Example

Request body

Response

Error codes

PUT products/variants/{attributeId}/positions

This endpoint lets you define the order in which the options of a variant attribute are offered. The options are placed in the order of the request. Options missing from the request follow afterwards in their previous order. Names and the options themselves do not change. The search by attribute name is case-insensitive. You specify each option by its id or by its name in option. If both are specified, the id takes precedence. To use this endpoint, a valid authentication is required. You also need permission to write product variants.

Example

Request body

Response

The response contains the attribute with all options in the new order.

Error codes

DELETE products/variants/{id}

This endpoint lets you delete either a variant attribute together with all its options or a single option. If the attribute is currently still used by a product, the operation is aborted with a conflict error. To use this endpoint, a valid authentication is required. You also need permission to delete product variants. If an attribute name is provided in the URL, the attribute and all its options are deleted. The search by attribute name is case-insensitive. If an option ID is provided instead, the singleOption=yes parameter must additionally be set in order to delete only this single option.

Example (attribute)

Response (attribute)

Example (option)

Response (option)

Error codes

Methods for product variants

The following endpoints let you manage product variants within an existing product. Variants represent specific instances of a product, for example sizes or colours, and are based on the previously defined variant attributes. The API lets you retrieve, create, update or delete variants individually. In addition, you can retrieve the variant attributes of a product, set them and change their order. Most endpoints in this section check the read, create or write permissions for product variants. Three endpoints, however, require permissions for products: deleting a variant requires the delete permission for products, retrieving the variant attributes requires the read permission, and moving a variant attribute requires the write permission. Variants also carry their price as an object. If a variant sets its own price field, this replaces both the standard price and the schedule of the base product. A variant with its own price and no promotional prices therefore does not inherit the promotion from the base product. If a variant does not set its own price field, the response returns null for this field and not the value of the base product. Integrations must handle this case; the type is object | null.

GET products/{productId}/variants

This endpoint can be used to load a list of all variants for the specified product. Variants are product versions that differ from the main product by different attribute combinations (for example size or colour). The response contains basic product data as well as the associated attribute values under selection. To use this endpoint, the corresponding permissions to read product variants are required. The response is paginated. Use size to specify how many variants a page contains (default value 10). To retrieve the next page, pass the value from nextPageToken of the previous response unchanged in the pageToken parameter. With the textSearch parameter, you can restrict the list to variants whose name, description or attribute values contain the specified text.

Example

Response

Error codes

GET products/{productId}/variants/{variantId}

This endpoint can be used to load a specific product variant by its ID within a product. The product ID is provided as part of the URL, as is the variant ID. The response contains the corresponding variant data including price, article number, selection attributes (selection) and other detail information. To use this endpoint, the corresponding permissions to read product variants are required.

Example

Response

Error codes

PUT products/{productId}/variants/{variantId}

This endpoint can be used to update the data of a specific product variant using its product ID and variant ID. The variant is identified by the given IDs. Fields that are not specified in the request body keep their value. The attribute combination (selection) must not be included in the request body and cannot be changed. To use this endpoint, write permissions for product variants are required.

Example

Request body

Response

Error codes

GET products/{productId}/variantAttributes

This endpoint can be used to retrieve the variant attributes of a product in the order in which they are offered. Each entry contains the name of the attribute (name) and its position (position, counted from 0). The response is not paginated and endReached is always true. To use this endpoint, read permissions for products are required.

Example

Response

Error codes

POST products/{productId}/variantAttributes

This endpoint sets the list of variant attributes of a product by which its variants differ. Each attribute provided must exist in the shop with at least one option (see POST products/variants). The endpoint itself does not create any variants. Specific variants are created via the endpoint POST products/{productId}/variants/manage. If the product already has variant attributes and attributes are added or removed, the operation is aborted by default with a 400 error of type conflict. The reason is that all existing variants would be lost. To bypass this abort, the optional force=yes parameter can be used. In this case, all previous variants of the product are deleted and the options of the attributes on the product are reset. If the product did not yet have any variant attributes, the attributes are set without a conflict. To use this endpoint, create permissions for product variants are required.

Example

Request body

Response

Error codes

POST products/{productId}/variantAttributes/move

This endpoint can be used to move a variant attribute of a product to a new position. The position determines the order in which the attributes are offered. The product must have at least two variant attributes. To use this endpoint, write permissions for products are required.

Example

Request body

position is counted from 0 and must be less than the number of variant attributes of the product.

Response

Error codes

POST products/{productId}/variants/manage

This endpoint lets you create specific variant combinations for an existing product in a targeted manner. The variant attributes of the product must first be set via the API using POST products/{productId}/variantAttributes. Only the explicitly provided combinations are created. Already existing combinations are skipped and do not appear in the response. Optionally, an id for the new variant can be provided per entry. If it is missing, the shop assigns an ID. The endpoint is particularly suitable if not all theoretically possible combinations of a product are needed, but only a specific selection. To use it, create permissions for product variants are required.

Example

Request body

Response

Error codes

DELETE products/{productId}/variants/{variantId}

This endpoint can be used to delete an existing product variant by product ID and variant ID. This is useful, for example, when certain combinations of variants (for example size and colour) should no longer be offered. Both the parent product and the variant must exist — otherwise a corresponding error is returned. To use it, delete permissions for products are required.

Example

Response

Error codes

Bulk methods for variants

This section describes the bulk endpoints that can be used to query or process multiple records in a single request.

POST bulk/products/variants

Allows mass creation and updating of product variants in a single request. The request body is a JSON array in which each element describes a product variant. Create and write permissions for product variants are required. For each entry, the respective product variant is identified by the productId, variantId and selection fields. To update a variant, productId together with selection or variantId is sufficient. When creating a new variant, selection is mandatory; if variantId is also provided, the new variant is created with this ID. By default, only product variants are updated. If the parameter createMissing=yes is set, product variants from the request that do not yet exist are automatically created. With the parameter updateIndex=yes, the search index is updated immediately. A maximum of 1000 entries can be processed in one request. This limit applies jointly to all bulk endpoints of the API. Details can be found in API basics: Bulk endpoints.

Example

Request body

Response

Error codes

Methods for general inventory

The following endpoints let you retrieve, create, update and delete inventories in the system. Each inventory is identified by a unique inventoryId. Depending on the endpoint, inventories can be set directly or changed relatively, for example when booking additions or removals. For all endpoints documented here, a corresponding permission to access inventories is required. All endpoints in this section support the optional URL parameter storageId, with which the storage ID can be specified explicitly. If this parameter is not set, the storage ID of the active subshop is used automatically.

Where does the inventoryId come from?

The inventoryId is the key of the inventory entry. When a product or variant is created, the system automatically creates an inventory entry with a default key: So you do not have to query the inventoryId separately; for the standard case, you can assemble it from the product and variant ID.
The default key is merely the initial value and does not represent a guarantee. The inventoryId of a product can be overridden. That is exactly what it is there for: multiple products or variants can share the same inventory by referring to the same inventoryId. To find out which inventoryId is actually assigned to a product, read the storeId field via the method GET products/{productId}/inventory. In integrations that work on maintained shops, do not blindly rely on the default scheme.
For the same reason, the examples in this section (for example 11-1701 M) deviate from the default scheme. They show a shop in which custom inventory keys are maintained.

GET products/inventory/{inventoryId}

This endpoint can be used to retrieve the inventory of a product or product variant by the inventory ID (inventoryId). The response contains information about the current stock, open orders and the time of the last update. To use the endpoint, the corresponding permissions to read inventories must be available.

Example

Response

Error codes

POST products/inventory

This endpoint creates a new inventory for a product or product variant. A unique inventory ID (id) is provided as well as the available and open quantities. To use this endpoint, the corresponding permissions to create inventories must be available.

Example

Request body

Response

Error codes

PUT products/inventory/{inventoryId}

This endpoint updates the inventory of a specific product using the supplied parameters. You can adjust both the stock (amount) and the number of open orders (openOrder) — either absolutely or relatively:
  • If amountType is set to relative, the current inventory is increased by the given amount or — if the value is negative — decreased. Otherwise, the inventory is set to the value of amount.
  • openOrderType works correspondingly: if it is set to relative, the number of open orders is increased or decreased (with a negative value) by openOrder. Without relative, openOrder is set directly.
If no inventory exists for the given {inventoryId}, the optional URL parameter createMissing=yes can be used to automatically create a new entry. To use this endpoint, you need permission to write inventories.

Example

Request body

Response

Error codes

DELETE products/inventory/{inventoryId}

This endpoint deletes the inventory of a product for the given {inventoryId} in the current subshop. If no corresponding entry exists, an error is returned. To use this endpoint, you need permission to delete inventories.

Example

Response

Error codes

POST bulk/products/inventory

This endpoint lets you create or update multiple inventories in a single request (upsert). Each entry in the request body is addressed by its id (inventory ID, see Where does the inventoryId come from?). For each entry, you can adjust the stock (amount) and the number of open orders (openOrder) either absolutely or relatively:
  • If amountType is set to relative, the current inventory is increased by the given amount. With a negative value, it is decreased. Otherwise, the inventory is set to the value of amount.
  • openOrderType works correspondingly. If it is set to relative, the number of open orders is increased by openOrder or decreased with a negative value. Without relative, openOrder is set directly.
  • If no inventory exists yet for an id, it is created by default, provided a product or variant of the subshop references this inventoryId. With createMissing=no, only existing entries are updated.
To use this endpoint, you need permission to write inventories.
The endpoint expects POST, even when existing inventories are updated. This applies to all bulk endpoints. A PUT to bulk/products/inventory is not answered. The request goes nowhere without the inventories changing.
Changed default behavior. Previously, missing inventories were only created with createMissing=yes. Creating them is now the default. Integrations that call the endpoint without createMissing and rely on unknown IDs not being created must send createMissing=no.
A maximum of 1000 entries can be processed in one request. This limit applies jointly to all bulk endpoints of the API. For more information, see API basics: Bulk endpoints. If there are more entries, the entire request is rejected and nothing is written.

URL parameters

Existing entries are always updated, even if no product references them. requireReference only applies when creating entries. If you deliberately want to create the inventory before the associated product exists, send requireReference=no.

Fields per entry

At least amount or openOrder must be specified. A field that is not specified remains unchanged. If an entry is newly created, a relative change counts from 0: {"id": "4800", "amount": 5, "amountType": "relative"} results in an entry with amount = 5. A field that is not specified is created with 0. All fields of an entry are checked before writing. An invalid entry is skipped completely, even if individual fields are valid.

Example

Request body

The request body is a JSON array. For compatibility reasons, an object with the array in the data field is also accepted ({"data": [ ... ]}).

Response

Line-level errors do not abort the request. Valid entries are written, invalid ones are listed in skippedLines. In both cases, the response has status 200.

Values for errorType

Back-in-stock

After every successful change, back-in-stock notifications are generated for all products and variants that reference the changed inventoryId. If back-in-stock is disabled in the shop, this step is skipped.

Error codes

Methods for product inventory

The following endpoints let you manage stock-related settings for individual products. This includes both the assignment to an inventory entry and the configuration of the display in the shop, such as colored traffic-light logic, custom inventory messages and reservation times. The settings directly access the general inventories maintained via the endpoints from chapter 6. For access to these endpoints, read or write permissions for product data are required, depending on the chosen operation.

GET products/{productId}/inventory

This endpoint can be used to retrieve the inventory configuration of a specific product. This configuration includes, among other things, thresholds for traffic-light colors, custom inventory messages and the reservation duration. The storeId reference points to a general inventory entry, as managed via the inventory endpoints. To use this endpoint, read permissions for product data are required.

Example

Response

Error codes

PUT products/{productId}/inventory

This endpoint is used to update the inventory settings of a product. It lets you adjust, for example, the display in the shop (traffic-light logic), inventory messages or the reservation time. The storeId setting remains unchanged and does not need to be provided. To use this endpoint, write permissions for product data are required.

Example

Request body

Response

Error codes

Methods for variant inventory

This chapter describes the endpoints for managing stock-related settings of individual product variants. As with products, you can also define specific inventory displays, traffic-light limits, custom texts and reservation times for variants. The assignment is also done via a storeId that references a centrally maintained inventory. For access, the corresponding read or write permissions on product variants are required.

GET products/{productId}/variants/{variantId}/inventory

Retrieves the inventory settings of the product variant with the given variantId. The settings include, among other things, traffic-light limits, availability display, email notifications as well as the reference (storeId) to the associated central inventory. For this query, read permissions on product variants are required.

Example

Response

Error codes

PUT products/{productId}/variants/{variantId}/inventory

Updates the inventory settings of the product variant with the given variantId. The configurations directly affect the display in the shop and control, for example, the availability display. The link to the central inventory is established via the storeId field. For this operation, write permissions on product variants are required.

Example

Request body

Response

Error codes

Bulk methods for inventory settings

The following endpoint lets you maintain the inventory settings of multiple products and variants in a single request. It is the bulk counterpart to PUT products/{productId}/inventory and PUT products/{productId}/variants/{variantId}/inventory.

POST bulk/products/inventoryConfig

This endpoint lets you create or update the inventory settings of multiple products and/or variants (upsert). This includes traffic-light thresholds, texts, inventory messages, reservation times and the link to an inventory via storeId. A request may contain a mix of products and variants. Since a request can contain products and variants, you always need write permissions for product data and for product variants. The permission is checked once for the entire request. A maximum of 1000 entries can be processed in one request. This limit applies jointly to all bulk endpoints of the API. For more information, see API basics: Bulk endpoints. If there are more entries, the entire request is rejected and nothing is written.

URL parameters

Addressing

A product and its variants may occur in the same request. However, the same combination of productId and variantId may only be included once.

Settings fields

All settings fields are optional. Fields that are not specified keep their stored value. The same fields and checks apply as for the individual endpoints. The product or variant must already exist. If no inventory settings exist for it yet, they are created with default values and supplemented with the values from the request. As with the individual endpoints, the search index is not updated.

Example

Request body

The request body must be a JSON array. An object with the data field is not accepted here.

Response

Line-level errors do not abort the request. Valid entries are written, invalid ones are listed in skippedLines. In both cases, the response has status 200.

Values for errorType

Error codes

Multiple variants share one inventory

Using storeId, you can link multiple variants to the same inventory, for example via the EAN:
A single entry in POST bulk/products/inventory is then enough to set the stock of both variants:
If back-in-stock is active in the shop, the notifications are generated for both variants. To remove the link of a variant again, send "storeId": "".

Typical import workflow

1

Import products

POST bulk/products creates or updates the products.
2

Set inventory settings

POST bulk/products/inventoryConfig sets the inventory settings. If required, you can link a different inventoryId via storeId.
3

Write stock

POST bulk/products/inventory writes the stock. Since requireReference is active by default, only inventoryIds that are referenced by a product or variant from the previous steps are created.
If the stock is delivered before the products, call POST bulk/products/inventory with requireReference=no.

Methods for set products

This chapter describes the endpoints for managing set products (product bundles). For access, the corresponding read, write or delete permissions on product data are required. The price of a set is not a stored value. It is calculated each time anew from the price of the main product and the prices of the sub-products. If you want to display it, retrieve it via the endpoint POST products/setproducts/preview. What this means for existing integrations is described at the end of this chapter in the section The set price is no longer stored.

GET products/{parentProductId}/setproducts

Returns a list of child products if the product with id=parentProductId has a set. Optionally, setParentProductList can contain IDs of products to whose sets the current product belongs. For this query, read permissions on product data are required. Use size to specify how many sub-products items contains. Use from to specify the starting point (counted from 0). Without size, items remains empty. totalCount and setData nevertheless contain all members of the set.

Example

Response (parent product)

Response (set child product)

Error codes

POST products/{parentProductId}/setproducts/assign

The products from the request body are assigned to the set of the product with the ID id=parentProductId. The prodId field can contain either a single string or an array of strings. Only existing products can be assigned. If one of the products is unknown, the shop rejects the entire request and assigns none of the products. For this query, write permissions on product data are required.

Example

Request body

Response

Error codes

POST products/{parentProductId}/setproducts/update/{childProductId}

Data of the product with id=childProductId in the set of the product with id=parentProductId is updated. For this query, write permissions on product data are required. All five fields id, quantityFactor, usePrice, fixQuantity and hidden must be specified in the setData object. If the id names a product other than childProductId, the member is replaced by this product.

Example

Request body

Response

Error codes

POST products/setproducts/preview

This endpoint calculates the price of a set product from the provided values and returns the result. It stores nothing. This allows the set price to be displayed already during editing, that is before the product is saved. Two values are calculated. setPrice is the sum of the price of the main product and the prices of all sub-products with usePrice. setOrgPrice is the sum of the price of the main product and the prices of all sub-products, and serves as a reference price. The prices are resolved as of the current point in time, so active promotional prices flow into both values. For this query, write permissions on product data are required.

Example

Request body

Unknown IDs in setProducts are skipped without triggering an error. A typo in setProducts[].id therefore does not result in 404, but in a response with a price that is too low. Check the IDs before the call.

Response

Both values are strings. The response in the example results from a price of 4.99 for P1 and 9.99 for P2. setPrice contains the main product and twice P1, so 19.99 plus 9.98. In setOrgPrice, P2 is additionally included because all sub-products flow into it. If all sub-products have usePrice, both values are equal.

Error codes

Removed endpoint. The previous endpoint PUT products/{childProductId}/setproducts/recalculate is no longer available. It calculated and stored the set price. Its replacement is POST products/setproducts/preview, which only calculates.

DELETE products/{parentProductId}/setproducts/{childProductId}

The product with id=childProductId is removed from the set of the product with id=parentProductId. If childProductId=all, all products are removed from the set. If parentProductId=all, the product with id=childProductId is removed from all sets in which it is contained. For this query, delete permissions for product data are required.

Example

Response

Error codes

The set price is no longer stored

The set price is no longer a stored value; it is calculated on demand. The implicit recalculations when creating, updating, and deleting products, in the bulk endpoints, and in the product import have been removed. For clients, this means two things. First, no endpoint delivers a stored set price any longer. Second, a client that wants to display the set price must have it calculated via the endpoint POST products/setproducts/preview.
In the shop, the set price continues to be calculated on every page load. The fields on the template object have changed for this; setPrice and the associated fields are now only available on set products. What this means for existing templates is described in the section Changes to existing templates.

Removed fields

The removal of double_setPrice affects all queries, filters and sortings that use this index field. Existing integrations must be reviewed and adapted before the update.

Additional references

Note about product data fields

New product data fields (additional properties, attributes or technical fields) cannot be created directly via the product API. The API is exclusively used to read and maintain existing fields. To define new fields, the configuration in the content.customProductField node must be used. → content - catalog (categories & products) There you can create individual fields with type, search relevance, mandatory status and variant properties. As soon as a field has been configured there, it is automatically available in the product API afterwards, for example in GET products or POST products.

Support

Bei technischen Fragen und Hilfestellungen ist unser Support-Team für Sie erreichbar: Zum Kundenportal Bitte senden Sie uns eine möglichst detaillierte Beschreibung sowie Screenshots, Requests/Antworten, damit wir Ihre Anfrage zeitnah und zielführend beantworten können.