Importing & exporting

Tiger can import collections from Postman, Insomnia, Bruno, OpenAPI 3 / Swagger 2, WSDL / SOAP, and pasted curl commands. It can also export a collection back to Postman v2.1 or OpenAPI 3.0, so you can share with teammates who use other tools.

Supported formats

How to import

All importers share the same entry point. Open the Import dialog from the sidebar (the arrow-into-box icon next to "Collections") or from the welcome screen. Then choose one of the sources below.

Faster still: drop an export file, several files, or a folder anywhere on the Tiger window. Tiger works out which tool each file came from. Drop a Postman collection together with its environment exports and you get one collection with those environments. Drop a Bruno collection folder and it is read as a whole.

The import report

After every import Tiger shows a short report: how many requests, folders and environments came in, and a list of anything that only partly mapped. Each entry names the request (and its folder) and says in plain words what to check, for example a file upload whose file lives on another machine, or a script that calls pm.sendRequest. Nothing is thrown away: unsupported pieces are kept as they were and flagged.

Switching from Postman, Insomnia or Bruno

On first launch the home screen has an import card per tool, each with a hint on where to find the export. Here is what carries over.

Postman (v2.0 / v2.1)

In Postman, open the ... menu next to the collection, choose Export and keep Collection v2.1. Export environments the same way from Environments, and globals from the globals page. Pick all the files together in Tiger (or drop them on the window). Tiger reads both the v2.0 and v2.1 schema variants.

• Collection auth becomes the Tiger collection auth, folder auth becomes folder auth, and requests set to "inherit" inherit through nested folders like they do in Postman. noauth becomes an explicit "no auth".
• Postman has several variable scopes; Tiger has one, the active environment. Collection variables are added to every imported environment (the environment value wins), or become an environment named "<collection> variables" when there is none. Globals become an environment named Globals. The first imported environment is selected for you.
• Collection and folder scripts are copied into each request below them, outermost first, because Tiger runs scripts per request.
• Path variables (/users/:id) are resolved into the URL. One without a value becomes {{id}} so you can set it in an environment.
• Descriptions become request, folder and collection notes. Saved response examples are not imported.

Scripts written for Postman

Tiger runs Postman scripts through a compatibility layer. It covers pm.test, pm.expect with the common Chai assertions (equal, eql, a/an, include, property, lengthOf, above/below, match, oneOf, empty, not and friends), pm.response (code, status, json(), text(), headers, responseTime, to.have.status, to.have.header, to.be.ok), pm.environment, pm.variables, pm.collectionVariables, pm.globals, pm.request (read it, and add or remove headers from a pre-request script), pm.info, and the legacy tests[...], responseBody, responseCode and postman.setEnvironmentVariable. Insomnia's insomnia.* API is the same layer.

Not supported: pm.sendRequest, pm.cookies, pm.vault, require() of libraries such as lodash or CryptoJS, asynchronous code, and flow control (setNextRequest is skipped, the runner goes in order). The import report lists every request that uses one, and the script is kept so you can adapt it.

Insomnia (v4 and v5)

In Insomnia, open the ... menu of the collection (or Preferences, then Data) and choose Export. The JSON and YAML exports both work, including the newer v5 YAML collection files. Choose Insomnia in Tiger and pick the file.

• {{ _.name }} becomes {{name}}. Nested environment JSON is flattened to dotted names, so {{ _.api.url }} becomes {{api.url}} and resolves against the imported environment.
• Each sub environment is merged over the base environment. Private environments are imported too.
• {% uuid %} and {% now %} become Tiger dynamic variables. Other template tags (response, prompt, base64, ...) are kept as text and flagged.
• Folder auth and folder scripts carry over; folder variables are flagged.

Bruno

Nothing to export: choose Bruno and pick the collection folder, the one that holds bruno.json (or drop it on the window). Tiger walks it recursively.

• bruno.json gives the collection name, folder.bru gives folder names.
• collection.bru and folder.bru auth become collection and folder auth. Their headers and scripts are copied into each request below them.
• Request auth follows the auth: mode, including inherit and none.
• params:query, params:path, multipart files (@file(...)), scripts, tests and docs carry over. The assert block becomes equivalent tests where the operator maps.
• Environments come from environments/*.bru. Bruno never writes secret values to disk, so the report lists the secret names to fill in.

OpenAPI 3 / Swagger 2

Tiger accepts OpenAPI 3.x and Swagger 2.0 documents in both JSON and YAML. Choose OpenAPI / Swagger, pick the spec file, and click Import.

What Tiger does with the spec:

• Each path + method combination becomes one request.
• Requests are grouped into folders by their first tag. If an operation has no tags, the first segment of the path is used as the folder name.
• The operation's summary or operationId becomes the request name.
• Query and header parameters are populated from the spec; if the parameter carries an example value (or a schema-level example), it is used as the default.
• For requests that include a requestBody with an application/json content type, the body is pre-filled with the example if one exists, or an empty {} object otherwise.
• The base URL comes from the first entry in servers (OpenAPI 3) or from scheme + host + basePath (Swagger 2). If neither is present, Tiger uses {{baseUrl}} so you can set it in an environment.

curl (paste)

Copy a curl command from a terminal, browser DevTools, or API docs, then choose Paste a curl command in the import dialog and paste it in. Tiger parses common flags including:

• -X / --request - HTTP method
• -H / --header - request headers (one per flag)
• -d / --data / --data-raw / --data-binary - request body
• -u / --user - Basic auth credentials
• The bare URL (with or without --url)

If the body starts with { or [, or the Content-Type header contains json, Tiger sets the body type to JSON automatically. Otherwise the body is imported as plain text.

Multipart (-F) flags are recognized and skipped cleanly; their values will not pollute other fields. Line continuations (\ at end of line) are handled, so multi-line DevTools curl exports paste without modification.

WSDL / SOAP import New in 0.4.0

WSDL import converts a SOAP service description into a set of Tiger requests - one per binding operation - ready to fill in and send. Both SOAP 1.1 and SOAP 1.2 are supported.

How to import a WSDL file

1. Open the Import dialog from the sidebar.
2. Choose WSDL / SOAP.
3. Pick your .wsdl or .xml file.
4. Click Import. Tiger creates a collection named after the <service> element (or the definitions root name as a fallback). Each binding operation appears as a separate request inside it.

What each imported request looks like

For every <operation> inside a <binding>, Tiger generates a POST request with:

• URL - the service endpoint extracted from the <soap:address location> attribute. If no address is found, the URL is set to {{baseUrl}}.
• Body (XML) - a SOAP envelope skeleton with the correct namespace for the protocol version and a placeholder element for the operation's input message. Fill in the element's children to complete the call.
• Headers - set automatically based on the protocol version:
  • SOAP 1.1: Content-Type: text/xml; charset=utf-8 plus a SOAPAction header whose value is quoted as required by WS-I Basic Profile (e.g. "urn:GetWeather").
  • SOAP 1.2: Content-Type: application/soap+xml; charset=utf-8, with the action folded in as a parameter (; action="urn:GetWeather") per RFC 7230.

Example skeleton for a SOAP 1.1 GetWeather operation:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:tns="http://www.webserviceX.NET">
  <soap:Body>
    <tns:GetWeather>
      <!-- fill in fields -->
    </tns:GetWeather>
  </soap:Body>
</soap:Envelope>

The matching headers generated for this request:

Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.webserviceX.NET/GetWeather"

Tiger detects whether a binding uses SOAP 1.2 by checking the namespace URI on the <soap:binding> child element. Namespaces are resolved per-binding, so a single WSDL that mixes SOAP 1.1 and 1.2 bindings will produce requests with the correct Content-Type for each.

Exporting

Postman v2.1

Right-click any collection in the sidebar and choose Export → Postman v2.1. Tiger writes a .json file that:

• Recreates the full folder hierarchy as nested Postman item groups
• Converts each Tiger body type - JSON, XML, text, GraphQL, form - to its Postman equivalent
• Embeds the currently active environment's variables as collection-level variables, so the exported file is self-contained

The exported file is valid for direct import back into Tiger, Postman, or any tool that accepts the Postman v2.1 schema.

OpenAPI 3.0

Right-click a collection and choose Export → OpenAPI 3.0. Tiger produces an openapi.json file where:

• Each request becomes an operation under its URL path (with the base URL or {{variable}} prefix stripped to leave a clean path)
• Query parameters and headers become OpenAPI parameters objects with example values taken from the request
• Request bodies are exported with the correct content type: application/json, application/xml, text/plain, or application/x-www-form-urlencoded
• The request name becomes the operation summary and operationId (sanitized to a valid identifier)
• Free-text documentation added to a request in Tiger becomes the operation description

curl and fetch (single request)

From any open request, click the Code snippet tab to generate a curl command or a JavaScript fetch snippet for that single request. Variable references are interpolated using the active environment before the snippet is rendered.

After importing

An imported collection opens in the sidebar straight away, ready to send. Once imported:

• Open a terminal in the collection folder and run git init (or use Tiger's built-in Git panel) to start version-controlling it.
• Add an environment with the base URL and any secrets the requests need - see Environments.
• Use {{variable}} references to replace hard-coded hostnames and tokens - see Variables.
• Rename, move, and organize requests in the sidebar using drag-and-drop or double-click to rename.

Related pages