Choose what runs, and in which order
Run the entire collection, a single folder or a single request. The run order is listed before you start: move requests up or down to change it for this run, or reset to the collection order. Pick the environment to use, or none.
Iterations and data files
Set a number of iterations to repeat the run, or attach a data file to drive it:
- CSV (RFC 4180, with quoted fields, escaped quotes and newlines inside quotes)
- JSON, as an array of objects
Each row's columns are available as {{column}} variables in URLs, headers and bodies, and as swc.iterationData.get("column") in scripts. A preview shows which values each iteration will use before you start.
email,password,expectedStatus
ada@example.com,correct-horse,200
ada@example.com,wrong-password,401
,missing-email,400swc.test(`login returns ${swc.iterationData.get("expectedStatus")}`, () => {
swc.response.to.have.status(Number(swc.iterationData.get("expectedStatus")));
});A run accepts up to 1,000 iterations and 10,000 data rows.
Delays, bail rules and variables
Add a delay between requests (up to 60 seconds) to stay within an API's rate limits. Choose when to stop early: never, on the first failed test, on the first send or script error, or on the first failure of either kind. Variables changed by scripts are persisted back to the environment by default, so a token fetched in the first request is used by the rest. You can also write the cookies a run received into the cookie manager, keep response headers and bodies in the results, or drop console output to speed up long runs.
Control flow from scripts
Scripts can change the order at run time. swc.execution.setNextRequest("Get order") jumps to a named request (or null to stop), and swc.execution.skipRequest() in a pre-request script skips the current request. Skipped requests are counted separately in the summary, so they never look like passes.
Run it in CI
Run in CI, next to the Run button, writes the pipeline file for the collection you have set up: GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, CircleCI or a plain shell script. It installs the swc CLI, loads the collection and environment from your account by id with an API key stored as a CI secret, runs the requests you selected and saves a JUnit report for your CI's test view. Tick one box to also fail the build on breaking API changes in the code, with a comment on each GitHub pull request.
Results you can share
While a run is in progress you see each request's status, response time and test results, with a stop button. The summary shows requests, failed requests, tests passed and failed, average response time and duration. Drill into a request to see its tests, console output and, if you chose to keep them, the response headers and body. Requests whose response no longer matches their saved examples are marked Docs drift, with the differences listed, so you see when the published docs need updating. Export a run as:
- JSON for your own tooling
- JUnit XML for CI dashboards that read test reports
- a self-contained HTML report to attach to a ticket
Previous runs stay in the run history.
Compare two environments
The Compare environments tab sends the selected requests in environment A and environment B and compares every response pair: status, headers and each JSON field, as paths such as $.items[0].price: 10 → 12. Ids, timestamps and other fields that always differ can be ignored by path. Each request is marked same, different, failed or missing; tests that pass in one environment and fail in the other are called out, and a click shows the two responses side by side. Use it to check staging against production, or a new deployment against the old one. See the lesson Compare responses and environments.
Find flaky tests
The Find flaky tests tab runs the selected requests several times in a row and marks each one flaky (a test passed some times and failed others, the status changed, or a response was sometimes missing), failing (failed every time) or stable, with the reason. Latency spikes are noted too. See Find flaky tests and check coverage.
Security checks and invalid input
The Security checks tab reads every response for CORS that trusts any website, missing security headers, cookies without Secure / HttpOnly / SameSite, version banners, stack traces and sensitive fields, then sends signed-in requests again without their credentials to find endpoints that do not enforce authentication. Fuzz inputs sends each request with one input wrong (wrong type, empty, very long, boundary numbers, left out) and flags server errors and accepted invalid input. See Security checks and invalid input.
Variables checked before you run
Before a run starts, the runner lists variables the selected requests use that nothing defines or that are empty, such as {{baseUrl}} with no environment selected, and which requests use them.
How it works
- Open the runner in the app and choose a collection or folder.
- Set iterations, a data file, a delay and a bail rule.
- Start the run. Runs execute on the Swastik Codes server with the same engine and script sandbox as the Send button, so they need a free account and public target URLs.
To run the same collection on a schedule, attach it to a monitor. To find out how it behaves under concurrency, use load testing.
Frequently asked questions
How do data file columns become variables?
Each CSV header or JSON object key becomes a variable for that iteration. Use {{key}} in the request or swc.iterationData.get("key") in scripts.
Can I run only part of a collection?
Yes. Run a single folder or request, or reorder the run before starting it.
Does the runner behave like Newman?
The runner follows the same collection semantics as Postman's runner and Newman: scripts run in inherited order, setNextRequest works, and a failing pre-request script still lets the run continue. Results export as JUnit XML for CI.
Are gRPC requests included in runs?
Yes. Saved gRPC requests run in collection runs with their scripts, recorded with the gRPC status code.