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

[Jacqui]

We’ll be hosting a live AMA on Tuesday, Oct 22nd from 11 am to 1 pm ET that will answer questions on the new GraphQL Product APIs announced in the 2024-04 stable API release.  

Hit reply now to post any questions here on this thread before October 22nd, 2024 and we’ll answer them live. You can also bring your questions to be answered 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.  

What’s more, we’ve been making updates to our APIs since they launched in April based on some of the feedback from our partner community, and we’d love to hear from more of you to ensure your voice is heard.

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

Read our Rules of Engagement before participating.

*Please note, there is no video component to this AMA. This is a text based AMA. Your questions will be answered LIVE via text during the time period listed above.

[AsafGitai]

Hi @tejasvyas,

Ok, this is a big question, but i will try to provide a succinct answer.

For published_scope, You can use the publishedOnPublication field with a publication id.

Regarding inventory, we will consider the best way to enable apps to read inventory fields that were available in REST via the variants.

For contextual pricing please refer to the answer here
https://community.shopify.com/c/community-amas-ask-me-anything/shopify-community-ama-

with-shopify-developers-the-new-graphql/m-p/2722397/highlight/true#M1091

Please reach out to Partner support regarding the Inconsistent Prices Between REST and Graphql

[BenoitN]

Hi,

In Shopify API 2024-07, the fields “weight,” “weightUnit,” and “inventoryManagement” have been moved to the inventory object. Please see the documentation for details:

• ProductVariant definition in 2024-04:
  The weight of the product variant is measured in the unit system specified by weight_unit. Use inventoryItem.measurement.weight.value instead.

• ProductVariant definition in 2024-07:
  These changes now require our app to have the read_inventory permission. While this works fine for new installations, it poses a problem for existing customers. It's quite complex to ask all of our existing customers to update the app, and some may not comply, leading to a broken service.

In 2018, you provided a backfill mechanism for the read_inventory permission. Could you offer the same solution again?
(Here is the reference link: August 2024 AMA)

This is a similar situation to the one discussed regarding the write_publications access scope, which was addressed by Naren1 in this AMA.

Thank you

[tlombardo]

We are considering the best way to enable apps to read inventory fields that were available in REST via the variants. We will get back to you ASAP.

[rewind_garrett]

Hello,

Currently, the productCreate, productUpdate, and productSet endpoints no longer accept ProductImage IDs as input. If a ProductImage ID is passed as a parameter, an “Invalid ID” error will be returned. Instead, these endpoints require a MediaImage to be submitted with a valid gid. If no MediaImage already exists in the store, a new one can be created by providing a source URL.

When fetching a product along with its associated images from the GraphQL endpoint, these images are returned as MediaImages. However, older data that has been backed up or synchronized might contain ProductImages. The only way to re-associate these images is by submitting their source, which creates new MediaImages even if identical ProductImages already existing for the product. This results in duplicate images—an unintended side effect.

Would it be possible for these mutations to accept ProductImage IDs to directly associate images with a product? This would greatly improve compatibility during the transition from REST to GraphQL.

Alternatively, is there a way to automatically detect duplicate images and either delete or replace them with the new MediaImage when an identical source is provided?

It appears that the conversion from ProductImage to MediaImage occurs automatically when fetching data. Could this same process be applied during submission by modifying the ProductImage ID to match the gid format, allowing the transition to continue seamlessly on Shopify’s side?

Thank you.

[tlombardo]

With the introduction of the media system, a unified pool of media that is available to all resources across a shop, the productSet, productCreate, and productUpdate APIs moved to using the media interface. A media must be created before being passed to these product APIs and can be managed with the files APIs such as fileCreate.

Thanks for this feedback, I'll be passing it along to the media team to see if theres any plan to support detecting duplication or transformation.

[rewind_garrett]

Hello,

We have observed that product webhooks continue to deliver payloads in REST format. For instance, product options are included as properties directly on the product object rather than as connections, which is how they are structured in GraphQL. Other differences include the use of snake_case for keys in REST versus camelCase in GraphQL or different key names such as body_html vs description.

This behavior appear to be consistent across all current versions of the product create/update webhooks.

Will there be an option to specify the payload format, allowing us to choose between REST and GraphQL? Alternatively, is there a plan to introduce a new webhook topic that would deliver payloads in GraphQL format? Receiving webhooks in GraphQL format would be beneficial for maintaining consistency between asynchronous queries, synchronous queries, and webhook callbacks.

Additionally, are there any plans to introduce webhook topics specifically for the creation/update of product variants, product options, and product images?

Finally, if media images are edited directly, will this trigger an update webhook event for the associated product or related items?

Thank you.

[Jason27]

This is an important question. Is there a plan to change the webhooks api and the property names to match graphql? 

[tlombardo]

Hi, thanks for this input. We recognize that the webhooks are more closely modeled to REST and are actively considering the path forward given we’re all in on Graphql.

> Additionally, are there any plans to introduce webhook topics specifically for the creation/update of product variants, product options, and product images? Finally, if media images are edited directly, will this trigger an update webhook event for the associated product or related items?

No specific plans atm but I will bring this back to the team as a feature request.

[rewind_garrett]

Hello,

When querying products via a BulkOperation, a signed URL is provided for accessing the resulting JSONL file. This signed URL expires after one week, as mentioned on this page.

Would it be possible to add a parameter that allows us to specify a shorter expiration time for the signed URL? This would enable us to limit the duration of access, helping us comply with any requirements or restrictions imposed by governing or certifying bodies.

Thank you.

[tlombardo]

Thanks for this input. I don’t think there are specific plans to do this atm. I’m going to share this with our API patterns team as a feature request.

[rewind_garrett]

Hello,

What percentage of stores do you anticipate will take advantage of the new 2,000 product variant limit? i.e. have greater than 100 variants and require additional calls when querying for the products and their variants.

Additionally, could you share any data or statistics on the current distribution of product variants per product, such as the mean, median, and mode? How do you expect these numbers to change with the increased variant limits?

This information would be valuable for our capacity and performance planning.

Thank you.

[tlombardo]

Thanks for the question. 

We don’t have a % to share but going beyond 100 is a very consistent ask for plus merchants. It’s a very common pattern as a store’s catalog grows. 

Today, we have many that have worked around this limitation today by stitching products together on the storefront, this makes Shopify and apps very hard to work with. 

> Additionally, could you share any data or statistics on the current distribution of product variants per product, such as the mean, median, and mode? How do you expect these numbers to change with the increased variant limits?

We don’t share this data publicly but we anticipate we’ll see a shift up in all three, especially in the Plus segment.

[Jason27]

Any plan to allow updating handles (and translated handles) using non-ascii characters? Both graphql and rest continue to transliterate non-ascii characters even though it is possible to create urls with non-ascii characters in the shopify admin when creating a new page/product/etc.

[EfstathiosS]

Hello Jason,

Thanks for your question.

At this time, we don’t have any plans for this.

Under normal circumstances the best way for you to raise a feature request is via Partner Support. In this instance, however, the wonderful @Jacqui will submit the feature request for you.

[LouiseEH]

Hi,

So I just wanted to double check the following:

1. Which of our solutions will be affected - is it limited to all solutions using the "productCreate" and/or "productUpdate" mutations?
2. Will the "productCreate" and "productUpdate" mutations be deprecated all together - or is it only the fields "variants" and "options" on the input to the mutations that will be deprecated?
3. We should handle the update by using the mutation "productSet" instead of the "productCreate" and "productUpdate" mutations?

Kind regards,
-Louise

[AsafGitai]

Hi @LouiseEH 

1. I’m not sure I understand your question, could you provide more context?
2. We do not plan to deprecate these mutations, just the fields.
3. It depends on your usecase. For most real time use cases, we want to ensure apps are designed to scale with merchants that require many, complex variants – so we suggest using productCreate/productUpdate and the corresponding variant mutations. For syncing from an external source, we suggest using productSet

[LouiseEH]

Hi, 

Thank you for your answer.
1. I am trying to figure out how to identify all the solutions we have made for various merchants, that need to be updated. So I was wondering whether it is as simple as searching for code occurrences of productCreate and productUpdate, or whether we need to identify the necessary updates in another way.
2. Ok
3. Why do you recommend productSet when it is an external source? And what would an internal source be? 

[Ufi]

Hi, 

my question is not about products but discount codes.

I would like to know if it is possible to combine the discount codes under one pricing rule with GraphQL, the same way we can do it with REST API?
I posted this question on the forums a while ago, but didn't get the answer
https://community.shopify.com/c/customers-discounts-and-orders/discount-types-combine-discount-codes...

Tnx

[tlombardo]

Hi, I’ve shared your question and previous post with the discounts team so they can answer there.

[juliandong]

Hi Ufi, thanks for your question. Yes, this is possible with the new GraphQL API through the discountRedeemCodeBulkAdd mutation. Hope this helps!

[fb_123]

Delay in some queries and stale results

We use the query `productVariants(first: 10, query: "barcode:'' OR -barcode:*")` to find items without barcode. In our testing, when we delete a barcode from an item, it takes several seconds for it to appear in the result of this query. If we then add a barcode to the item, it again takes several seconds for the item to be removed from the results. This is extremely error-prone, because it can cause our app to overwrite the barcode of an item if it thinks there are no barcodes for it. Weirdly, this delay does not appear when querying for empty SKUs, so there's probably some implementation difference there.

We can't reliably use GraphQL if the results it gives us might contain stale data. Imagine querying a SQL database and getting rows that contain stale data of more than several seconds after the commit has taken place. 

We noted the delay on this query at least a couple of years ago and notified Shopify a few times, but I just tested today and it's still there. This has caused us to avoid GraphQL as much as possible, and only use it in cases where the stale data wouldn't cause any issues. 

My question is: Is Shopify aware of this issue and what can be done to address it? Apparently, there is a difference in implementation between SKU and Barcode queries, so I believe that a solution is possible. If some kind of indexing is taking place, it's preferable that the query delay the return rather than return stale data. Our app makes decisions based on what's returned, and we're afraid of making the wrong decisions, based on the stale data.

[tlombardo]

Thanks for this feedback. I’ll take this back to the team to better understand the current state and why it may be happening with just barcodes.

[markko]

Dear Shopify team,

for our sales channel app, we need to be updated about products and product changes in the merchant's shop. We mainly get updated via webhooks of course, but we are hinted by documentation to at least sync all products once every 24h.

To trigger Shopify to give us a full list of all products, we used to (or still do to this day) call the REST API endpoint ProductListing. However, with the REST API being deprecated as of Oct. 1st 2024, we cannot find a replacement endpoint in the GraphQL API.

Can you tell us how to reach the same outcome with the GraphQL API, so that we can sync all product listings for our sales channel once every 24h?

Thank you!

[tlombardo]

Hi @markko, for now, we recommend channels continue to use the REST productListing endpoint if the GraphQL products APIs can't solve for your use case. you can essentially recreate the product feed with the products query publishable_status. This will allow you to filter to the set that are published on your channel.

[Naren1]

is there a way to limit the graphql bulk api to return only first X count products. for example: first 25,000 products

There are dropshipping stores that have a million products which our app cannot support.
Also our app has different billing plans based on the number of products in a store. 

Now with the GraphQL product count capped at returning only a max of  10,000 count, we don't have the ability to screen such stores at install time. Like we do currently with REST api product count.

Worse is I cannot retrieve only the specified number of products from their store since GraphQL bulk api returns ALL products in the store. 

Can we have the ability to atleast set a max limit on the number of products we want to retrieve like first:25000

See: https://shopify.dev/docs/api/usage/bulk-operations/queries 

The first argument is optional and ignored if present, so it can be removed.

[tlombardo]

Thanks for the input. I'll take this to our api pattern team that governs the bulk operations API as a feature request.

[Jacqui · Accepted solution]

The AMA is now closed. Questions asked past this time will not be replied to.

Thank you to everyone who joined us for this AMA, and for all your excellent questions. Even though our time is up our team will continue to post answers to the questions that have already been asked. We will do our best to answer them as soon as possible.

Make sure you subscribe to our Community AMAs board to be notified about any future community events and join our developer team in the new .dev community!