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

Community Events
1

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.

2

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?

3

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?

4

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!

5

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?

6

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

7

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.

8

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.

9

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?

10

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?

  1. 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?
11

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?

12

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!

13

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

14

Is there any graphql equivalent for this rest api

/products/count.json?collection_id=11616416461

15

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?

16

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

17

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.

18

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!

19

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

20

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/topic/2662734

Thanks