Issues with App redirect URL - using 'any' keyword

We are in the process of getting an App approved in the marketplace. When using the Authorization Url under the “Submit” tab to authorize within the same account, it fails with the error: “404 not found: Requested route (' does not eixst”
[actual value is masked with xxxxxx]. As we want to use the same app in multiple deployments of our application and each of these deployment has a different URL, we have used “any” keyword in the Redirect URL and added all the actual deployment URLs to the Allow list. This configuration is working perfectly fine for another app which is already published, but we are facing this issue in the new app. We are looking for guidance to overcome this error.

Hello, @martin.sommer1 have the additional domains have been added to the whitelist exactly how they look because the any does not work for the allowlist.

Regards, Kwaku

@kwaku.nyante Thanks for the prompt response. Here is the format used for the URLs under the Allow list:

We want to ensure the authorization works for all of our deployments. Could you please share more details on how we handle this use case? We see two “Redirect URL for OAuth” fields one of development and other for production. Here we have used the “any” keyword (URL Format: with an understanding that this will be a wild card that would route authorization via any of the Aloow List URLs (Redirect URLs). Your guidance here is much appreciated.

I believe your setup is correct, but if any is being used in the redirect field I believe the specific URLs have to be whitelisted under the allowlist you can’t just use any redirect in the allow list it won’t work.

Regards, Kwaku

Please see here for more information on this OAuth for user authorized apps

Thanks for sharing the article. We will review the same and share the feedback. Thanks again for your assistance.

Hello @kwaku.nyante , we re-looked into our configuration and the URLs from the allow list does exactly match the format provided in the Redirect URL with ‘any’. And the Oauth URL seems to be generated with the Redirect URL containing “any” instead of an URL (with an actual subdomain) from the allow list. We are clueless at this point for the next steps. Could you please help us the way forward from here?

Hello, @martin.sommer1 Not sure on my end, do you have a support plan to get help from someone on the support team?

Regards, Kwaku

@martin.sommer1 there may be an error in the docs or an updated flow that was not communicated clearly. The docs say to “Add the any wildcard domain to your OAuth Allow list”, but try this flow without the any wildcard domain in the OAuth allow list:

If that does not work, try with both in the OAuth allow list like this:

Additionally, do you have either of these checked?
Screenshot 2024-01-03 at 5.11.11 PM

Revisiting this portion, are you dynamically adding the respective subdomain on the redirect_uri param?



Hello @gianni.zoom Thanks for your response. Here is what we tried:

RedirectURL & AllowList:
We have set both dev and production redirectURL as: “https ://”

And the allow list contains:
https ://
https ://
https ://

And also enabled the setting for “Subdomain Check” under the Security Check section.

Actual Outcome:
When we tried to authorize using the authorizeURL(within the same acc), we were able to sign in and allow the permissions. But it then leads to an error - ```
404 Not Found: Requested route (‘’) does not exist.

The authorizeURL seems to be different from what you have mentioned in your comment. Here is the sample authURL:

The authorizationURL does not contain the "sub" in it.

Could you please assist further on this?

@martin.sommer1 , please try the guidance I outlined here:

This may be resolved if you try the guidance above. If it does not work, please tag Kwaku in your response. Be prepared to send him the following when he reaches out via email or private message on the forum so this can be escalated further:

  • a screenshot of the app credentials page with full visibility of the redirect url and OAuth Allow Lists
  • provide the direct link to their application credentials page
  • provide the direct link to the error page when they try to authorize
  • client ids


This topic was automatically closed after 30 days. New replies are no longer allowed.