We have identified a fundamental inconsistency in how Combined Listings are exposed through the Storefront API, which makes it impossible to reliably render product option pickers when querying a combined listing child product.
Observed behavior
When querying a combined listing child product via the Storefront API:
-
product.options.optionValues
-
Returns only the option values that exist on the child product itself
-
The combined option universe (as defined by the parent) is not accessible
-
-
encodedVariantExistence / encodedVariantAvailability
-
Appear to be calculated based on the combined listing parent option matrix
-
These encodings reference option values that are not present in product.options.optionValues
-
Why this is a problem
From Storefront API alone:
-
There is no standardized way to access the combined listing parent from a child product
-
There is no field indicating whether a product is a combined parent or child
-
There is no API contract that explains how options.optionValues should relate to encoded variant data
As a result, when using the Storefront API with a combined listing:
-
It is not possible to reconstruct the full option space
-
It is not possible to correctly interpret encodedVariantAvailability
-
Rendering an accurate option picker becomes impossible
Expected behavior (one of the following)
Any one of these would resolve the issue:
-
Child products expose a reference to their combined listing parent in Storefront API
-
options.optionValues on child products reflect the combined option universe
-
Encoded variant data is scoped strictly to the child product’s option set
Is this a known issue, and is there a roadmap or recommended pattern for safely handling combined listings via the Storefront API? We want to support 2k variants, so loading all variants is not an option.