Importing

Bring existing work into Impostor by importing Postman collections and environments, OpenCollection (Bruno) YAML collections, OpenAPI/Swagger API specifications, or by pasting a cURL command.

Postman compatibility

Impostor provides first-class support for importing Postman v2.1 collections. The importer accurately maps folders, requests, headers, body modes (including binary file bodies), and scripts. It also correctly handles Postman’s authentication and script inheritance, ensuring your setup remains intact.

You can import Postman environments directly; any variables marked as secret will be securely migrated to Impostor’s encrypted secret storage. The Environments section’s ⋮ menu offers Import from Postman as a shortcut, with the environment kind pre-selected.

Importing several files at once

The import dialog accepts multiple files in one batch — Postman JSON exports, OpenCollection YAML, or OpenAPI/Swagger specs — browse for several files (or add paths one by one) and each is auto-detected. Files are imported independently, so a problem with one file never aborts the rest of the batch.

After an import, each file gets its own result row with counts and warnings for any features that couldn’t be mapped.

OpenCollection (Bruno)

OpenCollection is the open YAML format Bruno 3.x writes natively — the successor to its .bru DSL. Impostor imports it in every shape it comes in:

• A collection folder on disk — pick its opencollection.yml and the whole tree comes with it: one .yml per request, each sub-folder’s folder.yml, and everything under environments/. Picking a nested folder.yml imports just that subtree.
• A bundled single file — one document carrying the tree in a nested items array, with environments inline under config. Detected by content, so the file name doesn’t matter.
• A single request file — imports as one request into the folder you picked, with no wrapper folder around it.
• A standalone environment file — the shape Bruno writes under environments/, added to the workspace’s environments.

Only a picked opencollection.yml or folder.yml speaks for its directory. A bundled file under any other name is read on its own, so dropping one into a folder of unrelated YAML never sweeps that folder up.

What maps across

• Folders and requests — with info.seq preserved, so the sidebar keeps the order you had in Bruno.
• Auth — inherit, none, basic, bearer, API key (header/query), digest, AWS SigV4, and OAuth 2.0 (client credentials and authorization code, with PKCE). Collection- and folder-level request.auth becomes folder auth that descendants inherit, exactly as they did in Bruno.
• Bodies — json, text, xml, sparql, form-urlencoded, multipart-form, file, and GraphQL (query + variables). Where a request carries several body variants, the selected one is imported.
• Protocols — HTTP and GraphQL, plus WebSocket and gRPC requests (a grpc:// target, its fully-qualified method, metadata, and the message draft).
• Headers, query and path params — disabled rows stay disabled. Path parameters are substituted into the URL, since Impostor addresses them with {{variables}} rather than a separate table.
• Variables and environments — including typed values and secret variables, which land in Impostor’s encrypted vault rather than on disk.
• Settings — timeout, followRedirects, and maxRedirects, at both request and folder level.

Scripts and assertions

Script code is imported verbatim, so nothing is lost — but Bruno’s scripts use a bru/req/res API while Impostor’s use im.* (with pm.* as a Postman-compatible alias), so expect to port them. before-request becomes the pre-request script; after-response and tests are concatenated into the post-request script.

Declarative runtime.assertions have no Impostor equivalent. Rather than dropping them, the importer appends them to the post-request script as an inert comment block so you can port them to im.test(...).

Known limitations

oauth1, ntlm and wsse auth import as No Auth with a warning, as do the OAuth 2.0 implicit and resource-owner-password flows. WebSocket draft messages and docs blocks aren’t imported. Anything that couldn’t be mapped is listed in the import’s warnings.

OpenAPI & Swagger

Impostor imports OpenAPI 3.0/3.1 specifications, with best-effort support for Swagger 2.0. Specs can be either JSON or YAML — the format is detected automatically.

Each spec becomes a collection folder named after the API’s title. Operations are grouped into sub-folders by their first tag (the Swagger-UI convention); untagged operations land at the collection root. The importer maps:

• Servers → a baseUrl variable every request is built on ({{baseUrl}}/path). Server-URL template variables (and Swagger 2.0’s host/basePath/schemes) are resolved into folder variables you can point at different environments.
• Path/query/header parameters — path templating like /users/{id} becomes {{id}}, and required parameters are imported enabled.
• Request bodies — a representative JSON body is generated from the operation’s schema (using declared examples where present), with local $refs resolved. Form and multipart bodies map to their field lists.
• Security schemes — http bearer/basic, apiKey (header/query), and oauth2 flows map to the matching auth type. Because a spec never contains credentials, these are imported as empty placeholders for you to fill in. Spec-wide security becomes the collection’s auth; per-operation security overrides it.

Known limitations

External or remote $refs (to other files or URLs) are skipped, oneOf/anyOf compositions import using their first option, and response examples aren’t imported. Anything that couldn’t be mapped is listed in the import’s warnings.

cURL commands

For quick ad-hoc requests, you can import a request directly by pasting a cURL command. Impostor will parse the command and populate a new tab with the corresponding URL, method, headers, and body.

Paste a curl command — method, headers and body are parsed into a saved request.