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

Runtime Variables → Data File (iteration) 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 or JSON sit just below Runtime Variables. This lets a script override a column for one run, which is the usual way to refresh a token that the data file only seeds.
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, including over a data file column of the same name. If a runtime variable with the same name exists, it overrides all other scopes for the duration of the session.
  • Data file variables come next during a Collection Runner run, and override environment, collection, and global values.
  • 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. The same order applies whether the value is resolved for a {{name}} reference in a request or read from a script with rq.variables.get, so the two never disagree.

​
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.