Environment Variables

Environments let you store variables (like API URLs, tokens, or IDs) that can be reused across your requests. Instead of hardcoding values, use variables to easily switch between development, staging, and production configurations.

Environment Types

Atrahasis has four separate environment systems, each scoped to a different part of the app:

Global Environments

  • Available to every standalone request (i.e., requests not opened from a project)
  • Managed from the Environment section at the bottom of the sidebar
  • Plain key-value pairs — no enabled, secret, or vault flags

Project Environments

  • Scoped to a specific OpenAPI project
  • Managed from the project's Environment panel
  • Each environment carries a Base URL and optional description
  • Variables support the enabled/disabled toggle
  • Maps directly to OpenAPI Server objects on export

Flow Environments

  • Scoped to a flow group (folder of related flows)
  • Managed from the Environment panel inside the flow designer
  • Variables support enabled/disabled toggles, Secret variables backed by the OS keychain, and Vault-backed sources — covered in the Flow Runner section

Load Test Environments

  • Scoped to a load test spec folder
  • Managed from the Environment panel inside the load test designer
  • Same feature set as Flow Environments (enabled/disabled, Secret variables, Vault sources) — covered in the Load Testing section
Note: By default, projects use their own environments. To use global environments with a project, configure the Environment Resolution Mode in Settings. Flow and Load Test groups always use their own environments — global and project envs do not bleed into flow or load test execution.

Global Environments

Global environments are available to every standalone request — requests that live directly in the Box or in a new tab, not requests opened from a project, flow, or load test. For project-linked requests, see the Environment Resolution section below; flow and load test runs always resolve against their own environments.

Creating an Environment

  1. Look at the bottom of the sidebar for the Environment section
  2. Click the dropdown (shows "No Environment" by default)
  3. Click "Manage Environments..." at the bottom
  4. Click "New Environment"
  5. Enter a name (e.g., "Development", "Staging", "Production")

Managing Environments

In the Environment Manager, hover over an environment to see action buttons:

  • Rename — Click the edit icon to change the environment name
  • Delete — Click the delete icon to remove the environment (with confirmation)

Adding Variables

After creating at least one environment, you can add variables:

  1. In the Environment Manager, click "Add Variable"
  2. Enter the variable name (e.g., base_url, api_token)
  3. Set values for each environment

Variable names can only contain (max 100 characters):

a-zA-Z0-9_

You can also edit existing variables by clicking the edit icon, or delete a variable from all environments by clicking the delete icon.

Switching Environments

Use the dropdown in the sidebar to quickly switch between environments. The active environment determines which values are used when you send a request.

Example Setup

Development
base_url: localhost:3000
api_token: dev_token_123
Staging
base_url: staging.api.com
api_token: stg_token_456
Production
base_url: api.example.com
api_token: prod_token_789

Using Variables

Reference variables using double curly braces: {{variable_name}}

In URL

https://{{base_url}}/api/users/{{user_id}}

In Headers

Authorization: Bearer {{api_token}}

In Request Body

{
  "user_id": "{{user_id}}",
  "api_key": "{{api_key}}"
}

In Authentication

Bearer tokens, Basic Auth credentials, and API keys all support variable substitution.

In Query Parameters

api_key: {{api_key}}
Tip: If a variable is not found in the active environment, it remains as-is in the request (e.g., {{undefined_var}}). This helps identify missing variables.

Project Environment Settings

When working with requests from a project, you can configure how environment variables are resolved. This setting is found in Settings → Projects.

ModeBehavior
Project Only(Default)Variables are resolved only from the project's own environments. Global environments are ignored.
Merge (Project > Global)Project variables override global variables. If a variable exists in both, the project value is used. If only in global, the global value is used.
Global OnlyVariables are resolved only from global environments. Project environments are ignored.

How to Configure

  1. Open Settings (gear icon in the sidebar or Cmd/Ctrl+,)
  2. Go to the Projects tab
  3. Select the project you want to configure
  4. Choose the desired Environment Resolution mode

When to Use Each Mode

Project Only:When the project has all the variables it needs and you want complete isolation from global settings.
Merge:When you want to share common variables (like auth tokens) globally but override specific ones (like base URLs) per project.
Global Only:When you manage all environments globally and don't want to duplicate them in each project.

Project Environments

Each project can have its own set of environments with additional features not available in global environments.

FeatureDescription
Base URLEach environment can have a base URL that maps to OpenAPI Servers
Enabled/DisabledIndividual variables can be toggled on/off without deleting them
Secret FlagMark sensitive values (like API keys) as secret for visual distinction
DescriptionAdd descriptions to environments for documentation
OpenAPI Integration: Project environments map directly to OpenAPI Server objects. When you export a project to OpenAPI, environments become server definitions.

Variable Resolution

When a request is sent, variables are resolved in a specific order based on the context:

For Standalone Requests

Global Environment→Variables replaced

For Project Requests (Merge Mode)

Global Environment+Project Environment→Project overrides Global

For Flow Steps

Flow Environment→Used as-is; global and project envs are ignored

For Load Test Specs

Load Test Environment→Used as-is; global and project envs are ignored
Flow and Load Test contexts: These two contexts resolve against their own isolated environment folders; the global/project merge logic does not apply. Additional runtime helpers such as at.flow.set() / at.flow.get() for inter-step data passing are documented in the Flow Runner section.
Remember: Variables are replaced at send time, not while editing. This means you can prepare requests with variables even if the environment isn't selected yet.
Best PracticesHistory