API Monitoring & Testing: Managing Configuration with Environments

An Environment is a group of configuration settings (initial variables, locations, notifications, integrations, etc.) used when running a test. Every test has at least one environment, but you can create additional environments as needed. For common settings (base URLs, API keys) that you'd like to use across all tests within a bucket, use a Shared Environment.

Environments are great for cases when you need to re-use the same set of test steps with different configurations e.g. executing the same test against your local dev version of an API as well as the live production version.

Example Multi-Environment Test Configuration

Here's an example of environment settings for a test that re-uses steps across three different environments: your local dev environment, a staging server, and a production realm.

The user interface for switching and editing environments.

Selecting and Managing Environments

The user interface for switching and editing environments.

There are two primary places you'll interact with your environment settings: the environments switcher (top right of the test editor) and the environment settings editor (above the test steps in the test editor). The switcher determines the current environment you're working with. When you switch between environments, the values in the settings editor will be updated to reflect the currently selected environment.

The environment switcher is where you'll create and delete environments. Create an empty environment by selecting Add Environment or alternately select Duplicate to create a copy of an existing one.

Test-specific Environments

Test environments belong to a single test. They can optionally inherit settings from a shared environment, overriding variables and other settings specific to the test. The following settings are included in an environment:

Shared Environments

Shared environments belong to a bucket and can be used by any test within the same bucket either on their own, or via a test-specific environment set to inherit its settings.

Inheriting From Shared Environments

When a test-specific environment is set to inherit from a shared environment, the shared environment is used as a base that the test environment builds on. Depending on the setting, you may be able to override settings in inheriting test environments:

Initial Variables and Initial Scripts

See: Evaluation Order of Initial Variables


Locations that have been enabled in a shared environment cannot be disabled from an inheriting test environment. Additional locations and agents can be enabled for the specific test environment.

Email Notifications

If email notification settings are specified in a shared environment, inheriting test environments can add to the list of team members to receive notifications, but cannot override the frequency or turn off notifications to team members specified in the shared environment.

Webhook Notifications

Callback URLs specified in the shared environment will be called in addition to the callback URLs specified in the inheriting test environment.


Connected services enabled in the shared environment cannot be disabled in the inheriting test environment. You can enable additional integrations in the per-test environment.


Behaviors enabled in the shared environment cannot be disabled in the inheriting test-environment. Behaviors set to 'Off' in the shared environment can be turned on in a test environment.


Headers in the shared environment with the same name as those in a test environment will be overridden by those in the inheriting test environment.


Authentication settings in the shared environment can be overridden by test environment settings.

Default Environment

Every test has a default environment for backwards compatibility. Some features do not support specifying an environment. In these cases, the default is used instead. The default environment can be set by going to a test and selecting 'Settings' from the left nav.

Functions that do not currently support specifying an environment and will fallback to the default are:

  • Bucket-wide Trigger URLs
  • Batch Trigger URLs
  • Trigger URLs with an unspecified environment (missing runscope_environment parameter)
  • 'Run All Tests' button on the test list page
  • 'Run Again' button on the test result page
  • AWS CodePipeline test runs

Next: Global Monitoring Locations →