App reviews, troubleshooting, and recommendations
Hi,
We have an application which relays in restock_type to handle refunds. Recently we have started seeing payloads with "restock_type": "no_restock" in orders which have been actually restocked. I could provide some examples in private (what happend to chat support?) because it's a bit annoying to see these cases.
Has the field been deprecated? Is there any other field we can trust?
Thanks!
Quick update on this. I found some kind of pattern, recently I have started seeing this "inspected by" in different stores. I don't know why this new inspect thing is, but it seems to be quite related to the issue...
...because whenever I see it, I get the restock_type "no_restock" in the json payload:
For whoever interested, I got this response from Shopify:
Hi Álvaro,
Thanks for the information you've provided. I checked with our development team, they have informed me of a recent API change in our APIs and how restocks are handled when they occur through the Admin.
This year, we’ve released Exchanges capabilities around a month ago (see changelog), and with that release, we’ve updated Shopify Admin to use reverseFulfillmentOrderDispose. When you use this mutation, restock information would now reside under ReverseFulfillmentOrderDispositions. This is why you are getting restock: false now, as restocks done on Admin are no longer done under a refund mutation, but instead under a reverseFulfillmentOrderDispose mutation.
You can also access this information by subscribing to the reverse_fulfillment_orders/dispose webhook (using this link). You can also refer to our documentations on how the Return APIs work (ie: the new API Objects we’ve introduced in 2023-01 ).
Moving forward, to query restock data you'll want to follow this document here.
As always, please do not hesitate to reach out with any further questions.
All the best!
That's not an excuse for breaking the API contract for all currently-supported historical API versions. The existing historical API versions should be doing the extra work needed to retrieve the restock information from its new storage into the refunds restock_type so that the API contract can be honored.
This response destroys trust that Shopify will provide stable APIs.
I cannot agree the most @John_Hardin . Now the information provided by the order payload is not aligned anymore with the actual status of a item and it's quite more complicated to figure out if a item has been restocked or not.
About your only option is to do what Shopify should be doing behind the scenes to honor the API contract: whenever you retrieve an order object from the API, you need to then also retrieve the associated Return object(s) and dig around in them to associate the reverse fulfillment order dispositions to the refund line items and update the restock_to status and restock location if the product has actually been restocked.
One possible twist to this is it looks like the data structure supports splitting the refund reverse fulfillment across multiple locations (e.g. the customer returns qty 2 for a refund, the order refund has one line , but somehow the restocking is qty 1 to two different locations). I've haven't seen that and don't know a plausible scenario for it to happen, but the reverse fulfillment order data structure does allow for it.
This is frustrating since the return_type told whether this was a cancel (removed item) or not restocking the item for other reasons.
Small update on this in case somebody is following the thread. Now I'm getting "restock_type": "return" and "restock": true but the location_id is null:
@pmathbliss please share your investigations. My guess is that Shopify "half fixed" the issue...
We recently spoke with Zopi developers @Zopi about how dropshipping businesses can enha...
By JasonH Oct 23, 2024A big shout out to all of the merchants who participated in our AMA with 2H Media: Holi...
By Jacqui Oct 21, 2024We want to take a moment to celebrate the incredible ways you all engage with the Shopi...
By JasonH Oct 15, 2024