Executive summary
- What: Shopify removed the Discounts Allocator Function API and closed its developer preview. The registration mutations are gone from the unstable Admin GraphQL API, and functions registered during the preview have already been unregistered for you.
- Why: Native discount handling improved while the preview was open, including stacking multiple product discounts on one cart line. Shopify judged that platform logic now covers most of what the allocator was built for.
- Who: Only app teams that joined the preview, or whose configuration still declares the purchase.discounts-allocator.run extension target. Every other app is untouched.
What changed
The Discounts Allocator Function API let an app control how a discount was spread across the lines in a cart. It never reached a stable version, and the preview carrying it has closed rather than graduated. The register and unregister mutations were pulled from the unstable Admin GraphQL API, preview functions were unregistered without developer action, and the reference and build tutorial were removed from the documentation.
One consequence deserves more attention than the removal itself. If your configuration still declares the purchase.discounts-allocator.run target, a deploy fails for the entire app rather than that one extension, with an error naming a target the platform no longer knows. Published releases stay installable and the rest of the app keeps working, but their allocator functions no longer run. The failure surfaces on the next deploy, usually part way through an unrelated release.
Why it matters
For most Shopify Plus merchants this is close to a non event. The API never shipped in a stable version, so nothing in a live storefront depends on it. The part worth tracking is second order: if an app vendor you rely on still carries the extension target, their whole deployment pipeline is blocked until they remove it. Unrelated fixes queued behind it sit still until someone clears the target.
The other signal is directional. Shopify is consolidating discount allocation into platform logic rather than opening it to custom code, and native stacking covers much of what teams once used a custom allocator for. If your promotional model depends on which line absorbs which discount, the practical path is the Discount Function API plus disciplined testing, as in our notes on complex discount logic at enterprise scale.
Role-specific impact
- Marketers: Campaigns already running are unaffected. If a planned promotion assumed an app could hand pick which line absorbs a discount, confirm native stacking covers it before committing to the calendar.
- Developers: Search your app configuration for the purchase.discounts-allocator.run target and remove the extension block ahead of the next release, not during one. Rebuild on the Discount Function API if the allocator carried real behavior.
- Store admins: Nothing to change in the admin. If an app partner reports a release is stuck, this deprecation is a reasonable first question.
Use-case example
Real-world scenario
A Plus merchant in specialty food runs a private app that joined the preview to control how a spend threshold discount landed across bundled lines, so refunds returned the right amount per item. Nobody has touched that extension in months. During a routine sprint the team ships a fix to a checkout UI extension correcting a shipping message shown on roughly 8 percent of orders. The deploy fails, and the error names a discounts allocator target rather than anything they changed, so the first hour goes to the wrong file.
The actual fix is a short deletion in the app configuration. The cost is that misdirected hour plus a delayed release on a message generating support tickets daily.
Implementation checklist
- Search your app configuration and extension directories for purchase.discounts-allocator.run.
- Remove the extension block and its directory entirely if the target is present.
- Delete any remaining code paths calling the allocator register or unregister mutations.
- Deploy against a development app first to confirm the build passes cleanly.
- If the allocator carried real behavior, rebuild on the Discount Function API and test against your promotion mix.
- Re-test refunds and partial cancellations, since allocation drives how money is returned per line.
- Tell the merchant which releases contained allocator functions, because those functions stopped quietly rather than failing loudly.
FAQ
Q: Do we need to act if our app never joined the preview?
A: No. If your configuration has never declared the purchase.discounts-allocator.run target, nothing changes and no deploy will fail because of this.
Q: Did storefronts break when the functions were unregistered?
A: No. Allocation fell back to platform logic. The risk is quiet rather than loud: a promotion may now split across lines differently than intended, surfacing in refund amounts rather than cart totals.
Resources
Shopify documents the supported path in the Discounts developer documentation.
Need guidance? Talk to Makro.