/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 thecustom 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.Price fields in responses
A price field contains the standard price and the list of scheduled promotional prices. The listscheduledPrices is always present. If no promotional prices are maintained, it is delivered as an empty array.
Response (excerpt)
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.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 fieldscheduledPrices 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 laterstartDate 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.
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 in400 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 thesubshopId 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.
Example
Response
Filter fields
All product data fields can be filtered. User-defined fields have thecustom. prefix, for example filter_eq[custom.brand]=Barbour.
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 typesList, 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 thewithExternData=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. Thesize 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 therules parameter. To be interpreted correctly, this parameter must be URL-decoded.
- The field
activemust have the valuealways.
Only permanently active products are considered. - The article number (
itemNumber) must contain the digit “5”.
Only products whose article number contains a “5” somewhere are selected (for example11-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
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}
Theproducts/{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}
Theproducts/{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 parametercreateMissing=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 theproducts/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 thetextSearch 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, thesingleOption=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 anid 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.
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 itsid 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, thesingleOption=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 returnsnull 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 underselection.
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 typeconflict. 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, anid 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 theproductId, 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 uniqueinventoryId.
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.
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
amountTypeis set torelative, the current inventory is increased by the givenamountor — if the value is negative — decreased. Otherwise, the inventory is set to the value ofamount. openOrderTypeworks correspondingly: if it is set torelative, the number of open orders is increased or decreased (with a negative value) byopenOrder. Withoutrelative,openOrderis set directly.
{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 itsid (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
amountTypeis set torelative, the current inventory is increased by the givenamount. With a negative value, it is decreased. Otherwise, the inventory is set to the value ofamount. openOrderTypeworks correspondingly. If it is set torelative, the number of open orders is increased byopenOrderor decreased with a negative value. Withoutrelative,openOrderis set directly.- If no inventory exists yet for an
id, it is created by default, provided a product or variant of the subshop references thisinventoryId. WithcreateMissing=no, only existing entries are updated.
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 thedata field is also accepted ({"data": [ ... ]}).
Response
Line-level errors do not abort the request. Valid entries are written, invalid ones are listed inskippedLines. 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 changedinventoryId. 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. ThestoreId 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. ThestoreId 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 astoreId 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 givenvariantId.
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 givenvariantId.
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 toPUT 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 viastoreId. 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 thedata field is not accepted here.
Response
Line-level errors do not abort the request. Valid entries are written, invalid ones are listed inskippedLines. In both cases, the response has status 200.
Values for errorType
Error codes
Multiple variants share one inventory
UsingstoreId, you can link multiple variants to the same inventory, for example via the EAN:
POST bulk/products/inventory is then enough to set the stock of both variants:
"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.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 withid=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 IDid=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 withid=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
Response
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
DELETE products/{parentProductId}/setproducts/{childProductId}
The product withid=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
Additional references
- API reference image converter
- API reference categories
- API reference configuration
- API reference meta data
- API reference SEO URLs
- content - catalog (categories & products)
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 thecontent.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.
