Currently, when an automatic discount applies to an order, the only field that identifies which discount it was is title on AutomaticDiscountApplication:
{
order(id: "gid://shopify/Order/123") {
discountApplications(first: 10) {
nodes {
... on AutomaticDiscountApplication {
title # the only identifying field
index
value { ... }
allocationMethod
targetSelection
targetType
}
}
}
}
}
title is unsuitable as an identifier for two reasons:
It’s mutable.title is the discount’s display name, which merchants can rename at any time in the admin. There’s no stable reference back to the source discount (e.g. the DiscountAutomaticNode ID).
It’s not guaranteed to be unique. Multiple automatic discounts can share the same title, so matching on it is ambiguous even on a single order at a single point in time.
This contrasts with DiscountCodeApplication, which exposes a code field — a durable string that reliably identifies the underlying discount.
The index field doesn’t help either: it’s documented as an ordered index indicating precedence for calculations, so it’s only meaningful relative to other applications on the same order, not a cross-order identifier.
Why this matters
Any app or integration that needs to reconcile order-level discounts back to the discounts that produced them — reporting, accounting/ERP sync, promotion performance analysis, reconciliation — has to match on title. Because title is both mutable and non-unique, that matching is unreliable: renaming a discount silently breaks it, and two discounts sharing a title make it ambiguous. There’s no way to detect or recover from either case after the fact.
Requested change
Add a durable, unique identifier to AutomaticDiscountApplication (and ideally to the DiscountApplication interface where applicable), such as a reference to the source discount’s ID (DiscountAutomaticNode). This would give automatic discounts the same reconcilability that code already provides for code-based discounts.
You’re right that AutomaticDiscountApplication exposes the basic common discount application fields, but it doesn’t expose a durable source discount ID back to the underlying automatic discount.
I definitely get the reconciliation issue here, especially for reporting, ERP sync, etc.
I’m going to pass this on internally as a feature request for a stable source reference on automatic discount applications, ideally in a way that works across the applicable discount application types where a backing discount object exists. I can’t guarantee anything, but just wanted to let you know I’m passing this on.
For now, there isn’t a clean public API workaround that makes title durable or unique after the fact. If your app owns the discount creation flow, the safest short-term path is to keep any promotion/reporting identifier in your own system and avoid relying on mutable titles.
Let me know if I can clarify anything on our end here.
Thanks for writing this up @Colby, well put. Just wanted to add that this problem exists across multiple surfaces; the order API, storefront API, extension API(s) etc!
Just confirming, are there one or two surfaces where this is creating the biggest blocker for you right now? For example, Admin order API vs Storefront API vs extension APIs, or a specific reporting/reconciliation workflow that breaks because there’s no durable source ID.
I’ll include the broader cross-surface concern in the feature request on our end here, but any concrete examples you can share would make the use case stronger. Hope to hear back soon!
Did you find a work-around for this ? I am in the exact same boat and there doesn’t seem to be a way to figure out the discount_id in the case of automatic discounts…
I checked into this again. There isn’t a product update or timeline I can share yet, and AutomaticDiscountApplication still doesn’t expose a durable reference to the source discount.
I’ve added your report to the existing request. For now, there still isn’t a clean way to recover the automatic discount ID from an existing order. If your app controls discount creation, the best workaround is to persist your own identifier and include a stable token in the title, but that won’t cover historical orders, merchant-renamed titles, or discounts created elsewhere.
I’ll loop back here if anything changes on our end.
