Variables & Request Chaining

Variables let you extract values from one request's response and inject them into subsequent requests within a test plan. This enables multi-step workflow testing where later operations depend on data produced by earlier ones — for example, inserting a row, capturing the returned id, and using it in a follow-up SELECT, UPDATE, or DELETE.

Core Concepts

• Variables use {{variableName}} syntax and are scoped to a single test plan.
• Extraction rules define how a variable's value is pulled from a response, using a JSON path or regex.
• Built-in variables provide auto-generated values such as timestamps, UUIDs, etc.
• Validation prevents running a test plan if any variable is referenced before it has been defined by a prior test.

How It Works

1. Create a test plan with multiple tests.
2. In any request field (table name, filter value, RPC parameter, JSON body, etc.), type {{variableName}} to reference a variable.
3. Click a {{variable}} token to open an inline popover where you can manually set a test value for ad-hoc execution.
4. In a Test Plan, in the Edit Test dialog, define extraction rules — specify which part of the response should be captured into which variable.
5. At run-time, the test runner resolves variables top-to-bottom, injecting extracted values into each subsequent request.
6. If a variable is referenced but never produced by a prior test, the plan displays a "Unresolved Variables" warning, which will inform you of what the variable is and which test(s) require it.

Scope

Variables are scoped to the test plan they are defined in. There is no global variable store or cross-plan sharing.

Built-in Variables

Built-in variables are prefixed with $ to distinguish them from user-defined variables. Each one is resolved fresh every time it is encountered (values are not cached).

Variable	Description	Example Output
{{$uuid4}}	Random UUID v4	f47ac10b-58cc-4372-a567-0e02b2c3d479
{{$uuid7}}	UUID v7 (time-ordered)	018f6b2e-3b6a-7f1a-8c5d-4a3b2c1d0e0f
{{$ulid}}	ULID (time-ordered, Crockford base32)	01HYX3KBZQA5RNHX1V6J7C4F8G
{{$timestamp}}	Current ISO 8601 timestamp	2026-02-15T14:30:00.000Z
{{$timestampUnix}}	Current Unix timestamp (seconds)	1771162200
{{$timestampUnixMs}}	Current Unix timestamp (milliseconds)	1771162200000
{{$dateOnly}}	Current date (YYYY-MM-DD)	2026-02-15
{{$timeOnly}}	Current time (HH:mm:ss)	14:30:00
{{$randomInt}}	Random integer 0–99999	48271
{{$randomEmail}}	Random test email	test_x8k2m@example.com
{{$randomString}}	Random 12-char alphanumeric	aB3kQ9mW2xYz
{{$results}}	JSON representation of all the results, failures from the last Test Plan run	See Below

Results variables:

The {{$results}} JSON includes:

• run.stats — total/passed/failed/skipped test counts, total duration, and number of test plans.
• run.failures[] — an array of every failed test with the error message, HTTP status, and raw error response for debugging.
• run.executions[] — an array of every test execution in order, including pass/fail status, response data, extracted and resolved variables, and timing.
• startedAt / completedAt — ISO 8601 timestamps marking the run window.

Key details about built-in variables:

• Always available — they don't require a prior test to define them.
• Generate a new value on every resolution (each {{$uuid4}} in a plan produces a different UUID).
• Cannot be overwritten by extraction rules — names starting with $ are reserved.