Introspection API - Version 2025-04 - Response broken

GraphQL Admin API Troubleshooting
1

We rely on introspection query to generate GraphQL queries programmatically.

We are using Post end point - /admin/api/2025-04/graphql.json

Introspection query -

query IntrospectionQuery {
__schema {
types {
name
kind
isOneOf
fields {
name
type {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
ofType {
name
kind
isOneOf
__typename
}
}
}
args {
name
type {
kind
name
ofType {
kind
name
}
}
}
}
}
}
}

We don’t change the version and stick to 2025-04 version.

Suddenly we see that couple of fields from products is not returned in the query response.

  1. data.products.edges.node.resourcePublicationOnCurrentPublication.isPublished
  2. data.products.edges.node.resourcePublicationOnCurrentPublication.publishDate

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

2

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
            }
          }
        }
      }
    }
  }
}
1 Like
3

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:

  1. Revert the deprecation status for isPublished and publishDate within the 2025-04 version specifically, to restore the schema to its original “released” state.

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

4

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
            }
          }
        }
      }
    }
  }
}
5

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?

6

Waiting on your response as its currently breaking our pipelines