the next admin API version: fields removed, and which apps feel it.

Shopify ships a new API version every quarter and supports each one for at least twelve months. That rhythm is predictable, which is exactly why version bumps get missed: nothing breaks on release day. It breaks months later, when the version your integration pins to falls out of support and requests are served by a newer one your code was never tested against.

what changes when a new admin API version ships?

Each new stable version of the GraphQL Admin API adds fields and types, and removes or changes some that were deprecated in earlier versions. At the same time, an older version moves closer to the end of its support window. Which fields go differs every cycle, so the release notes for the version you are moving to are the only list that counts. The method below works whichever fields are on it.

The rule that matters: when a version you call is no longer supported, Shopify serves your request from the oldest supported version instead. Your code keeps running, but against a schema that may no longer contain the fields it expects. That is how integrations fail quietly.

which apps and integrations feel it?

• Custom and private apps that pin an API version in their client config and have not been touched in a while.
• Middleware and ERP, WMS or CRM integrations that call the Admin API directly. These are the usual culprits, because they belong to a different team.
• Webhook subscriptions, which carry an API version too and shape the payload you receive.
• Scripts and one-off jobs: bulk operations, data exports, scheduled syncs.

Public apps from the App Store are the vendor’s responsibility, but their failure is still your incident. Ask.

what we’d do

Start with what you actually call, not with what the changelog says.

1. Find every caller. Search your repos and your integration platform for the API version string. Check the partner dashboard or app settings for the version each custom app uses, and check the version on each webhook subscription.
2. Read the deprecation warnings you already have. The partner dashboard reports deprecated API calls per app, and deprecated fields are marked in the schema itself. Between the two, you may already have a list.
3. Diff your queries against the new schema. For each query and mutation, confirm every field still exists in the target version. Generated types make this a compile error rather than a production one.
4. Bump, test, ship. Move one integration at a time to the new version on a dev store, run the jobs end to end, compare output with production, then deploy.
5. Set the next date. Put the support end date for your new version in the calendar now. Quarterly is a cycle, not an event.

# Pin the version explicitly in the endpoint, never rely on a default.
# /admin/api/<version>/graphql.json
query ProductCheck($id: ID!) {
  product(id: $id) {
    id
    title
    updatedAt
  }
}

checklist

• Every app, integration and script that calls the Admin API is listed.
• The pinned version is recorded for each, including webhook subscriptions.
• Deprecated-call reports are reviewed in the partner dashboard.
• Queries are checked against the new schema.
• Each integration is bumped and tested on a dev store.
• The next support end date is in the calendar.

impact

Action needed for anyone running private apps or custom integrations. If everything you run is a maintained public app, confirm with the vendors and move on.