Collection returns null via collection(id:), node(id:), and handle search, but its products are queryable

GraphQL Admin API Troubleshooting
1

Summary

Using a public app’s offline Admin API token, one existing and published collection cannot be read through the Collection object:

  • collection(id:) returns null
  • node(id:) returns null
  • collections(query: "handle:...") returns no results
  • collections(query: "title:...") does not include it

However, the collection:

  • Exists in Shopify admin
  • Is published to multiple sales channels
  • Appears on the storefront
  • Returns the expected products through products(query: "collection_id:...")

The issue persists across multiple requests and days, so it does not appear to be indexing delay. Other collections are readable with the same token.

Reproduction

Using Admin API 2026-01 and an app offline token:

collection(id: "gid://shopify/Collection/<id>") {
  id
  title
  handle
}

Returns:

{ "data": { "collection": null } }

node(id: "gid://shopify/Collection/<id>") {
  __typename
  ... on Collection {
    id
    title
  }
}

Also returns null.

collections(query: "handle:<handle>", first: 5) {
  edges {
    node {
      id
    }
  }
}

Returns no results.

By contrast:

products(query: "collection_id:<legacy_id>", first: 250) {
  edges {
    node {
      id
      title
    }
  }
}

Returns the expected products.

Questions

Could this be related to the collection’s type or configuration, such as automated/manual rules or exclusions? Or could it indicate a data-integrity issue?

Is products(query: "collection_id:<legacy_id>") the supported way to retrieve membership in this situation? Is there another supported method for reading the collection object by ID?

2

Hey @Daniel_Moseley - thanks for flagging this.

These symptoms appear to line up with the changes introduced by Shopify’s new Collection model. The collection might be using one or more new source features.

Collections using new source features are intentionally filtered from API versions before 2026-07 because the legacy ruleSet model can’t represent them. This could explain why the collection is missing from collection(id:), node(id:), and searches in 2026-01, while the supported collection_id product filter can still return its membership.

Could you retry the same collection(id:) query against API 2026-07? Shopify’s Collection model changelog confirms that 2026-07 and later return these collections. If it still returns null, please share the x-request-id from that 2026-07 response and I can investigate this further.

Hope this helps!

3

Hey @Wes-Dev-Shopify

Thanks for getting back to me so quickly. I can confirm that the collection returns null on 2026-01 via collection(id:), node(id:), and handle/title search, but resolves correctly on 2026-07. The collection_id: product filter returns membership on both.

The filtering itself is fair enough due to the model changes, but really the issue is that a filtered collection comes back as a plain null (and empty search results), byte-for-byte identical to a deleted or nonexistent one. There’s no error, userError, or extensions warning to tell “filtered for this API version”. On a still-supported version that’s easily interpreted as missing data; our app read it as an empty collection and a merchant-facing feature silently failed and did nothing, with no error to catch.

I’ll work around it for now, but just some feedback for the team to ideally return an explicit signal instead of null when a collection is filtered for representability. That’d let apps detect it and prompt an API upgrade rather than fail silently. We’re migrating to 2026-07 regardless since collections are a big part of what our app does, but any app on an older supported version hits this blind.

Thanks again!

4

We encountered the same issue today, and Shopify’s response has been unacceptable.

Shopify Plus Support dismissed it as “expected behavior” and “not a breaking change.” But when existing queries on a supported API version can no longer retrieve newly created collections, that is clearly a breaking change.

The changelog was only published on June 17, 2026, leaving merchants less than one month to upgrade. In a serious corporate environment, API changes require impact assessment, development, testing, approval, and controlled deployment. One month is simply unreasonable.

I am now forced to spend significant time dealing with the impact of Shopify’s irresponsible decision. Once this is resolved, I intend to share the experience on SNS. Businesses deserve to know how Shopify repeatedly forces disruptive changes on merchants and developers without adding real business values.

6

We are having the exact same issue as OP.

Our app is on API version 2026-04 and has been since API release and our codebase has worked.

Today, all out of the sudden, queries to:

query collectionSettings($id: ID!) {
collection(id: $id) {
[WHATEVER]
}
}

return:

{
"data": {
"collection": null
},
"extensions": {
"cost": {
"requestedQueryCost": 1,
"actualQueryCost": 1,
"throttleStatus": {
"maximumAvailable": 20000,
"currentlyAvailable": 19999,
"restoreRate": 1000
}
}
}
}

And now our system is throwing errors all around because of this.

If our app is on 2026-04 why are we dealing with this?

7

I must have missed the heads up in the changelog :confused: was it reported there?

Our merchants are also suffering as a result of these being invisible to older api versions

Bumping to a new version isn’t something that can easily be done over night. Any way for the Shopify dev team to alleviate the pain here @Wes-Dev-Shopify?

8

Chiming in here with our experience. This broke a lot of things related to collections for our app and we were getting a ton of complaints from merchants. Our backend also uses the Shopify API ruby gem, and as of the time of this comment, the gem does not yet support 2026-07 (source). Because of this, I was forced to update our graphql api version without updating our rest api version (not ideal :confused: ).

I have to say that, while introducing breaking changes to new API versions would be considered standard procedure, introducing updates that suddenly break the existing (still-supported) API versions is extremely surprising behavior. In fact, it would sort of negate the whole idea of using API versioning to begin with. Surely this was inadvertent?

9

Can someone from the Shopify dev team tell us what is going on?

Why did all of us were forced to update from one day to another to an API version at gun point?

Is this the way we should expect API releases to be now? Break everything and acknowledge frustrations but do nothing later?

10

Shopify Plus support’s response (see below) is a complete joke. They’re forcing the new collection model with zero opt-out, making new collections invisible on pre-2026-07 API versions. No fallback, no backward compatibility, no grace period, no active alarm—just straight-up breaking production setups. And they have the straight face to call this “expected behavior”.

Imagine paying enterprise-tier Shopify Plus prices just to get held hostage by forced, unscheduled API upgrades just to query basic store data. It’s sabotaging live business operations and dumping garbage tech debt on devs because Shopify genuinely does not care about ruining merchant workflows. Typical Shopify behavior.

_________________________________________________

Jess (Shopify Plus Support)

Jul 23, 2026, 09:11 EDT

Hi Tom,

Thank you for your patience while we looked into this further.

After reviewing the findings from both your conversations with our team, I can confirm that my colleague’s explanation on your other ticket is correct. This is expected behavior tied to the new collections model that shipped with API version 2026-07.

Collections built using the new model are intentionally filtered out from API versions prior to 2026-07, because the legacy data structure cannot represent them. This applies to direct node lookups, list queries, and all other collection-returning fields on older versions. The only resolution is to update your API version to 2026-07 or later, which is the only way to see and manage all collections in your shop.

On the migration side, deprecated fields remain queryable in 2026-07, so you can migrate without breaking your existing queries. More details are in our documentation below:

We understand this creates urgency on your end while your team works through testing. If you run into anything specific during your migration to 2026-07, please don’t hesitate to follow up and we are happy to assist.

11

Hey folks - thanks to everyone who’s shared feedback of the impact on your apps and merchants. We’ve heard the feedback and have some additional context to share for clarity.

To start, it’s important to mention that collections that only use features supported by earlier Admin API versions remain readable and manageable in those earlier versions. The null response only occurs when a collection uses new model features that versions before 2026-07 can’t represent.

Regarding collections using the new model/features, I want to manage expectations and be transparent that this null filtering behaviour on versions earlier than 2026-07 won’t change. The supported path is to move affected collection queries to Admin API 2026-07 or later.

If you’re facing a specific migration blocker, let us know where you’re stuck. The more context we have about how these changes are affecting your apps, the more we can help work through it with you and identify any gaps along the way. There is also this Community thread where a number of different questions have been addressed that you may want to take a look at as well:

We’re also here to help separate expected API-version behaviour from bugs that need fixing. If an issue persists on 2026-07 or doesn’t match the documented behaviour, please share the x-request-id from the request and a summary of what you’re seeing that’s unexpected so we can investigate.

For reference, the new Collection model changelog has the migration guidance. We advise keeping an eye on the changelog for the latest updates, especially those marked Action required

I recognize this may not be the exact answer you’re looking for, but I’m doing my best to be transparent about where things stand today. I hope this helps set expectations, and please let me know if I can clarify anything further.

12

Hi Wes,

I believe that this is not true, Wes.

We haven’t implemented any new features. The new collection uses the exact same legacy rules (1 vendor + 1 product type) as our old, working collection.

Stop deflecting this onto us. The issue isn’t us using new features—it’s that your 2026-07 update is breaking backward compatibility on basic, unchanged collections.

13

Just spent the last hour trying to workout why a particular collection on one of my merchant stores wasn’t showing up via the GQL API… then found this thread, I’m honestly pretty shocked that Shopify introduced a breaking change here and didn’t give us forward warning of it.

It seems now when any merchant edits one of their existing collections it will simply disappear from the API :man_shrugging:

14

I am genuinely shocked by Shopify. Imagine if the same happens to products, customers, or orders, the impact could be even more disastrous…Shopify’s attitude and approach are more concerning than this issue alone.

15

Hey folks - these are valid concerns, and I’m sharing this feedback with the team.

Collections that only use features supported by earlier Admin API versions should still be returned by those versions. The documented filtering applies only when a collection uses features the legacy ruleSet model can’t represent.

If you’re seeing what should be a legacy-compatible collection return null, could you share an x-request-ID from a query that’s returning an unexpected null? I’d like to investigate whether the collection is being classified incorrectly.

16

Hi @Wes-Dev-Shopify

Hope that it helps: 779dcfb457904a4617c59fe6d2057990 (return null)

You may also compare it to the below request.
Both collections look the same to me, except the above one is opened after your upgrade.
8a1b5c4fba186f1e846897c69a02a496 (X-request-id)

17

We have ~120.000 error logs that say otherwise.

Tuesday when this issues started to happen for us, our client hasn’t even started to use this feature and most collections were returning null in 2026-01 API version, causing errors all across our application.

Even if hypothetically this feature release from Shopify would have been flawless (which wasn’t and still isn’t), what’s the point of having API versioning if you release a new feature on the latest API version that can affect all the previous versions and potentially break them?

Why not just communicate from the get-go that this will affect everything and that everyone should update? Why not advertise this change in the dev dashboard API Health? Why not advertise this as a banner on the Shopify app backend?

18

We warned Shopify many times that this would happen, they said it’s a non breaking change. We pushed back, but they didn’t want to listen.

Btw, it’s related to this announcement: Introducing the New Collections API (2026-07) — Developer Preview - #99 by Soufiane_Ghzal

@Tronquin just so you know, you’re not alone, this has been a pain in my bottom for the last 4 few weeks. The attitude of Shopify regarding this update is not understandable.

We’ve been stuck between a very short notice to upgrade - other stuff to do - if we upgrade we would potentially break other apps - if we don’t upgrade other apps will break ours - and Shopify claiming it’s non-breaking.

19

For everyone’s information about how Shopify handled this, on june 19 @diana_cheptene said:

20

Hey folks - thanks for the candid feedback. I’m continuing to share it internally. I recognize the direct impact this has had on your apps. If you’re facing any specific migration blockers, please share them here and we’ll do our best to help work through them.

@Tom_Chan - thanks for sharing those trace IDs. You were correct, the collection you reported wasn’t using any new Collection model features. It was affected by a known bug where some newly created collections using only legacy-compatible rules were incorrectly classified as incompatible with API versions before 2026-07.

The fix has now shipped, and we reprocessed the affected collections. I’ve confirmed that your collection now returns as expected on API version 2026-04 and earlier. This was separate from the intended behaviour for collections that use features older API versions can’t represent, which still require API version 2026-07 or later.

Please continue to flag any behaviour that doesn’t match that distinction, or anything unexpected associated with the rollout. The context you shared helped us trace, confirm and resolve this bug.

@jed - we’re also working to move the open PR adding 2026-07 REST API support to shopify-api-ruby forward, although I don’t have an exact timeline. In the meantime, one developer has reported that temporarily switching to the PR branch until a new version is released is working smoothly for them.

Hope this helps!

21

Could that also be added to the shopify_app gem?