Goal: Changing the env from Production to Staging
Steps: N/A
I would like to use a REST API based on configuration values that vary depending on the environment, but I cannot change the environment.
Is it a bug that the Retool app cannot recognize that this app is using one of the configVars values, or is it deliberately blocked from changing the env when no resources used?
Hi @Max, the environment will appear as disabled at the App level if one or more of the resources being used within the App don't have that environment configured at the Resource level. I recommend going over the Resource queries one by one on the App, and checking each Resource on a second tab. In addition, what do you see when you hover over '(disabled)'? There should be a helpful tooltip.
In case we need it, here is our doc on environments:
Hi @Paulo, Thank you for your response.
I understand that the (disabled) message disappears when using one of the predefined resources available in the resource tab.
However, in the app I’m currently building, I don’t need any of the predefined resources. Instead, I’m using an ad-hoc REST API that utilizes config vars. I’d like to verify its behavior based on different environments, but it seems that this functionality is intentionally restricted.
Is it mandatory to use one of the predefined resources for this purpose? What options are available if I don’t want to use these resources? Is the platform intentionally designed to prevent switching between environments when no predefined resources used?
We don't necessarily need to use one of the predefined Resources. As long as your REST API resource exists under Resources and has the desired environment, we should be able to change between prod and staging.
For example:
Here is a simple REST API resource with both environments:
And here is an App with nothing but a Resource query using that REST API Resource:
Yes, by 'predefined resources,' I meant the ones listed under the Resources tab. So, if I understand correctly, to achieve this, I should create this ad-hoc REST API as a resource under the Resources tab, even though it's only used in this specific app, right?
Thank you for the clarification.
@Max,
It seems like even in a brand new app (with no resource/queries created) there is no ability to switch the environment in the app. It further appears that if you include a single resource which has the environments you need setup you can then switch environments and access the configVars.
So, on one hand, yes you should setup a REST API or other resource that uses the environment(s) you need in the Resources tab but, on the other hand, you should only need to do this with one resource and not have to create several different REST API resources for everything that needs to access the variables so you can continue with the ad-hoc setups if that fits your use case.
The above is correct. Just to clarify, creating a Resource from the App or from the Resource page has the same result. Every new Resource we create exists under Resources.
For example,
Here is the creation of a Resource from an App:
After creation, we'll find it at the Resources page:
@pyrrho I appreciate your answer 
@Paulo I'm not sure when this was updated, but it appears that there are now two types of REST APIs you can create within an app editor page.
As far as I remember, there was only one method: creating app-exclusive REST APIs (please correct me if I'm wrong). However, I now see that you can also create a new resource directly in the app editor page.
(I was aware that you could create a REST API in the Resources tab.)
I have been using the ad-hoc version since this API is only needed for this specific app and not for any others. Additionally, the Resources tab suggests that these resources are meant to be defined for universal use across multiple apps.
Apparently, there is no way to switch the environment when a query in the Resources tab is not used.
To be honest, the main purpose of this post was to confirm if this is indeed the case.
I also appreciate the helpful response that included screenshots. Thank you for the detailed information 
Hi @Max, you are welcome! 
You are correct, in versions v3.3X and before, all REST API queries created at the app level were ad hoc.
In versions 3.4X we introduced REST API (example) for ad hoc queries, and the option to Create a new resource directly from an app, with the purpose of improving access, debugging, and reusability:
We then renamed REST API (example) to REST API, which is what we currently see in our latest version 3.96.0:
I should've been more specific in my previous post. As you pointed out, there are in fact two types of REST API Resources:
The built-in, ad hoc REST API Resource, which can be used from any app. It's configuration only exist within the scope on the current App, it does not create a new Resource, and will have no impact on blocking environments as along as all other Resources used in the app have the desired environment enabled. This is what we should be using for environment agnostic requests, like fetching data we need from an endpoint despite the environment of all other Resources (i.e. getting an image from AWS)
A REST API Resource that we create by selecting this option:
This does create a Resource at the organization level (will show up in the Resources tab). This is what we should be using when we need to set up multiple environments for an endpoint.
I'll also mention the elephant in the room, Demo Resources / REST API:
If you are working with a Self-hosted instance, please let me know what version it is so I can further clarify any confusions.
