Apidog Docs
Environments & services
When making API requests, it is often necessary to switch between development, testing, and production environments. Apidog makes it convenient to send requests to different environments - you simply need to click and select the desired environment at the top right corner of the interface.
An Apidog environment consists of two core elements. The first is the service (base URL), used to maintain the target of request delivery. The second element comprises a group of one or more variables that can be referenced in requests or scripts. When switching between environments, both the service (base URL) and environment variables will use the values defined in the current environment.
Create an environment
Click
Save.To use the new environment, select it from the environment selector at the top right of the interface. This makes it the active environment and sets all variables to the values specified in the environment.
:::tip[]
Environments in Apidog are distinct from those in Postman, where there is a tendency to associate each Base URL with a separate environment. This blurs the lines between environments and base URLs.
In contrast, Apidog's environments directly reflect real environments like development, testing, and production, rather than treating each base URL as one single environment.
For example, within a testing environment, there may be various services such as user service and order service all contained within the same testing environment. It is important that these services are not divided into separate user and order environments.
:::
Services (base URLs)
The Service (base URL) is the primary feature in an Apidog environment. In Apidog, an endpoint starts with a forward slash (/) and does not include the base URL; when sending an endpoint request, it is necessary to specify the destination base URL. This underlines the importance of the Service feature in the environment—selecting a particular environment is a prerequisite for sending an endpoint request.
A standardized base URL format begins with the protocol and without trailing slash (/), like
https://127.0.0.1
or
http://abc.com/v1
Every environment contains a default server; when an endpoint does not specify a specific service, the request is directed to the default server.
For instance, if the default server base URL for your production environment is http://abc.com/v1 and your endpoint path is /pet, then when you send a request in the production environment, the actual request sent would be
http://abc.com/v1/pet
:::tip[]
If the endpoint path begins with http:// or https://, the base URL will not be appended to the request. Nonetheless, this practice is generally discouraged.
:::
:::tip[BASE_URL variable]
In Apidog, there is a special environment variable called BASE_URL, which stores the base URL for the "Default Server" of the current environment.
It is generally discouraged to use this variable. For custom scripts, it is recommended to use pm.request.getBaseUrl() to fetch the base URL for the present endpoint. Avoid using pm.environment.get('BASE_URL'), as it may not correctly capture the base URL for the current endpoint if the endpoint does not employ the "Default Server."
If the user manually creates an environment variable labeled BASE_URL, it will supersede the system's predefined BASE_URL.
Scripts are unable to modify the base URL. The command pm.environment.set('BASE_URL', 'My_url') within a script will establish a genuine environment variable called BASE_URL instead of altering the base URL itself.
:::
Utilize multiple services
If your project involves multiple distinct services — for example, directing user-related requests to https://user.abc.com and order-related requests to https://order.abc.com - then you need to utilize multiple services. Here is the specific process:
Services can also be added by folder. Click on the folder name, and in the Folder settings, select the service from the Service dropdown. Then all endpoints under this folder will be directed to this service.
This is because in most teams, both test and develop environments have corresponding services. By setting the respective base URLs for each environment, when you switch environments at the top right corner, all endpoint requests will be directed to the correct services. In practice, this is the most efficient design approach.
Add environment variables
When you add a variable to an environment, you can specify the Initial value (shared) and the Current value (local) for the variable.
:::highlight purple
Learn more about Using variables.
:::
Switch between environments
Apidog shows the current environment in the environment selector at the top right of the workbench. Whenever you make a request or execute a script, Apidog will use the current values for all variables in the selected environment.
To switch to a different environment, simply choose it from the environment selector.
:::tip[]
In Apidog, endpoints and requests are two distinct concepts. An endpoint represents the API specification and does not include the base URL, whereas a request is the concrete API request, which includes the base URL. Therefore, the services defined in an Apidog environment only apply to endpoints, not to requests.
When using the requests functionality, you can leverage the environment variables in a similar way to Postman, by using the {{Base_url}} syntax.
:::
Environment Migration
In Apidog, the Initial value of variables is synchronized within the team, while the Current value is only stored locally. This means that when you use Apidog on another computer, you won't have access to the previously used Current values.
Therefore, Apidog provides the functionality to migrate environments. You can export the services and variables in environments as a JSON file and then import it on another computer. Here are the steps:
In the environment management, hover over the ... next to the Environments list, click Export to obtain a JSON file.
Visibility Scope of Environments
Sometimes, you may need to create variables for personal use only and prefer they are not visible to others. In such cases, you can create a Private Environment.
In the top right corner of the environment, you can set the visibility scope of the environment. By default, it is shared, while you can make environments you create visible only to yourself. However, you cannot change the visibility of environments created by others.
:::tip[]
Private Environments share the same Service list as other environments. Adding or removing services in a Private Environment will affect all environments simultaneously.
:::