October 4, 2026 · Muhammad Umar · More by Muhammad Umar
Shopify's Rollouts API Lets Apps See the Test
Apps can now read Shopify Rollouts via GraphQL — schedules, traffic allocation, and lifecycle webhooks — closing a blind spot for theme and checkout apps.
Shopify's Rollouts feature shipped to merchants in June 2026, under Markets > Rollouts in the admin. It lets a merchant schedule an entire theme or checkout swap, run an A/B test between two themes or checkout setups, gradually roll out a new configuration to a percentage of visitors, or localize content per market — all while a copy of the live theme or configuration keeps running independently so the merchant can still edit it. On October 1, 2026, Shopify opened this up to apps: a new read_rollouts scope and a pair of GraphQL queries let third-party apps discover that a Rollout is running and see what it changes.
The blind spot this closes
Before this API existed, a merchant could start a Rollout and nothing in the Admin GraphQL API told an installed app about it. A theme app reading theme settings, a personalization app rendering checkout content, or an app reading discount configuration had no way to know it might be looking at a treatment that's only live for a fraction of traffic, or about to flip entirely when the Rollout concludes. The app wasn't wrong about what it read — it just didn't know the read was partial or temporary.
As of API version 2026-10, apps can call a root rollouts query to list and search active Rollouts, or rollout(id:) to fetch one directly. The response describes what each treatment changes across discounts, catalogs, themes, and checkout and accounts configurations — so an app can check, before it acts on a piece of configuration, whether that configuration is currently part of a live experiment.
Configured allocation isn't effective allocation
The API's documentation is explicit about a distinction that's easy to gloss over: it separates configured trafficAllocation from current effectiveTrafficAllocation, and states plainly that configured allocation alone does not determine effective reach. A merchant can set a Rollout to send 50% of traffic to a treatment, but the API also exposes what's actually happening right now — which won't always match the configured number. An app that reads only the configured split and assumes that's what's live is making the same mistake the pre-Rollouts API made, just one layer deeper: trusting a static value for something that changes dynamically.
Alongside allocation, the API surfaces planned activation and conclusion times and treatment split values, giving an app enough to reason about where in its lifecycle a Rollout currently sits — upcoming, live and ramping, or winding down — rather than treating every Rollout as a single fixed state.
Webhooks tell you to go look again, not what changed
Apps can subscribe to Rollout webhooks covering lifecycle events, effective-allocation changes, and resource changes. The documented pattern is to treat these as notifications to refetch the affected Rollout, rather than as a complete record of what changed — the webhook tells you something moved, and your app re-reads the Rollout to get the current picture. For apps already built around classic webhooks, this will feel familiar: a webhook is a cue, not a payload you can trust as a full diff.
What this means for which kinds of apps
The apps with the clearest reason to adopt read_rollouts are the ones reading resource state that a Rollout can alter: personalization apps rendering storefront content, theme apps inspecting the active theme, and apps that read discount configuration. For each of these, the practical question a Rollout answers is simple — is the data I'm about to act on part of a live experiment right now, and if so, is this visitor in the treatment or the control? Requesting read_rollouts requires merchant reauthorization on existing installations, since it's a new access scope; existing resource scopes still govern the underlying resource payloads a Rollout's treatments describe. That's a real adoption cost, which is exactly why it's worth checking first whether your app's reads are sensitive to Rollouts at all before adding the scope by default.