Hi devs,
If there are specific issues or gaps on the GraphQL API, please post them in this topic, so we can support you with your migration from the REST API.
ProductsCount: (I havenât confirmed if its been updated in the last couple of months) - it should match all features with products_count.
Product MediaImages: Ability to add new item with set Position. Should also return created_at, updated_at, Position, and linked variant_ids.
I will run more tests soon and add to this thread with my findings.
1 Like
Hello @Liam-Shopify, I am looking for a replacement for the below REST API that retrieves all article authors.
Since the above is a REST API, it is already deprecated, but I canât find a direct replacement for this in the GraphQL API explorer. The AI assistant suggests using the get articles GraphQL API (which is paginated) and then extracting the authors out of it - articles - GraphQL Admin.
Please suggest.
order.order_number not being present in graphql
This is completely blocking us. There is too many code to rewrite and this is just stopping us from doing that and the deadline is approaching
The checkouts webhooks: Webhooks, whose payloads represents an AbandonedCheckout until they are converted to a real order, do not send the id of the line items(the AbandonedCheckoutLineItem), however this field is newly introduced in the GraphQL admin api: AbandonedCheckoutLineItem - GraphQL Admin
There is a key property on the line item in the webhook payload but no key field exists on the AbandonedCheckoutLineItem GraphQL object.
This is a major blocker for us as there is no way to map an AbandonedCheckoutLineItem from a webhook to its GraphQL equivalent resource- we can uniquely identify an AbandonedCheckoutLineItem by its unique key in the webhook but not in its GraphQL resource, and we can only identify AbandonedCheckoutLineItems by itâs id in GraphQL but can not by its key.
Can we please get the id of the line item sent along with the webhook, or add the key field to the GraphQL object, or even better both to make the REST vs GraphQL versions of the object consistent with each other? 
Another request- the fulfillment_events webhooks contain an updated_at: Webhooks
However I noticed there is no updatedAt field on the GraphQL resource, only a createdAt: FulfillmentEvent - GraphQL Admin
I do see the updated_at property is marked as deprecated on the FulfillmentEvent REST resource: FulfillmentEvent - REST however isnât this not correct as the field is available on the GraphQL admin api? Can we get an updatedAt field on the GraphQL version of the resource as it does seem to be available and sent along in the webhooks?
For the Dispute/DisputeEvidence resource, there is a REST admin api endpoint to get the DisputeEvidenceâs associated with a Dispute: Dispute Evidence - REST
However I canât seem to find an equivalent query on the GraphQL admin api side. There is only a query to get a disputeEvidence given its id, disputeEvidence - GraphQL Admin, but none that actually lets you list the DisputeEvidenceâs associated to a Dispute. There is a way to query for all Disputes via the shopifyPaymentsAccount query: shopifyPaymentsAccount - GraphQL Admin, but no connection to DisputeEvidence.
Is there a way to fetch the DisputeEvidence for a Dispute?
@Liam-Shopify currently we have the following gaps in GraphQL which we would require to be filled before we move on from the REST API;
| REST Object | REST Field | Note |
|---|---|---|
| User | permissions | Not available even though it is documented. An error is returned when querying this field in GraphQL. |
| GiftCard | api_client_id | |
| user_id | No longer accessible by public applications | |
| line_item_id | ||
| Shop | plan_name | Doesnât exist in GraphQL. DisplayName can be used in GraphQL but not fully consistent with plan_name when shop is Frozen or Cancelled for example |
| OrderTransaction | source_name | Docs suggest using Order.source_name but it has a different meaning. |
| device_id | ||
| payments_refund_attributes.status | ||
| location_id | Docs suggest using Order.location but it has a different meaning. | |
| message | ||
| user_id | No longer accessible by public applications | |
| Refund | user_id | No longer accessible by public applications |
Please let us know if you require more info
Similar to @geon, the omission of order.order_number is a big blocker for us.
1 Like
In the REST API Refund data, the OrderAdjustments have a field called âkindâ (which is now deprecated): Refund - REST
Valid values: shipping_refund and refund_discrepancy .
This is no longer present in GraphQL - OrderAdjustment - GraphQL Admin
What would be the correct way to determine if the refund adjustment is related to shipping or not?
EDIT: found the answer, should be inside refundShippingLines now.
Guys, the product count is still returning 10,000 if ANY query is applied.
You guys understand that we CANNOT use graphql if this continues to fail right?
There should be an entire thread providing the exact status of fixing ProductCount - this has been an issue for years.
âIts so complicatedâ is not acceptable - that means there was an architectural flaw. Is the architecture being updated, or is fixing ProductCount simply being ignored internally and you are telling us something different publicly?
HERES A HACK YOUR TEAM CAN USE TO FIX IT:
SIMPLY POINT IT TO THE REST API VERSION SINCE THE REST API WORKS. ONCE YOU FIX IT, JUST REMOVE THE POINTER. DO YOU UNDERSTAND?
In fact - ALL THE REST TO GRAPH MIGRATION BLOCKERS could be solved by writing some hack wrappers that point to the REST API. Everyone would think the GraphQL API works perfectly, we could all move to it, and then you could work behind the scenes to remove the hacks on your own time.
The graphql Shop object is missing:
- a reference to âpassword_enabledâ
- a reference to the plan âidâ - in the Rest Api plans are listed in snake case (âshopify_plusâ) ie. like ids, but in the Graph Api they are display names âShopify Plusâ. Would be very useful to get the id type name for programmatic reasons.
Would be nice to switch over 100% but still encountering these gaps.
For password_enabled can you query this object: OnlineStorePasswordProtection - GraphQL Admin
1 Like
@Liam-Shopify Do you have an estimate EOL for the REST API yet?
There are still a number of open queries regarding fields/data available in REST but not yet available in GraphQL and we are getting worried that those queries might not be addressed in time.
user_agent is missing in graphql orders api
Orders REST API has âclient_details->user_agentâ field to get information about customerâs browser etc.
Same is not available in Order GraphQL API.
In REST API âclient_detailsâ is mapped with GraphQL âcustomerJourneySummaryâ but it doesnât have any option to get âuser_agentâ.
is there any alternative for it?
Hi @Mehmet_Talha_Seker - thanks for flagging this, Iâve connected with the relevant team for their recommendation.
@Mathieu_Nunez - thereâs no estimated deadline yet for end of life for the REST API. Are these the main gaps you are concerned about: Please flag GraphQL Migration blockers here - #9 by Mathieu_Nunez
- order.checkout_token
- order.cart_token
- order.checkout_id
- order.cart_id
The checkout_token is most crucial, as itâs used by checkout extensions and web pixels and in GraphQL orders query
@Liam-Shopify see below for our up to date version of that table;
| REST Object | REST Field | Note |
|---|---|---|
| User | permissions | Not available even though it is documented. An error is returned when querying this field in GraphQL. |
| GiftCard | api_client_id | Deprecated |
| user_id | No longer accessible by public applications | |
| line_item_id | Deprecated | |
| Shop | plan_name | Doesnât exist in GraphQL. DisplayName can be used in GraphQL but not fully consistent with plan_name when shop is Frozen or Cancelled for example |
| OrderTransaction | source_name | Docs suggest using Order.source_name but it has a different meaning |
| payments_refund_attributes.status | Deprecated | |
| message | ||
| user_id | Only accessible by private applications for Shopify plus stores. Reporting no longer available for others. | |
| Refund | user_id | Only accessible by private applications for Shopify plus stores. Reporting no longer available for others. |
| Order | cart_token | No longer available in GraphQL |
| checkout_id | ||
| device_id | ||
| client_details | ||
| token | ||
| source_name / channel | ||
| landing_site | ||
| referring_site | ||
| fulfillment_status | Values are different from REST | |
| attributed_staff | Only accessible by private applications for Shopify plus stores. Reporting no longer available for others. | |
| user_id | ||
| total_line_items_price | ||
| UserAgent | ||
| LineItem | product_id | No historical value kept so it can be an issue if re-imported and product no longer exists |
| variant_id | No historical value kept so it can be an issue if re-imported and product variant no longer exists | |
| grams | Accessible via productVariant.InventoryItem.measurement.weight. No historical value kept so it can be an issue if re-imported and product variant no longer exists |
|
| fulfillment_service | ||
| Fulfillment | Shipment Status | Cannot get equivalent between GraphQL and REST |
Shop.primary_locale is missing from GraphQL.
While this can be queried via shopLocales, this requires read_locales, which can cause issues for past installations that do not have that permission.
Additionally, not exactly a blocker, but something that should be addressedâŚ
Reading settings_data.json via GraphQL (eg. to check if an app embed is enabled) returns non-JSON data (thereâs a warning comment added to the top of the file).
This can be parsed out, but it creates some uncertainty as App developers donât know if this could change in the future and break existing code.
It would be better, in my opinion, if there was a field on OnlineStoreTheme that allowed for directly querying whether or not an app embed block was present, enabled, disabled, etc.
eg. something like this:
query {
themes(first: 1, roles:MAIN){
edges{
node{
appEmbeds(appIds: ["<uuid>/block", "<uuid>/block2"]){
appId
disabled
settings{
key
value
}
}
}
}
}
}