Dynamic Variables

Dynamic variables are built-in shortcuts that generate fresh, random values at the moment you send a request. They work exactly like regular environment variables — you use the {{...}} syntax — but their names always start with $, and you never need to define them anywhere.

{{$guid}}           → a fresh UUID every time
{{$timestamp}}      → the current Unix timestamp
{{$randomEmail}}    → a random email address

Use them anywhere you would use a regular variable: in the URL, query parameters, headers, request body, and authentication fields.

Why Use Dynamic Variables?

Avoid duplicate key errors. If your API rejects requests where a record with that ID already exists, using {{$guid}} in the ID field guarantees each test run creates a unique record.

Test with realistic data. Instead of hardcoding "test@example.com" everywhere, use {{$randomEmail}} to test with a variety of inputs automatically.

Timestamp your requests. Use {{$isoTimestamp}} to record when an event was created, or {{$timestamp}} when an API requires a Unix epoch.

Generate idempotency keys. Many payment and messaging APIs require a unique idempotency key per request — {{$guid}} is perfect for this.

How They Work

When Is the Value Generated?

Dynamic variables are resolved just before the request is sent. Each {{$...}} placeholder is replaced with a freshly generated value at that moment.

Each Occurrence Gets Its Own Value

If you use the same dynamic variable twice in one request, each occurrence gets a separately generated value:

{
  "requestId": "{{$guid}}",
  "correlationId": "{{$guid}}"
}

Both requestId and correlationId will contain different UUIDs. If you need the same value in two places, generate it once in a pre-request script and save it to an environment variable:

// Pre-request script
fc.environment.set("requestId", crypto.randomUUID());

Then use {{requestId}} (without the $) in both places.

Overriding a Dynamic Variable

You can override any dynamic variable by defining an environment variable with the same name (including the $). This is useful when you need reproducible results for a specific test:

When that environment is active, {{$guid}} returns your fixed value instead of a random UUID.

Resolution Priority

Dynamic built-in variables are resolved last — only if no environment, collection, or local variable with the same name exists. The full order (highest priority first):

1. Local variables (from pre-request script)
2. Data file values (Collection Runner iteration data)
3. Environment variables
4. Collection variables
5. Global variables
6. Dynamic built-in variables ← these

Complete Variable Reference

Identity and UUIDs

Current Time

Random Dates

Numbers and Booleans

Characters and Short Strings

Lorem Ipsum Placeholder Text

People

Network

Location

Colour

Company

Finance

Files and MIME Types

Examples

Creating a New User

POST /users
{
  "id": "{{$guid}}",
  "name": "{{$randomFullName}}",
  "email": "{{$randomEmail}}",
  "phone": "{{$randomPhoneNumber}}",
  "address": "{{$randomStreetAddress}}, {{$randomCity}}, {{$randomCountryCode}}"
}

Every time you send this request, a brand-new user is created with unique details — no more "email already exists" errors when re-running tests.

Timestamped Events

POST /events
{
  "eventId": "{{$guid}}",
  "occurredAt": "{{$isoTimestamp}}",
  "sourceUrl": "{{$randomUrl}}"
}

Adding Idempotency Headers

Some APIs (Stripe, for example) require a unique key per request to safely retry without creating duplicates:

File Upload Metadata

{
  "fileId": "{{$guid}}",
  "fileName": "{{$randomFileName}}",
  "mimeType": "{{$randomMimeType}}",
  "uploadedAt": "{{$isoTimestamp}}"
}

Stress Testing Validation

Run this in the Collection Runner with 50 iterations to test your API's input validation with 50 different random inputs automatically:

POST /users
{
  "email": "{{$randomEmail}}",
  "password": "{{$randomPassword}}",
  "country": "{{$randomCountryCode}}",
  "jobTitle": "{{$randomJobTitle}}"
}