Shopify Community AMA with Shopify Developers: The New GraphQL Product APIs

[Jacqui]

Join us Tuesday, June 18th from 11 am to 1 pm ET for a live AMA where our team will answer questions on the new GraphQL Product APIs announced in the 2024-04 stable API release.  Hit "Reply" below to ask your questions before June 18th, 2024 and we’ll answer them live, or bring your questions to be answered on the day of.

What to know:

The new GraphQL product APIs that support up to 2,000 variants per product were recently launched in the 2024-04 stable API release, enabling developers to build support for larger and more complex catalogs. Alongside the release of the new GraphQL product APIs, we also announced deprecations of the REST product APIs, as well as several fields within the existing GraphQL product APIs. 

This AMA is an opportunity to interact with the developers who built these APIs to get any questions on both the new APIs and associated deprecations answered.  

In advance of the session, please review the API documentation on the new GraphQL product APIs, our FAQ and our relevant community discussions.

Rules of engagement:

We’ll do our best to follow up on every question during the event.

• You must be logged into your account on Community to participate.
• Assume positive intent with one another and be kind. Some users may be new and learning how to engage with the Community. 
• Be authentic and honest with your questions and answers.
• Do not ask for or share store admin login details or passwords.
• Like posts and threads that are of interest or helpful to you.
• Be constructive with criticism, not offensive.
• Share your experiences and insights whenever you can to support others. 
• Abuse, harassment, and spam content won’t be tolerated.

[Eligijus]

With the new GraphQL update and deprecation of image updates we got image conversion and background removal killed.

If we cannot upload different extension images (from png to jpg or from jpg to png) - all image optimization apps loose the ability to save a lot of space for customers and all background removal apps loose the ability for automation: automatically re-upload a png image with the removed background that was jpg.

Can you please allow us to upload different extension images for products and collections ?

[Eligijus]

I've been communicating with Shopify support and there are no clear plans for this. We are optimizing over 50 million images each year and around 6 million of them are converted from png to jpg. Removing this functionality will impact 20 thousand stores from our app alone. 

[AsafGitai]

Hi @Eligijus 

I think you are referring to the migration of productUpdateImage -> productUpdateMedia where we don’t allow the filename or extension to be changed in that mutation - right? This should be able to be changed through the fileUpdate call using the filename input parameter. If you are looking to update the file itself - even if it’s associated with a product - fileUpdate should work here.

[Eligijus]

No, I was referring to fileUpdate. I cannot upload a file with a different extension. If the original image is png, I cannot upload a jpg. If the image is jpg, I cannot upload png. The file extension must match currently and this will kill a lot of functionality that we had before.

Even if you guys think It should allow different file extensions - the devs should update It asap as It's expected behaviour. 

mutation FileUpdate($input: [FileUpdateInput!]!) {
    fileUpdate(files: $input) {
        userErrors {
            code
            field
            message
        }
        files {
            alt
            ... on MediaImage {
                id
                image {
                    url
                }
            }
        }
    }
}

[AsafGitai]

I'll pass this to the relevant team

[OliUK]

Hi there,
Thanks for doing this. 

I've got two questions:

1. Simple, but consequential... Are we correct to assume that GraphQL IDs will always follow this pattern 

`gid:/shopify/Resource/123` where 123 is the REST ID? or may the numbers in the IDs diverge at some point in the future?

2. Could you touch on any plans you have for Product and Variant webhooks? Are there plans to swap out the variant `option1`, `option2` and `option3` or any other fields?

Thanks a lot,
Oli

[AsafGitai]

Hi @OliUK 

1. At the moment, we are sending the same id as REST for products. That said, we already have examples in the system where the ID is diverging and it is recommended to just parse the value as any valid URI
2. At the moment we dont not have any plans in place for variant webhooks or upcoming changes to the product ones.  If the number of options were to increase we would consider transforming option1,2,3 into an array of option value objects.

[AndreyFourmeta]

Hi! I have a few questions:

1. Is it possible to increase the limits of a specific store much earlier than the beginning of 2025? We want to implement more than three options in the near future.
2. What changes are there in the API regarding the standard work with variants? If I need to get all the variants and make a standard variant selection on the PDP in my headless application, do I need to make any additional changes?
3. We use the Search and Discovery app for a large number of filters. After adding more options, can we discontinue the app and use only filters from the options?
4. Do you plan to add the ability to filter products by multiple types? Currently, it's only possible to filter by one type.

Thank you.

[AsafGitai]

Hi @AndreyFourmeta 

1. While there will be early access to some stores earlier than the beginning of 2025, you can create a dev store today and select extended variant dev preview. As for more than 3 options, this is not ready yet, that said, the API shape will not change. Meaning productOption arrays will just accept more than 3 once we have it in place
2. We are currently shipping improvements to support increased variant limits in the unstable version of the Graphql Storefront API. You can continue to use variant pagination as you do today, but the changes should improve dev ergonomics for displaying option values.
3. For questions 3 and 4, we are following up with our Search and Discovery team and will be posting back here with a response. This could be within our AMA timeframe but if not, we will follow up as soon as possible. Thanks for your patience!

[AndreyFourmeta]

Thanks for your reply! About the dev store: we already have a production Shopify store and want to raise limits, is it possible in the near future, during summer for example?

[AndreyFourmeta]

@AsafGitai could you answer, please?

[kestutisbalt]

Since the REST API is being deprecated, are there any plans to improve the stability of the products and productVariants queries?

Problems I have encountered:

1. There is no way to query products by multiple categories other than using the category query for each category and matching the products ourselves. This makes the operation impractical for stores with thousands of products. Currently, we have to use the productVariants query, which can find product variants by categories, but it does not always return all the results it should. Searching by automated collections is also troublesome, as the search sometimes returns a 500 error or no product variants at all. I have reported these issues many months ago but I haven't heard any progress regarding this. I had to introduce an error message in the app that explains about these issues in Shopify.

2. Please make the https://shopify.dev/docs/api/admin-graphql/2024-04/mutations/productVariantsBulkUpdate  accept variants for multiple products, or at least support partial updates. Currently, if you provide an ID for a non-existent product variant among others, the entire mutation fails.

Thank you.

[AsafGitai]

Hi @kestutisbalt 

1. Sorry to hear about the issues you are experiencing. We are aiming to have parity between REST API capabilities and GraphQL in the near future - EOY.
2. At the moment productVariantsBulkUpdate is intended to work for a single product Id, we are not planning to change that. We are aware of the issue with allowPartialUpdates and this is planned to be fixed soon.

[Nicola_Bizzoca]

What is the story about liquid and ajax frontend api for products which have more than 100 variants (such as /products/tshirt.json)? Seems a topic never addressed in the documentation around this. Even when creating a dev store with the ability to have products with more than 100 variants, the theme provided by Shopify doesn't work correctly once the product have more than 100 variants

[TR_Page]

Agreed that it would be good to hear what are the implications for Shopify themes here specifically - not just apps. At the moment, we have the ability to source variant options directly to themes with Liquid. However, there are restrictions there with loops where 2k variants would become problematic very quickly.

What is the implication for Shopify themes and incorporating more than 100 variant options?

[AsafGitai]

Hi Both,

The Liquid and AJAX apis are both limited to return a maximum of 100 variants per product, we are updating documentation to reflect this. Supporting 2K variants requires theme code changes which will be released in v15.0.0 of our free Shopify themes this month.

Recommended theme changes to support high variant products can be found in our dev docs: https://shopify.dev/docs/storefronts/themes/product-merchandising/variants/support-high-variant-prod...

[dylanpierce]

First off, Shopify's API versioning scheme is 2nd to none. I love the feedback we see in the Partner dashboard and this communication far ahead of the changes. I can see why Shopify is moving to GraphQL, it's more efficient for both partners and Shopify and it gives far more control to only ask for the data you need.

Two questions:

1. I just want to confirm what's on every developers mind - this change is only affecting the Product API right? The other REST APIs aren't deprecating on this same date.
2. Should we expect other REST APIs to be deprecated in the future? If so, can you share which might be deprecated next?


Thanks again!

[AsafGitai]

Hi @dylanpierce 

1. Confirmed, the Feb 2025 REST deadline only refers to the Products APIs.
2. You can expect that the GraphQL API will be the only supported API over the long term. We will continue to share timelines as they become available.

[Arif_Shopidevs]

Hi,

1. Their is no way to find how many products in a site, may be a static variable can be good.

2. Product sorting find product is not good.

Thank you

[AsafGitai]

Hi @Anonymous 

1. There is the productsCount query - https://shopify.dev/docs/api/admin-graphql/2024-04/queries/productsCount
2. Are there specific things that you would like to sort by that you would like to see added? This is a capability that we would like to improve over time.

[Naren1]

@AsafGitai  Why is there a limit of 10,000 products on productsCount?

We have stores that have a lot more products and we need to know the accuracte productCount 

[AsafGitai]

The initial limit was tied into performance concerns, we are looking into the best way to lift the limit sooner than later

[Aaron_Alfson1]

HI Jacqui & Shopify,

1. Are there are plans on improving the rate-limiting mechanism for the GraphQL endpoints? It would be great to know, in advance, if a request will exceed the number of available credits. The dynamic nature of the calculated cost mechanism and the requested cost / actual cost duality introduces a degree of uncertainty and complexity that isn't found in your REST endpoints. 

2. How are product and order webhook payloads changing as a result of the new product schema updates? 

[tedtate]

👋 Hi Aaron,

1.

It’s possible to calculate the cost of a query beforehand. This article gives a good indication of how that can be done: https://shopify.engineering/rate-limiting-graphql-apis-calculating-query-complexity

https://shopify.dev/docs/api/usage/rate-limits 

If you write a query that is below the maximum allowed query cost, you should never get an actual cost above that. The only dynamism should come from when you request connections but get less objects back than you requested.

At that point things are very similar to REST in that you need to be able to back-off your requests when you start getting back 429’s form the API.

Are there specific queries that you are finding difficult to fit into the current cost constraints that we give you?

2.

We added the list of changed variant IDs to product webhooks in 2024-07 because it wasn’t possible for us to continue including the full variant payload anymore once you hit a certain threshold of variants. There are no changes to order webhooks due to the variant limit increase.

[ClementBR]

@tedtate  "added the list of changed variant IDs to product webhooks in 2024-07 "

Are you saying that only the IDs of variants that have changed are included in the payload?

[DanAtBonify]

It was not super clear to me if anything changes in regards to the singular GET products/ID query the after Feb 1st, 2025. Will fetching a single product via the REST API continue to function normally for the foreseeable future?

[AsafGitai]

Hi @DanAtBonify 

The answer here depends on if you are asking for a public or a custom app:

https://shopify.dev/changelog/deprecation-timelines-related-to-new-graphql-product-apis

Let us know if there is a further question for either

[DanAtBonify]

Hello, this is for public apps. Is loading a single product by ID via REST API being deprecated? It wasn't clear to me from some of the verbiage used.. For example: Listing, creating, updating, and deleting products is deprecated as of REST API 2024-04. For more information, refer to the guide to the new product model.

My assumption was that fetching a single product by ID did not fall under "listing, creating, updating, and deleting"....

[AsafGitai]

Listing was meant to cover querying as well, sorry if that was not clear

[SKULabs]

1. With regard to the statement "Running a query is the best way to find out its true cost." Will we be able to estimate cost of a query more effectively in the future?

2. Has any thought been put into supporting JSONL responses from the standard GraphQL API? The chaotic nested edges with multiple pageInfos and endCursors that need to be recursed are difficult to restore into a standard data model. We've invested thousands of dollars on edge unrolling and sub-cursor pagination from this difficult to parse (non-jsonl) response data.
3. BulkOp performance. If a bulkOp randomly takes 58 minutes for a trivial amount of information (say 50 items with associated itemInventory), we're forced to continue to invest in the solution described above in point 2 (non-jsonl cursor resolution & edge unrolling) which costs thousands of dollars most app developers won't have to invest. What improvements to bulkOp reliability and performance are on the way that would permit us to use bulkOps in more scenarios for semi-real-time information?

4. With regard to the statement "Try removing some fields from your query so that it can run successfully.", what is the recommended way for software to be architected to "try removing some fields" dynamically especially those that are mandatory?

5. Can we run one bulkOp for products and one bulkOp for orders seeing as we're both an inventory and order management app? This would significantly improve the competitiveness of the GraphQL API vs REST API.

[ewalker]

1. We have no plans to release a standalone query cost tool. What specific scenarios are you finding which are giving you inaccurate estimated costs?
2. Can you provide a concrete example of a query you would like to combine with a JSONL input?
3. This AMA is focused on the product APIs. We will pass on the issue related to fulfillmentOrders performance. Shopify will continue to improve the reliability of bulk operations.
4. As the number of fields on the query grows, the first step to look at is requesting fewer objects per page. For example, pull back 25 products instead of 100 per request.

[SkulabsDevMat]

Hello, we are having difficulty calculating query costs on queries with nested connections.

Here is an example query that costs 98 according to extensions.cost.requestedQueryCost:

{
      orders(first: 25, after: "cursor") {
        edges {
          node {
            id
            name
            displayFulfillmentStatus
            fulfillmentOrders (first: 1) {
              edges {
                node {
                  id
                  status
                  assignedLocation {
                    name
                    location {
                      id
                      fulfillmentService {
                        handle
                      }
                    }
                  }
                  lineItems (first: 1) {
                    edges {
                      node {
                        id
                        remainingQuantity
                        totalQuantity
                        lineItem {
                          id
                        }
                      }
                    }
                    pageInfo {
                      hasNextPage
                      endCursor
                    }
                  }
                }
              }
              pageInfo {
                hasNextPage
                endCursor
              }
            }
            localizationExtensions(first: 5) {
              edges {
                node {
                  countryCode
                  purpose
                  title
                  value
                }
              }
            }
          }
        }
        pageInfo {
          hasNextPage
          endCursor
        }
      }
    }

[JustinKillian]

Hello there,

We used to use the `publishedAt` attribute to publish to Online Stores when calling `productCreate` and `productUpdate` operations. However, the `publishedAt` attribute is marked as deprecated in the latest API version (2024-04).

The docs suggest to use `publishablePublish` operation. Doing this would imply several changes to our workflow:
- Our app would have to make two API calls instead of one
- Our app would have to first be aware (fetch, parse/filter and store) of available publications to then be able to publish to the Online Store
- Our users would have to re-authorize our app tp get an access token with permissions `read_publications` and `write_publications` so we can read and publish products to the Online Store

The questions are:
- Is there any way to continue to automatically publish to Online Stores in a single API call (e.g. productSet which is what we are using) instead of making our app aware of all the publications?
- If the only way is to use the `publishablePublish` operation, is there any way to publish to Online Stores by default without having to specify the publication ID?
- If the only way is to use the `publishablePublish` operation, is there any way to do so without having our users to re-authorize?

Thanks

[tedtate]

👋 Hi Justin,

1. We are considering adding publishing to a future version of productSet. But when we do, it will require the publishing permission to do so.
2. With publishablePublish you would need the publication ID of online store to do the operation.
3. You will need to re-authorize with merchants to get this additional scope.

[JustinKillian]

Hello,

Thanks for the reply. I understand that adding publishing to a future version of `productSet` will require the publishing permission to do so. Question, would it require us to send the publication ID?

Also, I noticed that the `publishedAt` continues to be (marked deprecated but) supported in `productCreate` and `productUpdate` mutations. I think I can use that one in the meantime unless you advise otherwise.

Thanks again

[Naren1]

@JustinKillian I  requested a backfill of read/write_publications and Shopify is considering it

See their reply in latest AMA

[Naren1]

@JustinKillian Shopify has given an option to backfill read/write_publications. You need to support these scopes in code and fill out a form

See latest AMA reply: https://community.shopify.com/c/community-amas-ask-me-anything/shopify-community-ama-with-shopify-de...

[Next_Cart]

Hi Shopify developers,

We have updated our app to the latest version of the GraphQL product APIs (2000 variant limit), but there are still some limitations that require us to use a few REST API endpoints such as "products/count.json" for counting the total number of products, or "/products.json?collection_id=841564295" for filtering products in a specific collection. Therefore, we have two questions:

1. According to the latest changelog, the REST API endpoints "/products" and "/variants" have been marked as deprecated in API version 2024-04 and will be removed in the future. Does this mean that all REST API endpoints related to products and variants will be removed?
2. The current GraphQL API version only supports counting up to 10,000 products per channel. In the event that the "products/count.json" REST API endpoint is removed, would you update the GraphQL API to support counting all products across all channels as "products/count.json"?

Thank you for addressing our questions.

[AsafGitai]

Hi @Next_Cart 

1. You can expect that the GraphQL API will be the only supported API over the long term. We will continue to share timelines as they become available.
2. We will be adding extra query support to productsCount so that it has parity with REST in the upcoming API version 2024-10. There may be additional constraints added when attempting to query more than 10,000 products to guarantee fast responses.

[Chris_Geelhoed]

Is the development team building the new 2000 variant per product feature aware that that the product variant API already has several bugs even at the 100 variant limit? I have been reporting these bugs and begging for them to be fixed for over a year and nothing has been done. The API can fail in several ways, but one example is that when you try to use the graphQL API to fetch the product variants under a certain collection or vendor, the Shopify API cannot handle the request often, and will send back an response that is incorrect (for example will fail to include all variants under a collection) or often will simply respond with 500 level internal error. These errors are most common for stores with large product catalogs so Shopify Plus merchants are affected at a higher rate than any other Shopify merchant, despite paying much more than other merchants.

Support just says "this is being investigated however we are unable to guarantee a timeframe on an answer/resolution at this time".

If the system cannot scale to work with a 100 variant limit, how is it going to scale when that limit is 20X larger?

I apologize for the negative tone but I am frustrated that nothing has been done to fix the problems that I repeatably report. I have submitted many support requests and tried to reach out to all the Shopify contacts that I have, and still nothing has been done. I am very concerned that the 2000 variant feature will result in even worse reliability for the API as we approach BFCM 2024. I am also concerned that Shopify is prioritizing new features above ensuring the reliability of existing features.

[kestutisbalt]

I don't want to spread negativity as well but this answer has many valid cases described.

[Shailesh_-_Aten]

My system imports all product data to generate feeds and also encounters the HTTP 500 Internal Server Error when the REST API page size is too high.  Shopify API may be running out of memory or hitting an internal timeout.  Setting the page size lower resolves the issue.  At a minimum, the API should return a more accurate error code so that our system can handle the exception correctly.  The Shopify API should never return HTTP 500 errors for commonplace error conditions.

[AsafGitai]

Hi @Chris_Geelhoed 

We appreciate the feedback that you’ve given us, which we have passed along to our team. Now that we have the shape to support 2K variants we have shifted gears to improve our performance. We are currently focused on the mutations, but expect to improve the queries as well.

@Shailesh_-_Aten we distinguish timeouts in GraphQL, let us know if there are any cases we aren't and we will make sure to fixing those.

[Chris_Geelhoed]

Thank you. One detail that I think is very important to note, is that the graph QL endpoints noted above did not have performance issues originally. Instead, the performance regressed over time. I am not requesting performance beyond what the system offered originally, I just want the regressions that occurred over the past few years to be investigated and repaired.

Also, can you please provide a timeline for which the performance regressions will be addressed?

[AsafGitai]

Would be difficult to give you a definitive timeline as different endpoints will receive focus separately.
As we have enabled productSet to be called with 2K variants, we are focused on getting it to handle non complex inputs

synchronously (meaning in 45 seconds) and potentially remove the 100 variant limit that was put in place in 2024-04.

Following that, we will likely focus on productDuplicate, productDelete & productOptions* as they operate on the 2K scale, even if their input does not contain the 2K variants. 

[Chris_Geelhoed]

I am referring to this query specifically, not productSet: https://shopify.dev/docs/api/admin-graphql/2024-04/queries/productVariants

In particular when a query is made which filters by a collection, vendor, tag, etc. Is there is a timeline on restoring the reliability of this part of the graph QL specifically?

[johngully]

How are product webhook impacted (if at all) by these changes?

We would love to see product webhooks that

• Only fire when the product attributes change (not the inventory level)
• Include product category information

[JoesIdeas]

I like this, also think it would be amazing for webhooks to say what changed exactly, would prevent so many wasted API calls guessing what changed.

[EfstathiosS]

Hello!

We added the list of changed variant IDs to product webhooks in 2024-07 because it wasn’t possible for us to continue including the full variant payload anymore once you hit a certain threshold of variants.

1. There is nothing currently planned to change when product webhooks fire but we acknowledge that the current situation is incredibly noisy and is causing frustration for partners. How we sync data to external sources is something we are looking to improve in the future.
2. There is a `metafieldNamespaces` on the webhook registration mutation that allows including metafields in the payload. All standard taxonomy attributes are in the `shopify` namespace. https://shopify.dev/docs/api/admin-graphql/2024-01/mutations/webhookSubscriptionCreate#argument-webh...

Thanks for this feedback, we will consider adding this by default in the future.