Developer changelog

The nine per-entity operations are removed: productAttributeDefinitions, mediaAttributeDefinitions, customerAttributeDefinitions, addProductAttributeDefinitions, updateProductAttributeDefinitions, mediaAttributeDefinitionAdd, mediaAttributeDefinitionUpdate, addCustomerAttributeDefinition, and updateCustomerAttributeDefinition. Requests using these operations fail schema validation. Their brief deprecation period ended on October 14.

Attribute definitions for products, customers, and images now use attributeDefinitions(entityType:), attributesAddDefinition, and attributesUpdateDefinition. The mutations take an entityType, change one definition per call, and return the definition directly. They do not return result, status, message, or processId. Existing permissions still apply.

Use showInList instead of showInProductList, and remove brand from definition selections. Omitted settings keep their current values. Definition names must be unique within a company and entity type, and addProductAttributes rejects duplicate definitions in one request.

Products have two component settings: fulfillWithComponents and inventoryIncludesComponents. Both are available on product queries, create and update inputs, and imports. The old API names are removed, and a query or mutation that still uses one fails validation.

fulfillWithComponents takes AUTO, YES, or NO. It replaces decompositionStrategy on products and the short-lived fulfillWith. AUTO keeps the product line when its stock covers the entire line and otherwise uses components for the whole line. YES always creates component lines. NO keeps the product line. New aliases and bundles default to AUTO, and other product types default to NO. Manual decomposition works with every value. Existing products were reset by product type when this shipped.

inventoryIncludesComponents replaces includeComponentsInAvailableToSell. It is a Boolean with the same meaning, and it defaults to true for aliases and bundles and false for other product types.

Fulfillment rules no longer have decompositionStrategy, so omit it. Endless applies the product setting when it creates a fulfillment, not as a delayed step or when a rule is assigned. It skips the setting for fulfillments whose processInEndless is false.

productAddCosts, productUpdateCosts, and productArchiveCosts now run as a tracked process and return its processId. For productArchiveCosts, that value previously contained the product ID. Treat it as a process identifier and inspect failedItems for rejected products.

SupplySupplier.address now returns the ship-from address. Callers that need the remit-to address must select it explicitly. Dropship cost tiers now require a minimum order quantity of 1.

You can now set up a Custom Product Integration to write catalog data into Endless the same way our built-in product connectors do. It behaves like a Custom Sales or Custom Fulfillment integration — Endless provisions an access token, API key, and API secret — but the scope is product data: attributes, media, and inventory. Use it to feed the catalog from a system we don’t have a first-party connector for, without a bespoke build. It shows up under Custom Integrations in the integrations picker alongside Custom Sales, Custom Fulfillment, and the Read-Only Data Integration.