I’m coming up against an issue when trying to identify a native bundle product via a carrier service request. The issue:
A merchant sells a wedding cake as a native bundle (requiresComponents: true). Their shipping rules target the bundle parent (its collection/product type).
At checkout the bundle expands, so my CarrierService callback receives the component line items, not the parent:
"items": [ { "sku": "CCSF167", "product_id": 10476235325704, "variant_id": 52254663868680, "properties": [] },
... 3 more component cheeses ...
]
// no parent line, no bundle id, properties empty
The components are ordinary cheeses also sold standalone, so I can’t distinguish “wedding-cake bundle” from “those 4 cheeses bought à la carte” - the payloads are identical. Result: parent-based rules don’t match and the wrong rate is returned.
What I’ve already ruled out:
Cart attributes aren’t in the rate-request payload.
Line-item properties can’t be set on component lines (and don’t survive the split for native bundles).
Q1: Is there any route I’m missing to tell, at rate-request time, that an item is a bundle component and what its parent is?
Q2 (suggestion): Could the rate request expose the bundle relationship — e.g. a bundle_parent / line_item_group reference on items[], or simply pass through cart attributes? Either would let apps apply the merchant’s intended bundle-level shipping logic without an Admin API round-trip per line (Which is not viable given carrier service response time restrictions that Shopify enforce).
Just confirming, I don’t think you’re missing a documented route here. The CarrierService rate request payload exposes the expanded items[] data like product_id, variant_id, sku, properties, etc., but it doesn’t currently include a bundle parent reference, line item group reference, or cart attributes at rate-request time.
There is bundle grouping context elsewhere, like LineItemGroup on order line items after purchase, but that isn’t exposed in the CarrierService callback payload today. So in the specific case where the same component variants can be bought standalone or as part of a native bundle, there isn’t enough information in that rate request alone to reliably tell those two cases apart.
The only workaround I’d be comfortable suggesting right now would be to pre-cache known bundle/component relationships and infer the parent only when the component set is unambiguous. But for your example, where those cheeses can also be bought à la carte, that can produce false positives, so it’s not a clean solution.
I definitely get the request here though. A bundle_parent, line_item_group, or similar reference on items[] would be the right shape for this, especially given CarrierService response time limits make per-line Admin API lookups pretty fragile. I’m happy to pass this along as product feedback on our end. Let me know if I can clarify anything further here.
I thought about pre-caching too, but it’s not a viable option for our system at scale and would require a fair bit of extra system resource we can’t justify.
As you said the easiest solution would be to have a ref on items we can read
Hey @Alex_Hooper - thanks for confirming. I agree with you here: for carts where the same component variants can be purchased either standalone or as part of a native bundle, pre-caching/inference is not the most ideal workaround for sure.
I’m going to pass this along as product feedback with the specific ask that CarrierService rate requests expose bundle grouping context on items[], such as a line_item_group / bundle_parent reference or another way to read the parent bundle context during rate calculation.
I don’t have a platform workaround or timeline to share right now, but I do agree this would make sense to offer on our side. Let me know if there are any extra details you’d want attached to the feedback, like rough merchant/order volume or whether this is strictly native Shopify bundles. Hope this helps a little. bit at least!
