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.

The GraphiQL pages in the app (/graphiql under a company and under system admin), their sidebar entry, and the Download Schema button are removed. Use your own GraphQL client to explore the API.

The countries and states queries now treat % and _ in search keywords as literal characters. For example, A_B no longer matches A1B or AXB. Update callers that relied on these characters as wildcards.

Other filtering and sorting behavior is unchanged.

Password submissions now use shared configurable rules. Read passwordRules instead of assuming a fixed minimum length or character policy. Invalid submissions return INVALID_PASSWORD; a signup below the minimum length now returns HTTP 400 rather than 500.

Authentication can return PASSWORD_EXPIRED or ACCOUNT_LOCKED instead of a generic login failure. A password reset unlocks a locked account. Password-reset token failures now return HTTP 401. Update clients that branch on the previous error codes or status codes.

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.

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.

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.