Developer changelog

Shipment.shippedAt now returns the actual shipping date and may be null. V2 shipment creation no longer substitutes the create timestamp when a shipping date is missing, and the Amazon FBA importer no longer estimates a date from ship-by deadlines or the Orders API LastUpdateDate. Amazon dates that precede order creation are rejected outright. A caller that assumed shippedAt was always present should treat null as “shipping date unknown.”

An update that omits the shipping date or sends null preserves the existing date. Existing shipment dates are not changed automatically.

ECHO shipment reporting uses shippedAt when set, and the recording date when it is null, applied consistently to aggregation windows, daily buckets, and backfills. Clearing or adding a shipping date rebuilds both affected days without double-counting.

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.

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.

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.

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.

New fulfillment numbers on V2 orders read ORDERNUMBER-F-XXXXX, where they used to read FO-ORDERNUMBER-XXXXX. Numbers already issued keep their original shape, so both forms are live: treat a fulfillment number as an opaque identifier and match on the whole string rather than parsing it.

Manually created V2 orders also take a shorter default order number, something like EC-A1B2C rather than EC-MANUAL-XXXXX. It is a default an operator can still change before saving. V1 order numbering is unchanged.

createPendingOrder accepts an externalId on each order item. Pass the identifier the line carries in your own system and it stays on the Endless order item, so a line can be matched back to its source without keeping a map of your own.

The field is optional, and calls that omit it behave exactly as before.