Admin GraphQL API / Storefront GraphQL API · 2026-07

Variants can be
published or unpublished independently of the product

Starting with API version 2026-07, ProductVariant becomes Publishable , letting you control publication status per variant on a per-publication (channel or catalog) basis. Workarounds like deleting variants, duplicating products, or hiding them in storefront code are no longer needed.

On this page
  1. What actually changes (understand it in 30 seconds)
  2. How it works: publishing is a "two-stage gate"
  3. Three non-breaking, additive ground rules
  4. Changes to the Admin GraphQL API
  5. Impact by app type
  6. Five points engineers should know
  7. Three use cases you can apply to your business
  8. A one-line summary you can use in a pitch

1What actually changes

Until now, to achieve "don't show only certain variants (sizes, colors, etc.) on this channel," you neededdeleting variants / duplicating products / hiding them in storefront code and similar workarounds.
Starting with 2026-07, ProductVariant itself becomes Publishable , so you can toggle each variant's published/unpublished state on a per-publication (channel / catalog) basis.

Before: no publishing control at the variant level

The only way to "hide just this variant" was workarounds like deleting it, duplicating the product, or hiding it on the storefront side—distorting data and adding maintenance overhead.

New: control each variant individually per publication

Without deleting or duplicating variants, you can finely decide "which variants to show" for each channel / catalog (API version 2026-07).

2How it works: publishing is a "two-stage gate"

Whether a variant is shown depends on passing① product-level publishingand then also passing② variant-level publishing—only those that pass both are shown. If ① is closed, it won't show regardless of ② (the product level takes precedence).

Gate ①: Product level Product is active and published to the channel = Core prerequisite (takes priority) Gate ②: Variant S ... resourcePublicationsv2 = published M ... published L ... unpublished (unpublish) Evaluated per publication Visibility on that channel ✓ Show S ✓ Show M — Don't show L Only those that satisfy both ① and ② ※ If Gate ① is closed, nothing is shown at all, regardless of ②'s state
Publishable interfaceWhat it is: a common type that Product and Collection have long had, which holds publication status per publication. Now ProductVariant conforms to it as well, and withresourcePublicationsv2 / publishedOnPublication you can now read a variant's publication status.

3Three core prerequisites that are non-breaking and additive

The article explicitly describes this as a "non-breaking, additive change." There are three prerequisites that keep existing implementations from breaking.

Prerequisite 1

Product-level publishing takes priority

Product-level publishing behavior is unchanged. Unless a product is active and published to a channel , none of its variants are shown on that channel.

Prerequisite 2

Default is "published" (opt-out)

Variants are published by default. Existing apps that publish at the product level without any changes keep working as-is.

Prerequisite 3

Can be created in an unpublished state

Variants can be created in an unpublished state, and early exposure to buyers can be prevented..

4Changes to the Admin GraphQL API

publish

1. publish/unpublish now support variant IDs

publishablePublish and publishableUnpublish now accept ProductVariant IDs .

2. Conforms to Publishable

ProductVariant now conforms to the Publishable interface, just like Product and Collection.resourcePublicationsv2 and publishedOnPublication are included.

3. The Product feed webhook fires

When a variant is published to or removed from a feed's channel,product update the product feed webhook fires as such (accompanied by variant added / deleted).

soon

4. A dedicated webhook is in development

variant_publication/create update delete The webhook is still in developmentand is scheduled to ship imminently.

The dedicated variant_publication/* webhook'sexact availability and the concrete read specification on the Storefront GraphQL API side are not documented. For now, the reliable event sources are the product feed webhook and, on the Admin API, resourcePublicationsv2 reads.

5Impact by app type

App typeRequired actionNotes
Channel apps that use product feed No changes needed The feed adds/removes variants on the product, and the incremental sync webhook fires.
Channels / pseudo-channels that don't use feed and read publication status via the Admin API Action recommended ProductVariant.resourcePublicationsv2 you should add an implementation that reads each variant's publication status.
Apps that create variants after the product is published Needs review New variants default to published across all of the parent product's publications. To create them unpublished, use productSet / productVariantBulkCreate 's variant.published: false .
Apps that publish products No changes needed As before, on the product you just need to call publishablePublish . If unpublished variants are relevant to your workflow, consider handling it.
Most apps work without changes. Active handling is only needed for two types: "channels / pseudo-channels that read publication status via the Admin API without using feed" and "apps that want to create variants unpublished."

65 points engineers should keep in mind

Product Variants

1. Publishing has two levels: product → variant

Product-level publishing always takes precedence. Unless the product is active and published to the channel, publishing variants won't make them appear no matter what. When debugging, suspect the product level first.

v2

2. Reads go through resourcePublicationsv2

With the same Publishable approach as Product / Collection, you fetch each publication's publish status fromProductVariant.resourcePublicationsv2 . Existing Publishable implementations are easy to reuse.

3. Published by default (opt-out)

Variants are published if you do nothing; making them unpublished must be explicit — i.e., specify variant.published: false with productSet / productVariantBulkCreate .

4. For now, the event source is the feed webhook

A dedicated variant_publication/* webhook is still in development. If you want to detect changes in real time, a realistic design is to first ride the product feed's product update (variant added/deleted).

2026-07

5. Requires API version 2026-07 / no Storefront-side spec documented

This feature is available in API version 2026-07 . The tags also include the Storefront GraphQL API, but the body only describes changes to the Admin API, andthere is no documentation on how to actually read it on the Storefront side. Verifying the storefront display must be done separately.

7Three use cases you can apply to your business

A B
USE CASE 1

Show different variants per channel / market

Challenge
Even within the same product, you want to show a specific color or size "only on the wholesale channel" or "only in a specific market's catalog." Previously you handled this by duplicating or deleting products, which doubled up inventory and SKU management.
Solution
Keep a single product, and for the variants you don't want to show, on the target publication, run publishableUnpublish. This gives them a publish status at the channel / catalog level.
Result
Product duplicates disappear, and inventory, pricing, and analytics consolidate into a single product. You can switch the per-channel presentation through operations alone.
Technical note
When checking display, first make sure the product level is active and published on the target channel. The publish status is read via resourcePublicationsv2.
Scheduled publishing
USE CASE 2

Prepare new product / new variant launches on production data

Challenge
You want to register new sizes and colors ahead of time, but avoid exposing them to buyers the moment you register them.
Solution
productSet / productVariantBulkCreate 's variant.published: false , create them unpublished → at launch, use publishablePublish to publish them all at once.
Result
You can stage product data, images, and inventory in production ahead of time. You get full control over exposure timing and prevent premature sales.
Technical note
Creating items as unpublished requires explicit specification (the default is published). For now, detect publish-state changes via the product feed webhook. A dedicated webhook is in development.
USE CASE 3

Variant publishing sync support for first-party and channel-like apps

The problem
First-party and channel-like apps that read publication status via the Admin API instead of the product feed only check publishing at the product level, so they miss variant-level unpublishing.
The fix
ProductVariant.resourcePublicationsv2 and build per-variant publication status into your sync process.
The benefit
Never accidentally expose unpublished variants externally. Shopify's publication model and your app's display stay in sync.
Technical notes
Because it conforms to the Publishable interface, it's easy to extend your existing read logic for Product / Collection to ProductVariant.

8A one-line summary you can use in a pitch

"ProductVariant is now Publishable.Starting with API version 2026-07, you can control publish/unpublish per variant at the publication (channel/catalog) level.
It's non-breaking and additive, so existing apps need no changes, and the default is published (opt-out).
As long as you keep in mind the core premise that product-level publishing always takes precedence, you can handle channel-specific visibility entirely in operations—without duplicating or deleting products."