Query Parameters

The [params] block allows you to specify query string parameters that will be appended dynamically to your request URL. Rumour supports robust dynamic values, parent/child environment inheritance, URL-encoding, and path-based dependency references.

1. Syntax & Configuration

Query parameters are defined in a key-value structure under [params].

[request]
method = "GET"
url = "{{base_url}}/products"

[params]
category = "electronics"
sort = "price_desc"
limit = "20"
page = "1"

The request URL compiled at runtime will be: https://httpbin.org/products?category=electronics&sort=price_desc&limit=20&page=1

URL Encoding

All keys and values defined inside the [params] block are automatically URL-encoded at runtime. You do not need to manually escape special characters or spaces.

2. Setup Environment

To set up a test environment from scratch and replicate the workspace example, follow these steps:

A. Initialize the Workspace

Create a new directory and initialize a clean, zero-clutter Rumour workspace root:

mkdir param_example
cd param_example
rumour init

B. Scaffold Modular Collections

Scaffold two modular collections inside the workspace (auth and users) using the scaffolding tool:

rumour new auth
rumour new users

3. Directory Structure & File Contents

After setting up the workspace, your directory structure will look like this:

param_example/
├── workspace.env.toml
├── param_example.config.toml
├── param_example.suite.toml
├── auth/
│   ├── auth.config.toml
│   ├── auth.env.toml
│   ├── auth.suite.toml
│   └── requests/
│       └── login.toml
└── users/
    ├── users.config.toml
    ├── users.env.toml
    ├── users.suite.toml
    └── requests/
        └── get_users.toml

Here are the complete contents for each file in this setup:

A. Workspace Level Files

`workspace.env.toml`

Defines base variables and global environment definitions.

# workspace.env.toml
[variables]
base_url = "https://httpbin.org"
"env.ENV_STAGE" = "staging"

`param_example.config.toml`

Workspace-level request runner configurations.

[config]
# timeout_ms = 5000
# max_retries = 3

`param_example.suite.toml`

Global ordered execution suite.

[suite]
name = "Workspace Workflow Suite"
description = "Global ordered execution suite for all workspace request workflows."
ordered = true

requests = [
    # Add paths to your requests or modular collection suites here
]

B. `auth` Collection Files

`auth/auth.config.toml`

Collection-level configuration for the auth collection.

[config]
# timeout_ms = 5000
# max_retries = 3
# retry_backoff_ms = 500

`auth/auth.env.toml`

Collection-level variables for the auth collection.

[variables]
# Collection-level variables for the 'auth' collection.

`auth/auth.suite.toml`

Modular suite for executing auth requests.

[suite]
name = "Auth Workflow Suite"
description = "Modular ordered execution suite for Auth request workflows."
ordered = true

requests = [
    "requests/login.toml"
]

`auth/requests/login.toml`

Performs authentication and extracts the returned token from the JSON body payload.

# auth/requests/login.toml
[request]
method = "POST"
url = "{{base_url}}/post"

[body]
raw = '{"username": "admin", "token": "session_secret_xyz123"}'

[extract]
token = "json.token"

C. `users` Collection Files

`users/users.config.toml`

Collection-level configurations.

[config]
# timeout_ms = 5000
# max_retries = 3
# retry_backoff_ms = 500

`users/users.env.toml`

Collection-level variables.

[variables]
# Collection-level variables for the 'users' collection.

`users/users.suite.toml`

Modular suite for executing users requests.

[suite]
name = "Users Workflow Suite"
description = "Modular ordered execution suite for Users request workflows."
ordered = true

requests = [
    "requests/get_users.toml"
]

`users/requests/get_users.toml`

Consumes the token extracted by login.toml and passes it as a query parameter.

# users/requests/get_users.toml
[dependencies]
"../../auth/requests/login.toml" = "token"

[request]
method = "GET"
url = "{{base_url}}/get"

[params]
# 1. Access variable extracted from a dependency (relative file path)
userId = "{{../../auth/requests/login.token}}"

# 2. Access local variable defined in the [variables] block below
client = "{{client_name}}"

# 3. Access environment variable from env files / environment
stage = "{{env.ENV_STAGE}}"

# 4. Access secrets securely from the vault
api_key = "{{vault.SECURE_KEY}}"

# 5. Dynamic placeholders
ts = "{{timestamp}}"
nonce = "req-{{random}}"

[variables]
client_name = "RumourTestAgent/2.0"

4. Run the Requests & Outputs

To run the execution of the main request, run the following command. The runner automatically detects the dependency on login.toml, executes it, extracts the token, and passes it to get_users.toml. Since we use vault secrets, pass the vault decryption password as well:

Command

RUMOUR_VAULT_PASS=mypassword123 rumour run users/requests/get_users.toml -vt

Output

~/workspace/testing main* ❯ RUMOUR_VAULT_PASS=mypassword123 rumour run param_example/users/requests/get_users.toml -tv
  POST https://httpbin.org/post
  URL: https://httpbin.org/post
  Body (json): {"username": "admin", "token": "session_secret_xyz123"}
  ✓ SUCCESS: /home/bugsfounder/workspace/testing/param_example/auth/requests/login.toml (1055ms)
  GET https://httpbin.org/get
  URL: https://httpbin.org/get?client=RumourTestAgent%2F2.0&stage=staging&api_key=super_secure_vault_value_987&userId=session_secret_xyz123&ts=1779390420189&nonce=req-7c662d12
  Query Param: client=RumourTestAgent/2.0
  Query Param: stage=staging
  Query Param: api_key=super_secure_vault_value_987
  Query Param: userId=session_secret_xyz123
  Query Param: ts=1779390420189
  Query Param: nonce=req-7c662d12
  ✓ SUCCESS: /home/bugsfounder/workspace/testing/param_example/users/requests/get_users.toml (249ms)
    ✓ param_example/users/requests/get_users.toml → PASS (2 Pass, 0 Fail, 0 Skip)                                                           
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT                                                  │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests:      2                                                   │
│ Successful:          2                                                   │
│ Failed:              0                                                   │
│ Skipped:             0                                                   │
│ Success Rate:        100.0%                                              │
│ Total Time:          1338ms                                              │
╰──────────────────────────────────────────────────────────────────────────╯

✓ Successful Requests:
  - /home/bugsfounder/workspace/testing/param_example/auth/requests/login.toml  [200] [1057ms]
  - /home/bugsfounder/workspace/testing/param_example/users/requests/get_users.toml  [200] [280ms]

Actionable Recommendations:
  → Run with --json to export this report for your CI/CD pipeline.

5. Dependency Resolution Options & Recommendations

When referencing extracted values from dependency requests (like token), you have two distinct syntaxes:

Option 1: Direct Dotted Relative Path (Explicit)

You can directly reference the path of the dependency file relative to the current request folder, followed by the variable name.

[params]
userId = "{{../../auth/requests/login.token}}"

Option 2: Simple Local Mapping

Alternatively, you can reference the token directly using the short-hand local variable name:

[params]
userId = "{{token}}"

info

While using userId = "{{token}}" works directly, it is not recommended if your workspace has multiple upstream requests extracting same-named variables (e.g., auth.token, product.token, user.token). Under ambiguous conditions, Rumour might get confused and resolve the wrong token value.

Recommended Practice: Explicit Mapping via `[dependencies]`

To keep your parameter values clean, readable, and deterministic, it is highly recommended to declare and map dependencies explicitly at the bottom of your request file:

# Place this at the bottom of users/requests/get_users.toml
[dependencies]
"../../auth/requests/login.toml" = "token"

This maps the value of token extracted from login.toml specifically to a local variable named token within this file's namespace, avoiding resolving collisions.

For more details on execution and graphs, refer to the Dependency Overview and Explicit Dependencies sections.

6. Inspecting Outgoing Request Payloads

To audit the exact query parameters and payloads transmitted:

Verbose CLI Logging (-v / -vt): Details outgoing headers, query params, and body payloads in real-time.
JSON Output (--json): Outputs a request_sent block containing exact transmission parameters, including params.
Echo Server Parameters: Query parameters received by the server are returned in the response body (typically under args) when hitting echo hosts.

Vault Troubleshooting

If Rumour fails execution with a Variable Resolution Error complaining about a missing vault.SECURE_KEY, ensure you have correctly set the RUMOUR_VAULT_PASS environment variable when launching the run to unlock the vault.

1. Syntax & Configuration​

2. Setup Environment​

A. Initialize the Workspace​

B. Scaffold Modular Collections​

3. Directory Structure & File Contents​

A. Workspace Level Files​

workspace.env.toml​

param_example.config.toml​

param_example.suite.toml​

B. auth Collection Files​

auth/auth.config.toml​

auth/auth.env.toml​

auth/auth.suite.toml​

auth/requests/login.toml​

C. users Collection Files​

users/users.config.toml​

users/users.env.toml​

users/users.suite.toml​

users/requests/get_users.toml​

4. Run the Requests & Outputs​

Command​

Output​

5. Dependency Resolution Options & Recommendations​

Option 1: Direct Dotted Relative Path (Explicit)​

Option 2: Simple Local Mapping​

Recommended Practice: Explicit Mapping via [dependencies]​

6. Inspecting Outgoing Request Payloads​