Admin GraphQL API / API version 2026-07

App discount inputs'
appliesOnSubscription
default is now false → true (changed)

In the Admin GraphQL API, the DiscountCodeAppInput / DiscountAutomaticAppInput default value has changed. The article states: "No action required; no impact on how discounts are applied at checkout." Apps that set the value explicitly behave the same.

On this page
  1. What actually changed (in 30 seconds)
  2. Diagram: the default value change and its scope
  3. The two affected input types
  4. Before vs. after comparison
  5. Is any action required?
  6. 5 key points developers should know
  7. 3 use cases you can put to work
  8. A one-line summary you can use in proposals

1What actually changed

Used to create or update app discounts in the Admin GraphQL API, the appliesOnSubscription field'sdefault value changed from false to true ..
The article explicitly states: No action required.No impact on how discounts are applied at checkout. Apps that set the value explicitly behave the same.

Before: the default was false

When you created an app discount without passing a value,appliesOnSubscription was implicitly treated as false .

Going forward: the default is true

the default when the value is omitted is now true . If you specify it explicitly, the value you set is used as-is (no impact).

2Diagram: the default value change and its scope

DiscountCodeAppInput Code discounts (app-managed) DiscountAutomaticAppInput Automatic discounts (app-managed) Field default value appliesOnSubscription false → true (this change) appliesOnOneTimePurchase true (no change; true from the start) Scope All active API versions Pinning a version won't let you avoid it
appliesOnSubscription What it is : a flag indicating whether an app-managed discount also applies to subscription (recurring) line items. This time, only itsdefault value when omittedchanged to true .
Also, the article explicitly states: "this does not affect how discounts are applied at checkout".The article gives no details on the reason there is no impact or on the internal behavior..

3The two input types affected

Target

DiscountCodeAppInput

the input type used when creating or updating an app-managed "code discount." This type's appliesOnSubscription default is now true .

Target

DiscountAutomaticAppInput

the input type used when creating or updating an app-managed "automatic discount." Likewise, its appliesOnSubscription default is now true .

appliesOnOneTimePurchase(applies to one-time purchases) fieldalready has true as the default, with no change this time. As a result, when omitted, both subscriptions and one-time purchases end up with the same default of true .

4Before vs. after comparison

ItemBeforeAfter (from 2026-07 / all active versions)
appliesOnSubscription Default value false true
appliesOnOneTimePurchase Default value true true(no change)
Apps that explicitly set the value Behavior is unchanged
Discount application at checkout No impact (stated in the article)
Required action None
Target input types DiscountCodeAppInput / DiscountAutomaticAppInput

5Is action required?

In principle: no action needed

The article explicitly states "No action is required." The change to the default value itself does not affect how discounts are applied at checkout.

Unchanged if explicitly specified

When creating or updating discounts, apps that explicitly pass appliesOnSubscription behave exactly as before.

What the article does not cover

The reason it "has no impact," details of the internal behavior, and the migration schedule (beyond version numbers) arenot described in the article. Check separately if needed.

This change isapplied to all active API versions. Note that the workaround of "pinning to an older version to avoid the impact" does not work (as stated in the article).

65 points engineers should keep in mind

×2

1. Only the two app discount types are affected

The ones affected are DiscountCodeAppInput and DiscountAutomaticAppInput. The article does not mention any other discount input types.

F T

2. Only the "default when omitted" changes

false → true is purely a matter of default resolution. If you pass a value explicitly, the result does not change at all.

3. Applied to all active versions at once

Version pinning cannot avoid it. Even for apps running across multiple versions, the default is unified to true everywhere.

4. No impact on checkout behavior

The article explicitly states there is no change in how discounts are applied. It is positioned as a cleanup of defaults with no user-facing experience change.

SUB

5. The defaults for subscriptions and one-time purchases align

appliesOnOneTimePurchase was already true. This time, appliesOnSubscription also becomes true , andwhen omitted, both now default to true , making them symmetric. That said, since relying on implicit defaults is prone to breakage across version differences, for new implementationsthe convention of explicitly specifying both fieldsis safer.

73 use cases you can apply in your work

USE CASE 1

Auditing discount app mutations (identifying implicit default dependencies)

Challenge
Your own discount app does not explicitly specify appliesOnSubscription , relying instead on the implicit false may have been relying on the default.
Action
Search all mutation calls that create or update app discounts and check whether they explicitly specify the field in question. Rewrite any unspecified cases to set it explicitly.
Benefit
Ensures deterministic discount behavior that isn't affected by API versions or default changes.
Technical notes
The article explicitly states that 'behavior is unchanged if already explicitly specified' and 'there is no impact on checkout.' This is a quality-maintenance audit, not an emergency fix.
v1 v2 v3 true
USE CASE 2

Eliminating default differences in apps running multiple API versions

Challenge
The app runs across multiple API versions, and the differences in defaults between versions create confusion and branching in tests.
Action
On the premise that, across all active versions, this change has standardized it to true, update the internal documentation, type definitions, and test expectations.
Benefit
Reduces version-dependent conditional branching and consolidates the expected values in regression tests.
Technical notes
Applies to all active versions, as stated in the article.appliesOnOneTimePurchase was originally true , so they're easy to tidy up at the same time.
subscription: T oneTime: T
USE CASE 3

Make 'being explicit' about the subscription discount spec a team convention

Challenge
The discount spec relies on implicit defaults, so during code review or handoff it's hard to tell whether 'it applies to subscriptions,' which leads to misunderstandings.
Action
In the discount-creation mutation, appliesOnSubscription and appliesOnOneTimePurchase arealways specified explicitly; adopt this as a coding convention.
Benefit
Advances self-documentation of the spec, stays unaffected by default changes, and prevents inconsistent interpretation during review.
Technical notes
If you specify it explicitly, you won't be affected by this default change (stated in the article). Adding it to your linter / code-review checklist helps it stick.

8One-line summary you can use in a proposal

'The app discount input (DiscountCodeAppInput / DiscountAutomaticAppInput)'s appliesOnSubscription default has changed to false → true .
No action required; no impact on how discounts apply at checkout; behavior is unchanged if already explicitly specified.
Because it applies to all active API versions, it's safest to take this opportunity to fully commit to "stop relying on defaults and specify explicitly."'