Skip to main content
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

Data File (iteration) Variables → Runtime Variables → Environment Variables → SubCollection Variables → Collection Variables → Global Variables → Dynamic Variables
During a Collection Runner data-file run, the per-iteration variables from the CSV/JSON take the highest precedence, above Runtime 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

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: 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) 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:
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.