Have your say in Community Polls: What was/is your greatest motivation to start your own business?

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

Solved

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

Jacqui
Community Moderator
255 46 467

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.

Jacqui | Community Moderator @ Shopify
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution 
- To learn more visit the Shopify Help Center or the Shopify Blog
Accepted Solution (1)

Jacqui
Community Moderator
255 46 467

This is an 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!

Jacqui | Community Moderator @ Shopify
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution 
- To learn more visit the Shopify Help Center or the Shopify Blog

View solution in original post

Replies 76 (76)

___END___
Excursionist
28 1 12

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
Shopify Staff
1 0 2

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.

Xuya | Shopify 
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution
 - To learn more visit the Shopify Help Center or the Shopify Blog


sevenminds
Shopify Partner
13 0 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?

AV_SL
Shopify Partner
39 4 11

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

Biscuits Bundles App - Create beautiful mix and match bundles using native Shopify bundles functionality.
AsafGitai
Shopify Staff
109 16 45

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
Shopify Partner
74 2 57

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
Shopify Staff
16 1 14

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
Shopify Partner
74 2 57

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
Shopify Staff
109 16 45

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
Shopify Partner
74 2 57

@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
Shopify Partner
171 4 26

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


https://apps.shopify.com/seokart
SEOKart
Shopify Partner
171 4 26

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?


https://apps.shopify.com/seokart
___END___
Excursionist
28 1 12

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
Shopify Staff
109 16 45

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
Shopify Partner
9 0 11

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
Shopify Staff
16 1 14

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
Shopify Partner
7450 657 1564

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.

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


kliveny
Shopify Partner
5 0 3

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
Shopify Staff
1 0 0

@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
Shopify Partner
11 0 6

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___
Excursionist
28 1 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!  

tlombardo
Shopify Staff
16 1 14

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
Shopify Partner
14 0 1

Is there any graphql equivalent for this rest api 

/products/count.json?collection_id=11616416461
AsafGitai
Shopify Staff
109 16 45

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
Shopify Partner
113 3 44

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

PaulNewton
Shopify Partner
7450 657 1564

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.

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


Ajay_399
Shopify Partner
9 0 11

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
Shopify Staff
109 16 45

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
Shopify Partner
7450 657 1564

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

This is how survivor bias is created in a service.

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


rewind_garrett
Shopify Partner
6 0 25

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
Shopify Staff
109 16 45

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
Shopify Partner
6 0 25

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

PaulNewton
Shopify Partner
7450 657 1564

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.

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


fcodelgado
Tourist
6 0 6

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
Shopify Staff
109 16 45

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
Tourist
6 0 6

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
Shopify Staff
16 1 14

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
Shopify Partner
7450 657 1564

 

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.

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


fcodelgado
Tourist
6 0 6

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
Shopify Staff
16 1 14

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
Shopify Partner
5 0 3

/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(first10) {
      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
Shopify Staff
109 16 45

@hi @kliveny ,

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

OptionsSoftware
Shopify Partner
2 0 2

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
Shopify Staff
16 0 4

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
Shopify Partner
2 0 2

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
Shopify Staff
16 0 4

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
Shopify Partner
1 0 2

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
Shopify Staff
16 1 14

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

tejasvyas
Shopify Partner
11 0 5
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