@konrad.sopala same use case as @longjaso if we were to open this ability up to “development” or “staging” accounts that would be enough!
Thank you @lucas1 and sorry for the inconvenience! I’ll make sure to relay that feedback to appropriate team!
Hi Konrad,
We are also facing the same issues as @karlis.filipsons - we are using dynamic URLs ci kubernetes etc etc etc
Is there any way around this? maybe an api call that we can fire adding the new URL to the list of allowed urls?
Thanks
@reneweteling we tried to programatically update this in the past without success 
I’m not able to provide any timelines and dates for this as of now and the only thing I can do is to assure you that I’m indeed advocating for your needs and passing this feedback which I do. Sorry for any inconvenience and thank you for all the input!
@konrad.sopala, thanks for advocating on our behalf.
In the meantime, until a workable solution is available, can the community engineers like yourself put together a blog post/doc with examples of how the many teams that need a multi-tenant or deployment environment solution can achieve it using Auth0? Frankly this a blind spot of growing impact on our engineering quality stance and a documented work around solution (e.g. v2 API) would provide some help until an official solution is available from Auth0.
Thanks,
Joe
4 Likes
Totally agree with @lust it would be really nice to get a few blog posts in place about this.
The blog post of setting up Cypress with Auth0 was a life saver adding review apps into it would be amazing too.
As a starting point for the heroku use case there is a good article to setup dynamic environment variables: Streamlining setup for Heroku review apps | Dylan Wolff. I used those to setup the callback urls, which do support wildcards.
API identifier urls don’t support wildcards and need to use the management API (right now we do it manually)
Our platform is also a multi-tenant solution, providing a custom sub-domain per account. Due to this gap in functionality we will not be able to continue as an Auth0 customer.
1 Like
Thanks a lot for providing that feedback @patricksculley! Will make sure to relay that feedback to appropriate team!
We too are a multi-tenancy app with a subdomain per tenant. The list of Allowed Callbacks, Allowed Web Origins and Allowed Logout Urls is getting REEEEeeeeaalll Long. I’m expecting to hit a limit of some kind any day now. We either need to look at programatically creating an app client per domain or migrate away from Auth0. Wildcards for all of these would solve everything.
An update but not really. More like a BUMP 
I’m able to get wildcard subdomains working for Callbacks and Logout urls, but naturally not for Allowed Origins.
So handling my product’s own subdomains created per each of our customers eg, mystuff.website.com or hello.website.com requires an Auth0 Management API call to add each new subdomain to its Allowed Origins.
And for fully external customer domains mapping to our product a Management API call to add their domain to our Callbacks, Logout and Origins fields.
As i mentioned, this list of domains grows all the time. Starting to rethink Auth0 for multi-tenant but too in <3 with its features.
Unfortunately no update on this front.
Thanks again for following up.
1 Like
No worries, we’re here for you!
I know i’m simultaneously asking these questions here and Allowed Callback URLs field limitations? - #11 by steve1 however just looking to solve this so i’ll do my best to find solutions.
So, in the scenario of a single Auth0 tenant tied to a single web app. I map various subdomains and instruct to configure DNS for external domains for my customers to point to our single platform CNAME. eg, mycommunity,app,com or somethingelse,aaa,com or community,customer1,com (which points to alias,aaa,com).
Hurdles and options that seem worth considering so far:
- Allowed Callbacks
- Allowed Web Origins
- Allowed Logout Urls
When a new customer is created on my multi-tenant platform, using the Management API i could either:
- Use a single Auth0 Application (Client) and add the new domain using Auth0 Management API v2 to update callbacks, web_origins and allowed_logout_urls
- Use multiple Auth0 Application (Client), one for EVERY customer domain using Auth0 Management API v2 and then adding the relevant connections (eg, ‘facebook’) using Auth0 Management API v2 enabled_clients
My issue with 1. is the 100 domain limit on callback urls. Eventually you’ll hit it.
And my issue with 2. is similar, is there a limit on the amount of Auth0 Applications (Clients) we can create, not to mention how unwieldily that will get. Plus i can’t easily bundle the Auth0 ClientId with the app, will have to query it per tenant based on hostname.
I’m leaning towards 2. even though i have been using 1. for some time, just feeling like i’m on borrowed time and eventually the limit will be hit.
edit However after some thought … can you do Single Sign On (SSO) between Auth0 Applications (Clients)?? perhaps not.
Anyone else have a suggestion? Perhaps an insecure universal callback url? 
Would like to throw my vote in the ring. We’d really like to use wildcard origins for our staging environment. I think for now I’ll manually (w/ script) generate as many review app URLs as the input box will accept. But clearly this is not ideal.
One solution if you’re really sticking to the OAuth 2 recommendations would be to release a tool that makes the client app spin up/teardown stuff @nicolas_sabena mentioned easy. Integrate with Heroku/Netlify if you can
Thanks for adding to this one @bogdan! Just relayed this feedback to appropriate team!
1 Like
Right @bogdan as @nicolas_sabena said earlier up top:
For the types of automatic deployments that you are describing, I would suggest using our management API to automate the provision of a new client when deploying to a new domain and the deletion of that client when tearing down the deployment.
I’m currently using the management API to append urls but the list is long. Will look into using the management api to create a new Auth0 client per domain (eeeep, this list of clients will be long). Unsure if this will mess with SSO between domains but hey, only one way to find out.
Presuming i’ll need to:
- create the client using: Auth0 Management API v2
- update the connection property - enabled_clients: Auth0 Management API v2
1 Like
Update: now have wired up api calls to new create new clients for each subdomain. Annoying but functional.
2 Likes
Thank you a lot @steve1 for sharing it with the rest of community!
I’m doing my best to advocate for that but as you guys know everything is in product managers’ hands.