Home

Environments

Switch between development, staging, and production configurations effortlessly with Echolon's powerful multi-level environment system.

Overview

Environments let you define sets of variables that change based on your context. Instead of manually updating URLs, API keys, and other values when switching between development and production, you can define these values once per environment and switch with a single click.

Echolon supports three levels of environments, each with its own scope and purpose:

  • Global Environments — Available across all workspaces and collections
  • Workspace Environments — Scoped to a specific workspace
  • Collection Environments — Scoped to a specific collection

Environment Types

Global Environments

Global environments are available everywhere in Echolon. They're perfect for variables that you need across all your projects, like personal API tokens, default headers, or company-wide settings.

Where to create:

  • Click the Environments icon in the left sidebar
  • Click New Environment to create a global environment

Workspace Environments

Workspace environments are scoped to a specific workspace. Use them when you have variables that should apply to all collections within a workspace but shouldn't affect other workspaces.

Where to create:

  • Click the Workspaces icon in the left sidebar
  • Select a workspace to open the workspace editor
  • Navigate to the Environments tab
  • Click New Environment

Collection Environments

Collection environments are the most specific. They only apply to requests within that collection. Perfect for project-specific settings like base URLs, test accounts, or feature flags.

Where to create:

  • Double-click a collection to open the collection editor
  • Navigate to the Environments tab
  • Click New Environment

Override Hierarchy

When the same variable is defined in multiple environments, Echolon uses a clear priority system to determine which value to use. More specific environments always override less specific ones.

PRIORITY Highest Lowest Collection Environment Highest priority • Overrides all other environments 1 Workspace Environment Middle priority • Overrides global, overridden by collection 2 Global Environment Lowest priority • Base values used when not overridden 3

Environment override hierarchy: Collection overrides Workspace overrides Global

How Overrides Work
When you use a variable like {{baseUrl}}, Echolon first checks if it exists in the active collection environment. If not found, it checks the workspace environment, and finally the global environment. The first match wins.

Example Override Scenario

Imagine you have a variable baseUrl defined in all three environment levels:

Environment Variable Value
Global baseUrl https://api.company.com
Workspace baseUrl https://staging.company.com
Collection baseUrl http://localhost:3000

In this case, if all three environments are active, {{baseUrl}} will resolve to http://localhost:3000 because the collection environment has the highest priority.

Creating Environments

Creating a Global Environment

1

Open Environments Panel

Click the Environments icon in the left sidebar to open the environments panel.
2

Create New Environment

Click the New Environment button at the top of the panel.
3

Add Variables

Name your environment and add key-value pairs for your variables. You can also add descriptions for documentation.

Creating a Workspace Environment

1

Open Workspace

Click the Workspaces icon in the left sidebar and select your workspace.
2

Navigate to Environments Tab

In the workspace editor, click the Environments tab.
3

Create and Configure

Click New Environment, name it, and add your workspace-specific variables.

Creating a Collection Environment

1

Open Collection

Double-click a collection in the sidebar to open its editor.
2

Navigate to Environments Tab

Click the Environments tab in the collection editor.
3

Create and Configure

Click New Environment and add collection-specific variables like local URLs or test credentials.

Using Variables

Reference environment variables anywhere in your requests using double curly braces: 

GET {{baseUrl}}/api/users
Authorization: Bearer {{apiToken}}

Variables can be used in:

  • URLs — Full URLs or parts of paths
  • Headers — Authorization tokens, API keys, custom headers
  • Request Body — JSON payloads, form data
  • Query Parameters — Dynamic query values
  • Path Parameters — Resource IDs, slugs
Variable Preview
Hover over a variable in the request editor to see its resolved value from the currently active environments.

Switching Environments

Use the environment selector in the top toolbar to quickly switch between environments. The selector shows all active environments from each level and lets you toggle them independently.

Best Practices

Use Global for Personal Settings

Keep personal API tokens, authentication credentials, and user-specific settings in global environments. This keeps them separate from shared project configurations.

Use Workspace for Team Projects

For team projects, define shared staging and production URLs in workspace environments. This ensures consistency across all collections in the project.

Use Collection for Local Development

Collection environments are perfect for local development settings like http://localhost:3000. They override everything else, making it easy to develop locally without affecting shared configurations.

Name Environments Consistently

Use clear, consistent names like Development, Staging, and Production across all levels. This makes it easy to understand which configuration is active at a glance.

Sensitive Data
Never commit sensitive data like API keys or passwords to shared collections. Keep sensitive values in your personal global environment instead.