Is restock_type field reliable for handling refunds?

[arsuceno]

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!

[arsuceno]

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:

[arsuceno]

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!

[John_Hardin]

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.

[arsuceno]

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.

[John_Hardin]

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.

[pmathbliss]

This is frustrating since the return_type told whether this was a cancel (removed item) or not restocking the item for other reasons.

[arsuceno]

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]

I'm seeing different data too. I am going to do some reviewing of manual
orders, canceling line items and returns today.

[arsuceno]

@pmathbliss please share your investigations. My guess is that Shopify "half fixed" the issue...

[pmathbliss]

At least on my development Shopify site, its doing the right restock types.

The first refund is a replace of an item. The second is a return of the
item. Fingers crossed this is fixed. I'm reviewing if I need to change
to the return object over the refunds object.

[arsuceno]

Is location_id filled in your tests @pmathbliss ? Thanks

[pmathbliss]

Fulfillments have a location.

The refund from a cancel has a location_id. The refund from a return
does not though it does show it was returned at a location in the admin.

I remember early the location ids didnt related to the locations in
shopify and had to be requested from different objects anyway. I'm sure
the GraphQL mentioned would have that location for the return rather
than the refund.