Migrate from Postman in 5 minutes

Switching from Postman doesn’t mean starting over. Export your collection, drop it in, and your requests become plain .aether files in your repo — versioned in Git, runnable from the terminal, and editable as a graph or as code. Here’s the whole path, start to finish.

1. Export your collection from Postman

In Postman, right-click your collection → Export → Collection v2.1 → save the .json. If you use Postman environments, export those too (the ⋯ menu on an environment → Export) — Bandura turns them into your .env so secrets never live in the flow files.

2. Drop it into Bandura

Open a workspace folder (this is where your flows will live as files), then drag the exported .json straight onto the Bandura window. A “Drop to import” overlay confirms it, and the Import dialog opens pre-filled with your collection — already recognized as Postman. Click Import.

Each Postman request becomes its own .aether flow, with headers, body, and path/query params carried over as structured, editable fields (not baked into the URL). Folders are flattened; collision-safe names mean nothing you already have is overwritten.

Prefer menus or paste? File → Import Flows… does the same thing — see the full import guide. Coming from Insomnia or Bruno instead? Those import the same way; export Insomnia as v4 (JSON) first.

Your pre-request and test scripts come too

Scripts are usually the part people expect to lose. They don’t get dropped: Postman’s event[] entries land in the flow’s hooks block — pre-request scripts as before, tests as after — with collection-, folder-, and request-level scripts concatenated in the order Postman ran them.

Where every pm.* call has a direct equivalent, your code comes across as you wrote it, sitting above a small generated shim that maps pm onto Bandura’s variables, request, and response. The shim is right there in the file, so you can read it, edit it, or delete it once you’ve rewritten the script natively:

hooks:
  before:
    script: |
      // Ported from this request's Postman pre-request script.
      // --- Postman compatibility shim (generated by `bandura import`) ---
      const __vars = { get: (k) => variables[k], set: (k, v) => { variables[k] = v } }
      const pm = { environment: __vars, request: { headers: {
        add: (h) => { request.headers[h.key] = h.value },
      } } }
      // --- end shim ---
      pm.request.headers.add({ key: "X-Trace", value: pm.environment.get("traceId") })

Where a script reaches for something Bandura’s sandbox doesn’t have — pm.test, pm.sendRequest, CryptoJS, require, console — the whole script is kept, commented out, under a banner naming exactly what stopped it. Nothing runs until you port it, and nothing is thrown away without telling you. That’s on purpose: a signing script where two of three lines survived would send unsigned requests that look like they worked.

Two things to know when you read the result. Postman’s four variable scopes (environment, collection, globals, local) all collapse onto Bandura’s single variables bag, so flatten any names you were relying on to stay separate. And pm.test(...) assertions are better rewritten as assertion nodes than kept in a hook — an assertion node reports which check failed and rings the node red.

3. Bring your environment over

Drop your exported Postman environment file in the same way. Instead of creating flows, Bandura writes its values into a git-ignored .env and records the variable names in your project manifest’s requiredEnv. Your {{baseUrl}}-style references resolve from there — and because secrets live in .env, not in the committed flow files, sharing via Git stays safe.

See Variables & environments for how the resolution order works (manifest environment → .env → per-run overrides).

4. Run it — the muscle memory carries over

Open any imported flow and press ⌘⏎ — the same key Postman uses to send a request. The graph lights up node by node as it runs, and the History panel records every run locally.

Pressing ⌘⏎ on a flow that references a variable you haven’t filled in yet? Bandura points you at the missing value first instead of failing blindly. Fill it in and run again.

5. Chain requests into real scenarios

Postman requests are individual calls; Bandura’s strength is stitching them into flows. A couple of moves that pay off immediately:

• Capture and reuse — a login request can capture its token (capture: { token: "response.body.token" }) and a later request reads ${{ variables.token }} for its Authorization header. See Variables & environments.
• Assert, don’t eyeball — add an assertion node after a request (response.status === 200) so a run is pass/fail, not a wall of JSON to read.
• Add nodes without the docs — right-click the canvas to drop in a prefilled example node (request, assertion, condition, loop…), or use the + Node button. Press ⌘/ anytime for the full keyboard cheat sheet.

6. Commit — Git is your sync from here

There’s no cloud account and no sign-in. Your flows are files; git add, git commit, and you’re done. Teammates clone the repo and run the same flows — no shared-workspace service, no seat limits, no lock-in. See Share flows with Git.

That’s the migration: export, drop, fill in secrets, run. From here on, your API tests are part of your codebase like everything else.