Variables let you give a name to a value and reuse it anywhere you need.
For example, instead of pasting a frequently changing API token into every request, define a variable like ACCESS_TOKEN and use {{ACCESS_TOKEN}} in your requests. When the token expires, update the variable once and all requests using it will automatically pick up the new value.
Variable Types at a Glance
Apidog supports several variable types, each designed for specific scenarios. You can use: team-level global variables, project-level global variables, module variables, environment variables, test data variables, and local variables.
Global Variables
Global variables let you share data widely. There are two kinds:
Project-level Global Variables: Limited to the current project. Perfect for passing data between requests in the same project. For example, store a token from the login endpoint as a project-level global variable, then reuse it in other requests within that project.
Team-level Global Variables: Shared across all projects in a team. Ideal for cross‑project collaboration. For example, if an auth service issues a token used by multiple projects, store it as a team global variable.
Permissions note: Regular members can only view and change the current values of existing team-level global variables. They cannot add/delete variables or rename them. Only team admins can fully manage team-level variables on Team Resources → Variables.
Module Variables
Module variables are scoped to a specific module. If you import a Postman Collection, its collection variables are imported as Apidog module variables.
They're great for module‑specific configuration. For example, a project might have separate modules for users, orders, and products—each can keep its own configuration in module variables.
Make sure Apidog is up to date to use module variables.
Environment Variables
Environment variables are likely your most‑used type. They let you switch between environments without changing the configuration for each request.
In practice, you usually have multiple environments (local, test, staging, production). Each has different server addresses, database connections, or third‑party configs. With environment variables, you can flip between them instantly.
Note: Only one environment can be active at a time. When you select an environment, all variables defined in it take effect.
Test Data Variables
Test data variables power data‑driven testing. When you need to test the same endpoint with many sets of data, this is your friend.
Prepare a CSV or JSON file with multiple rows (or objects). In an automated test scenario, import the file, and Apidog will iterate each row as one variable set and execute the test for each.
Local Variables
Local variables have the shortest lifetime—valid only during a single request or test run. They disappear after execution.
Because local variables have the highest priority, they're perfect for momentarily overriding other variable types. For example, your environment defines user_id, but for one special test, you need a different value—set a local variable with the same name instead of changing the environment.
Variable Priority
When multiple variables share the same name, Apidog resolves them by priority (highest to lowest): Local Variables> Test Data Variables > Environment Variables> Module Variables> Project-level Global Variables> Team-level Global Variables
Example: If you define three variables named userId:
- Project-level global variables
userId = 1000 - Module variables:
userId = 2000 - Environment variables:
userId = 3000
When you use {{userId}} in a request, the effective value is 3000 (from the environment). If there's no environment value, it falls back to the module value (2000), then to the project global value (1000).
Initial vs Current Values
Global, module, and environment variables have both initial and current values—this balances team sharing with personal privacy.
- Initial values live on Apidog's servers and sync with teammates. Use them for shared config, like test server URLs and public API keys.
- Current values live only on your device. Use them for secrets like personal API keys, passwords, or private environment settings.
When a current value exists, Apidog prefers it. If the current value is empty, Apidog uses the initial value. Want the current value to follow the initial one? Click the link icon next to the current value to rebind.
Current values are stored on your device and can be lost if you clear the cache or switch devices. In the Apidog web version, they're stored in the browser. To move to a new device, export/import environments to migrate the current values.
Note: When running automated tests with Apidog CLI, keep in mind a key difference: The Apidog client uses current values during execution, while the CLI uses the initial values. If results differ between the client and the CLI, this is a common reason.
Ways to Set Variables
Choose the method that best matches where the value comes from and how you'll use it.
Set Variables Directly in the Environment Management Page
The most straightforward method. Click the Environment Management button (top‑right), switch to global or a specific environment, then add names and values.
This method is great for stable configurations such as database connections. You can set both initial (shared) and current (private) values.
Use the "Store Variable" feature
Often, the variable value comes from a response—like a token from a login endpoint or a user ID from a create‑user endpoint. Use the visual "Store Variable" in Post Processors to set up a new variable.
In a request's Post Processors, add "Store Variable", choose the source (commonly the JSON response), and select the field using JSONPath.
For example, if the response JSON is:
{
"user": {
"id": "69",
"email": "Ralph85@gmail.com",
"first_name": "Katlynn",
"last_name": "Reichert",
"api_token": "dolore ut mollit Duis sit",
"created_at": "2025-09-19T01:03:50.236Z",
"updated_at": "2025-05-10",
"deleted_at": "2025-09-18T18:30:51.217Z",
"role": "developer",
"metadata": {}
}
}Use $.user.email to extract the token.
You can also set variables directly from a request's response section.
Set Variables via Scripts
For more complex logic, use Custom Script in Pre Processors or Post Processors. Apidog provides a full script API to manipulate all variable types.
// Set a project‑level global variable
pm.globals.set('variable_key', 'variable_value');
// Set a team‑level global variable (must be defined on the Team Resources page first)
pm.globals.set('variable_key', 'variable_value', 'TEAM');
// Set an environment variable
pm.environment.set('variable_key', 'variable_value');
// Set a module variable
pm.moduleVariables.set('variable_key', 'variable_value');
// Set a local variable
pm.variables.set('variable_key', 'variable_value');When storing objects or arrays, stringify them first and parse when reading. For example:
pm.environment.set('user', JSON.stringify(userObj));
const users = JSON.parse(pm.environment.get('user'));Note: Scripts can only set the current values of the variables. Initial values should be set in Environment Management Page.
Use Database Data as Variables
Apidog can fetch data directly from a database and set it as variables—great for tests that rely on real records.
Add a Database Operation in Post Processors, configure the connection, and write the SQL. Then extract fields into variables using JSONPath.
Tips for Using Variables
Where Variables Work
Variables are resolved only when a request is actually sent. That means you can use them in headers, params, body, test scenarios, and scripts—anywhere involved in the sending of a request.
Because Apidog is visual first, a simple rule of thumb: if you see a "Dynamic Value" button, you can use variables there.
Basic Syntax
Use double curly braces to reference a variable: {{variableName}}. This works in URL, headers, params, and body.
For example, in params:
And in body:
Notes for JSON bodies: string variables need quotes, numeric variables do not. Double curly braces may trigger JSON lint warnings, but they can be safely ignored.
If you see "unresolved variable", don't panic. Variables set in Post Processors or scripts may not exist until the request runs, and local variables vanish after the run. The best way to confirm is to actually send the request.
Fetch Child Fields from a Variable
Sometimes your variables store objects or arrays, not just strings or numbers. For example, a user API often returns an object with id, name, email, etc.
Suppose you stored this response object as a variable named user:
{
"id": 1001,
"name": "Joe",
"email": "joe@example.com",
"role": "admin"
}You can reference specific fields with dot notation, like {{user.id}} (1001) or {{user.name}} ("Joe").
For arrays, it's similar. If you have a variable users:
[
{"id": 1001, "name": "Joe"},
{"id": 1002, "name": "Rio"},
{"id": 1003, "name": "Outher"}
]Use {{users[0].name}} to get the first user's name, or {{users[1].id}} for the second user's id.
This follows JSONPath‑like semantics—the variable name acts like the root ($).
Use Variables in Scripts
You can use variables in the custom scripts of Pre Processors or Post Processors. Apidog provides a complete set of script APIs, allowing you to flexibly access different types of variables.
// Get a project‑level global variable
pm.globals.get('variable_key');
// Get a team‑level global variable
pm.globals.get('variable_key', 'TEAM');
// Get an environment variable
pm.environment.get('variable_key');
// Get a module variable
pm.moduleVariables.get('variable_key');
// Get a local variable
pm.variables.get('variable_key');For objects/arrays stored as strings, parse first:
const userObj = JSON.parse(pm.environment.get('user'));
console.log(userObj.name);Data‑Driven Testing with Test Data Variables
Upload a CSV or JSON file containing multiple data rows. During execution, Apidog substitutes {{variableName}} with the values from each row and runs the test once per row—perfect for validating robustness with many inputs.
Dynamic Value Expressions
Beyond your own variables, Apidog supports dynamic values, which generate random data following specific rules.
In scripts, you can process strings that include dynamic expressions with await pm.variables.replaceInAsync():
const template = "Hello, {{$person.fullName}}";
const result = await pm.variables.replaceInAsync(template);
console.log(result); // Outputs a randomly generated name
Dynamic values are perfect for generating random test data without preparing a dataset ahead of time.
Summary
Variables are one of the most powerful features in Apidog. They reduce repetition, make tests flexible, and simplify switching between projects and environments. Whether you're sharing global settings across teams, driving tests with CSV data, or overriding values locally, variables help keep your workflow efficient and organized. By mastering variable types, priorities, and ways to set them, you can ensure your API requests remain consistent, maintainable, and ready for real-world scenarios.
