App or workaround to auto-fill from a backup SKU when primary SKU sells out?

Shopify Apps
1

We have several products where the same item ships in two different packaging types. Each packaging type has its own SKU, its own UPC/barcode, and its own Shopify variant ID, since our 3PL keys off the variant ID and UPC to pick the right box.

We want the customer to see and order one product listing with no packaging choice. Behind the scenes, we want fulfillment to pull from Packaging A until it’s out of stock, then automatically switch to Packaging B, without the customer knowing or choosing.

The key constraint: we can’t just change the SKU text on the same variant, because the UPC and variant ID need to change too, or our 3PL will send the wrong physical item.

Has anyone found an app, or built a workaround, that actually swaps which real variant gets fulfilled (not just relabels a SKU field) once the primary one hits zero stock? Open to native Shopify solutions, apps, or custom Admin API approaches if anyone has done this.

Thanks in advance!

2

Hi @DefinedRobo Welcome To Shopify Community So The cleanest way to do this without a fragile after-the-fact swap is to make the switch happen at add-to-cart time instead of after checkout. Keep both variants (Packaging A and B) hidden from the customer-facing product page, but on your product template, use JavaScript with the Storefront API to check each variant’s real-time inventory quantity before the customer clicks add to cart. Show one clean “Add to Cart” button with no packaging choice, but have the JS silently determine which variant currently has stock (A first, falling back to B when A hits zero) and add that specific variant to the cart behind the scenes. Since the correct variant ID and UPC get added to the cart from the start, your 3PL sees the right data with zero risk of the order needing to be edited afterward.

If you’d rather not touch the add-to-cart JS, the alternative is a Shopify Flow workflow triggered on Packaging A’s inventory hitting zero, which calls a custom app/webhook using the Admin API’s order editing mutations (orderEditBegin, then remove the A line item and add the B variant) before the order is sent to fulfillment, but this is riskier since it depends on the edit happening before your 3PL picks up the order, and it only works for orders placed in that gap window. The add-to-cart approach avoids that timing risk entirely since the correct variant is locked in before the order even exists.Hope this helps solve your problem, and if it does, don’t forget to like and mark it as the solution. Thank you!

3

@DefinedRobo

I’d be careful with checking inventory only when the customer clicks Add to Cart. With multiple customers shopping at the same time there can still be a race condition between checking the quantity and actually creating the order.

also make sure both variants are properly excluded from customer facing feeds/search so customers never accidentally reach the hidden packaging variants directly.

If the 3PL absolutely requires the real variant ID and UPC I agree with keeping A and B as separate variants and selecting the correct one before the order is created. That seems much safer than trying to modify the order after checkout.

The main thing I’d test is what happens when the last unit of Packaging A is being purchased by two customers simultaneously. That edge case could be the one that causes fulfillment problems.

4

@DefinedRobo Before building anything, ask your 3PL whether their system supports substitute or alternate SKUs. Most WMS platforms do. You map SKU A with a fallback to SKU B, and the warehouse picks whichever it has.

If they support it, the whole problem leaves Shopify. One variant, one UPC, one combined inventory number, no hidden variants, no javascript, no order editing, no race condition. Its worth one email before you spend a week on the harder version.

If they cant, then on the storefront approach above, the race condition isnt actually your biggest risk. The bigger hole is that add to cart javascript only runs on your product page. Plenty of things create carts without ever loading it:

cart permalinks, the Shop app, Google and Meta product feeds, abandoned cart emails, back in stock emails, buy buttons, subscription reorders, and Shopifys agentic channel feeding ChatGPT, which is live now. Every one of those carries a variant id straight to checkout. So eventually someone buys hidden variant B while A still has stock, or hits A after its empty, and your product page logic never gets a say.

On the race condition itself, its less scary than it sounds. Shopify revalidates inventory at checkout, so two people racing for the last unit of A means the second one gets a checkout error rather than a wrong box. The thing that would actually cause a mis-ship is Continue selling when out of stock being ticked. Worth confirming thats off on both variants, since that single setting is the difference between a failed checkout and a wrong item leaving the warehouse.

One thing worth doing whichever route you take. Write the intended packaging into a line item property when the item goes into the cart. It lands on the order and the packing slip, so the warehouse has a human readable cross check that doesnt depend on any of this working.

And to close one door before someone suggests it, Cart Transform functions wont do this either. Expand is driven by metafields on the parent variant, so the components are fixed in advance and the function cant look at live stock and choose.

5

Have you tried Mechanic app?

For a native solution, I think the simplest solution would be:

Same product, different variants. Tracking on, continue selling when out of stock disabled on Packaging A (so it goes unavailable at zero). In the product editor, make sure Packaging A variant is the first choice, so it’s always selected by default when in stock. Create and assign product to a new template, and hide the variant selector. This would default to Packaging A (when in stock), fall back to Packaging B, and present it as one product.

6

The storefront half of this has been covered well above. The part that bites later is on the inventory side, and it doesn’t go away once the swap works.

The moment A and B are separate variants, every number about that product splits across two rows. Sales velocity, days of cover, low stock alerts, reorder point. And the fallback makes it worse than a plain split would, because A always drains first by design. So A reads like your fast mover and B reads like it barely sells, and neither is true. Real demand for that item is A plus B, always.

So pick which one is the planning unit before you build anything, and sum them every time you decide what to buy. Same for the low stock trigger. An alert firing on A while B has four hundred units is noise, and after a few of those nobody reads the alerts anymore.

The reorder side has a wrinkle too. You’re not really reordering the product, you’re reordering the packaging, and if box B has a longer lead time than box A you want to know that well before the fallback fires. The design makes B your buffer. So the safety stock belongs on B, which is the opposite of where most people put it, because B is the one that looks like it never moves.

Last one, and it’s the quiet one. If A and B cost you different amounts to land, your margin on that listing changes depending on which box shipped, at the same selling price. Worth pulling the two unit costs before you commit to the approach. If it’s a few cents, ignore me. If it’s a dollar on a mid volume SKU you want that visible somewhere, rather than averaged into a number nobody looks at.

7

I agree that changing the real variant before the order reaches the 3PL is much safer than editing a live order afterward. I would treat the two packaging variants as fulfillment substitutes, but keep their inventory and 3PL identifiers completely separate.One extra point to plan for is the last-unit edge case.

The storefront should not simply look up Packaging A and assume it is available; the same stock needs to be reserved or denied at checkout so two buyers cannot both be routed to the final unit.I would also make the fallback relationship explicit somewhere outside the product title: sellable product → preferred fulfillment variant → fallback variant.

That makes it easier to audit why a customer received Packaging B and prevents the substitution rule from becoming hidden logic that only one person understands.Finally, use the combined demand for both packaging variants when you plan reorder points. They are two fulfillment forms of one sellable item, so looking at either SKU in isolation can make the packaging change look like a demand drop when it is not.