Routing bundle reorders without replaying internal components

Context

Ikigai Cases sold individual pill cases alongside configurable sets. A past order could therefore contain ordinary merchandise, a parent that represented a configured purchase, or component lines produced by bundle transformation. Those lines might look individually purchasable in order data even when their prices and meaning depended on the original configuration.

The customer account needed a useful reorder action across those shapes. A repeat purchase of an ordinary item could go straight to the cart. A configured set needed a different path because replaying its internal variants could skip current selection, pricing, and availability rules.

My role

I built the reorder behavior across a Customer Account UI extension and the existing Online Store theme. In the extension, I retrieved complete order lines, classified protected bundle groups, resolved current catalog records, and selected the action shown to the customer. In the theme, I implemented the handoff that validated and added eligible ordinary items to the cart.

Shopify supplied the account, order, catalog, and cart APIs. I owned the reader and routing layer that interpreted historical order shapes against the current catalog. Rather than reconstructing an old configuration or price, the flow guided each purchase through the rules that applied now.

The actual challenge

The safe action depended on more than whether an order line still had a variant ID. Transformed bundle components could retain valid variant IDs while being unsafe to buy on their own. Older MagNano orders used a legacy marker, while newer Combined, Magnetic Set, BYO, and Monthly orders used versioned markers with different roles and grouping rules.

Catalog state could also change after the order. A variant might no longer be available, a product URL might be absent, or a destination embedded in a marker might conflict across a group. Mixed orders could combine an eligible ordinary item with a protected set or an unrecognized line. One generic Buy again link could not express those cases safely.

System design

I separated the workflow into retrieval, classification, resolution, payload construction, and action selection. Each stage produced a bounded result for the next stage instead of letting account UI code infer bundle behavior from a title.

The classifier divided order lines into three categories: protected groups, eligible ordinary lines, and blocked lines. Catalog resolution then checked current products and variants. Payload construction accepted only the eligible ordinary set. The final selector reduced those facts to four states: direct-configure, direct-buy, modal, or none.

This made partial failure visible. A missing destination did not turn bundle components into ordinary merchandise, and one unavailable ordinary line did not disappear behind a misleading direct action.

Classifying historical order shapes

I parsed the supported bundle formats into five protected families: MagNano, Magnetic Set, Combined V2, BYO V2, and Monthly V2. The parser constrained bundle IDs, numeric IDs, roles, slots, and pack counts before grouping lines. It also recognized the retained legacy MagNano format and rejected conflicting legacy and current identities.

Grouping checked more than a shared string. Analysis tailored to each family identified parents and components, tracked destination conflicts, and blocked malformed or ambiguous signals. Ordinary lines remained eligible only when they had no protected bundle meaning. This protected the physical components from direct replay while allowing unrelated merchandise in the same order to continue through the ordinary path.

Resolving a current destination

The extension queried current catalog nodes in chunks and retrieved the shop's primary domain with them. Ordinary variants had to resolve as product variants and remain available for sale. Protected groups resolved differently by family: some used configured canonical destinations, while others could use a current product URL or a validated fallback.

I treated destination URLs as data that needed validation. A candidate had to use HTTPS, contain no credentials, and match the current shop hostname. Monthly groups received an additional catalog check for the expected carrier, four cases of the same size, and allowed engraving products before their product destination was accepted.

This resolution step deliberately returned no destination when the catalog could not provide a safe one. The action selector could then show review information rather than sending the customer to an untrusted or stale location.

Building the handoff for ordinary items

For eligible ordinary lines, I copied only properties visible to customers and discarded private keys. I merged lines only when their variant and visible property sets matched. The payload enforced limits for quantity, distinct line count, property count and length, and total encoded size.

The handoff used a versioned payload in the cart URL fragment. On the storefront, the theme decoded the payload, checked its version and shape again, validated variant IDs, quantities, properties, and overall limits, and submitted the accepted items through the Ajax Cart API. It then removed the fragment and reported whether items were added, unavailable, or invalid.

Configured groups did not use this payload. A single protected group with a known destination could go directly to its configurator. Mixed, unavailable, or blocked orders opened a review path so the customer could see what required attention.

Result

I protected five configured product families from direct component replay and reduced the customer decision to four explicit action states. In September 2026, the account reorder suite passed 128 tests covering classification, paginated order retrieval, catalog resolution, URL origin checks, payload limits, and action selection.

The finished flow let ordinary products move directly back to the cart while keeping configured purchases inside their current product rules. Mixed and incomplete orders received an honest review state instead of a Buy again action that could assemble the wrong merchandise.

Takeaway

A reorder feature should restore customer intent, not blindly reproduce stored line items. Once a product can transform into internal components, safe repeat purchasing requires a reader that understands the original contract, checks the current catalog, and chooses a route that matches current product conditions.