Liquid and the Storefront API have no way to check variant-level membership

Extensions
1

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:

  1. Add variant-level collection membership to Liquid (e.g., variant.collections, or a membership check equivalent to inAnyCollection).
  2. Add inAnyCollection / inCollections to ProductVariant in the Storefront API, mirroring the Functions input schema and Admin API.
  3. If these are already planned, could you share a rough timeline? This directly affects how we advise merchants using variant-scoped collections today.
3

Hey @ogasawarakyohei - thanks for reaching out. We’re aware this gap isn’t ideal, and it has also been discussed in the main 2026-07 Collections API thread.

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 :slight_smile: