Environments & Variables in Automation
Environments and variables let you write tests once and run them against different configurations — development, staging, production, or any custom setup. The Environment Management view is where you manage them.
Opening Environment Management
Open the Environment Management view from the Test Automation area (the active-environment selector in the API Playground toolbar also has a manage button that opens the same manager).
Environments
Each project has a Default environment plus any number of custom environments. The Default environment is the base configuration — it is synchronized to all other environments and cannot be deleted. Custom environments can be added, copied, renamed (double-click), and deleted.
The environment tab strip lets you:
Switch between environments- Add a new environment
- Copy the selected environment
- Assign a Color in the Properties tab to visually distinguish an environment
Tabs
The Environment Management view is organized into four tabs:
| Tab | Purpose |
|---|---|
| Service Endpoints | Base URLs for each imported service, per environment |
| Authentication Profiles | Reusable credentials (HTTP Basic, Bearer Token, API Key, OAuth2, Kafka SASL) |
| Variables | Named values resolved at runtime with ${Name} |
| Properties | Appearance (color) for non-default environments |
Service Endpoints
Lists every service used by the project with its endpoint value for the selected environment. You can edit the endpoint inline and test the connection with the inline connection button. Clean Up Unused Services removes endpoints no longer referenced by the project.
When an environment other than Default is selected, this value is the host every bound request and
test step actually uses — the URL stored on the request itself is ignored while that environment is
active. Under Default, the request's own URL wins and these values only seed new requests. Changing
an endpoint here never rewrites a URL a request already carries. See
Which URL a Request Uses for the full rule, including ${variable}
endpoints for a single-gateway estate.
Authentication Profiles
Store reusable credentials once, then select the profile in any request's Auth tab. Supported methods:
- HTTP Basic
- Bearer Token
- API Key
- OAuth2 (flow configuration stored in the profile; tokens are fetched automatically)
- Kafka SASL
Variables
The Variables tab holds the environment-scoped variables. The set of variable names belongs to the project: Add Variable creates the row in every environment of that project at once, and a new environment inherits the names from Default. What each environment carries independently is the value. Each variable has:
| Column | Description |
|---|---|
| Name | The variable identifier (read-only once created) |
| Value | The value; masked as •••••• for password variables |
| Type | Plain or Password |
Add variables with Add Variable; remove them with Delete Variable. Values of type Password are masked in the UI and encrypted at rest.
Variable Scopes
Variables are resolved from several scopes, highest priority first:
| Scope | Defined In | Visibility |
|---|---|---|
| Case | The Parameters tab of a test case / data-driven case | Only within that case |
| Suite | The Parameters tab of a test suite | All cases within the suite |
| Environment | The Variables tab of an environment | All suites and cases using that environment |
| Project | The Parameters tab of the project | Everything in the project |
When a variable name exists in multiple scopes, the highest-priority scope wins. You can also set variables at runtime with the Set Variable step (scope = project / suite / case / step).
Referencing Variables
Use the ${VariableName} syntax anywhere a value is expected:
- URL paths:
https://${Host}/api/v2/users - Query parameters:
?filter=${StatusFilter} - Header values:
Authorization: Bearer ${Token} - Request body values
- Assertion expected values
Imported Postman / Bruno {{variableName}} tokens are automatically converted to Aethrix ${variableName} syntax during collection import.
Environment Overrides
Environments provide the primary mechanism for switching configurations:
- Define a variable at the Default (or project) level with a base value.
- Override it in each custom Environment with environment-specific values.
- Switch the active environment to change all values at once.
Use Compare Endpoints, Compare Credentials, and Compare Variables (in the Actions row) for a side-by-side view across environments, and Export Selected Environment / Import from File to share environment definitions as JSON.