Move SKUs and groups across the catalogue tree
Reorganise the catalogue by moving a SKU to a different group or a group to a different sub-category, staying within the same category type.
Clients can reorganise the catalogue by moving a SKU to a different group (sku/update with a new group) or moving a group to a different sub-category (sku_group/update). Both moves are validated against the category TYPE, not the category: the source and destination must resolve to the same category type, otherwise the API rejects with CANNOT_CHANGE_GROUP_TO_DIFFERENT_CATEGORY_TYPE or CANNOT_CHANGE_SKU_SUB_CATEGORY_TO_DIFFERENT_CATEGORY_TYPE. This is because the category type fixes the pricing dimension and functional behaviour of everything under it - so a wardrobe-type SKU can move between wardrobe categories but can never become, say, a hardware SKU by moving. One silent side effect: when a group is moved to a sub-category under a different category, any tags attached to it that are not valid for the new category type are automatically removed during the move, with no warning in the response. If a client reports tags missing from a group, ask whether the group was recently moved. Moves refresh the catalogue search index and hierarchy caches in the background; if search results briefly show the old location, that is index lag, not data loss - the tree view is authoritative.
The move is done from the SKU's Edit SKU menu.
✓ 10 ਅਕਤੂਬਰ 2026 ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਜਾਂਚਿਆ ਗਿਆThe SKU's Edit SKU menu offers separate options to clone a SKU to the same group, to a new group, to any group, or to move it to an existing group.
✓ 10 ਅਕਤੂਬਰ 2026 ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਜਾਂਚਿਆ ਗਿਆChoosing the move option and picking the target group relocates the SKU rather than copying it.
✓ 10 ਅਕਤੂਬਰ 2026 ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਜਾਂਚਿਆ ਗਿਆThe move is reached from the SKU's settings (cog) menu via 'Move SKU to existing Group', where you pick the destination group.
✓ 10 ਅਕਤੂਬਰ 2026 ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਜਾਂਚਿਆ ਗਿਆA whole group moves through 'Move Group' in the group's own menu.
Both the model number and the group name are compulsory fields when creating or cloning a SKU, so a value must be entered for each before submitting.
✓ 10 ਅਕਤੂਬਰ 2026 ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਜਾਂਚਿਆ ਗਿਆTag eligibility is enforced continuously, not just at attach time. When someone changes the category type of a user-created category, or moves a group under a sub-category with a different category type, every tag assignment that becomes ineligible is identified at all four levels — category, sub-category, group and SKU — and deleted as part of the change. The UI calls a preview endpoint first so the user is warned which tag/item pairs will be dropped, but once confirmed the removal is permanent. This is the usual answer to 'our tags disappeared from a whole category': check whether the category's type was changed or the group was moved recently. Tags with no category-type restriction are never affected — only restricted tags whose applicability list doesn't include the new category type. There is no undo; the assignments must be re-created manually after the category type is corrected, so warn clients to review the invalidation list carefully before confirming a category-type change.