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 ?

[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

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

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

[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

[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!

[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

[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?

[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?

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

[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

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

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

[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

[tejasvyas]

Hello, We want to share that we are using presentment-prices on Rest product API to get the currency prices, As we need to move to new GraphQL APIs. what is alternate in this new GraphQL product APIs to fetch this data?
We tried with contextual prices but it is not a optimized solution as it requires to execute lot of API calls, due to API limiter, it would take lot of time to fetch the currency prices for lets say 10 Countries with even 20k products.
What is the optimized solution for this? Unfortunately, I can not attend the call so can it be recorded to be hear it later?

[AlexisBreuil]

Hi!

We can update a metafield with a key and a namespace, why is the metafield id mandatory on the productSet mutation?

thanks

[ClementBR]

We need to sync all products and variants data in our database.

I see that moving forward, the product webhook will only contain data for the first 200 variants. I guess we are expected issue one or more queries to get the data for all the remaining variants.

That sounds very inefficient, especially considering that only a single variant might have changed.

To make things more efficient, can you introduce a new set of webhook topics for variants specifically, so that we can know when a specific variant was changed? Such as variants/created , variants/updated, variants/deleted.

While on this topic, it has been a long standing issue that updating a variant metafield (via the API, no the admin) does NOT trigger any products/update. Maybe this can be fixed at the same time, by firing variants/updated whenever a metafield is updated?

[JustinKillian]

Hello there,

We are an app that requires to sync an external database to Shopify. We support syncing media, products, variants, inventory items and available inventory quantities (through inventory levels). In previous versions of the GraphQL API we could sync complete products (with all attributes previously mentioned) in a single bulk mutation using productCreate or productUpdate.

With recent changes to the product model we need to refactor our workflow to be backward compatible. We are thinking about doing something like this:

1. Create new media using bulk createFile

2. Create/update products and variants using bulk productSet

3. Publish products using publishablePublish

4. Update inventory items using bulk productVariantUpdate (with nested inventoryItem) or use inventoryItemUpdate

5. Update inventory quantities using inventoryActivate. We could potentially use inventoryAdjustQuantity too

6. Delete, rearrange, update media

It would require us to perform at least 6 API calls instead if 1 to continue to support what we already support in our app. Some of the API calls previously mentioned support bulk mutations but some others don’t.

I am worried about the complexity that’s getting introduced for use cases like ours, as well as rate limits and the app performance of our integration (timeouts from Shopify) when we get to sync customer’s shops for thousands of products with hundreds (and now potentially thousands) of variants each.

Two questions:

1. Are the plans to extend productSet so it would work as productCreate and productUpdate used to work? It was very useful for use cases where a complete database sync should happen
2. Is the algorithm described above accurate to achieve what we need to achieve or there are better/easier ways to achieve our goal?

Thanks!

[kestutisbalt]

Also, are there any plans to introduce change history for product updates?

Currently, it’s challenging to troubleshoot issues when multiple apps update the same product. Customer support often tells merchants that it’s the app’s fault without trying to understand where the issue is coming from (I guess they have no technical background). As app developers, we then have to spend long hours as outsiders gathering timestamps from the API and proving to clients that the app did not update the product and that it was likely another third-party app. By this point, the merchant doesn’t believe us because Shopify customer support stated that it was the app’s fault, and 9 out of 10 times, it isn’t. Having a change history showing who made changes would solve this issue and save time for app developers and Shopify customer support.