Environments and Variables

When working with APIs in real-world scenarios, you'll often need to test against different environments—development, testing, staging, and production. Each environment typically has different server URLs, API keys, and configuration values. Manually changing these values for every request would be tedious and error-prone.

This is where environments and variables come in. They allow you to manage different configurations and reuse values across multiple requests, making your API testing workflow more efficient and maintainable.

1. What Are Environments and Variables?

Environments

An environment in Apidog represents a specific context where your API requests run. Each environment contains:

Base URLs: The server addresses where your requests are sent

Variables: Reusable values that can change between environments

For example, the Pet Store API defines two environments in its OpenAPI specification:

Production: https://api.petstoreapi.com/v1 — the live, production server

Sandbox: https://sandbox.petstoreapi.com/v1 — a testing server for development

When you switch environments in Apidog, all your requests automatically use the base URL and variable values defined for that environment.

Why Separate Production and Sandbox?

In real-world API development, it's crucial to keep production and testing environments separate:

Production is the live system that serves real users and handles actual data. Making mistakes here can affect real customers and business operations.

Sandbox (or testing environment) is a safe space where developers can experiment, test new features, and debug issues without risking the production system.

By using different environments, you can:

Test your API integration thoroughly in sandbox before deploying to production

Safely try out new features or changes without impacting real users

Debug issues in a controlled environment

Ensure your code works correctly before it goes live

This separation is a best practice in software development and helps maintain system reliability and data integrity.

Variables

A variable is a placeholder that stores a value you can reuse across multiple requests. Instead of hardcoding values like API keys, tokens, or IDs, you store them as variables and reference them using {{variable_name}}.

For example, imagine you need to create a pet, then query the pet you just created, and finally update that pet. Without variables, you would need to manually copy and paste the pet ID into each endpoint. With variables, you can:

Create a pet using POST /pets and extract the returned pet ID into a variable (e.g., {{pet_id}})

Query the pet using GET /pets/{{pet_id}} — the variable automatically fills in the ID

Update the pet using PUT /pets/{{pet_id}} — again, using the same variable

This way, you don't need to manually enter the pet ID value in each endpoint. Once the variable is set, it's automatically used wherever you reference {{pet_id}}.

2. Working with Environments in Apidog

Step 1: Access Environment Management

In Apidog, click the environment icon ≡ in the top-right corner of the interface.

This opens the Environment Management panel.

Step 2: Create Environments

When you import the Pet Store API spec, Apidog can automatically create environments based on the servers defined in the OpenAPI specification. However, you can also create environments manually:

In the Environment Management panel, click "New Environment" at the bottom of the environments list.

Enter a name for your environment (e.g., "Production" or "Sandbox").

Set the Base URL for the default module. For the Pet Store API:

Production: https://api.petstoreapi.com/v1

Sandbox: https://sandbox.petstoreapi.com/v1

Click "Save" to create the environment.

Step 3: Switch Between Environments

Once you have multiple environments set up, you can easily switch between them:

Look at the environment selector in the top-right corner of the interface (next to the ≡ icon).

Click the dropdown to see all available environments.

Select the environment you want to use (e.g., "Production" or "Sandbox").

When you switch environments, all subsequent requests will use the base URL and variable values from the selected environment.

3. Working with Variables in Apidog

Step 1: Create a Variable

Let's create a variable to store a pet ID that we can reuse across multiple requests:

Open the Environment Management panel (click the ≡ icon).

Select an environment (e.g., "Production" or "Sandbox").

In the Variables section, click "Add Variable" or the "+" button.

Enter:

Variable Name: pet_id

Initial Value: pet_1Nv0FGQ9RKHgCVdK (a sample pet ID from the Pet Store API)

Current Value: (optional - leave empty to use the initial value)

Click "Save".

Step 2: Use Variables in Requests

Now that you've created a variable, you can use it in your requests:

Open any endpoint in your Pet Store API project (e.g., GET /pets/{id}).

Switch to the "Run" tab.

In the path parameter field for id, instead of typing a value directly, enter: {{pet_id}}

When you hover over {{pet_id}}, Apidog will show you the current value and scope of the variable.

Click "Send" to execute the request. Apidog will automatically replace {{pet_id}} with the actual value (pet_1Nv0FGQ9RKHgCVdK) when sending the request.

Important distinction: In Apidog, {{a}} represents a variable that will be replaced with its stored value, while {a} represents a path parameter in the API specification.

For example:

In the endpoint path /pets/{id}, the {id} is a path parameter placeholder defined in the API spec.

When filling in the value for this parameter, you can use {{pet_id}} to reference a variable, which will be replaced with the actual pet ID value when the request is sent.

Step 3: View the Actual Request

After sending a request, you can see how variables were resolved:

In the response panel, switch to the "Actual Request" tab.

You'll see the actual URL that was sent, with all variables replaced by their values.

For example, if your endpoint path is /pets/{{pet_id}} and the base URL is https://api.petstoreapi.com/v1, the actual request URL will be:

https://api.petstoreapi.com/v1/pets/pet_1Nv0FGQ9RKHgCVdK

4. Practical Example: Testing Across Environments

Let's walk through a practical example using the Pet Store API's two environments:

Scenario: Get Pet Information

Set up Production Environment:

Base URL: https://api.petstoreapi.com/v1

Variable pet_id: pet_1Nv0FGQ9RKHgCVdK

Set up Sandbox Environment:

Base URL: https://sandbox.petstoreapi.com/v1

Variable pet_id: pet_1Nv0FGQ9RKHgCVdK (same pet ID for testing)

Test in Production:

Select the "Production" environment.

Open GET /pets/{id} and use {{pet_id}} as the path parameter.

Click "Send".

The request goes to: https://api.petstoreapi.com/v1/pets/pet_1Nv0FGQ9RKHgCVdK

Test in Sandbox:

Switch to the "Sandbox" environment (using the dropdown).

The same request now goes to: https://sandbox.petstoreapi.com/v1/pets/pet_1Nv0FGQ9RKHgCVdK

No need to change the endpoint or variable—just switch environments!

This demonstrates how environments make it easy to test the same API against different servers without modifying your requests.

5. Variable Scopes

Apidog supports variables at different scopes, each serving a specific purpose:

Global Variables: Shared across all requests, scripts, and environments in a project or team

Environment Variables: Specific to an environment (like Production or Sandbox)

Module Variables: Specific to a module (group of related endpoints)

Local Variables: Temporary variables that only exist during a single request execution

When a variable with the same name exists in multiple scopes, the narrower scope takes precedence. The priority order is: global < module < environment < data < local.

For most use cases, environment variables are the best choice because they allow you to have different values for the same variable in different environments (e.g., different API keys for production vs. sandbox).

6. Initial Value vs. Current Value

Each variable in Apidog has two types of values:

Initial Value: The default value that's shared with your team and synchronized across devices. This is useful for collaboration.

Current Value: A local, personal value that's only stored on your computer. This is useful for storing sensitive data like personal API keys or tokens that you don't want to share.

If you don't set a Current Value, the variable will use the Initial Value. If you set a Current Value, it will override the Initial Value for your local use only.

7. Key Takeaways

Environments represent different contexts (production, testing, etc.) with their own base URLs and variables.

Variables are reusable placeholders that store values you can reference using {{variable_name}}.

Switching environments automatically updates base URLs and variable values for all requests.

Use environment variables to have different values for the same variable in different environments.

Variables can be used in request URLs, parameters, headers, and request bodies.

Initial Values are shared with your team; Current Values are personal and local only.

Environments and variables make your API testing workflow more efficient and maintainable.

Now that you understand how to work with environments and variables, you can efficiently test your APIs across different contexts. In the next article, we'll explore how to chain multiple endpoints together—combining multiple API requests in sequence to accomplish real-world tasks.

Continue with → Chaining Multiple Endpoints

Environments and Variables

1. What Are Environments and Variables?#

Environments#

Why Separate Production and Sandbox?#

Variables#

2. Working with Environments in Apidog#

Step 1: Access Environment Management#

Step 2: Create Environments#

Step 3: Switch Between Environments#

3. Working with Variables in Apidog#

Step 1: Create a Variable#

Step 2: Use Variables in Requests#

Step 3: View the Actual Request#

4. Practical Example: Testing Across Environments#

Scenario: Get Pet Information#

5. Variable Scopes#

6. Initial Value vs. Current Value#

7. Key Takeaways#