Collection Runner

The Collection Runner executes multiple requests automatically in sequence or parallel, perfect for testing complete API workflows, running integration tests, or validating endpoints in bulk.

Quick Start

---

Opening the Runner

For Collections

Click the Run All button in the collection header to open the runner.

All requests in the collection will be included, including those in nested folders.

For Folders

Click the Run All button in the folder header.

Only requests in that folder (and its subfolders) will run.

---

Execution Modes

Sequential Mode

Requests execute one at a time, in order.

Use when:

• Order matters (later requests depend on earlier ones)
• Testing API workflows with dependencies
• You need to throttle request rate
• Scripts set variables for subsequent requests

Settings:

• Delay Between Requests: Add a pause (in seconds) between each request
• Default: 0 seconds (no delay)

Parallel Mode

Multiple requests execute simultaneously.

Use when:

• Requests are independent
• You want faster execution
• Load testing or bulk operations
• Order doesn't matter

Settings:

• Concurrent Requests: How many requests run at once
• Range: 1 to 10
• Default: 5

---

Selecting Requests

Default Selection

All requests are selected by default when you open the runner.

Individual Selection

Uncheck any request you don't want to run. Only selected requests execute.

Bulk Actions

Custom Order

Drag and drop requests to change execution order.

Note: This only affects the current run - your collection's actual order doesn't change.

---

Running Requests

---

Execution Controls

Pause

Click Pause to temporarily stop execution.

What happens:

• Currently running requests finish
• No new requests start
• Progress freezes
• Resume button appears

Works in both modes:

• Sequential: Pauses before next request
• Parallel: Waits for active requests to complete, doesn't start new ones

Resume

Click Resume to continue from where you paused.

Execution picks up with the next request in the queue.

Stop

Click Stop to cancel the entire run.

What happens:

• Currently running requests finish
• Remaining requests are skipped
• Results show only completed requests
• Run Again button appears

---

Progress Tracking

Overall Progress

Progress Bar

• Shows percentage complete
• Updates in real-time as requests finish
• "X of Y completed" counter

Elapsed Time

• Counts up from 0 seconds
• Updates every second
• Freezes when paused
• Shows final time after completion

Individual Results

Each request result shows:

Color Coding:

---

Results Summary

After execution completes, you'll see aggregated statistics.

Statistics Cards

Success Count

• How many requests returned 2xx or 3xx status
• Green indicator

Failure Count

• How many requests returned 4xx, 5xx, or errored
• Red indicator

Average Response Time

• Average of all request response times
• Helpful for performance analysis

Total Time

• Total elapsed time from start to finish
• Includes delays (in sequential mode)

Test Results

If your requests include tests (in post-response scripts), you'll see test aggregation.

Test Summary:

• Total tests passed
• Total tests failed
• Pass/fail badge
• Expandable details per request

---

Expandable Details

Click any result row to see more information.

Expanded view shows:

• Full URL as it was sent
• Error message (if request failed)
• Test results (if tests exist)

Click again to collapse. Only one row can be expanded at a time.

---

Variables and Scripts

Environment Variables

Requests use variables from your active environment.

Variable Resolution:

1. Request variables (highest priority)
2. Folder variables
3. Collection variables
4. Environment variables (lowest priority)

Example:

URL: {{baseUrl}}/users/{{userId}}
Resolved: https://api.example.com/users/12345

Script Execution

Pre-request scripts run before each request.

Post-response scripts run after each request.

Script Order:

1. Collection pre-request script
2. Folder pre-request script (if applicable)
3. Request pre-request script
4. HTTP Request
5. Request post-response script
6. Folder post-response script
7. Collection post-response script

Variable Propagation

Scripts can set variables that persist for subsequent requests in the run.

Example:

Request 1 post-script:

// Extract auth token from response
const data = nova.response.json();
nova.environment.set("authToken", data.token);

Request 2 can use it:

Authorization: Bearer {{authToken}}

---

Runner Presets

Save common configurations for quick reuse.

Saving a Preset

What's saved:

• Execution mode (Sequential/Parallel)
• Delay or concurrency settings
• Selected requests
• Custom request order

Loading a Preset

1. Open the runner
2. Select a preset from the list
3. All settings are restored automatically

Updating a Preset

1. Load the preset
2. Make changes
3. Click Save again - the existing preset is updated

Preset Statistics

After each run, the preset stores statistics:

• Last run date and time
• Success count
• Failure count
• Total requests run

These stats appear in the preset list for quick reference.

---

Error Handling

Request Failures

If a request fails (network error, timeout, 4xx/5xx), it's marked as failed and execution continues.

The runner does NOT stop on failure - all remaining requests still execute.

Network Offline

If you're offline, requests fail immediately with a network error.

The runner doesn't queue or retry requests automatically.

Timeouts

Requests timeout after 30 seconds by default.

Timeout errors are marked as failures and execution continues.

---

Best Practices

1. Start with Sequential — Use sequential mode first, especially when requests depend on each other
2. Test with Few Requests — Validate your configuration on a small subset before running all requests
3. Use Delays for Rate Limits — Add delays in sequential mode if the API has rate limits
4. Save Common Configurations — Create presets for frequently used test scenarios
5. Review Test Results — Add assertions to catch API regressions early
6. Check Variables — Ensure your environment is active and variables are set correctly
7. Monitor Resource Usage — Limit concurrency in parallel mode to avoid overwhelming the API

---

Troubleshooting

All Requests Failing

Check:

• Internet connection is active
• Variables are resolved correctly (no {{unresolved}} in URLs)
• Environment is active if using variables
• API endpoint is accessible

Slow Execution

Causes:

• Large delay between requests (sequential mode)
• Low concurrency (parallel mode)
• Slow API responses
• Script execution taking time

Solutions:

• Reduce delay (sequential)
• Increase concurrency (parallel)
• Optimize scripts

Tests Failing

Check:

• Response structure matches expectations
• Status codes are as expected
• Variables are set correctly before tests run

---

Next Steps