Cancel exchange order

Hello, I am trying to cancel an exchange order via di API. My current procedure is to update the return with a canceled status, then retrieve the exchange order id via a query, and then use the order_cancel mutation to cancel it. However I am getting the following error:
ReturnObserverResponse: {"errors":[{"message":"Cannot access the requested order. Permission denied","operation":"order_cancel","field":"order_cancel","request_id":"611c111a0cf53519ba132fd1","code":9}],"data":{"order_cancel":null}}

Any ideas?

One thing I forgot to add, I am getting this error both with and without the “customer_account_id” field.

It looks like you have the data parameters one too many times. After mutation, you have data that should be put in the parameter for the order_cancel. EXC should cancel like any other order.

mutation {
  order_cancel(data: { order_id: "**order id here**" }) {
    request_id
    order{
      order_number
    }
  }
}
mutation
"""remove this ***($inputtwo: CancelOrderInput!)"""
 { 
order_cancel(data: $inputtwo) {
 request_id 
  }
}

Hi Theresa, I tried to do as you said but I got an error, as expected:

ReturnObserverResponse: {"errors":[{"message":"Variable \"$inputtwo\" is not defined.","locations":[{"line":1,"column":31},{"line":1,"column":1}]}]}

The piece of code you are referring to is necessary to use the $inputtwo variable. Also, this is the same mutation I use to cancel my regular orders, so I am sure it is working. It seems like there is a permissions error more than anything else.

I am looking for a workaround, but if this is a bug it may be beneficial to let your engineers know.

Best,
Claudia

Oh, ok. I see now that it was just sending in the definition. I do apologize, it looks like you were correct in that. When I tested with just the order id,(first mutation example) it worked perfectly and canceled the order. It should not be the EXC differentiation holding the mutation from working. Do you have the request-id of the mutation that used the same format in deletion for regular orders? It may also be the sequence where the RMA is canceled first. What is the process you follow when udating the return with a canceled status?

Hello,

I don’t think it is the sequence, because I have attempted the same sequence (cancelling RMA first and then the order) using a regular order (not an exchange) that I created via API and had no problem. Not sure what the issue may be, it mentions permissions, but not sure why that may be.
At any rate, I have bypassed this error by creating my own exchange order rather than using the one ShipHero creates within the return_create mutation, and this is working perfectly for me in terms of cancellation. This has also ended up being the best solution for us, in that it has allowed us to name the exchange order with the order number we prefer. Moreover, it works better with our purchase orders, in that the items get backordered without having to release the exchange first (given that we make items to order, this is a big plus for us). So all OK for us here. Thank you for your assistance!

1 Like