Scripting

Mitey runs JavaScript before and after a request using an embedded engine, with an mt.* API. This lets you prepare requests, extract values from responses, chain requests, and assert on results.

Pre- and post-request scripts

Each request has a Pre and a Post script tab:

• Pre-request scripts run before the request is sent — set up variables, compute signatures, or tweak the request.
• Post-request scripts run after the response arrives — extract tokens, set variables for the next request, and run tests.

Folders can carry scripts too; descendant requests inherit them.

The mt.* API

A familiar scripting API is available:

• mt.variables.get(key) — read any in-scope variable.
• mt.environment.set(key, value) — set a variable for subsequent requests (persisted to the active environment on send).
• mt.request.method, mt.request.url — inspect the outgoing request.
• mt.response.code, mt.response.status, mt.response.responseTime — response metadata.
• mt.response.text(), mt.response.json() — the response body.
• mt.response.headers.get(name) — a response header.
• console.log(...) — write to the Console tab.

// Post-request: capture an auth token for later requests.
const body = mt.response.json();
mt.environment.set("token", body.access_token);

Tests and assertions

Write assertions with mt.test and a chai-style mt.expect:

mt.test("status is 200", () => {
  mt.expect(mt.response.code).to.equal(200);
});

mt.test("returns a user id", () => {
  mt.expect(mt.response.json()).to.have.property("id");
});

mt.expect supports the common matchers (equal/eql, a, above/below, least/most, include, property, match, ok, true/false/null) and .not. Results show in the Tests tab, and are aggregated by the collection runner.

Assertions from the post-request script show up in the response pane's Tests tab.

Postman Compatibility

We support Postman pm scripts fully. If you import a Postman collection or already have scripts using the pm.* API, they will run seamlessly in Mitey without any modifications. The mt.* API is simply a Mitey-native alias for the exact same underlying functionality. Scripts written before the rename from Impostor use im.*, which also still works.

The sandbox

Scripts run in a fast, embedded JavaScript engine (QuickJS) that is sandboxed — no filesystem or network access by default. Each script has a hard time limit and a memory cap, so a runaway script can’t hang the app.

Workspace trust and script consent

Opening or importing someone else’s workspace brings its pre/post-request and ƒx scripts, which run automatically. Because a script receives your fully resolved variables — including secrets pulled from encrypted storage — and can rewrite the outgoing request, Mitey makes you review and enable each script before it runs.

Trust is keyed by the script’s content, not by the workspace:

• Each distinct script must be enabled once. The first time a request would run a script you haven’t enabled, Mitey shows it to you and asks you to confirm.
• Editing a script — or a git pull that changes one — produces new content, so it must be reviewed again. If you don’t recognise a script, cancel and delete it.
• The set of enabled scripts is stored on your machine, outside any workspace, so trust can never travel with (or be pre-seeded by) a shared workspace.

Because it’s keyed by content, even a script you wrote yourself prompts the first time — just review it and enable it.

Enforcement lives in the core, not the UI, so the gate can’t be bypassed:

• Pre/post-request scripts that aren’t enabled are stripped before the request engine ever sees them (the response log notes that they were skipped).
• ƒx value scripts that aren’t enabled resolve to an empty value instead of executing. This covers every path that resolves variables — HTTP send, collection runs, WebSocket/SSE/gRPC/MCP connect, and Copy as cURL/code — so an un-reviewed ƒx can never read a secret and bake it into a request or a generated snippet.