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
itemVariants entries with a variantCode the item does not have yet are now created, on POST api/v1/Item (also for an item that this call creates) and on POST api/v1/ItemBulk. Each entry takes variantCode (required, up to 200 characters), variantDescription (up to 400 characters, defaults to the variantCode), quantityOnHand, productCode (up to 50) and refNumber (up to 400). For a variant the item already has, only quantityOnHand changes, as before: its description, product code, reference number and active status are not changed through the API, and an inactive variant stays inactive. An invalid entry (a missing or too long value, the same variantCode twice, more than 500 variants) rejects the update of that item before anything is saved; on POST api/v1/ItemBulk the item gets updateStatus ERROR with the reason in updateMessage. On POST api/v1/ItemBulk updateMessage now also tells what happened to the variants, for example Updated. Variants: 1 created, 2 stock updated., and a failure while saving variants is reported on the item instead of being ignored. The list rules are unchanged: POST api/v1/ItemBulk treats itemVariants (with itemVariantsSpecified: true) as the item's complete set, so active variants that are not in it are deactivated; POST api/v1/Item leaves variants that are not in the request untouched.
POST api/v1/ItemBulk no longer accepts shippingWeight and shippingWeightUnit (with shippingWeightSpecified / shippingWeightUnitSpecified); they are ignored if sent. Send the shipping weight of each unit of measure in unitCodes[].packaging instead (weight with weightUnit), which is what invoices, picking tickets and delivery documents use.
Each unit of measure in unitCodes now carries its shipping packaging in packaging, used for the weight and volume totals on invoices, picking tickets and delivery documents. packaging has length, width, height with dimensionUnit (IN, FT, CM, M), volume with volumeUnit (CUFT, CUIN, CBM; leave volume empty to calculate it from the dimensions), weight with weightUnit (LB, KG, OZ, G), packagingWeight (in weightUnit: the weight of a larger unit's own packaging, such as a carton or pallet, added to the base unit weight multiplied by the base count when the unit has no weight of its own), isStackable and maxStackCount. It is returned by GET api/v1/Item, GET api/v1/ItemList and GET api/v1/ItemAllList (omitted for units without packaging). POST api/v1/Item and POST api/v1/ItemBulk accept it: a unit sent with packaging gets it replaced with the values sent, an empty packaging {} clears it, and units sent without packaging keep theirs. In POST api/v1/ItemBulk the packaging is saved even when unitCodesSpecified is false, so you can change only the packaging without replacing the units. A unit that is not a unit of the item, an incomplete set of dimensions or an unknown unit fails the item with a message in updateMessage.
Orders written as plain text can now be sent to OrderSense through the API and reviewed in the OrderSense Inbox like a text message or email. POST api/v1/OrderSenseMessage takes text (the order as the customer wrote it, required), optional subject, externalId (your own id of the order; the same id sent again is stored once and answered with status duplicate) and senderName, and names the customer with any of customerId, accountNumber, phone, email or customerName: the first that matches exactly one active customer is set on the message, anything else is shown to the reviewer as a hint. POST api/c1/OrderSenseMessage takes the same text, subject, externalId and senderName for the customer the access token belongs to. Both answer data with messageId, status (queued or duplicate), customerId, customerName and customerMatchedBy (ID, ACCOUNT, PHONE, EMAIL, NAME, or TOKEN for C1), or updateStatus ERROR with updateMessage when OrderSense is not switched on for the company or the request is incomplete.
When POST api/v1/SalesOrder updates an existing order, a line sent with an empty itemVariants array ("itemVariants": []) no longer clears the variant selection stored on that line. Omitted, null and empty itemVariants all leave the line's variants unchanged, in line with the update rule that fields cannot be cleared; send a non-empty itemVariants array to replace the selection. Previously an empty array (the default many client libraries send for an unset collection) wiped the stored variants.
AI assistants can now connect to LodDepot through the new MCP (Model Context Protocol) server, which authenticates with dedicated MCP Access credentials. POST api/v1/GetMcpAccessToken exchanges an MCP Access credential set (companyCode, clientId, clientSecret, optional accountId) for a 60-minute bearer token, the same way POST api/v1/GetAccessToken does for API Access credentials. MCP Access credentials are created in the Portal under Settings, API / AI Access, AI Assistant (MCP) Access, and are separate from API Access credentials: each credential type is only accepted by its own token endpoint, so MCP access can be granted and revoked without affecting existing API integrations. The returned token is a standard V1 bearer token accepted by all api/v1 endpoints.
POST api/v1/ItemBulk now applies the itemVariants array that was previously ignored on this endpoint. Send itemVariantsSpecified: true together with itemVariants, where each entry needs variantCode and quantityOnHand, e.g. "itemVariantsSpecified":true,"itemVariants":[{"variantCode":"46","quantityOnHand":13}] — the variant's stock quantity is updated the same way POST api/v1/Item does it. On POST api/v1/ItemBulk the list is treated as the complete set of the item's variants: variants NOT included in the list are deactivated (an empty list with itemVariantsSpecified: true deactivates all of the item's variants), so only send itemVariantsSpecified: true when the full variant list is provided. Only the stock quantity and active status of existing variants change: other variant fields are left unchanged, entries with an unknown variantCode are ignored, and variants cannot be created or deleted through the API.
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.