Hello there, I am looking into creating returns via API.
I started out by testing within Shiphero (without API) and I have a few questions…
- I see that it is possible to set up shipping carriers for returns, so I attempted to set up on of my API carriers to test… however it doesn’t seem to show up in the options for carriers when I create a return. If I send over the carrier data via the return_create mutation, will that work even if the carrier isn’t working on the Shiphero end? I am attaching two screenshots of what I mean… I attempted to set up API Fedex, but it doesn’t show when creating a return. Can I still use this via the return_create mutation?
-
When creating a label, the return address is automatically set to the warehouse selected for the return, which makes sense. However, in our specific case, certain returns are sent to local hubs (for example, all of our UK orders are returned to the UK even if we don’t have a warehouse there). Is there any way to specify a different return address without creating warehouses for these locations? They are not really warehouses, so I wanted to avoid creating them.
-
When you create an exchange order, there is a checkbox which states: “Do not allocate product to exchange order, until exchange order is manually released to ship”. This also makes sense. However, in our specific case, we make our items to order… thus we usually start producing the new items even before the return is received and inspected. The issue is that, by selecting this checkbox, the items do not go into the backorder state and are not included in any PO until the exchange is manually released. If we don’t check the box, the order does become backordered and is included in a PO, but when the item arrives, it becomes “Ready to Ship: yes” even before the exchange is manually released. Is there any way to included exchange orders in POs even if the checkbox is checked?
Thank you!
hello! is there any update on this? thank you!
Thank you for the heads up! I will update shortly.
1.In the return_create mutation, there is data fields for both the shipping_carrier and the shipping_method. If you enter the API carrier that you have setup, it will show up as the Return Package Label Carrier on the RMA. I was not able to have the label printed tho. I am still looking into this to see if there was a flaw in my testing.
2. The return addresses are pulled from the default warehouse profile. So, you may, yes, have to create a warehouse with the default profile of the address you need it returned to.
3. This is an interesting dilemma. The one thing that I would consider is to have the items allocate to the exchange order, and put an operator hold on the order. Would that work for your needs?
Hi Theresa,
Thank you for your reply.
I look forward to hearing about the API label, thank you.
As for the rest, this all makes sense.
I do have another question…
When shipping an exchange, it seems that the return does not automatically get flagged as complete. Have I made a mistake when testing? Is there any way to complete the return automatically when the exchange is shipped? Or does someone need to manually change the status?
I spoke with a colleague and there is a request that is active in engineering for API carriers to show up in the UI for creating a return. I also got a request for your RMA mutation request-id. Can you please post the request-id?
In your exchange order question, do you mean the order does not complete when it is shipped or the RMA does not get set as complete when the exchange order is sent?
Hi there!
I don’t have a request id because I made the first tests directly through the Shiphero dashboard, as shown in the screenshot I sent with my previous message. I will test this via graph soon and let you know.
As regards the exchange, the exchange order gets fulfilled as usual, however the RMA doesn’t get set as complete. Is there any way around this?
1 Like
You are correct in that the RMA will not automatically mark as complete when the exchange order is sent. It would make sense in that receiving the returned product, restocking, refunding, and sending the exchange are all separate pieces of the returns process. With different warehouse procedures, the shipment of the exchange may not always signify that an RMA is complete. There really is no way around that, you would need to review the RMA and manually mark it as complete
ok, that makes sense! we’ll work with that.
I have two more questions… sorry, but as I work on this more things come up.
-
when creating the exchange order, is it possible to specify a different warehouse from the one the return is going to? for example, we have our uk clients send their returns directly to a hub in the uk, however their exchange is shipped from an entirely different warehouse. how can i do this?
-
when creating the line_items, where is it possible to specify the return type? i need to be able to indicate whether the client wants a refund or store credit (which I see is possible when creating returns from the dashboard).
I have also noticed the following issues now that I have started testing:
- when sending “label_type”:PAID, the return shows up as a free label… not sure why. this is the return id: UmV0dXJuOjI1MDI0MjA=
- I cannot manage to send a “return_reason” on an item level, even though I am sending it in my mutation (pls refer to the above return id as an example)
- when creating an exchange order, the “notes” section indicates “array”, but I haven’t sent any notes in my mutation (ex. UmV0dXJuOjI1MDI0Mjk=)
any insight would be very helpful, thank you!
best,
claudia
Hi, apologies for the delay.
About setting the EXC order to ship from a different warehouse than the RMA, I am not sure that is possible. But will check the documentation and see if I can test it.
Ok, i appreciate that, thank you.
Please let me know when you have a chance to check out the issues I encountered that I listed in my previous comment, thank you so much.
The EXC should work like any order and should allocate to whatever warehouse it is set to.
When creating a line item in a return, the only things that can be set in the API on generating the line item is:
sku
quantity
return_reason
condition
is_component
exchange_items
PAID designation would mean that the store pays for the label so it will be the free type for the end customer.
I will check further into numbers 2 and 3 in the last section and update you shortly.
Hi
Do you have the request-id for the mutation that created return id: UmV0dXJuOjI1MDI0MjA=
With that, I can check the return_reason in the mutation.
Hi Theresa,
From my understanding, PAID should mean “paid by customer”, whereas FREE means “paid by store”. Or at least this is what occurs when you create the return from the Shiphero dashboard rather than via API: paid labels are detracted from the refund, while free labels are not. Please refer to my screenshot of two returns created from the Shiphero dashboard.
At any rate, the problem is that these designations are incorrectly mapped in the API, or so it seems… both FREE and PAID create a return with a “free label” when I imagine they should do two different things.
I will send you the request_id for each individual issue.
-
Both FREE and PAID create “free label” returns:
PAID - 6115830a8f1a93535a0caf90
FREE - 611584f9d4efb65ba22f6753
-
return_reason is not being registered in my returns on an item level: 6115830a8f1a93535a0caf90
-
a “notes” section appears, and contains an array, when an exchange order is created, even if I have not sent any notes with the mutation: 611584220ffb88e061acc104
Finally, regarding the return_type on the item level, will this be implemented at any time? I find it a useful feature to be able to specify store credit, and I see that on returns generated from the shiphero dashboard this is possible. I hope this will be implemented for API as well.
Looking forward to your reply.
Claudia
While we are looking at issues, I also have this problem:
ReturnObserverResponse: {“errors”:[{“message”:“Invalid Line item 559278290, warehouse Primary. It must belong to the same warehouse 75507, USA returns.”,“operation”:“return_create”,“field”:“return_create”,“request_id”:“61167f4a03f9ba1b4a864b63”,“code”:9}],“data”:{“return_create”:null}}
What I was trying to do here was return an item to a different warehouse from which it was shipped. This IS possible when creating a return from the shiphero dashboard, but I am not sure why it isn’t possible to do so when using the API. This is essential for me as we have warehouses around the world which only receive returns. What can I do to fix this?
1 Like
We pushed this as a bug, thank you!
Hi again, which issue did you push as a bug? Have you been able to look at the request ids I sent about regarding the PAID/FREE label types, weird notes array on exchanges, and missing return_reason on the item level?
The one you found on the other post about getting the error returned when you try to send the exchange from a different warehouse than the one the return is locked to.
Not yet, it is in my lineup. Thank you for all the information, I see they all have request ids.
Hi Theresa,
The issue isn’t sending the exchange order from a different warehouse. The issue is that, if the warehouse specified in the return_create mutation is different from the one used for the original order, it will not create the return at all. It is my understanding that you should be able to return to any warehouse. In my tests, it seems the exchange order has nothing to do with it.
Is there an ETA for the bug fix?
The old ticket has been sitting there for many months so I’m a bit worried about it…
As regards the rest of the issues, I look forward to hearing from you.
Thanks again for your help.
I do not have an ETA. The ticket being sidelined was because of code freeze during peak season. It has been resumed and set with priority.
