Shopify Admin GraphQL API not returning a specific product when combining status and updated_at filters

GraphQL Admin API Troubleshooting
1

I am encountering an issue while fetching bulk products from the Shopify Admin GraphQL API using query filters.

When querying products with updated_at and a specific id, the API correctly returns the product data. However, when I add a status filter (ACTIVE and DRAFT) to the same query, the API does not return the product, even though the product exists and matches the criteria.

Working Query

This query successfully returns the product:
query {
products(
first: 250
query: “updated_at:>2026-01-12T11:12:54Z AND id:8982301999341”
) {
edges {
node {
id
legacyResourceId
title
vendor
productType
publishedAt
status
updatedAt
}
}
}
}

Non-working Query

This query does not return any data for the same product:
query {
products(
first: 250
query: “status:ACTIVE,DRAFT AND updated_at:>2026-01-12T11:12:54Z AND id:8982301999341”
) {
edges {
node {
id
legacyResourceId
title
vendor
productType
publishedAt
status
updatedAt
}
}
}
}

2

Hi @Manish_Buddhacharya,

This could be expected behaviour if the product is in Draft status, due to how you are filtering by status.

When you want to search for multiple values with the same filter, you should be using the OR boolean, not separating them by commas.

Here’s an example of how you can update your second query to correctly filter by status Active or Draft, additionally to ensure the updated_at filter is parsed correctly, you need to pass the timestamp in quotation marks:

query: "status:ACTIVE OR status:DRAFT AND updated_at:>'2026-01-12T11:12:54Z' AND id:8982301999341"

Here is some Shopify.dev documentation that discusses the search syntax in further detail.

If the same issue is occurring after updating the query filters with the OR boolean, please share with us the x-request-id from a specific api call that’s not returning the expected product, and we can absolutely help look into it further.

3

Hi,

Thanks for the explanation. I’ve tried updating the query exactly as suggested, using the OR boolean for status and wrapping the updated_at timestamp in quotes. Unfortunately, the behavior is still the same as before — the query does not return the expected product.

Here are the details for reference:

  • Request where the product is missing (with status filter applied):
    x-request-id: 50488ca1-896b-4c28-934c-bf04ef212ffc-1768280390

  • Request where the product is returned (status filter removed):
    x-request-id: 5745fdb8-f2de-4cb0-8d81-5f01e4c4c153-1768280277

In the second request, when the status filter is removed, the same product (which is Active) is returned correctly. However, it is missing in the first request when filtering by status:ACTIVE OR status:DRAFT.

Please let me know if you need any additional details from my side.

4

Hi @Manish_Buddhacharya,

Thanks for sharing that context, I’ve looked into these queries and I do see what’s going wrong here.

First of all, I’d like to apologize as I did give some incorrect information in my previous post. The status filter does actually support comma separated values, so the previous query you were using would be expected to work as well, with status:ACTIVE,DRAFT.

Most filter values do not support comma separated strings, and it is mentioned specifically in the documentation for the status filter.

Documentation mentioning comma separated values:

Other filters typically don’t support comma separated values, and require the use of the OR operator, as seen with the vendor filter for example:

As for the actual issue here, this is occurring because the status of the actual product you are querying is UNLISTED, instead of ACTIVE or DRAFT.

If we filter by the UNLISTED value, the expected product is returned.

The issue here is that you are calling the 2025-01 version of the API, where the UNLISTED status was added in the more recent version, 2025-10.

The documentation for the Product object does mention this, and does indicate that for older API versions the UNLISTED status is translated to ACTIVE, which explains why the actual product returned does show status: ACTIVE even though the actual status of the product is UNLISTED

The remaining question here is, if it is expected with older API versions if UNLISTED products should be returned when filtering by status:ACTIVE or not, since the status is translated and displays as ACTIVE.

I will be discussing this with our developers further to confirm the actual expected behaviour here, and I will follow up with an update once we have more information. Though in the meantime you can workaround this behaviour with the following query instead:

products(first: 250, query: "updated_at:>'2026-01-12T11:12:54' AND id:8982301999341 AND status:ACTIVE OR status:DRAFT OR status:UNLISTED")

1 Like