Developer changelog

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.

AutomationExecution.status can now return waiting while an automation is paused. Clients that classify runs as complete or failed must also handle this state. resumeAfter gives the earliest scheduled resume time and is null when the execution is not waiting.

An action after a wait evaluates its conditions against the record’s current state when it runs. Do not assume the remaining actions have completed when the initial execution returns.

Conditions on a failed_to_fulfill fulfillment now use failed_to_fulfill_to_in_progress instead of ready_to_in_progress. Update callers that filter conditions by phase.

A condition that applies to several phases appears once per phase in conditions. Identify a row by (id, phase) rather than id alone. Callers that only need the requirements for the next transition can read Fulfillment.blockers.

AWAITING_SHIPMENT_CREATION is removed from OrderSignalNameEnum. Remove it from requests and saved API filters; requests using a removed enum value fail validation.

Responses can include the categories ISSUES, TO_DO, and INFORMATION, and the signal FULFILLMENT_BLOCKED. Update exhaustive enum handling. The older category values remain accepted while both sets are in use. Held orders continue to use the on_hold order status.

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.

InventoryWarehouse.available, WarehouseItemAvailability.available and the AVAILABLE sort value are deprecated in favour of the explicit metrics beside them: availableToSell, availableToAllocate, and the matching AVAILABLE_TO_SELL and AVAILABLE_TO_ALLOCATE sort values.

Nothing you receive changes — the deprecated fields resolve exactly as they did — so moving across is a matter of naming the number you actually mean. available stays for now on the supply inventory types and the product sort enum, where no explicit metric exists yet.

The V1 order mutations — updateOrder, fulfillOrder and more than twenty siblings — are deprecated. Each names its V2 replacement in the schema, and a call to one returns a DEPRECATED_V1_ORDER_MUTATION warning in errors[] alongside its data.

They still work. createOrder is the exception and no longer accepts calls; create orders through its V2 equivalent. Version-agnostic mutations such as reloadOrders and orderOperations, and the Order read type, are unaffected.

One thing to check in your own client: the warning arrives in errors[] on an otherwise successful response, so a client set to reject any response carrying an error will throw away data it should keep.

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.

Automations can be filtered by the actions they are configured to run, and a reverse lookup returns the triggers available for a given action. Together they answer what would run when a particular action fires, without reading every automation on the company.

Both are additions. Existing automation queries return what they always did.

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.