Updates and changes to the LodDepot API. For API documentation and support, please visit help.loddepot.com or contact support@loddepot.com.
Machine-readable version: /changelog?format=json
Items now expose a blackListMode field controlling how the item's customer/user list is applied: BLACK (default) hides the item from the customers and users on the list, WHITE makes the item visible ONLY to the customers and users on the list (with an empty list, a WHITE item stays visible to everyone; WHITE items are always hidden on public catalog links). Item responses include blackListMode; POST api/v1/Item accepts it to set the mode, and POST api/v1/ItemBulk accepts blackListMode with blackListModeSpecified: true to change it for many items at once. The list itself is still managed with the existing customerBlackListIdsAdd / customerBlackListIdsRemove / customerBlackListClear fields.
The itemVariants array on item responses now includes quantityOnHand — the variant's stock on hand (omitted when not set). POST api/v1/Item now accepts an itemVariants array to update variant stock: each entry needs variantCode and quantityOnHand, e.g. "itemVariants":[{"variantCode":"BGL","quantityOnHand":25}]. Only the stock quantity of existing variants is updated — other variant fields are left unchanged, entries with an unknown variantCode are ignored, and variants cannot be created or deleted through the API (variants are managed in the LodDepot portal). Variants not included in the request are left untouched.
POST api/v1/SalesOrder now performs an update when orderId or salesOrderGuid identifies an existing order (when both are sent, orderId wins); requests without an identifier keep creating new orders. Update rules: omitted fields are left unchanged (fields cannot be cleared); customer is ignored on update — an order cannot be moved to another customer; items are merged by itemId — a matching line is updated, an unmatched line is added, a line sent with quantityUnit: 0 is removed, and lines not included in the request are left untouched (omit items entirely for a header-only update); address, when provided, replaces the ship-to address (send an empty address object {} to remove it, omit to keep it). An unknown orderId returns an error; an unknown salesOrderGuid still creates a new order with that ID. Note: previously a request re-using an existing salesOrderGuid returned an error — such a request now updates that order. Updates trigger the SALESORDER.UPDATE webhook and ERP re-sync.
Item responses now include the read-only itemVariants field — an array of the item's active variants: [{"itemVariantId":123,"variantCode":"BGL","variantDescription":"Brooklyn Gray L","quantityOnHand":25.0,"productCode":"012345","refNumber":"..."}] (omitted when the item has no variants; variants are managed in the LodDepot portal). Sales order line items now include an itemVariants array holding the selected variants with quantities: [{"variantCode":"BGL","variantDescription":"Brooklyn Gray L","quantity":2}] — variantCode is the variant identifier on order lines. POST api/v1/SalesOrder accepts itemVariants on order lines in the same format; quantities are in the line's selling unit.
Item responses now include the itemWarningText field containing the product warning text entered in LodDepot (Item Information/Warning Text; HTML allowed, returned exactly as entered; null when not set). POST api/v1/Item also accepts itemWarningText on create and update — omitting the field leaves the stored value unchanged. Bulk updates via POST api/v1/ItemBulk already supported this field.