> ## Content Index
> Fetch the complete content index at: https://debugly.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# One Order, Two Fulfillments: The October 12 Assumption Breaker
- URL: https://debugly.dev/shopify-one-order-two-fulfillments/
- Published: 2026-10-12T13:30:00.000Z
- Updated: 2026-10-12T13:30:00.000Z
- Description: Shopify's Cart API now lets one order split into shipped and pickup fulfillment orders, and no new fields means your old assumptions are the breaking change.
- Author: Rohit Bhadani
- Tags: Shopify, DevOps

The quietest breaking changes are the ones with no diff. Shopify's ship and pickup in one order capability expands Cart API support today, 12 October, for Plus and Enterprise merchants, and the developer changelog says it plainly: there are no new API fields and no breaking schema changes. Existing fields now return data in combinations that were previously impossible. Your schema is fine. Your assumptions are the breaking change.

I have been writing about this failure class for years, most recently when [a carrier service silently produced no rates at checkout](https://debugly.dev/shopify-carrier-service-silent-no-rates/), because the system was not erroring, it was merely omitting. Today's change is the same shape at a deeper level: a single order can now produce more than one fulfillment order, one SHIPPING and one PICK\_UP, each with its own delivery\_method, and a checkout can carry multiple deliveryGroups. Every line of code you own that reads an order and says the delivery method, in the singular, just became a loop it never asked to be.

## What actually changes today

A shopper with both options enabled can choose, item by item, whether each line ships home or waits at a store. One payment, one order number, one confirmation email, and behind that, two fulfillment orders walking two different operational paths. Pickup locations with partial availability become selectable, with the unavailable items offered as a split into shipping. The partners blog places this inside the next generation of fulfillment, alongside market-driven shipping that began its opt-in rollout on 1 October and becomes the default for qualified merchants by 1 July 2027.

The changelog's own audit instruction is the whole job: identify any logic that assumes a single delivery method per order. That sentence sounds small. It is not.

## The assumptions I would hunt first

Start with money. Shipping fees computed once per order, pickup fees assumed absent, tip and tax logic keyed to one destination: all of these now meet an order with two destinations and two fee contexts. Then the emails: the ready for pickup message sent when the order is ready, where the order is half ready at a store and half on a truck. Then inventory: reservations that assume one location per order, and the [oversold inventory race](https://debugly.dev/oversold-inventory-race/) you thought was a concurrency problem becoming a modelling problem, because the same cart now touches two stock pools in one transaction.

Then the integrations you forgot you own. The warehouse connector that expects one fulfillment per order and quietly drops the second. The returns desk that refunds per order while the money lives per fulfillment. The analytics query that counts orders and calls it shipments. None of these throw. They misroute, mischarge and miscount, which is the failure style that survives to Black Friday because it only appears under combinations your staging data never contained.

## The staging data you do not have

Here is the practical blocker most teams will hit: you cannot test against combinations your store has never produced, because the feature was not on. So build the fixtures by hand. One order, two fulfillment orders, one of each delivery\_method. A pickup location with partial availability and the split fallback exercised. A refund initiated against only the pickup half while the shipped half is in transit. A shipping label request that must now fire per fulfillment, not per order. That last one is where the packing bench feels it: two labels, two tracking numbers, one order number on the slip, and a staff procedure that still says print one.

The operational half is code-adjacent and easy to forget. The packing slip template, the courier handoff file, the pickup shelf logic, the support macros that look up an order and read its shipment: every one of those is a reader with the singular assumption, living outside the repository. I would walk the physical bench with the same checklist I walk the codebase, because the misrouted parcel does not care which layer made the mistake.

Treat the changelog's new combinations as a test data spec and the floor, not the ceiling: it tells you the shapes that now exist, and your job is to assume a third shape will appear by July, when market-driven shipping becomes the default and split shipments join split delivery methods in the same order.

## Why the timing is the point

Shopify warns that new installs of incompatible apps see warnings from 1 October, and the partner guidance says to upgrade and confirm compatibility before peak holiday volume, starting with Black Friday at the end of November. That leaves you this month to find the singulars in your codebase while traffic is still polite. The feature is good for shoppers, one checkout instead of two orders is honestly better, and it is precisely because the feature works that the back office has to catch up before the season does. October is the last polite month this feature will have, and the polite months are when the cheap bugs get found.

The bug you find this week is a unit test. The one you find on 27 November is a thread in the refunds queue.

Returns are the last reader to audit. A return that refunds against the order while the money and the stock sit in two fulfillments will either overpay or strand a pickup item on the wrong queue, and the support macro that asks is this order shipped is reading a question that no longer has one answer.

## What I now do

Any reader of order fulfillment data gets audited for the singular assumption, fees and emails and reservations first, and the mixed order becomes a permanent fixture in the test suite, because from today onward one order is a container, not a shipment, and the code that forgets that will not error, it will just be wrong.