October 3, 2026 · Muhammad Rehan · More by Muhammad Rehan
Fulfillment Order Reroute vs. Move in Shopify
Shopify has two mutations to relocate a fulfillment order — one you aim yourself, one Shopify aims for you — and each fails differently.
Two Ways to Move the Same Thing
Shopify's Admin GraphQL API has two mutations for relocating a fulfillment order, and they solve the same problem from opposite directions. fulfillmentOrderMove takes an exact destination: the caller passes a newLocationId, and Shopify moves the specified line items there. fulfillmentOrdersReroute, introduced in the 2025-10 API version, does the opposite — the caller doesn't name a destination at all. Instead, Shopify finds the next best location according to the shop's own order routing settings, and the caller can only narrow the candidate pool with includedLocationIds or excludedLocationIds, with exclusions taking precedence over inclusions. Neither mutation documents what the shop's routing logic actually weighs when picking that destination — that stays internal.
For an integration — a 3PL, a WMS, or an ERP relocating orders after a stockout or a warehouse outage — the choice isn't cosmetic. If the integration knows exactly where an order should go, fulfillmentOrderMove is the right tool. If it just wants Shopify's own routing rules to decide, fulfillmentOrdersReroute is the one built for that.
Where fulfillmentOrderMove Fails
fulfillmentOrderMove fails outright in several named circumstances: the fulfillment order is closed; it has had progress manually reported, which means it must first be marked open to resolve that state; the destination location doesn't stock the requested inventory item; or the API client lacks the correct permissions. It also can't reassign a fulfillment order while its request status is SUBMITTED, ACCEPTED, CANCELLATION_REQUESTED, or CANCELLATION_REJECTED — those statuses mean a fulfillment service is already mid-action on the order, and Shopify blocks the move until that resolves, specifically to prevent an order being fulfilled from two places at once.
As of the 2026-04 API version, failures here return a dedicated error type instead of a generic userError, giving integrations a code field to branch on programmatically instead of parsing message strings.
A Silent Split Worth Knowing About
One behavior of fulfillmentOrderMove is easy to miss: if you move a subset of an order's line items, specified through the fulfillmentOrderLineItems parameter, to a location that's already assigned to another active fulfillment order on that same order, Shopify closes the existing fulfillment order and recreates those line items as a new one. The original ID an integration was tracking may no longer represent live state. fulfillmentOrdersReroute's payload is simpler by comparison — it just returns the list of moved fulfillment orders — and it hasn't been documented as picking up the same dedicated error-type upgrade that fulfillmentOrderMove got.
Different Permission Floors
The two mutations also sit behind slightly different access requirements. fulfillmentOrderMove needs write_merchant_managed_fulfillment_orders or write_third_party_fulfillment_orders, plus the fulfill_and_ship_orders permission. fulfillmentOrdersReroute accepts a broader set of scopes, including write_assigned_fulfillment_orders, and carries a carve-out: the fulfill_and_ship_orders permission requirement is waived if the calling API client is Shopify POS itself.