Can fulfillment Order have multiple items

We have a fulfillment center and when user sending fulfillment request from order details page we are reading onle lineItems[0] of fulfillmentOrder.

But I found there might be multiple line items too. After running the below command (order create via graphql) I noticed two variant has only one fulfillment request button.

But after trying to replicate this from storefront it was splitted into multiple items in order details.

What should I consider for fulfillment properly, should I dynamically paginate through all items of fulfillment lineItems?

Hey @illusionist3886 :waving_hand: Yes, a fulfillment order can absolutely have multiple line items. The FulfillmentOrder object represents an item or a group of items expected to be fulfilled from the same location. Items routed to the same location are generally grouped into one fulfillment order, though the docs note there can be more than one fulfillment order at a given location. Your screenshot is a good example of this, two variants both assigned to Hoodsly Fulfillment Center in one fulfillment order.

Reading only lineItems[0] will silently drop items whenever a fulfillment order has more than one line item. You need to iterate every node in the FulfillmentOrder.lineItems connection. That field is paginated, so you should use cursor-based pagination (first/after) to make sure you’re not missing anything. Something like this:

query getFulfillmentOrderLineItems($id: ID!, $first: Int!, $after: String) {
  fulfillmentOrder(id: $id) {
    lineItems(first: $first, after: $after) {
      edges {
        node {
          id
          remainingQuantity
          totalQuantity
          sku
          productTitle
          variantTitle
        }
        cursor
      }
      pageInfo {
        hasNextPage
      }
    }
  }
}

Hope this helps!

Yes, but the confusion arises on another point. When I use orderCreate mutation then variants of same product are grouped into one item for fulfillment request. But when I create order from frontend then variants of same product are separated for fulfillment request. (we are using cart/add.js). We are following this add to cart as our products variants are dynamically created based on a lot of user options.

I took a look, and the difference you’re seeing is expected and comes down to how the two order creation paths handle fulfillment order grouping.

When a customer checks out through the storefront, the checkout flow groups line items into delivery groups based on their shipping profiles. Each delivery group can become a separate fulfillment order after order routing runs. If your variants are assigned to different shipping profiles, or if the checkout routing logic splits them for any reason (inventory distribution, delivery method differences), you’ll end up with multiple fulfillment orders even though everything ships from the same location.

The orderCreate mutation skips that checkout delivery grouping entirely. Order routing still assigns locations, but without the delivery group splitting step, items headed to the same location typically land in a single fulfillment order. That explains why your API-created orders have one fulfillment request button and your storefront orders have multiple.

First thing I’d check is whether your dynamically created variants all belong to the same shipping profile. If they’re spread across different profiles, that’s your answer for the storefront split. Either way, your fulfillment integration should always iterate through all fulfillmentOrders on the order rather than assuming a specific grouping, since the number of fulfillment orders can vary depending on how the order was created.

1 Like