Area Mode

Request Testing Mode

Area Mode is the familiar HTTP client interface optimized for testing API endpoints. It provides the same powerful request editing experience you use with Box and History, but organized around your project's modules and endpoints.

When to Use Area Mode

Use Area Mode when you want to test endpoints, configure request parameters, set up authentication, run assertions, and see real responses.

Area vs Designer Mode

AreaDesigner
AreaTesting & Execution
  • •Full HTTP Panel with all tabs
  • •Send requests, see responses
  • •Configure auth, assertions
  • •Edit request body, headers, params
  • •Use environment variables
DesignerAPI Design & Documentation
  • •Edit OpenAPI spec directly
  • •Visual form-based editing
  • •Swagger UI preview
  • •Schema management
  • •Security scheme setup

Interface Layout

Area Mode has a clean, vertical layout with three main sections:

Authorize
Users (3)Orders (5)Products (4)
GETList Users×
POSTCreate User×
DELETEDelete User×
GET/users
ParamsHeadersBodyAuth
Request configuration...
1

Module Bar

Authorize + module pills

2

Endpoint Tabs

All endpoints from module

3

HTTP Panel

Full request editing

Module Selection

The top bar displays your project's modules as pill buttons. Click one to load its endpoints:

Auto-Select

When you enter Area Mode, the first module is automatically selected and its endpoints are loaded.

One Module at a Time

Clicking a module loads all its endpoints as tabs. This keeps the interface focused and organized.

Endpoint Count

The number in parentheses shows how many endpoints are in that module.

Endpoint Tabs

When you select a module, all its endpoints are automatically loaded as tabs:

GETList Users×
POSTCreate User×
DELETEDelete User×
Auto-Loading

Selecting a module automatically opens all its endpoints as tabs. The first endpoint is selected by default.

Tab Indicators
  • • Filled lock = endpoint requires auth (authorized)
  • • Open lock = requires auth (not authorized)
  • • No lock = no auth required

Empty State

If no module is selected or the module has no endpoints, you'll see a "Select a module to load endpoints" message. Select a module from the pills above to get started.

Authorization

If your API has security schemes defined, the Authorize button appears on the left of the module bar:

Authorize

Not authorized

Authorize

Authorized

Shared with Preview

Authorization state is shared between Area Mode and Preview Mode. Authorize once, use everywhere.

OAuth Error Recovery

If a request fails due to an expired or invalid OAuth token, the response panel will show an error with a link to the Auth tab. Click it to re-authenticate without leaving your current endpoint.

HTTP Panel

The HTTP Panel in Area Mode is the same powerful interface you use elsewhere in Tigrister:

Request Line Layout
GET/users

The request line follows: Method → Server → Path → Send. Select a server from the dropdown to set the base URL. Servers come from your OpenAPI spec.

Body

Request body

Params

Query params

Headers

HTTP headers

Auth

Authentication

Changes Sync Automatically

Everything you edit in Area Mode updates the underlying OpenAPI spec:

What Syncs
  • Request method and URL
  • Query/header parameters
  • Request body schema
  • Authentication settings
Stored as Extensions
  • Test assertions (x-tigrister-assertions)
  • Auth overrides (x-tigrister-auth)
  • Variable values (runtime only)

Typical Workflow

1

Select a module

Click a module pill in the top bar. All its endpoints load as tabs.

2

Authorize if needed

Click "Authorize" to set up authentication for secured endpoints.

3

Configure and test

Set parameters, body, headers. Send requests, verify responses.

4

Switch to Designer to refine spec

Your changes sync automatically. Add descriptions, schemas, etc.

CRUD API Testing Walkthrough

Here's a complete example of testing a Users API with Create, Read, Update, and Delete operations:

POST1. Create a User
POST /users
Request Body:
{
"name": "John Doe",
"email": "john@example.com",
"role": "admin"
}
Response: 201 Created
{ "id": 123, "name": "John Doe", ... }
GET2. Read the User
GET /users/123
Response: 200 OK
{ "id": 123, "name": "John Doe", "email": "john@example.com", ... }
PUT3. Update the User
PUT /users/123
Request Body:
{ "name": "John Smith", "role": "user" }
Response: 200 OK
DELETE4. Delete the User
DELETE /users/123
Response: 204 No Content

Verify deletion by calling GET again - should return 404 Not Found.

CRUD Testing Checklist
  • ✓ Create returns correct status code (201 or 200)
  • ✓ Created resource has all expected fields
  • ✓ Read returns the same data that was created
  • ✓ Update changes only the specified fields
  • ✓ Delete removes the resource completely
  • ✓ Operations on non-existent resources return 404
  • ✓ Invalid data returns 400 with error details

Using Environment Variables

Environment variables let you switch between servers and reuse values across requests without manual editing.

Variable Syntax
# Use double curly braces to reference variables
{{variableName}}
Server Selection
baseUrl = https://api.example.com
# Or for staging:
baseUrl = https://staging.example.com

Switch environments by changing one variable instead of updating every request.

Authentication Tokens
authToken = eyJhbGciOiJIUzI1...
# In Authorization header:
Bearer {{authToken}}

Update your token once, all requests use the new value.

Dynamic IDs
userId = 123
# In path:
/users/{{userId}}/orders

Test different resources by changing the ID variable.

Test Data
testEmail = test@example.com
# In request body:
{ "email": "{{testEmail}}" }

Keep test data consistent across related requests.

Variable Scope

Variables are scoped to the current project. Each OpenAPI project can have its own set of variables. Variables are stored locally and never included in exported specs.

Request Chaining Pattern

Many API workflows require using data from one response in subsequent requests. Here's how to handle this common pattern:

Example: Create Order with New Customer
1
POST/customers
Request:
{ "name": "Alice", "email": "alice@example.com" }
Response:
{ "id": 456, "name": "Alice", ... }

→ Copy the customer id from response

Use returned ID in next request
2
POST/orders
Request:
{
"customerId": 456,
"items": [{ "productId": 1, "quantity": 2 }]
}
Response:
{ "orderId": 789, "status": "pending", ... }

→ The order is now linked to the customer

Verify by retrieving customer orders
3
GET/customers/456/orders
Response:
[{ "orderId": 789, "status": "pending", ... }]

→ Confirms the relationship is correctly established

Best Practices
  • • Store returned IDs in environment variables
  • • Test in logical order (create → read → update → delete)
  • • Verify relationships with GET requests
  • • Clean up test data after testing
Common Pitfalls
  • • Forgetting to copy IDs before making next request
  • • Testing with hardcoded IDs that don't exist
  • • Not handling 404 errors gracefully
  • • Missing required relationships
The DesignerCode Editor