Developer changelog

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.

The order field originalCarrierService and the update input’s shippingMethod argument are deprecated aliases of requestedShippingMethod. Existing names still work. Use the replacement when updating an integration, and do not send conflicting values under the old and new names: those requests are rejected.

The value remains the customer’s original shipping choice. It is distinct from requestedCarrierServiceName, which identifies the carrier service selected to fulfill the order.

ordersSendShipments takes orderIds and queues each order’s shipments for delivery to its source integration. It replaces bulkForwardShipments, which is removed. Update any caller to the new name. The input and the asynchronous response are unchanged.

The integration capability is renamed from forward shipments to send_shipments. Calling the mutation again no longer clears earlier delivery receipts. It retries outstanding work and skips shipments the integration already accepted.

A deliverOutboundTransaction call without a message now sends the document even when it matches the last automatic delivery. Repeating a manual call can therefore send the same document again. Callers must not rely on this path to suppress unchanged documents.

Automatic delivery still skips unchanged documents. The optional fulfillmentId limits delivery to one fulfillment; omitting it keeps order-level scope.

The three dataset-specific ECHO export mutations are deprecated in favor of echoExportData. They still work, and their schema deprecation messages identify the replacement.

When migrating, pass exactly one of demand, shipments, inventory, or inventoryChanges under input.export, with filters nested inside that selection. Missing, null, or multiple selections are rejected. An empty object for the selected dataset exports without filters.

Order.fulfillmentOrderAlignment is removed. Queries that select it fail schema validation.

Read FULFILLMENTS_NOT_LINKED_TO_SOURCE and SHIPMENTS_NOT_LINKED_TO_SOURCE through OrderSignalNameEnum instead. These signals report missing source links; they replace the former alignment comparison.

assignAuthority, orderAuthority, and AuthorityState are removed, and externallyManaged is removed from Fulfillment. Shopify supplies the initial fulfillment plan on order creation and later planning happens in Endless, so mutable planning authority is gone from the model.

Endless still enforces user permissions, source-integration authorization, fulfillment-service authorization, source-identity ownership, and existing fulfillment-state protections. Historical AuthorityAssigned events and legacy assignment records are preserved for audit and timeline purposes; only the schema surface used to read or transfer authority at runtime has been removed. A client that selected the removed fields will fail GraphQL validation after the deploy — update to the new bundle before the backend rollout.

Order-item source identity is now preserved across edits, so a later Shopify reload matches existing lines instead of creating replacement lines that carry a fresh identifier.

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.

You can now create a Custom Data integration that reads your Endless data — products, prices, orders, inventory, warehouses, purchase orders, suppliers, customers, accounting, ASNs, automations, and more — without being able to write anything. Set it up from the Integrations page, hand its credentials to a reporting tool or a data warehouse, and it sees your data end-to-end but can’t change it.

The role is scoped to your company. It can’t reach other tenants’ data, and it doesn’t have access to sensitive internal surfaces like other integrations’ credentials or staff PII.

Sales channels now carry an optional handle — a short, stable identifier that travels with the channel even if the display name changes. You can set a handle when creating a channel, and edit it on the channel header card; it auto-suggests a kebab-case version of the channel name and you can override it. Handles are lowercased, validated against the allowed shape, and must be unique inside your company; the same handle can be reused across companies.