Return requested Trigger -> returnApproveRequest Action: "Return not found."

Shopify Plus

Topic summary

Users encountered a “Return not found” error when attempting to automate return request approvals using Shopify Flow’s returnApproveRequest mutation, despite verified return IDs and successful manual processing through the Admin UI.

Key Investigation Findings:

  • Return IDs were confirmed accurate across webhooks, Flow triggers, and Admin UI
  • Manual API requests via Postman and GraphiQL worked, but Flow-based requests failed
  • The mutation format and API version were correct

Root Cause & Resolution:

  • Identified as a scopes issue preventing Flow from writing return data
  • Initial fix was deployed but subsequently rolled back due to unintended side effects
  • Final fix successfully deployed - both returnApproveRequest and returnDeclineRequest mutations now working in Flow

Current Status:

  • Issue resolved and confirmed working by multiple users
  • One user reported brief instability accessing the customer portal, which self-resolved

The problem affected both approval and decline mutations, requiring investigation by Shopify’s returns team to address the underlying permissions configuration.

Summarized with AI on October 31. AI used: claude-sonnet-4-5-20250929.
1

Background:

I am setting up a flow to automatically process return requests. When I use the “Send Admin API request” with mutation returnApproveRequest (or decline) and the “return.id” from the trigger for the input.id the step always fails with “Return not found.”

Investigation:

  • Verified the ID is accurate. I setup a webhook for returns/request and verified the id in the payload is the same id I am using in the flow mutation. I also checked the admin UI “Review Return Request” page and the id in the url matches (minus the gid://shopify/Return bit)
  • Verified the return works if done manually via the admin UI. I even checked the network tab to make sure the id being sent in the mutation is the same one I was using in flow and they matched.
    • The only different I notice in the Admin UI mutation call and the flow call is the input payload from the admin UI has some extra parameters (calculatedReturnId, notifyCustomer, unprocessed) but none of those show up in the docs
  • Verified the API version being used in flow matches the input in the flow action

Really stumped by this one. Has anyone faced this issue or a similar issue before?

2

You probably have a malformed request. Like extra spaces in your JSON or something like that. Look data on the workflow run log. If you can’t find it, post a screenshot here of the data in the request

3

@paul_n Thanks for reply,

Here is example of the input sent to the mutation. I used the formatting that comes with the action template (example below)

{
  "mutation_name": "returnApproveRequest",
  "mutation_input": "{\n  \"input\": {\n    \"id\": \"gid://shopify/Return/9112420674\"\n  }\n}",
  "api_version": "2024-04",
  "hydration_type_patch": "{}"
}

{
  "input": {
    "id": "{{return.id}}"
  }
}
4

Where are you requesting the return? I think you need to do that via the customer portal. Otherwise, you are just creating a return, but not an approval request.

5

I am requesting the return via the customer portal. Example below.

Screenshot 2025-02-27 at 9.51.07 AM.png
Screenshot 2025-02-27 at 9.51.07 AM.png521×363 15.9 KB

6

Yep, I’ve reproduced this on my shop. I suspect there is some kind of defect with that mutation/API. Will report this to the return team.

7

I tried approving return request manually via the Admin UI to see what happened and it works and looks like it uses the same ID as I used in flow.

Screenshot 2025-02-25 at 2.44.51 PM.png
Screenshot 2025-02-25 at 2.44.51 PM.png3152×1224 379 KB

8

I have the same problem, I couldn’t solve it.

What I could notice is that when I try to make the return using the Shopify GraphiQL App installed in my store or through the Flow App, I get the same behavior “Return not found.”

However, when I make the same request using Postman, it worked.

9

Hi, we found the bug - it’s a “scopes” issue on writing return data. Fix should be fairly quick…perhaps try retesting early next week

2 Likes
10

Awesome! Thanks for investigating and reporting the issue. I will try again early next week and report back.

11

Same. If I did the request manually via the GraphQL Admin API it would work. Sounds like the issue should be resolved some time next week.

1 Like
12

The issue has been fixed and your actions should now work

2 Likes
13

@paul_n Just tested the flow and it’s working. Thank you for the quick turn around on this fix!

@bmatumoto :up_arrow:

14

It also worked for me. Thanks for your collaboration, guys.

15

@paul_n After further investigation it appears the same issue is happening with the returnDeclineRequest mutation.

16

Yeah, we had to rollback the change as it caused another issue. They are now investigating why that happened. Will post back here when I know more.

1 Like
17

We figured out the issue. Returns should again be working in Flow now.

18

@paul_n
I am requesting a refund through the customer portal. The same as the print sent by @JSheldon3488

But now I am getting an error:
Does not exist at this address.
Check the URL and try again.

Anyone else having this problem?

19

apparently it was just an instability, because now it’s ok.