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.

warehouseAddExternalRelation, warehouseUpdateExternalRelation, and warehouseRemoveExternalRelation are deprecated. Migrate to buildingIntegrationConnectionsCreate, buildingIntegrationConnectionsUpdate, and buildingIntegrationConnectionsRemove. The old operations still work.

The warehouseExternal query and Warehouse.externalData are also deprecated. Read buildingIntegrationConnections on Warehouse or Integration instead. Create takes buildingId and integrationId; update and remove take connectionId. A building can have only one active connection to an integration.

v2Order.orderItemCoverage and the coverage-only fulfillment item type are removed without aliases. Queries selecting them fail validation. Read coverage on sales and fulfillment items instead.

onInvoice now returns a number, including zero when the order has no accounting documents. It no longer uses null to mean unknown. Fulfillment item quantities use the item’s product units; sales item quantities count complete bundles after pooling components. Partial bundles are not rounded up.

Removing a sales line with shipment records now preserves the line at quantity zero. Clients must not assume that a removed line disappears from the response.

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.

shipmentShippedDateFrom and shipmentShippedDateTo now match only live shipments in the shipped state. Canceled, archived, and deleted shipments no longer make an order match.

Queries and exports using these filters can return fewer orders for the same date range. Recheck reports that relied on those shipments being included. shipmentCreatedAt filters are unchanged.

Inventory receivedAt and the landed cost date now use a supply shipment’s actualReceivedDate, falling back to the delivered date when receipt is unknown. Previously they used the delivered date. Reports or integrations that treated warehouse delivery as inventory receipt must account for the distinction.

Advancing a shipment to In Transit, Delivered, or Received records the corresponding date. Pass statusDate when recording a historical transition so it uses the intended date.

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.

createDraftFulfillment now rejects a location that does not exist, belongs to another building, or is not active and pickable. This applies to the new typed items argument and the deprecated JSON fulfillmentItems argument. Such locations were previously accepted and ignored.

The JSON argument still works and stores a location without restricting allocation. Migrating to typed items changes that behavior: the location becomes a binding restriction, and insufficient stock there returns an error. Do not send both arguments in one request.

The V2 order edit mutations now leave a field unchanged when you omit it, and clear it when you send an empty value. This covers saveDraftOrder, updateOrderDetails, updateOrderGiftMessage, updateOrderShippingInstructions, and updateOrderCustomerInformation. Before, clearing a value was often ignored, and an edit to one part of an order could change another.

An empty string clears text such as contact fields, address line 2, the gift message, and the requested shipping method. An explicit null also clears the expected and shipping dates, the gift message, and the requested shipping method. An empty orderItems list or orderMetadata object clears its contents.

shipToSameAsBillTo on saveDraftOrder no longer defaults to true. Omit it to keep the current setting. Editing the shipping address no longer removes the billing address, and the reverse.

echoDeleteData deletes ECHO order history, shipment history, or inventory snapshot records. Each request selects one dataset and either a list of IDs or the same filters the list queries accept. The three earlier delete mutations, one per dataset, are removed. Update any caller to the new name.

Deleting by IDs finishes in the request and returns deletedCount. Deleting by filters runs in the background across all pages and returns a processId. Filtered deletion skips records changed after the request. The mutation requires the new echo:delete_data permission, which company operators and operations integrations do not hold. Records created automatically are never deleted.