Bulk edit sales-channel prices and switch price types on a design
Edit sales-channel and price-type values for many SKUs at once and re-price an existing design by switching its price type.
Bulk editing sales-channel prices for many hardware or accessory SKUs is done by selecting the SKUs, opening the bulk edit action, editing the individual sales-channel and price-type values, and confirming the changes.
Switching the price type on an existing design re-prices it in place — the design does not have to be copied or re-modelled to be quoted at a different rate set.
A price type can be used to switch a quote on an existing design between default and franchisee prices instantly, without changing the sales channel.
A price type cannot be defined as a factor or percentage of another price type.
Each price type must be given its own per-SKU values.
A price increase is applied by editing the individual item prices rather than by setting one multiplier.
POST /price/update (also exposed under enterprise_api) updates one SKU's price. Rules enforced in code: sales_channel_id and price_type_id must be sent together or not at all — omitting both updates the org/BU default price, sending both updates that channel + price-list price; sending only one errors. price, tax, margin and display_unit are mandatory (zero is accepted; missing values return 'price, tax, margin, display_unit must be specified'); discount fields are optional. The call also accepts an optional serviceability setting ('serviceable' or 'unserviceable') that applies to the SKU + sales-channel mapping independently of the price list; it may only be sent together with a sales channel, and sending it without one is rejected. Through the enterprise API, use_referred_price is hard-coded to false, so every API update UNLINKS the sales-channel price from the default price — after an API write, later changes to the default price no longer flow into that channel price until someone re-links it in the admin portal. When the target channel + price-type had no explicit price row yet, the API creates one, copying CBU/exclusion-list/override-margin/pricing-from settings from the default price. Prices for dimensional display units must be sent in the per-millimetre basis. Failures surface as PRICE_UPDATE_FAILED, and a request naming a sales channel that has no matching SKU entry is rejected as an invalid-parameters error; authorization requires catalog-manager rights for the org or for the BU owning the sales channel, and every call is audit-logged.
Deleting a price type (price_type/remove; org- or BU-level catalog manager) is a guarded two-step flow. The default price type can never be deleted (CANNOT_DELETE_DEFAULT_PRICE_TYPES). A first call without force returns successfully_removed:false plus what blocks it: sales_channel_map_req lists sales channels where this is the ONLY mapped price type (each needs a replacement), and users_map_req lists users whose PREFERRED price type it is (num_users counts everyone mapped). The caller must resubmit with sales_channel_map and user_map supplying exactly one replacement per blocked entity — no extras, none missing, all price types belonging to the same org — otherwise INVALID_PARAMS. Gotcha: a user's replacement preferred price type must ALREADY be mapped to that user at the same level (org or BU); the API will not create the mapping and fails with INVALID_PARAMS. On success it deletes the price type, its user and sales-channel mappings, and all sales-channel SKU price mappings under it — every custom per-SKU price stored under that price list is permanently dropped (a code comment notes the underlying Price rows are left orphaned for reference reasons). Advise clients to treat price-type deletion as destructive and irreversible for that list's prices.