We understand that its marked deprecated in the version, but as long as we are on the version 2025-04, we expect the query response to not change. This breaks our subsequent pipelines as the programmatically generated query now changes.
Could you please help restore this field for the version 2025-04
The introspection query should additionally provide includeDeprecated as part of the introspection query (see spec). The default is false resulting in that content appearing missing, but still being accessible ( Product - GraphQL Admin , ResourcePublicationV2 - GraphQL Admin ).
query IntrospectionQuery {
__schema {
types {
name
kind
isOneOf
fields(includeDeprecated: true) {
name
type {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
}
}
}
args(includeDeprecated: true) {
name
type {
kind
name
ofType {
kind
name
}
}
}
}
}
}
}
Thank you for the clarification regarding the includeDeprecated argument within the GraphQL introspection specification.
While we understand the technical mechanics of the includeDeprecated flag, we would like to highlight a significant concern regarding the Schema Stability of the 2025-04 versioned endpoint.
Our team relies on this specific version as a frozen contract. A core requirement of our automated pipeline is to work exclusively with non-deprecated fields to ensure maximum stability and longevity for our integration. By flagging these fields as deprecated mid-lifecycle within a “stable” version, Shopify has effectively “hidden” them from our default introspection, breaking our programmatic query generation.
This creates a contradiction in the versioning logic:
To maintain our existing functionality, we are now forced to manually enable includeDeprecated: true.
This fundamentally undermines our goal of building against a stable, non-deprecated schema, as our tools can no longer distinguish between truly active fields and those slated for removal.
If these fields were intended to be deprecated, our expectation is that such a status change would occur in a subsequent API version (e.g., 2025-07), leaving the 2025-04 schema metadata exactly as it was at release.
We kindly request that you consider the following:
Revert the deprecation status for isPublished and publishDate within the 2025-04 version specifically, to restore the schema to its original “released” state.
Ensure that deprecation flags are only introduced in new version releases, rather than retroactively updating the metadata of an active, stable version.
We value the versioning system Shopify provides, but its utility is greatly diminished if the introspection response—and the definition of what is “stable”—changes dynamically within a fixed version.
It is a fair criticism of our APIs and common point of friction with introspection having a poor default. Our recommended work around is to always ask for deprecated schema members as it remains functional (valid according to the schema) until it is removed from the schema as of an API version. There is no guarantee that @deprecated will be annotated before a schema member is removed from an upcoming version.
This fundamentally undermines our goal of building against a stable, non-deprecated schema, as our tools can no longer distinguish between truly active fields and those slated for removal.
Can the isDeprecated field exposed by introspection help distinguish this?
query IntrospectionQuery {
__schema {
types {
name
kind
isOneOf
fields(includeDeprecated: true) {
name
isDeprecated
type {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
}
}
}
args(includeDeprecated: true) {
name
isDeprecated
type {
kind
name
ofType {
kind
name
}
}
}
}
}
}
}
We understand the technicalities in the design.
And its fair for you to mark certain fields deprecated.
However, thinking from the user perspective, they want to subscribe to a contract and assume its fixed. We want to deal with non-deprecated fields as default and do not want to commit to our customers on deprecated fields, because its going to break their pipelines later.
That said, we are okay to mark fields deprecated, as long as they are marked in the latest/current release indicating that future releases won’t have these fields. What is the need to come back to older release and change the state to deprecated which affects the contract?
At this time, there are no plans to adjust our approach to this nuanced topic.
We appreciate this objective, and something we try to promote in our own way by communicating early about upcoming changes (deprecation is retroactively applied). We are trying to decrease the quantity of breaking changes, but the system does need to evolve through new information and requirements.
GraphQL spec provides Introspection as a standardized way to fetch metadata about the schema. Over the years, the spec as evolved and how to fetch the complete metadata about the schema has evolved. Notably you have to opt-in to using includeDeprecated: true because at one point it was not spec defined and had to remain backwards compatible.
Our stance is that the schema should be stable within a version as much as possible, including introspection subschema. Similar to normal APIs, the response values can change based on the provided/omitted input arguments and the backing data. With introspection being a metadata API, its schema remains stable, but the data about the API can change (e.g. updated description, additional enum value, custom introspection fields).
To recap, our advice is that tooling should always ask for deprecated content as it remains functionally valid until it is removed from the schema as of a future API version. For tools that want to go further within a version, the isDeprecated field can distinguish state. Use a schema diff between versions to verify change/removal of schema members.