Variable Precedence

Variable precedence in Requestly defines how a variable value is resolved when the same variable name exists in multiple scopes. The value is picked based on scope priority, ensuring the most relevant context is always applied.

Precedence order

Runtime Variables → Environment Variables → SubCollection Variables → Collection Variables → Global Variables → Dynamic Variables

Dynamic variables are built-in variables (like {{$timestamp}}, {{$randomUUID}}, etc.) that have the lowest precedence. If you define a custom variable with the same name, your custom value will be used.

How it works

• Runtime variables have the highest priority. If a runtime variable with the same name exists, it overrides all other scopes for the duration of the session.
• Environment variables are checked next and override SubCollection, Collection, and Global variables.
• SubCollection variables apply only within that SubCollection and override Collection and Global variables.
• Collection variables apply to all requests in the collection unless overridden by a higher scope.
• Global variables act as the final fallback when the variable is not found in any other scope.

This model makes it easy to reuse variables globally while still allowing precise overrides for environments, collections, or temporary runtime use cases.

Developer style explanation

if (variable_name in runtime_variables) {           // Check runtime
  return runtime_variables[variable_name];
} else if (variable_name in environment_variables) { // Check environment
  return environment_variables[variable_name];
} else if (variable_name in subcollection_variables) { // Check sub-collection
  return subcollection_variables[variable_name];
} else if (variable_name in collection_variables) {  // Check collection
  return collection_variables[variable_name];
} else if (variable_name in global_variables) {      // Check global
  return global_variables[variable_name];
} else if (is_dynamic_variable(variable_name)) {     // Check dynamic variables
  return generate_dynamic_value(variable_name);      // e.g., $timestamp, $randomUUID
} else {
  return null; // Variable not found in any scope
}

When using the $ prefix (e.g., {{$timestamp}}), the system skips user-defined variable lookups and directly generates the dynamic value.

Example scenario

Assume the variable {{base_url}} is defined in multiple scopes:

Scope	Value
Global	https://global.api.com
Collection	https://collection.api.com
SubCollection	https://sub.api.com
Environment	https://env.api.com
Runtime	https://runtime.api.com

If you send a request inside a SubCollection with an active Environment, and a runtime variable with the same name exists, {{base_url}} resolves to:

https://runtime.api.com

If the runtime variable is removed, the value falls back to the environment variable, followed by SubCollection, Collection, and finally Global based on availability.

Dynamic variables precedence example

Assume you want to use a timestamp in your request:

Scenario 1: Using {{timestamp}} (without $ prefix)

Scope	Value (if defined)
Environment	"2024-01-15"
Dynamic	Current timestamp (e.g., 1613360320)

Result: {{timestamp}} resolves to "2024-01-15" (your custom environment variable)

Scenario 2: Using {{$timestamp}} (with $ prefix)

Result: {{$timestamp}} always resolves to the current Unix timestamp (e.g., 1613360320), regardless of whether you have a custom timestamp variable defined.

Best Practice:

// In pre-request script
// This uses your custom variable if defined, otherwise falls back to dynamic
const myTimestamp = "{{timestamp}}";  

// This always generates a fresh dynamic timestamp
const freshTimestamp = rq.$timestamp();

Use the $ prefix ({{$variableName}} or rq.$variableName()) when you explicitly want to use a dynamic variable, even if a custom variable with the same name exists.