What’s going on with these new Shopify v3 modules? The email from Make said that the previous versions will begin limiting features starting in July (less than 24 hours of notice too) but they seem to be functioning as normal whereas the new ‘upgraded’ modules are very much limited.
Here’s just some of the data that is no longer avaliable through the new ‘Watch Orders’ and ‘Get Orders’ modules:
Shipping Cost
Selected Shipping method
Product handle/title (only variant title is avaliable)
Dicounted amount per line item
Tax Type
Tax Rate
Tax Price/Tax Total Price
Order Subtotal
Total Discount
And I’m sure there’s more, this is just what’s missing from my scenarios.
I feel like I’ve got to be missing something here, am I now required to set up a ‘Custom app’ connection to get this data?
@PEIT yeah, it doesn’t seem this update has been handled in a thoughtful way…
There’s no exact timeline on when specific endpoints will be phased out, nor the final date of when REST API will be unavailable.
There’s more urgency to update any V2 /product related modules, as those seem to be the first that are impacted.
I’m facing the same issue with missing data for “watch orders” module, and figuring out the best way forward to transition without completing refactoring my scenarios (which are for invoice generation).
From my research so far, setting up webhooks from Shopify seems to be the best/leanest option to retain the same data properties and schema to have continuation without too much overhead.
The GraphQL way
I’m also checking out the Shopify GraphQL docs now too, and it seems that there are additional nodes that can be included within /order queries that will pull through the rest of the data that’s missing from the OOTB V3 make module for “watch orders”.
I’m not sure why these nodes weren’t also considered for the new predefined V3 modules for /orders data to have parity with the data that was available in V2 (Rest API) modules.
Maybe this is why other nodes with the equivalent data from V2 aren’t included in the V3 module for watch orders as it would cost too much
In short, webhooks seem to be the best option for a quicker solution right now.
But, it’s also worth exploring using custom GraphQL queries for a solution that’s potentially more future-proof or nuanced if webhooks don’t fit your spec.
Thanks @aidy. Reading your posts doesn’t reassure me, and it makes me think that the changes I need to make to the scenarios won’t be easy.
For webhooks, this requires direct intervention on my clients’ Shopify accounts, which isn’t currently the case.
Hi @PEIT, @aidy since Shopify is gradually moving their API steadily from REST to GraphQL we are also trying to keep up with them so there are no big issues in the future and the GraphQL version of the app is ready and (relatively) feature-rich. The “start of July” in the original messaging might be a bit misleading, so, sorry for that, Shopify does not really have “strong deadlines” but we suggested to do the change as soon as possible in July to avoid potential breaking due to deprecation/disabling of certain endpoints by Shopify in the middle of the month for example.
As you know the previous Shopify version had 100+ modules, we are working on bringing most of them to you, but since not the whole of the REST API is being deprecated yet (as far as we know), we started off with Product modules, and some of the other most used modules.
The big issue with GraphQL is that it works completely differently from REST, whereas with REST you have a specific amount of API calls you can make in a period of time (let’s say 100 calls per 10 second) with GraphQL the “cost” of the API call depends on the query you make and the response you get. Let’s take an example where your complexity budget is 100 (let’s say it also refills fully in 10 second with 10 points per second being restored), if you make 1 API call per second which costs you 10 complexity points, you will never hit the complexity budget limit because the restore rate will be equal to the API call cost. However, if you make 1 API call which costs 100, you will then have to wait 10 seconds to make the same call again. The complexity topic is a bit of a headache but I tried to explain as best I could, hope that helps.
Due to this, when before you could just use a Trigger or the “Search for Orders” modules to get everything in the response, now you have to be much more deliberate and maybe even go through some trial and error to optimize your scenario and fit in the complexity budget/restore rate provided by your Shopify plan.
Unfortunately there is no simple “formula for success” which we could provide for a quick migration, it depends purely on the amount of data that is going to come and the Shopify plan you are on (which we don’t know), so potentially your shop can return fulfillments, shipping lanes, addresses, and your friend’s shop can only return fulfillments before hitting the budget limit.
This is why the modules look completely different from the original, have a different set of inputs/outputs, and why we couldn’t just copy them 1-1.
I hope this somewhat clarifies the situation and why we did X and not Y. Please let me know if you have any questions!
Understood that much of the ambiguity on this transition is due to missing context from Shopify’s end.
Yes, I have a couple of questions, one of them (#1) unanswered from my last post;
Is it a case that Make team builds out the data schema for new modules, the vendor (Shopify), or it’s a team effort between Make and the vendor?
Will you be adding the option to include additional GraphQL connection nodes for the pre-built shopify modules? (Akin to how V2 modules had the field selection option)
i.e. for /orders endpoint there is additionalFees, cartDiscountAmountSet, channelInformation, currentShippingPriceSet, etc, to replicate the same fields that were available in the V2 version of the “Watch Orders” module.
I’d see this more for the segment of your users that won’t be familiar with building out custom GraphQL queries to get the data that’s now missing compared to previous versions of modules.
And, some feedback on the app version update communications;
It would be good to detail which specific fields (or equivalents) from new versions are missing compared to older versions.
You have the full schema for both, so it seems that it wouldn’t be too much overhead to list those changes per module. Especially for the segment of your customer base that doesn’t know how to efficiently compare the schema between the two versions.
I assume by schema you mean which inputs/outputs we include in each mode, yes that one is made by us, we are trying to replicate the older version as best we could. There’s no input from the vendor (Shopify) side for this new version. Let’s say it’s our best guesses as to how these features could work, have relatively understandable user experience, and functionality.
I assume you are asking how you would be able to access those parameters in the new app given that they are not currently included anywhere. For that, we will be adding new modules to the app to hopefully cover as much as possible so it’s as little a headache to all of you as possible, unfortunately there will still be come headache which is inevitable )
Obviously similarly to the universal Make an API call module which we have for non-GraphQL apps, there might still be some utility in using the Make a GraphQL query module but yeah ideally we would cover as many use cases as possible with our modules.
Regarding the migration guide, we tried to include the modules which were possible to migrate from to new ones, the other are either not implemented yet, or maybe we missed a use case.
I hope I covered everything, but I’d be happy to add more context if needed!
I’ll leave the GraphQL query for Watch Orders module below in case anyone else wants to use it as a basis for building out a custom query with additional data.
Here’s a GraphQL explorer that uses a demo store that folks can use to get acquainted too;
{
"variables": { #Variables have their own UI inputs in the "Make a GraphQL API call" module.
"query": "created_at:>'YYYY-MM-DDTHH:MM:SSZ'", #Update as necessary - Earliest order date/time
"nOrders": 20, #Update as necessary.
"sortKey": "CREATED_AT",
"nVariants": 250,
"nLineItems": 250,
"nMetafields": 250,
"nShippingLines": 250
},
"query": "fragment addressDetails on MailingAddress { name firstName lastName name phone company address1 address2 city province provinceCode country countryCodeV2 zip } fragment moneyDetails on MoneyBag { presentmentMoney { amount currencyCode } } query ($after: String, $query: String, $nOrders: Int!, $sortKey: OrderSortKeys, $nVariants: Int!, $nLineItems: Int!, $nMetafields: Int!, $nShippingLines: Int!) { orders (first: $nOrders, query: $query, after: $after, sortKey: $sortKey) { edges { cursor node { id legacyResourceId name email phone poNumber displayFinancialStatus displayFulfillmentStatus confirmed confirmationNumber tags statusPageUrl note createdAt updatedAt totalPriceSet { ...moneyDetails } shippingAddress { ...addressDetails } billingAddress { ...addressDetails } billingAddressMatchesShippingAddress fullyPaid customer { id legacyResourceId firstName lastName displayName defaultEmailAddress { emailAddress marketingOptInLevel marketingState validFormat } verifiedEmail defaultPhoneNumber { phoneNumber marketingOptInLevel marketingState } defaultAddress { ...addressDetails } note tags numberOfOrders } shippingLines (first: $nShippingLines) { nodes { id title } } lineItems (first: $nLineItems) { nodes { id sku originalUnitPriceSet { ...moneyDetails } discountedUnitPriceSet { ...moneyDetails } discountedUnitPriceAfterAllDiscountsSet { ...moneyDetails } product { id legacyResourceId totalInventory tracksInventory variants (first: $nVariants) { nodes { id legacyResourceId displayName sku title taxable taxCode availableForSale inventoryQuantity barcode } } } quantity } } metafields (first: $nMetafields) { nodes { id namespace legacyResourceId key value jsonValue type } } } } pageInfo { hasNextPage hasPreviousPage startCursor endCursor } } }"
}
Btw, if someone needs to also get the GraphQL queries for other modules as a base to build from to get additional data from Shopify, then you can do so via the Chrome browser extension Make dev tool.
After installing;
Run your module via “Run this module only”, or open a historical log that has data for the module you want to get the query for.
Open up web dev tools, click on “Make” tab (right-hand side)
Go to “Scenario Debugger” > Operation > Request Body (copy all for use / customisation)
NB. Variables have their own UI input within the “Make a GraphQL API call” module, so you need to separate those from the query itself.
)
Inline # = comments