Requests & auth

Every Tiger request has a method, a URL, headers, query params, a body and an auth block. All of those fields support {{variable}} interpolation, and Tiger sets sensible Content-Type defaults automatically so you rarely have to think about it.

HTTP methods

Tiger supports the seven methods you need day-to-day. Select the method from the dropdown to the left of the URL bar:

• GET
• POST
• PUT
• PATCH
• DELETE
• HEAD
• OPTIONS

GET and HEAD requests do not send a body. If a body type is selected when you switch to one of those methods, the body editor is hidden and the payload is not transmitted.

In the .tiger format the method is the block keyword:

get {
  url: https://api.example.com/users
}

post {
  url: https://api.example.com/users
}

URL and query parameters

Type the full URL in the URL bar. Use {{variable}} placeholders anywhere in the URL - they are resolved against the active environment before the request is sent:

get {
  url: {{baseUrl}}/users/{{userId}}
}

The Params tab below the URL bar is a table of key/value rows. Each row has an enable/disable toggle (the ~ prefix in the file format). Tiger appends enabled rows to the URL as a URL-encoded query string, preserving any ? and # that are already in the URL.

In the file format, query params live in a query block:

query {
  page: 1
  limit: 20
  ~debug: true
}

The ~debug row is disabled and will not be appended to the URL.

Headers

The Headers tab holds a key/value table with the same enable/disable toggle as query params. Headers you add here are merged with any headers that the auth block contributes. If you set a header whose name (case-insensitively) already exists from the auth block, your explicit header wins and replaces it.

headers {
  Accept: application/json
  X-Request-ID: {{$uuid}}
  ~X-Debug: 1
}

Dynamic variables like {{$uuid}}, {{$timestamp}}, {{$isoTimestamp}} and {{$randomInt}} are re-evaluated on every send, so each request gets a fresh value.

Body types

Tiger offers seven body types. Switching the type in the UI updates the body:<type> block tag in the .tiger file. When a type has a conventional Content-Type value, Tiger sets it automatically unless you have already added a Content-Type header yourself.

JSON body

Type or paste any JSON. {{variable}} placeholders anywhere in the text are resolved before the request is sent:

body:json {
  {
    "title": "{{postTitle}}",
    "published": true
  }
}

XML / SOAP body

Use the xml type for both plain XML REST APIs and SOAP/WS-* services. For SOAP 1.1, also add a SOAPAction header in the Headers tab. For SOAP 1.2, add action as a parameter of the application/soap+xml Content-Type header (override the default by adding the header manually):

headers {
  SOAPAction: "http://tempuri.org/GetUser"
}

body:xml {
  <?xml version="1.0" encoding="utf-8"?>
  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
      <GetUser xmlns="http://tempuri.org/">
        <UserId>{{userId}}</UserId>
      </GetUser>
    </soap:Body>
  </soap:Envelope>
}

If you have a WSDL file, use File > Import > WSDL instead. Tiger generates one ready-to-fill request per binding operation, with the correct method, Content-Type and SOAPAction already set. See Importing collections for details.

URL-encoded form body

Write one key: value pair per line. A ~ prefix disables a row without deleting it:

body:form {
  username: {{username}}
  password: {{password}}
  ~remember_me: 1
}

GraphQL body

The query document goes in the main editor. Variables go in a second pane that appears below it. Both support {{variable}} interpolation. Tiger sends them as a single JSON POST body:

body:graphql {
  query GetUser($id: ID!) {
    user(id: $id) {
      name
      email
    }
  }
}

graphql:vars {
  { "id": "{{userId}}" }
}

Multipart form-data (file upload)

The multipart editor has a table of rows. Each row is either a text field or a file row. For file rows, click the file icon to open a file picker; the path is stored in the .tiger file as an @file: value and the file is read from disk at send time. Tiger sets the Content-Type: multipart/form-data header with the correct boundary automatically.

body:multipart {
  description: Quarterly report
  file: @file:/Users/you/reports/q1.pdf
}

Auth

The Auth tab lets you attach credentials to a request without cluttering the Headers tab. Tiger applies auth after building the header table, so an explicit header you set always overrides what auth would have contributed.

Auth is inherited: if you set auth on a collection (the collection.tiger file), every request in that collection uses it unless the request overrides it with its own auth block.

None

The default. No credentials are added to the request.

auth:none {
}

Bearer token

Adds Authorization: Bearer <token> to the request headers. The token supports {{variable}} so you can store it in an environment or capture it from a login request:

auth:bearer {
  token: {{accessToken}}
}

Basic auth

Adds Authorization: Basic <base64(username:password)>. Both fields support variable interpolation:

auth:basic {
  username: {{apiUser}}
  password: {{apiPassword}}
}

API key

Sends a named key/value pair either as a request header or as a query parameter. Choose the placement with the In dropdown:

auth:apikey {
  key: X-API-Key
  value: {{apiKey}}
  in: header
}

auth:apikey {
  key: api_key
  value: {{apiKey}}
  in: query
}

When in is query, Tiger appends the pair to the URL's query string, after any explicit query params you have set.

OAuth 2.0 - client credentials

Tiger supports the client_credentials grant type. Fill in the token URL, client ID, client secret and scope, then click Get token. Tiger fetches a token from the token URL using a POST with application/x-www-form-urlencoded body, caches it for the lifetime of the session, and adds Authorization: Bearer <token> to every request that uses this auth block. The token is not written to the .tiger file.

auth:oauth2 {
  grantType: client_credentials
  tokenUrl: https://auth.example.com/oauth/token
  clientId: {{oauthClientId}}
  clientSecret: {{oauthClientSecret}}
  scope: read:users write:posts
}

All four fields support {{variable}} interpolation, so you can store client credentials in an environment and swap between staging and production by switching environments.

How auth and headers interact

Tiger builds the outgoing header map in this order:

1. Auth headers are applied first (e.g. Authorization: Bearer ...).
2. Explicit headers from the Headers tab are merged in next. If a header name matches an auth header (case-insensitively), the explicit header replaces it.

This means you can always override what auth injects by adding the same header name in the Headers tab, without disabling auth.

Content-Type defaults in practice

Tiger only injects a Content-Type header when you have not already set one. Here is a summary of when each default applies:

Disabling rows without deleting them

Every table row - headers, query params, form fields, multipart fields - has a checkbox in the UI. In the .tiger file the same concept is represented by a ~ prefix on the line. Disabled rows are saved and restored between sessions. Use this to keep useful headers or params around while testing different scenarios.

Related pages