Feature Request: Durable identifier for AutomaticDiscountApplication on orders

GraphQL Admin API Troubleshooting
1

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:

  1. 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).
  2. 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.

2

Hey @Colby - thanks for flagging this .

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.

4

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!

5

Hey @bkspace - thanks for adding this.

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!

6

As per @Colby’s original input - the order API would be the most important, and as you say is important for reconciliation and usage tracking.

7

Thanks @bkspace - just confirming I’ve logged this on our end :slight_smile: