Executive summary
- What: Admin GraphQL API version 2026-10 adds a read-only rollouts connection across Discount types, because merchants can now include discounts in Rollouts.
- Why: A discount's own start and end dates no longer describe what buyers get while a Rollout is serving, and earlier API versions omit affected discounts entirely.
- Who: Any app or integration that reads discounts, including ERP, reporting and promotion tooling.
What changed
Merchants can put a discount into a Rollout to coordinate a campaign launch, test a discount with a share of buyers, or run a temporary event alongside other store changes. The Rollout has its own schedule. While it is serving, a treatment can add the discount for the buyers it reaches or remove it for them, without altering the discount's own dates or configuration.
The consequence is that status and reality can diverge. A treatment that activates the discount leaves status as SCHEDULED or EXPIRED while the buyers in that treatment receive it. Treatments that expire it for everyone leave status as ACTIVE while no buyer receives it. A treatment that expires it for some buyers leaves status as ACTIVE while those buyers do not get it. Only a serving Rollout does this: while a Rollout is draft, scheduled, paused, concluded or archived, status is accurate.
On versions earlier than 2026-10, Shopify cannot represent a Rollout, so it filters those discounts out. An excluded discount disappears from discountNode lookups by ID, from the discountNodes, codeDiscountNodes, automaticDiscountNodes and automaticDiscounts connections, from discountNodesCount, and from the discount connections and counts on Market. Nothing in the response explains the absence. Upgrading to 2026-10 removes the exclusion.
Why it matters
A silent omission is the worst failure mode an integration can have. A promotion or margin sync on an older API version will not error when a discount vanishes mid-event, it will simply behave as though the discount never existed, and reconciliation will look clean. Teams running complex discount logic at enterprise scale should treat this upgrade as remediation rather than an enhancement.
There is also a channel detail worth knowing. A discount activated at 100 percent effective traffic is available across all sales channels, subject to the normal eligibility rules. Partial-traffic Rollout activation applies on the Online Store only. An integration that assumes a partial test reaches POS or a custom storefront will overstate its coverage.
Role-specific impact
- Marketers: You can test discounts against a share of buyers and schedule them alongside theme and catalog changes as one coordinated event. Read effective reach rather than the configured percentage when interpreting results.
- Developers: Move to 2026-10, add read_rollouts, query the rollouts connection on discounts, and combine Rollout schedule fields, effective allocation and treatment splits with the discount's own start and end dates before concluding anything about availability.
- Store admins: Discount status in reports and connected systems may not match what shoppers see during a Rollout. Check whether a Rollout is serving before escalating a discrepancy.
Use-case example
Real-world scenario
A housewares merchant on Shopify Plus runs a two-week Rollout testing an automatic 15 percent discount against 30 percent of online store buyers. Its ERP, still on version 2026-04, syncs active promotions nightly for margin reporting. Because the discount's status differs from what its dates imply, the ERP stops seeing it entirely and reports two weeks of full-margin orders, overstating gross margin on several thousand orders until someone catches it in the monthly close. Upgrading to 2026-10 and reading the discount's rollouts connection keeps the discount visible and makes its partial reach explicit.
Implementation checklist
- List every system that reads discounts from the Admin API, including reporting, ERP and middleware.
- Check the API version each one uses, and flag anything below 2026-10 as at risk of silent omission.
- Upgrade those integrations to 2026-10 and add the read_rollouts scope, planning for merchant reauthorization.
- Query the rollouts connection alongside the discount's own start and end dates wherever you determine availability.
- Read effective allocation and treatment splits rather than configured traffic allocation.
- Account for partial activation applying to the Online Store only, not to POS or custom storefronts.
- Run a test Rollout on a development store and confirm your integrations report the discount correctly throughout its lifecycle.
FAQ
Q: Do discounts outside Rollouts behave differently now?
A: No. Discounts that are not part of a Rollout behave exactly as before, governed by their own dates and configuration.
Q: How do we tell when status is unreliable for a given discount?
A: Read the discount's rollouts connection. If a Rollout affecting it is serving, treat status as a statement about the discount's own dates rather than about what buyers actually receive.
Resources
Discount Rollouts upgrade guide
Need guidance? Talk to Makro.