Import Postman, Insomnia, OpenAPI & curl

You don’t have to start from scratch. Bandura converts Postman collections, Insomnia exports, OpenAPI/Swagger specs, Bruno request files, and curl commands into .aether flows. After that, they’re plain files in your repo like everything else. Import is one-way and non-destructive: your original collection or spec is never modified.

Importing

The fastest way: drag the file onto the Bandura window. Drop a .postman_collection.json, an Insomnia export, an openapi.yaml, a .bru, or a Postman environment anywhere on the app and the Import dialog opens pre-filled with its contents; Bandura figures out the format for you. A “Drop to import” overlay confirms it’ll work while you drag.

Prefer menus? It’s the same dialog:

1. Click Import in the flow editor’s toolbar, choose File → Import Flows…, or run Import flows from the command palette (⌘⇧P). The toolbar button is the one route that is visible while you are actually looking at a flow.
2. Give it the source, any way:
   • drag a file onto the window (pre-fills the dialog), or
   • Choose file… to pick a .json or .yaml file with the OS file dialog, or
   • paste the collection, spec, or curl command into the text area.
3. Leave the format on Auto-detect; Bandura recognizes the source on its own. If detection guesses wrong, pick the format explicitly from the dropdown (Postman collection, Insomnia export, OpenAPI 3.x / Swagger 2.0, Bruno request, or curl).
4. Continue to Review (see below).
5. Click Import (or press ⌘⏎). The first imported flow opens. Press ⌘⏎ again to run it.

Bandura writes the resulting .aether files into your workspace with collision-safe names (an existing login.aether makes the new one login-2.aether) and opens the first one in the editor. If anything about the source can’t be parsed, you get the error inline and nothing is written.

Review before anything is written

Import has two steps, because “paste 200 requests, press Import, find out afterwards what landed and where” isn’t a review. The second step shows what the parse actually produced, before a single file is created:

• What was detected lists the format Bandura resolved, how many flows it found, and the environment it spotted with the number of values in it.
• A per-flow list gives each flow’s name, its node count, and a summary of the calls it makes. Every row has a checkbox, so you can drop the half of a collection you don’t want. Select all / None for the bulk case.
• Where it lands: a Destination folder field, prefilled from the collection’s own name and editable from here, plus a Flat checkbox that writes straight into the workspace root (the same choice as bandura import --flat).
• For HAR only, a checkbox to include static assets and preflights, which are dropped by default.

A single-flow import (a pasted curl, a .bru) has nothing to choose between, so it skips the list and shows a plain confirmation instead.

If a large collection only partly writes, the modal reports both halves: the files that did land are opened as normal, and the ones that failed stay listed with the reason.

Where the files land

A collection is a unit, so it arrives as one. An import that produces two or more flows goes into a subfolder named after the collection. The name is taken from the document’s own info.name / info.title, or from the file name with the format suffix stripped when the document doesn’t carry one. Importing a 40-request Postman collection gives you acme-api/ with 40 files in it, not 40 files loose in the workspace root.

A single-flow import stays in the root, because a pasted curl command isn’t a collection and a folder holding one file is just an extra click.

Both are defaults, not rules; the Review step’s Destination folder field and Flat checkbox override them per import. From the terminal, bandura import --flat is the same choice, writing every flow straight into --out.

What each format becomes

Insomnia import covers the common cases: method, URL, headers, JSON/form bodies, path/query params, and bearer/basic auth. A few Insomnia-specific things are skipped rather than half-imported: GraphQL bodies, gRPC/WebSocket requests, pre-request scripts, and OAuth flows. Export from Insomnia via Application → Preferences → Data → Export Data → Insomnia v4 (JSON).

Insomnia keeps its environments in the same export as its requests, and Bandura imports both halves in one go, with one command and one click of Import. The requests become flows; the environment values land in your .env with their names recorded in the manifest’s requiredEnv, exactly the way a Postman environment file does. You don’t run the import twice, and a flow that came across referencing ${{ env.API_KEY }} finds the variable already declared.

A HAR is the one source that doesn’t become one flow per request. The other formats are unordered catalogues; a HAR is a recording of a session, and that order is the only thing it carries that they don’t. So it imports as a single flow replaying those requests in sequence, each followed by an assertion on the status the server actually returned. The capture is the source of truth, which makes for a sharper check than a generic 2xx. Two rules come with it:

• Your tokens never land in the file. Authorization, Cookie, and anything looking like an API key or session token keep their header name, but the value becomes a ${{ variables.… }} reference you fill in. A HAR is full of live credentials; the generated flow has to be safe to commit.
• Assets and preflights are dropped. A browser HAR is mostly CSS, images and fonts; those are filtered out by content type and file extension, so you get the API calls.

Capture one from your browser’s DevTools → Network → Save all as HAR, or from a proxy like Charles or mitmproxy.

Imported request nodes get structured pathParams/queryParams (not params baked into the URL string), so they’re immediately editable in the inspector’s Params tab. And because .aether request nodes speak GraphQL natively, a Bruno request with a body:graphql block imports as a real graphql request node, with query and variables carried over, not flattened into an opaque JSON body.

After importing

• Imported single-request flows are building blocks. Chain them into real scenarios by setting next, adding assertions, and capturing values between steps.
• Replace hard-coded hosts with ${{ variables.baseUrl }} or an environment so one suite runs against staging and production.
• Commit the results. From here on, Git is your sync.

From the terminal

The same importers are available headlessly, as in bandura import ./openapi.yaml --out flows/. See the CLI reference.

Coming from Postman

Postman’s dynamic variables survive the move. {{$guid}}, {{$randomEmail}} and {{$timestamp}} are rewritten as dynamic value calls: ${{ $uuid() }}, ${{ $randomEmail() }}, ${{ $timestamp() }}. Fifteen of Postman’s built-ins map across, listed on that page.

They become function calls rather than ordinary flow variables, deliberately, because that is what keeps the behaviour you had: each reference regenerates a fresh value on every use, exactly as it did in Postman. One Postman has that Bandura does not comes through as an ordinary variable with no value, so it surfaces as unset rather than vanishing.

If you’re moving a whole workspace rather than one collection, Migrate from Postman in 5 minutes walks the full path including environments and pm.* scripts, and Bandura vs Postman covers how the two tools compare before you commit to the switch. Coming from Insomnia instead? Bandura vs Insomnia covers what an Insomnia v4 export carries across and how the two Git stories differ.