Request Processors - Tigrister Guide

Processors Tab

The Processors tab contains advanced features for request automation and validation: scripts that run before and after the request, and assertions that verify the response. These tools are essential for API testing and automation workflows.

Processor Types

The Processors tab contains three sub-tabs:

Pre-Script

Runs before the request is sent

Post-Script

Runs after the response is received

Assertions

Validates response conditions

Pre-Script

Pre-scripts execute JavaScript code before the request is sent. Use them to inspect request data, log information for debugging, or perform pre-flight validation.

Available APIs

API	Description
request.method	HTTP method (GET, POST, etc.)
request.url	Full request URL
request.headers	Request headers object
request.body	Request body as string
console.log()	Log messages to script output
console.info()	Log info messages
console.warn()	Log warning messages
console.error()	Log error messages
fetch(url, options)	Make HTTP requests (async)
setTimeout(fn, ms)	Delay execution

Example: Log Request Details

// Log request information for debugging
console.log('Method:', request.method);
console.log('URL:', request.url);
console.log('Headers:', JSON.stringify(request.headers, null, 2));

if (request.body) {
  console.log('Body:', request.body);
}

Example: Validate Request Before Sending

// Check if required headers are present
if (!request.headers['Authorization']) {
  console.warn('Warning: No Authorization header set');
}

// Validate JSON body structure
if (request.body) {
  try {
    const body = JSON.parse(request.body);
    if (!body.name) {
      console.error('Error: name field is required');
    }
  } catch (e) {
    console.error('Body is not valid JSON');
  }
}

Execution: Pre-scripts run synchronously before the request. If the script throws an error, the request is not sent.

Post-Script

Post-scripts execute after the response is received. Use them to inspect response data, log results for debugging, or perform custom validation.

Available APIs

API	Description
response.status	HTTP status code (e.g., 200, 404)
response.statusText	HTTP status text (e.g., "OK", "Not Found")
response.headers	Response headers object
response.body	Response body as string
response.timing	Timing information object
request.*	All request APIs also available
console.log()	Log messages to script output
fetch(url, options)	Make HTTP requests (async)
setTimeout(fn, ms)	Delay execution

Example: Log Response Details

// Log response information for debugging
console.log('Status:', response.status, response.statusText);
console.log('Headers:', JSON.stringify(response.headers, null, 2));

// Parse JSON body
if (response.body) {
  try {
    const data = JSON.parse(response.body);
    console.log('Response data:', data);
  } catch (e) {
    console.log('Body (raw):', response.body);
  }
}

Example: Validate Response Structure

// Validate the response matches expected structure
if (response.status === 200) {
  const data = JSON.parse(response.body);

  if (!data.id) {
    console.error('Missing required field: id');
  }

  if (!Array.isArray(data.items)) {
    console.error('items should be an array');
  } else {
    console.log('Found', data.items.length, 'items');
  }
}

Example: Log Timing Information

// Analyze request performance
const timing = response.timing;

console.log('Total time:', timing.total, 'ms');
console.log('DNS lookup:', timing.dns, 'ms');
console.log('TLS handshake:', timing.tls, 'ms');
console.log('Time to first byte:', timing.ttfb, 'ms');

JSON Parsing: Use JSON.parse(response.body) to convert the response body to a JavaScript object for easier inspection and validation.

Script Results

After execution, scripts show their results including:

SuccessScript completed without errors. Console output is displayed.

ErrorScript threw an error. Error message and stack trace are displayed.

Execution Duration

The time taken to execute the script is shown in milliseconds. Long-running scripts may indicate inefficient code or infinite loops.

Assertions

Assertions are declarative tests that validate the response. They provide a visual way to define expected conditions without writing code. Each assertion runs automatically after the request completes.

Assertion Structure

Each assertion consists of up to four parts:

Type	What to check: Status Code, Response Time, Header, JSON Path, or Body
Property	For Header and JSON Path types only: the header name or JSONPath expression
Operator	How to compare: equals, contains, exists, less than, etc.
Expected	The value to compare against (not needed for exists, is empty, etc.)

Assertion Types

Status Code

Validates the HTTP status code returned by the server.

Available operators:

equalsnot equals><

Status Code equals 200

Status Code < 400// Any success (1xx, 2xx, 3xx)

Status Code > 199// Not informational

Response Time

Validates the total response time in milliseconds. Useful for performance testing.

Available operators:

<>equals

Response Time < 500 ms// Fast response

Response Time < 2000 ms// Acceptable for complex queries

Response Time < 100 ms// Cache hit expected

Header

Validates response headers. Header name matching is case-insensitive.

Available operators:

equalsnot equalscontainsnot containsexistsnot existsmatches regex

Header Content-Type contains "application/json"

Header Cache-Control contains "max-age"

Header X-RateLimit-Remaining exists

Header Set-Cookie matches regex "session=.*; HttpOnly"

JSON Path

Extracts a value from the JSON response body using JSONPath syntax, then validates it. This is the most flexible assertion type with access to all operators.

Available operators:

equalsnot equalscontainsnot contains><existsnot existsis emptyis not emptyis typematches regex

JSON Path $.success equals true

JSON Path $.data.id exists

JSON Path $.items is type array

JSON Path $.items.length > 0

JSON Path $.user.email matches regex "^[^@]+@[^@]+$"

JSON Path $.error not exists

JSONPath Syntax Reference

Path	Description
$	Root object
$.property	Top-level property
$.user.name	Nested property
$.items[0]	First array element (0-indexed)
$.items[-1]	Last array element
$.items[0:3]	Array slice (elements 0, 1, 2)
$.items[*]	All array elements
$.items[*].id	Property from all array elements
$.items.length	Array length
$..name	Recursive search for "name" at any depth
$.items[?(@.active)]	Filter: items where active is truthy
$.items[?(@.price>100)]	Filter: items where price > 100

Body

Validates the entire response body as raw text. Useful for non-JSON responses or full-body matching.

Available operators:

containsnot containsequalsis emptyis not emptymatches regex

Body contains "success"

Body not contains "error"

Body is not empty

Body matches regex "<html>.*</html>"

Operators Reference

Complete list of all comparison operators. Not all operators are available for all assertion types.

Operator	Description	Expects Value
equals	Exact match. For JSON, compares normalized structure.	Yes
not equals	Passes if values are different.	Yes
contains	Substring match. For JSON, supports partial object matching.	Yes
not contains	Passes if value is not found.	Yes
> (greater than)	Numeric comparison. Both values converted to numbers.	Yes
< (less than)	Numeric comparison. Both values converted to numbers.	Yes
exists	Passes if value is not undefined or null.	No
not exists	Passes if value is undefined or null.	No
is empty	Passes if: empty string, empty array [], empty object {}, null, or undefined.	No
is not empty	Passes if value has content.	No
matches regex	Regular expression match. Supports multiline and cross-platform newlines.	Yes (pattern)
is type	Checks JSON type: string, number, boolean, array, object, or null.	Yes (type)

Smart Comparison: The equals and contains operators normalize JSON before comparison. This means {"a":1} equals { "a": 1 } regardless of whitespace.

Assertion Results

After sending a request, each assertion displays its result:

PassedThe assertion condition was met. A green checkmark appears next to the assertion, and a green left border highlights the row.

FailedThe assertion condition was not met. A red X appears next to the assertion, a red left border highlights the row, and an error message appears below showing expected vs actual values.

Tab Badge

The Processors tab header shows pass/fail counts as colored badges. A green badge shows passed count, a red badge shows failed count. This provides at-a-glance test status without opening the tab.

Summary Bar

At the bottom of the assertions panel, a summary shows the total count: "Results: X passed, Y failed". This appears only after a request has been sent.

Managing Assertions

Enable/Disable All

The "Enable Assertions" checkbox at the top controls whether assertions run at all. When unchecked, no assertions are evaluated regardless of individual assertion settings. This is useful for temporarily skipping validation during debugging.

Enable/Disable Individual

Each assertion row has its own checkbox. Unchecked assertions are skipped during evaluation but remain in the list. Use this to temporarily disable specific assertions without deleting them.

Add Assertion

Click the "Add" button to create a new assertion. New assertions default to:

Type: Status Code
Operator: equals
Expected: 200

Delete Assertion

Click the trash icon on any assertion row to delete it. This action is immediate and cannot be undone. If you accidentally delete an assertion, you will need to recreate it manually.

Assertion Order

Assertions are evaluated in the order they appear in the list. All enabled assertions run regardless of previous failures (unlike short-circuit evaluation). Results are independent of each other.

Common Testing Patterns

These patterns cover the most common API testing scenarios. Use them as a starting point and customize based on your API's response structure.

GET - Success Response

Basic validation for a successful GET request:

Status Code equals 200

Header Content-Type contains "application/json"

Body is not empty

POST - Created Resource

Validation for POST that creates a new resource:

Status Code equals 201

JSON Path $.id exists

JSON Path $.id is type number

JSON Path $.createdAt exists

PUT/PATCH - Update Resource

Validation for update operations:

Status Code equals 200

JSON Path $.updatedAt exists

JSON Path $.name equals "Updated Name"

DELETE - Remove Resource

Validation for DELETE operations (varies by API):

Status Code equals 204// No Content

Body is empty

Or if the API returns the deleted resource:

Status Code equals 200

JSON Path $.deleted equals true

GET - List with Pagination

Validation for paginated list endpoints:

Status Code equals 200

JSON Path $.data is type array

JSON Path $.data.length > 0

JSON Path $.meta.total is type number

JSON Path $.meta.page exists

POST - Login/Authentication

Validation for authentication endpoints:

Status Code equals 200

JSON Path $.access_token exists

JSON Path $.access_token is type string

JSON Path $.access_token is not empty

JSON Path $.expires_in > 0

400 - Validation Error

Testing that invalid input returns proper errors:

Status Code equals 400

JSON Path $.errors is type array

JSON Path $.errors.length > 0

JSON Path $.errors[0].field exists

JSON Path $.errors[0].message exists

404 - Not Found

Testing behavior when resource doesn't exist:

Status Code equals 404

JSON Path $.error exists

JSON Path $.message contains "not found"

401 - Unauthorized

Testing authentication requirement:

Status Code equals 401

Header WWW-Authenticate exists

JSON Path $.data not exists// No data leak

Performance Testing

Validate response time requirements:

Status Code < 400// Any non-error

Response Time < 200 ms// Fast (cached)

Response Time < 500 ms// Normal

Response Time < 2000 ms// Acceptable for heavy queries

Security Headers Check

Validate security-related response headers:

Header X-Content-Type-Options equals "nosniff"

Header X-Frame-Options exists

Header Strict-Transport-Security exists

Header Content-Security-Policy exists

Auth Random Variables