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.

[___END___]

Oct 3rd email about this event

We wanted to take this opportunity to remind you that all public apps need to migrate to the new GraphQL product APIs by February 1, 2025.

Oct 2nd email from email@email.shopify.com with the subject "New public apps must use GraphQL starting April 2025"

Starting April 1, 2025, all new public apps submitted to the App Store after this date must only use GraphQL. There are no changes for existing custom apps or published public apps, which can continue to use the Admin REST API.

So which one is it?

[Xuya]

Hi, we're sorry for the confusion. The new announcement doesn't change the previously announced migration timeline. All public apps must migrate to the new GraphQL product APIs by February 1, 2025. The /product and /variants REST endpoints will not be available to any public apps after that date.

[sevenminds]

The productVariantUpdate mutation will be deprecated soon, necessitating an upgrade to productVariantsBulkUpdate. However, there's no apparent way to indicate that a variant requires components with the new mutation. Specifically, the requiresComponents field is missing from the input. What's the best way to migrate?

[AV_SL]

+1 to this. It seems like an oversight that this is missing.

It made sense to not have it when it was strictly for bulk updates, but now that it's the preferred approach for single variant updates - it is absolutely needed as an input.

[AsafGitai]

HI @AV_SL  & @sevenminds , 

Similar to my answer in the board, this was an oversight on our part. The two mutations should have a logically similar inputs.
We shipped this yesterday https://shopify.dev/changelog/adding-requirescomponents-field-to-productvariantsbulkinput

[Naren1]

Asking again about the backfill of write_publications access scope for existing customers of existing apps that use REST API
Link to the detailed question from August AMA

In the August AMA @AsafGitai said they were considering the request.
It is now 2 months since that AMA and barely 4 months left for the deadline. 
Can the Shopify team please expedite this backfill request and share details on how it will be done?

Thanks!

[tlombardo]

Hi, please submit a Publishing Permission Request in order to have these permissions backfilled. 

If your app currently reads or writes `published_at`/`published_scope` via REST, this permission backfill will grant `read_publications` and `write_publications` to all existing installations. Those permissions will only be granted if the app currently has the corresponding `read_products` /  `write_products` scopes.

For apps that complete this form, we will backfill these permissions every Friday, except on December 27, 2024, until the migration deadline on February 1, 2025. 

Before completing this form, please update your app to request these permissions for new installs. If you submit before updating, new installs between the backfill and your update will not receive these permissions. 

Thanks!

[Naren1]

productsCount still has a maximum limit of 10,000

This limit of 10,000 is creating a lot of problems for us. 
Our apps rely on product count for billing and access to certain features. 

I see that productVariantsCount no longer has this limit. 
So why does productsCount still have this 10,000 limit?

[AsafGitai]

Hi @Naren1 ,

The limitation of GraphQL counts to a maximum of 10,000 is our default constraint across various count queries in Shopify's GraphQL Admin API. This limit is in place to ensure performance and stability of the API by preventing excessively large queries that could strain the system.

For products we believe this covers the majority of cases for merchants, especially with the filter capability.

productVariantCount was exempted from this default as a larger % of merchants will have more than 10,000 variants and the query does not support filtering.

[Naren1]

@AsafGitai 

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

[SEOKart]

We have an SEO app where we audit all the products/collections of our mutual users. There are merchants who have more than 10,000 products and sometimes in millions as well. 

With the new GraphQL APIs, it is restricted to 10,000 products only which is not enough for us. 

Also is it mandatory to have GraphQL APIs for the "Built for Shopify" badge? Right now we are using Rest APIs., 

Please suggest. Kindly reply at hi@seokart.com

[SEOKart]

Can you please reply @Xuya @Jacqui 

1. Should we disregard the email we received on 3rd October that GraphQL API migration is mandatory only for the apps which will be submitted after April 1, 2025. And existing apps can keep using REST APIs. 

All published Apps must migrate and stop using REST APIs else they will be delisted?

2. Fetching only 10k products will not work for us as we need to audit all the product's data to tell store's cumulative SEO score. Is there any way around?

[___END___]

They send contradictory email about this. Now they send new email to clarify:

> You must migrate your public app by Feb 1, 2025 if it’s using:

> GraphQL Admin API `variants` and `options` fields on the `ProductInput` on 2024-01 or earlier and/or
> the REST Admin API `/products` and `/variants` endpoints on any available version

[AsafGitai]

Hi @SEOKart ,

> With the new GraphQL APIs, it is restricted to 10,000 products only which is not enough for us. 

Assuming you mean productCounts limits here? Please let us know if you’re referring to something else. Please see the answer to the previous question.

> Also is it mandatory to have GraphQL APIs for the "Built for Shopify" badge? 

The migration to GraphQL is required for /products and /variants. At the moment, the remaining REST APIs are still supported for “Built for Shopify”. That said, as more features are delivered in GraphQL, the likelihood increases that an app using REST will not provide full support for Shopify’s features and may lag behind future “Built for Shopify” requirements.

[Ajay_399]

Hello Team,

We have shared the same concern on the previous graphQL AMA regarding the need to re-authorize all existing customers with the write_publications scope.

We manage 4 public apps that use automations and webhooks for creating and updating products based on our app functionalities. The issue is that if users don’t access the app, we can’t update the app scopes & it will stope & break the app automations. Therefore, I strongly request that publishing products be allowed under the existing write_products scope.

Please avoid introducing a new scope like write_publications. If it’s unavoidable, could you provide a workaround so that existing access tokens can continue publishing products using the write_products scope? For new app users, we will of course request the write_publications scope.

Additionally, I’m concerned about the efficiency of the GraphQL API compared to REST. In REST, we could add and publish a product with a single HTTP request. However, in GraphQL, the same process requires 3 HTTP calls:

• productCreate mutation
• publishablePublish mutation
• Fetching publicationId with another mutation

While REST handled this with fewer requests and less complexity, GraphQL seems to make the process longer and more complicated.

Moreover, adding tags and creating or updating variants also require separate mutations. Could we have a single master mutation that allows us to create a product with basic parameters, all in one HTTP call?

Could you please look into this? Many other developers share these concerns as well. Any assistance would be appreciated.

Thank you.

[tlombardo]

Hi, the API will require write_publication scope moving forward. Please submit a Publishing Permission Request in order to have these permissions backfilled. 

The publishing process had fewer calls in REST, however, it didn’t map to the reality of multi-channel and multi-catalog context that most growing merchants utilize today. Specifically, headless merchants (headless or hydrogen storefronts) and catalogs (to represent publishing state across many markets) are used by an increasing share of merchants. 

> Could we have a single master mutation that allows us to create a product with basic parameters, all in one HTTP call?
Since removing variants from productCreate and introducing productSet for the sync use case, we have added to the later support for fileCreation & inventory quantities.
For most real time use cases, we want to ensure apps are designed to scale with merchants that require many, complex variants. We believe the two stage approach, along with sometimes batching variant creation produces the best results that scale.

[PaulNewton]

Multiple calls turn real time into wait times.

multiple calls & real time & scale are three conflicting concepts.

A real time scenario is product customization apps et al., apps that create products at time of cart/pre-checkout.

Which already have a very common problem of needing to inject a loading animation to stall out the user experience as it's not just the shopify api that has to be worked and waited on as there's also checking the product is actually available on the frontend to update media or to avoid checkout issues.

And that's in REST when publication is already part of the call, and if inventory/locations/markets isn't involved.

Without being able to make a singular call to make a singular usable resource this is a step backward.

This seems like it will encourage more product generating apps towards using custom-line items on orders so they can give the perception of "real time"  instead of dancing with an atomized product api;  shifting the issue to holes in analytics and reporting etc.

Graphql's strength is supposed to be query only the data you need where you need it, but somehow the other side of that equation in mutations is being made to be more complicated than all the lessons that were learned with the REST api partners had to push for.

[kliveny]

https://shopify.dev/docs/api/admin-graphql/2024-10/mutations/inventorySetQuantities 

I adjusted the inventory of the variant according to this example, but why did the response parameter prompt "The specified location could not be found."? The value of the locationId I passed seems to be correct, what is the reason? Is it because the location is created using the Rest API?

[rjdavis]

@kliveny creating the location in the REST API shouldn't have any impact. It should work the same as graphql.

That said, I can see this error being confusing if the location does exist.

Can you tell me if this is a fulfillment service? Better yet can you direct message me the request body you are using to send the graphql request?

[Marc_Lawson]

It is very disheartening to hear that Shopify is deprecating the entire Admin REST API and forcing developers to adopt a completely different tech stack.

I hope there is some pushback on this. I am not sure I am up to recoding the entire backend of my app. It might be time for me to retire my app.

Any other devs feel this way?

[___END___]

Shopify couldn't care less about its small app developers. They have not done single thing to benefit group since 20% app store fee was waived 4 years ago. Everything go downhill and make life difficult: support team process is total disaster , they lie to shops and show false 'unsupported app' messaging, forcing app name change,  fragile api clients, I can list more but you get idea!  

[tlombardo]

For Public Apps using REST, the February migration timeline is only for  the /products & /variants endpoints. 

We understand that transitioning your app to GraphQL can be a significant  investment, but is necessary given GraphQL is the primary admin API going forward. You can learn more about GraphQL and our API strategy here. 

[pawanthalia]

Is there any graphql equivalent for this rest api 

/products/count.json?collection_id=11616416461

[AsafGitai]

Hi @pawanthalia 
Yes, you can get the equivalent count by checking the `productsCount` field inside of a collection query.

https://shopify.dev/docs/api/admin-graphql/2024-10/objects/Collection#field-productscount

[Jason27]

Can the shopify team consider keeping the /products/count.json endpoint active? 

[PaulNewton]

admin REST endpoints need to be decades reliable, not replaced with the latest and hottest.

Getting rid of REST is gonna kill off a lot of productivity gained from admin utilities like basic userscripts; or typing in a literal simple url without having to load megabytes of GUI.

[Ajay_399]

I’m concerned about the efficiency of the GraphQL API compared to REST. In REST, we could add and publish a product with a single HTTP request. However, in GraphQL, the same process requires 3 HTTP calls:

• productCreate mutation
• publishablePublish mutation
• Fetching publicationId with another mutation

While REST handled this with fewer requests and less complexity, GraphQL seems to make the process longer and more complicated.

Moreover, adding tags and creating or updating variants also require separate mutations. Could we have a single master mutation that allows us to create a product with basic parameters, all in one HTTP call?

[AsafGitai]

Hi @Ajay_399 ,

We encourage apps to handle publications directly because there are a growing number of merchants that do not rely on a single publishing state on Online Store. Specifically, headless merchants (headless or hydrogen storefronts) and catalogs (to represent publishing state across many markets).

Merchants that want products to publish automatically when created, can set the publication to be “auto published”.
Long term, we believe that any other publication should be done more explicitly in its own mutation with the proper api scope given to the app.

[PaulNewton]

If a merchant isn't in a majority they still exist.

This is how survivor bias is created in a service.

[rewind_garrett]

When querying for products and their related entities—such as variants, images, and options—using a BulkOperation, will the resulting JSONL file maintain the nesting of these related items? Specifically, will each product object be followed directly by its nested items (variants, images, options), ensuring that all nested items for a given product are output before the next product begins?

We are aware that when querying for more than 100 related items (e.g., variants), the output may interleave these entities—for instance, 100 variants may appear immediately below a product, followed by options or images, and then more variants for the same product.

The documentation appears inconsistent on this point. According to this page:

“The order of each connection type is preserved, and all nested connections appear after their parents in the file.”

---

However, a note on the same page later states:

“The GraphQL Admin API doesn't serially process the contents of the JSONL file. Avoid relying on a particular sequence of lines and object order to achieve a desired result.”

Example JSONL Output:

Scenario 1 - Observed:

Product A
Variant 1 for Product A
Variant 2 for Product A
Image 1 for Product A
Product B
Variant 1 for Product B
Variant 2 for Product B
Image 1 for Product B

Scenario 2 - Hypothetical (undesirable outcome):

Product A
Variant 1 for Product A
Image 1 for Product A
Product B
Variant 1 for Product B
Variant 2 for Product B
**Variant 2 for Product A**
Image 1 for Product B
**Image 2 for Product A**

We seek confirmation that Scenario 2 cannot occur, ensuring that the nested items for a given product will not appear out of sequence with respect to the parent product.

[AsafGitai]

Hi @rewind_garrett ,

Yes, Scenario 2 should not happen as nested connections are preserved in the response order.

Our documentation discourages assuming that the data was processed in the same order the JSONL file is presented. Using Scenario 1 as an example, you should not assume that the data for Image 1 for Product A was retrieved before Product B.

Product A
Variant 1 for Product A
Variant 2 for Product A
Image 1 for Product A

Product B
Variant 1 for Product B
Variant 2 for Product B
Image 1 for Product B

Have you see scenario 2 happen, if so, please reach out to support and we can look investigate further

[rewind_garrett]

Thank you for prompt response.  No we have not seen scenario 2 happen yet.

[PaulNewton]

Great question, the answer is a relief.

So maybe that non-linear scenario is something only paranoid devs should build error handling for , or there should be some sort of check in the SDKs if it happens.

[fcodelgado]

Our product is currently using the inventoryActivate mutation in 2024-07 version to manage inventory at different locations.

I noticed that you that the productSet mutation in 2025-10 version added the `variants.inventoryQuantities` to set quantities at different locations.

- Would the `variants.inventoryQuantities` work for both activated and non-activated inventory items?

- If it works for non-activated inventory items, would it activate them?

Thanks!

[AsafGitai]

We added variants.inventoryQuantities to productSet only for the scenarios where the variants are being created. Changing activation/deactivation of existing variants (at locations) is not supported via this mutation. For inventory management, your app would need to call the inventory mutations directly.

It looks like we did not mention this in our documentation, will get this updated soon.

[fcodelgado]

Our integration is currently using `productUpdate.publishedAt` available in version 2024-07 to publish active products to online stores.

However, that's being deprecated in favor of `PublishablePublish`. Publishing products to online stores using `PublishablePublish` for our integration involves several downsides:
1. We have to ask users to re-consent for a new scope
2. We have to add management for the available publication ids to our integration

All our product needs is to be able to publish to online stores. Is there a way to bring back the `publishedAt` within the `productUpdate` or even better within the `productSet` mutation which is what we are using?

Thanks

[tlombardo]

Hi, please submit a Publishing Permission Request in order to have these permissions backfilled. The backfill will mean you do not need to ask for re-consent, but moving forward you should ensure your app asks for these scopes on fresh install. 

> 2. We have to add management for the available publication ids to our integration

It’s important for apps to handle publications directly in this manner because there are a growing number of merchants that do not rely on a single publishing state on Online Store. Specifically, headless storefronts (headless or hydrogen apps) and catalogs (to represent publishing state across many markets) are used by an increasing number of merchants.

[PaulNewton]

All our product needs is to be able to publish to online stores

---

This is the problem, their app is not concerned with every possible channel just the channel that is specifically required/assumed for there app to be chosen and installed for in the first place; and currently works.

But devs are being setup to have to build in extra checks and UI affordances for systems they don't even want to support.

Also to add to the tangle of apps managing publications there is no "channels" feature row for apps on the app store listings to consitently mark what channels an app may or may not support; nor a search filter for channels.

[fcodelgado]

I noticed that Shopify implemented Product Category Metafields in the Admin UI.

Are there plans to support Product Category Metafields natively in any of the upcoming 2025-* GraphQL API releases? Or at least expose some public documentation that explain how to achieve the same behavior exposed by the Admin UI?

There is a question related to this in the community forum: https://community.shopify.com/c/graphql-basics-and/graphql-support-for-product-category-attributes-m...

Thanks

[tlombardo]

Yes we will have public APIs. The ability to read and update the values for category metafields are already available. More will be coming through 2025.

[kliveny]

/admin/api/2024-10/products/632910392/images/850703190.json
{
"image": {
"id": 850703190,
"alt": null,
"position": 1,
"product_id": 632910392,
"created_at": "2024-09-19T10:10:57-04:00",
"updated_at": "2024-09-19T10:10:57-04:00",
"admin_graphql_api_id": "gid://shopify/ProductImage/850703190",
"width": 123,
"height": 456,
"src": "https://cdn.shopify.com/s/files/1/0005/4838/0009/products/ipod-nano.png?v=1726755057",
"variant_ids": []
}
}

In the old REST API, admin_graphql_api_id is an identifier specifically for the GraphQL API, and its format is gid://shopify/ProductImage/{image_id}. The REST API returns this field directly for easy use in the GraphQL API.

{

  product(id: "gid://shopify/Product/632910392") {

    id

    title

    media(first: 10) {

      edges {

        node {

          mediaContentType

          ... on MediaImage {

            id

            image {

              id

              url

            }

          }

        }

      }

    }

  }

}

In the new version of the GraphQL API, you will find that when querying a product, the id and image { id, url } returned by the media node obtained through product(id: "gid://shopify/Product/632910392") do not contain the same admin_graphql_api_id as in the REST API.

[AsafGitai]

@hi @kliveny ,

Thanks for notifying us of this. We have forwarded this question to the relevant team. 

[OptionsSoftware]

Hi, 

Could you please provide further clarification on how the GraphQL API rate limits work? I have read through https://shopify.dev/docs/api/usage/rate-limits and it says "A single query may not exceed a cost of 1,000 points, regardless of plan limits" however, for a store with an Advanced Shopify Plan, they can only have 200 points/second. Does that mean queries can still be made up to 1,000 points but they will be executed slower, or will they be rejected completely? I have very limited understanding of GraphQL other than what I have worked on so far to support this conversion - with the REST API we just had requests wait a couple seconds before retrying the request again, however that won't work with the GraphQL as the cost of the request will still be the same.

Is there a way to set up a development store to test against the Advanced Shopify plan API limits to see the responses that are returned and test how this is handled? 

Thank you!

[EfstathiosS]

Hello!

Thanks for your question. I see that our documentation is not clear regarding the available pool of points. I will raise this internally to see if we can make this easier to understand.

Given this example, the field you’re looking for is `maximumAvailable`. That’s the current points budget. A store starts with a maximum available value that is 20x its leak rate. So, for the advanced plan (200 points/second), it is 4,000 points.

Please let me know if this doesn’t answer your question or if there's any more context I can provide.

Regarding your desire to test on a dev store, I believe this documentation will be helpful.

[OptionsSoftware]

Thank you for that information, so just to clarify - queries or mutations that have a cost over the 200points will not be rejected so long as there is enough budget in the maximum available points? 

I also do have a development store that I am testing on, I just wanted to know if I could select a specific Shopify plan to test the rate limits against?

[EfstathiosS]

Yes, that is correct.

Development stores are generally similar to the Advanced Plan in terms of features, I am not sure about the rate limit on them, but they would be 100 points/second in the worst case.

[SherwinSB]

Hello,

I have created a store using the developer preview for extended variants and added a product with 2,000 variants. However, when using the Ajax Product API, it only returns data for up to 100 variants, with no pagination system in place to retrieve more.

Is there an upcoming update that will include pagination or another method to access data for more than 100 variants through the Ajax Product API?

Thank you

[tlombardo]

Yes - we plan to provide an approach that will work for storefronts. We are prioritizing it now and will provide more details ASAP.

[tejasvyas]

Fields Only Available via read_inventory

The following fields are currently utilised in our REST API feed generation

variants[x].inventory_item_id

variants[x].grams

variants[x].weight

variants[x].weight_unit

variants[x].requires_shipping

With GraphQL, we are not able to get it without read_inventory permission. Where we will be update permission for Merchant.

Unavailable Fields

Few of fields are fully missing from GraphQL:

published_scope

variant.fulfillment_service

variant.inventory_management

Presentment Prices vs Contextual Pricing

When retrieving products via the REST API, the header X-Shopify-Api-Features could be used with the value include-presentment-prices to include multicurrency price information with the product object.

For Graphql, we need to join each currency individually via contextualPricing. Which has some downsides as below:

1. it requires extra markets permissions. Which lot of customer has not updated.

2. For large numbers of currencies, contextual pricing makes API queries slower and more expensive. In the example below, from one of our test stores, 23 currencies increased the requested cost from 142 to 878 and the time to execute from ~0.5s to ~2s.

By contrast, adding presentment prices to the REST query increased time to execute from ~275ms to ~330ms

 contextualPricing_GB: contextualPricing(

                context: { country: GB }

              ) {

                compareAtPrice {

                  amount

                  currencyCode

                }

                price {

                  amount

                  currencyCode

                }

              }

Product Images on Large Galleries

When retrieving products via the REST API, all product images are returned as part of the product model in an array.

For Graphql, we need to join the images (or media) nodes explicitly, as well as determining an appropriate page size / pagination strategy given some of our merchants may have large image galleries they wish to sync. 

This would impact lot of our customers with many images and also variant images mainly.

Inconsistent Prices Between REST and Graphql

On occasion, we have seen different prices returned by the REST presentment prices and Graphql contextual prices for the same product / currency. This is not a case where one is returning the base price, but where there is a difference of a few units. 

Can we check whether there is a differing caching strategy which may affect converted prices in this, with any relevant details that may help field support calls should they come in