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.

Postman (v2.0 / v2.1)

Export your Postman collection as a JSON file (Collection → Export → Collection v2.1). In Tiger, choose Postman JSON, pick the file, and click Import. Tiger reads both the v2.0 and v2.1 schema variants.

What carries over:

• Folder hierarchy (nested item groups become Tiger sub-folders)
• Request name, method, URL, query parameters, and headers
• Body - raw (JSON or text), URL-encoded form, GraphQL
• {{variable}} references - Postman uses the same syntax as Tiger, so they round-trip cleanly
• Disabled items (Postman's disabled: true maps to Tiger's ~ prefix)

You can also export the active environment alongside the collection: Tiger embeds the environment's variables as Postman collection variables, so a single exported file carries both requests and variable values.

Insomnia (v4)

In Insomnia, go to Application → Preferences → Data → Export Data → All and save the JSON file. Choose Insomnia v4 in Tiger and pick the file.

Insomnia stores all resources in a flat array keyed by internal IDs. Tiger resolves the parent chain of each request_group to reconstruct the original folder hierarchy. Body types supported: JSON, XML, plain text, GraphQL, and URL-encoded form. Insomnia's {{variables}} syntax differs slightly - review and remap them in Tiger's environment editor after importing.

Bruno

Bruno stores collections as folders of .bru files. Choose Bruno folder in the import dialog, then pick the root folder of the collection. Tiger walks the folder recursively; each .bru file becomes a request, and sub-folders become Tiger folders.

Bruno's block format is a close cousin of Tiger's .tiger format, so most fields map directly: method, URL, headers, query params, JSON / XML / form / GraphQL bodies, and the seq ordering field.

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 curl 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 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

Imported collections land in a folder on disk just like any collection you create from scratch. 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