Shopify Rollouts API: What Discount Apps Must Handle in 2026-10

The Shopify Rollouts API lets a merchant place a discount in a rollout to coordinate a launch, test it on part of the traffic or schedule it with other store changes. For apps that read discounts, that creates a trap: a discount’s status no longer tells you whether buyers can use it. This guide explains the behavior change in API 2026-10, the steps Shopify gives discount apps and the webhook topics for staying in sync. Checked against Shopify’s discount Rollouts guide, the Rollouts changelog and the discounts in Rollouts announcement.

What Rollouts Are

Shopify describes Rollouts as coordinated launches, experiments and temporary events that can span discounts, catalogs, themes and checkout and accounts configurations. API 2026-10 adds two Admin GraphQL queries, rollouts and rollout(id:). A rollout has a schedule, a configured trafficAllocation, an effectiveTrafficAllocation and treatments, and each treatment describes how it affects resources such as discounts. Reading rollout data requires the read_rollouts scope, and existing installations may need merchant reauthorization.

Why Discount Status Can Now Be Wrong

A serving rollout can add or remove a discount for the buyers it reaches, but it does not change the discount’s own dates or configuration. The guide spells out what that means for status, which is still derived from startsAt and endsAt.

• A treatment that activates the discount can give it to buyers even when status is SCHEDULED or EXPIRED.
• A treatment that expires it for everyone leaves status as ACTIVE while no buyer gets it.
• A treatment that expires it for some buyers leaves status as ACTIVE while those buyers do not get it.

Only a serving rollout changes buyer access. Draft, scheduled, paused, concluded and archived rollouts leave status accurate. Shopify also notes that API versions before 2026-10 omit affected discounts from lookups and connections such as discountNode, discountNodes, codeDiscountNodes, automaticDiscountNodes and automaticDiscounts, with no error to explain why. Nothing is removed or retyped in the schema.

What Discount Apps Must Change

1. Upgrade the API version to 2026-10, since older reads can silently drop rolled-out discounts.
2. Request read_rollouts alongside read_discounts.
3. Add the rollouts selection behind a scope check. Without the scope, an ACCESS_DENIED error propagates to discountNode, which returns null.
4. Filter rollouts with query, for example status:ACTIVE,SCHEDULED, where a comma acts as OR. Unfiltered results include drafts and concluded rollouts.
5. Paginate while pageInfo.hasNextPage is true.
6. Read treatment changes when you need to know what a rollout does to a discount, and check each change’s __typename.
7. Re-read discounts on rollout events and reconcile periodically.
8. Never delete local records because a read no longer returns a discount. Treat it as unavailable.
9. Show rollout context to merchants, such as name, status and traffic allocation, and do not rely on status for buyer-facing decisions.

The query below is adapted from the guide’s condensed sample. It reads the active rollouts that affect one code discount.

query DiscountRollouts($id: ID!, $cursor: String) {
  discountNode(id: $id) {
    discount {
      ... on DiscountCodeBasic {
        title
        status
        rollouts(first: 10, after: $cursor, query: "status:ACTIVE") {
          pageInfo { hasNextPage endCursor }
          nodes {
            id
            name
            status
            schedule { activateAt concludeAt }
            startedAt
            concludedAt
            effectiveTrafficAllocation
          }
        }
      }
    }
  }
}

The rollouts connection comes from the HasRollouts interface and is available on the eight built-in discount types: DiscountAutomaticApp, DiscountAutomaticBasic, DiscountAutomaticBxgy, DiscountAutomaticFreeShipping, DiscountCodeApp, DiscountCodeBasic, DiscountCodeBxgy and DiscountCodeFreeShipping. Treatment changes use RolloutDiscountActivateChange and RolloutDiscountExpireChange.

Partial Traffic and Promotion Safety

trafficAllocation is the configured value. effectiveTrafficAllocation is the share of new buyer assignments after conflicts with other active rollouts are resolved, so it can be lower. Neither measures actual buyer reach. Shopify also says discounts activated at 100% effective traffic are available across sales channels subject to normal eligibility, while partial-traffic activation applies to the Online Store only.

The guide’s rule for promoting a discount is strict. Promote it only when effectiveTrafficAllocation is 100 and one treatment activates it with a split of 100, and even then treat that as a strong signal and not a guarantee, because control arms, eligibility rules and market-specific application are not covered. If hasNextPage is true on rollouts or on changes, or a change’s resource is unreadable, treat the discount as restricted.

Webhook Topics for Rollouts

In 2026-10 the rollout webhook topics require read_rollouts and are app-only subscriptions.

• rollouts/create, rollouts/update and rollouts/delete report the rollout itself. Archiving produces rollouts/update, and a competing rollout that changes the effective allocation also triggers it.
• rollouts/resource_change_added, rollouts/resource_change_removed and rollouts/resource_change_updated report changes to a treatment.

Payloads are small. The resource_change_* topics contain only identifiers and occurred_at, and no payload includes treatments or changes, so re-query the rollouts connection after every event. Shopify warns that webhooks can be missed, and that merchants can pause or conclude a rollout early without the schedule showing it.

Our Analysis: Build for Uncertainty

Make availability a computed value. Our suggestion is to stop storing a single boolean for whether a discount is live. Compute it from status, rollouts and effective allocation each time, and record why it is restricted.

Reconcile on a schedule. Because webhooks can be missed and the schedule can be overridden, combine the topics with a periodic re-read, and refresh around schedule.activateAt and schedule.concludeAt. Our webhook setup and debugging guide covers the delivery side.

Report partial discounts honestly. A discount that reaches part of the traffic should not receive store-wide credit in analytics, a point the guide makes directly.

Handle the missing scope. Merchants must grant read_rollouts, so build a fallback for stores that have not. See our 2026-10 upgrade checklist for the other items to review in the same release.

FAQ about the Rollouts API

Do I have to change anything if I do not use discounts? The changelog tag for discounts in Rollouts is marked as action required for discount reads. If your app does not read discounts, there is nothing to change for this feature.

Can I trust discount status? Not for buyer-facing decisions on discounts inside a serving rollout.

Does the connection let me write rollouts? The rollouts connection on discounts is read-only, and the changelog does not describe write behavior.

Is there a deadline? The changelog states no upgrade deadline. The change takes effect on API version 2026-10.