Pre-request and test scripts at every level
Scripts can be attached to a collection, to folders and to individual requests. Pre-request scripts run before the request is sent, so they can compute signatures, fetch tokens or set variables; test scripts run after the response arrives. Collection and folder scripts run in inherited order before the request's own script, which keeps shared setup in one place.
Assertions that read like sentences
The swc.test and swc.expect functions use chai-style assertions, with response helpers for status, headers, cookies, body and timing:
swc.test("status is 201", () => {
swc.response.to.have.status(201);
});
swc.test("returns JSON with an id", () => {
swc.response.to.be.json;
swc.response.to.have.header("Content-Type");
const body = swc.response.json();
swc.expect(body).to.have.property("id");
swc.environment.set("orderId", body.id);
});
swc.test("matches the schema", () => {
swc.response.to.have.jsonSchema({
type: "object",
required: ["id", "status"],
properties: { id: { type: "string" }, status: { enum: ["new", "paid"] } }
});
});
swc.test("is fast enough", () => {
swc.expect(swc.response.responseTime).to.be.below(800);
});Other helpers include swc.response.to.have.jsonBody(path, value), to.have.body(text), to.have.cookie(name), status-class checks such as to.be.success, and swc.test.skip for tests you want to keep but not run.
Variables, chaining and control flow
Scripts read and write variables at every scope: swc.variables, swc.environment, swc.collectionVariables, swc.globals and, in data-driven runs, swc.iterationData. swc.sendRequest makes an extra HTTP call from a script (for example to fetch a token) with a callback or as a promise. In collection runs, swc.execution.setNextRequest(name) changes which request runs next and swc.execution.skipRequest() skips the current one from its pre-request script. swc.cookies reads response cookies, and swc.state keeps a small persistent store across runs.
Built-in libraries
require() gives scripts the libraries existing collections rely on: chai, lodash, moment, crypto-js, uuid, tv4, ajv, xml2js, cheerio, handlebars and csv-parse/lib/sync, plus Node-style modules such as buffer, url, util, querystring, events, path, assert and crypto, and atob/btoa.
const CryptoJS = require("crypto-js");
const ts = Date.now().toString();
const sig = CryptoJS.HmacSHA256(ts + swc.request.url.toString(), swc.environment.get("secret"));
swc.request.headers.add({ key: "X-Signature", value: sig.toString() });
swc.request.headers.add({ key: "X-Timestamp", value: ts });A package library for shared code
Put code your team reuses, such as a signing helper, a token parser or common assertions, in a package on a collection's Packages tab, and load it from any script in the workspace:
// Package @team/auth (module.exports, like Node):
module.exports = { bearer: (t) => ({ key: 'Authorization', value: 'Bearer ' + t }) };
// Any pre-request or test script:
const auth = swc.require('@team/auth');
swc.request.headers.add(auth.bearer(swc.environment.get('token')));Packages are saved with their collection, so they sync to the team, appear in version history and travel with exports. Every package in the workspace is available to every script; if two collections define the same name, the request's own collection wins. They also work in collection runs, monitors and the swc CLI. Scripts written for Postman's package library run unchanged once the packages exist here, and the import compatibility report lists the ones you still need to add.
Postman scripts carry over
Swastik Codes implements the documented pm.* API and the legacy forms many older collections use: tests["name"] = condition, responseBody, and postman.setEnvironmentVariable. Imported Postman collections keep their scripts; the importer can also rewrite pm.* to swc.* (exporting to Postman writes pm.* back), and so can the Convert to swc.* bar above any script that uses pm.*. Results show under Test Results, console.log output shows in the console panel, and swc.visualizer.set renders a custom HTML view of a response.
A safe sandbox
Scripts run in an isolated JavaScript sandbox with time and memory limits, never in your browser page. In the web app they run on the Swastik Codes server, the same engine used by the runner and monitors, so a test behaves identically everywhere.
Contract tests from your API definition
If you keep an OpenAPI definition in API design, you can generate contract tests that assert each response's status is documented, its content type matches and its JSON body satisfies the documented schema. Generated tests sit in a marked block, so regenerating them never touches your hand-written tests.
Test coverage
A collection's Coverage tab shows how many requests have their own tests, which rely only on folder or collection tests, and which have none. Pick the API definition the collection implements to also see endpoints no request calls and documented responses, such as 401 or 404, that no saved example, status assertion or last run has exercised. Download the summary as a report. See Find flaky tests and check coverage.
Access checks for every role
With roles set up on the collection, the Access matrix on the Roles tab records which roles may call each request and sends every request as every role in one run. Requests that let a role through when it should be denied are flagged first. See Check who can do what.
Security checks and negative testing
Check a collection's endpoints for common security problems, labelled with the OWASP API Security Top 10: endpoints that answer without credentials, CORS that trusts any website, missing security headers, insecure cookies, version banners, stack traces and sensitive fields in responses. Fuzz inputs sends wrong, empty, long and boundary values for every body field, query parameter and path variable and flags 5xx errors and input that is accepted without validation. No attack payloads are sent. swc security --fail-on high makes it a CI gate. See Security checks and invalid input.
Compare responses
Compare with… on any response shows what changed since a saved example or an earlier send: status, headers and every JSON field, ignoring key order, formatting and any paths you name.
How it works
- Open a request in the app and add code in the Scripts tab (pre-request or post-response).
- Send the request (free account needed) and read the results under Test Results.
- Run the whole collection in the runner, or schedule it on a monitor.
Frequently asked questions
Will my existing Postman tests run unchanged?
Most will. The pm.* API (as pm or swc), chai assertions, the common libraries and the legacy tests[] syntax are supported. Check Test Results after importing; scripts that depend on something unsupported report a clear error.
Can a script make extra HTTP requests?
Yes, with swc.sendRequest. Those requests go through the same network rules as normal sends, so they must target public addresses.
Where do scripts run?
In the web app, on the Swastik Codes server in a sandbox with time and memory limits. Nothing in a script runs inside your browser page.
Can I test gRPC or GraphQL responses?
GraphQL requests use the same HTTP assertions. gRPC requests have their own hooks (before invoke, on message, after response) with assertions for status codes, metadata and messages; see the gRPC client.