Postman → Tiger migration

Export your Postman collection, import it into Tiger, set your environments once, and commit. Your whole team is up and running in under an hour - no cloud account, no per-seat fee.

Before you start

You need:

• The Postman desktop app or web app, with the collection you want to migrate.
• Tiger 0.4.0 or later. Download it from GitHub Releases or the install page.

Step 1 - Export your Postman collection

Open Postman and locate the collection in the left sidebar. Right-click the collection name and choose Export. In the dialog, select Collection v2.1 (Recommended) and click Export. Save the .json file somewhere convenient on your machine.

Repeat for every collection you want to bring over. If you have named environments, export them too from Environments in the sidebar - you will not import them directly into Tiger, but having them open for reference makes re-entering values faster.

Step 2 - Install Tiger

Download the installer for your platform from the GitHub Releases page. Native builds are available for macOS (Apple Silicon and Intel DMG), Windows (installer and portable EXE), and Linux (AppImage).

Tiger requires no account, no license key, and no internet connection to run. Launch it once to confirm it starts.

Step 3 - Import the Postman JSON

In Tiger, click Import at the top of the sidebar (or File > Import) and choose Postman as the source format. Drop your exported .json file onto the import dialog or click Browse and navigate to it.

Tiger parses the collection and recreates the full folder hierarchy, request names, HTTP methods, headers, query parameters, request bodies, variable references and request descriptions. Large collections with hundreds of requests import in seconds.

Each request becomes a plain-text .tiger file on disk, inside a folder structure that mirrors your Postman folders. Here is what a migrated request looks like:

meta {
  name: Create invoice
  seq: 3
}

post {
  url: {{baseUrl}}/v1/invoices
}

headers {
  Authorization: Bearer {{accessToken}}
  Content-Type: application/json
}

body:json {
  {
    "customer": "{{customerId}}",
    "currency": "usd",
    "auto_advance": true
  }
}

Variable references like {{baseUrl}} and {{accessToken}} are preserved verbatim. You will fill in the actual values in the next step.

Step 4 - Set up environments and auth

Tiger does not import environment values from Postman - secrets and tokens should not travel in an exported JSON file. Open Settings > Environments in Tiger, create an environment for each context you need (for example, staging and production), and fill in the variable values.

Environment files live in an environments/ subfolder inside your collection folder and look like this:

meta {
  name: staging
}

vars {
  baseUrl: https://api.staging.acme.dev
  clientId: acme-ci
  ~clientSecret: s3cr3t
}

A ~ prefix marks a variable as secret. Tiger stores secret values separately from the collection files so you can safely commit the environment file to Git without leaking credentials.

Auth types

Tiger supports the following auth types, all configurable per-request or at the collection level:

• Bearer token - paste the token into an environment variable and reference it with {{token}}.
• Basic auth - username and password fields, interpolated from variables.
• API key - send as a header or as a query parameter.
• OAuth 2.0 client credentials - enter the token URL, client ID and client secret once; Tiger fetches and refreshes the token automatically.

For requests that used Postman's OAuth 2.0 flow, switch to Tiger's native auth:oauth2 configuration instead of scripting the token exchange manually.

Step 5 - Commit the collection to Git

Your imported collection is now a plain folder of .tiger files on disk. Add it to your team repository:

# From your project root
git add api-collections/
git commit -m "import: add payments collection from Postman"
git push

From this point on, adding a request is a commit, changing an endpoint URL is a diff, and reviewing auth changes is a pull request. Engineers joining the team clone once and get the full collection immediately - no shared Postman workspace, no invitation email, no seat count.

What carries over and what to redo

The importer is accurate but honest: structural data migrates automatically; secret values are entered once in Tiger.

Dynamic variables

Postman pre-request scripts that inject dynamic values are often unnecessary in Tiger. Tiger evaluates the following built-in variables on every send:

• {{$uuid}} - a fresh random UUID v4.
• {{$timestamp}} - current Unix timestamp in seconds.
• {{$isoTimestamp}} - current date-time in ISO 8601 format.
• {{$randomInt}} - a random integer between 0 and 1000.

For logic beyond these built-ins, Tiger supports pre/post-request JavaScript. Write a script in the request's Pre-request tab to set environment variables before the request is sent.

Chaining requests

If your Postman collection used test scripts to pass values between requests (for example, extracting an ID from a create response and using it in a subsequent read request), replace those scripts with Tiger's capture block:

capture {
  orderId: body.data.id
  authHeader: header.X-Request-Id
}

Each capture reads a value from the response - by JSON path, by header name, or as the raw status code - and writes it into an environment variable. The next request in the collection runner picks it up automatically via {{orderId}}.

Troubleshooting

Import dialog rejects the file

Confirm you exported as Collection v2.1 or v2.0 JSON, not a Postman workspace export or a team export. The file's top-level key should be "info" with a "schema" field pointing to the Postman collection schema URL. If you exported a workspace, go back into Postman, expand the workspace, right-click the individual collection, and export that.

Variable references show as literal text after import

You need to select an active environment. Open Settings > Environments, confirm your environment has the matching variable names, and set it as active for the collection. Tiger will then resolve {{baseUrl}} to the value you entered.

OAuth flow does not complete

For OAuth 2.0 client credentials flows there is no redirect URI - confirm the token URL and client credentials are entered in the environment, not hard-coded in the request. For authorization code flows, check that your auth server allows the redirect URI Tiger registers.

SSL certificate errors on internal services

Go to Settings and disable SSL verification for the relevant environment, or import your internal CA bundle under Settings > Certificates. You can also supply a client certificate (PEM pair or PFX/PKCS12) for mTLS endpoints.

macOS "app is damaged" or "cannot be opened" message

Tiger builds are not yet code-signed. Right-click the app in Finder and choose Open, then confirm in the dialog. You only need to do this once per version.

What comes next

Once your collection is imported and committed, explore these Tiger capabilities: