After migrating to API version 2026-07 for the new flexible collections model, we’ve hit a gap that we believe makes the current release inconsistent: there is no way to determine variant-level collection membership on any storefront surface.
Liquid: the variant object has no collection membership property, and product.collections is product-level only — for a variant-scoped collection it reports the whole product as a member as soon as a single variant is included.
Storefront API: ProductVariant has no membership field either — there is no equivalent of the inAnyCollection field that Functions and the Admin API received in 2026-07.
Concrete example: consider an app that enforces purchase rules, using a cart validation Function for checkout enforcement plus a theme app extension for the storefront UX (quantity selector limits, product page messages). A merchant sets a “max 1 per order” rule targeting a variant-scoped collection. The Function correctly restricts only the member variants via ProductVariant.inAnyCollection. But the theme side can only judge membership at the product level via Liquid, so non-member variants of the same product get restricted UI even though checkout would allow the purchase. The storefront and checkout disagree, and there is no way to make them agree. The same applies to any theme or app that renders variant-dependent UI based on collection membership.
Upgrading to the latest API versions to adopt the new model is a reasonable ask. But variant-scoped collections are already available to merchants in production stores (“New Collection model and APIs now available”, June 17, 2026), while Liquid and the Storefront API cannot represent variant membership — leaving theme and app developers unable to build consistent storefront experiences for a feature that’s already in merchants’ hands.
Requests:
Add variant-level collection membership to Liquid (e.g., variant.collections, or a membership check equivalent to inAnyCollection).
Add inAnyCollection / inCollections to ProductVariant in the Storefront API, mirroring the Functions input schema and Admin API.
If these are already planned, could you share a rough timeline? This directly affects how we advise merchants using variant-scoped collections today.
We’re working on improving variant-level collection support across storefront surfaces, but I can’t guarantee a specific API change or timeline. I’m going to close this out for now so the discussion stays consolidated there, but I’m more than happy to pass along any additional requirements as a specific feature request on our end, just feel free to ping me here and I’ll get that logged for you at the very least
@Alan_G — following on from the variant-level membership thread you closed. You offered to log additional requirements, so here’s a merchant-side case to add alongside the app-developer one.
We run a production DTC store on a custom theme. We built a variant-scoped collection in the admin — it shows correctly there (“1 of 4 variants”, “3 of 5 variants”). On the storefront it renders as an ordinary product grid: one card per product, with the price range drawn from all the product’s variants, not the selected ones. So a collection built to surface three specific variants advertises a “from” price belonging to a variant that isn’t in it.
We can’t fix this in the theme, because Liquid has no way to express which variants are members. product.collections reports the whole product once any single variant qualifies, and the variant object has no membership property. As far as we can tell that makes correct rendering impossible on a custom theme today, regardless of how we write the template.
What we’d need, in priority order:
Variant-level membership in Liquid — variant.collections, or a check equivalent to the inAnyCollection that Functions and the Admin API got in 2026-07. This is the blocker; everything else is downstream of it.
inAnyCollection / inCollections on ProductVariant in the Storefront API, mirroring Functions and Admin.
Collection pages that render the selected variants — the changelog says variants “appear on collection pages, in filters,” but we don’t see that on our theme. Clarifying whether that’s limited to specific themes or still gated would help us set merchant expectations.
On timeline — fully understand you can’t commit to one. What would help is knowing whether this is expected within the next couple of API cycles or is longer-term. We’re deciding between building a temporary sync layer to mirror membership into a metafield, or waiting. If it’s near-term we’d rather wait than ship and remove a workaround.
Hey @stephen_snap - thanks for following up. I’m going to add the Liquid and Storefront API membership requirements to the feature request I offered to log.
The collection-page behaviour is worth separating out, though. Variant-scoped collections are intended to scope the displayed variants and price range automatically, so what you’re seeing may be a storefront or theme compatibility issue rather than only the missing Liquid property (more info here).
If you can share the affected collection URL and an example product, along with which variants should belong to the collection? If you’d rather not post the store publicly, I can set up a DM with you to get the ball rolling there. I’d also be interested to know whether the same behaviour appears in an unmodified Dawn preview.
I can’t give you a reliable timeline for the API additions, but I’ll see if we can confirm a relative timeline too (can’t guarantee anything - but I’ll advocate as best as I can on my end here!)
