Response Overview

Configure how your mock API endpoints respond to requests. Control response bodies, conditional logic, HTTP headers, and status codes.

What is a Response?

A Response defines what your mock API endpoint returns when called. Each endpoint can have multiple Responses with different configurations, allowing you to simulate various scenarios and conditions.

A Response includes:

• HTTP status code (200, 404, 500, etc.)
• Response body with dynamic template support
• Conditional rules to match specific requests
• HTTP headers for content type, CORS, caching, etc.
• Latency simulation (optional delay)

Configuration Inheritance

Responses can inherit settings from their parent Folder, reducing duplication and making it easier to manage common configurations across multiple endpoints.

✅ Inherit from Parent Folder

When a Folder defines Headers or Rules, all Responses within that Folder automatically inherit those settings. Manage common configurations in one place for better maintainability.

How Inheritance Works

1. Folder defines settings

Configure Headers and Rules at the Folder level (e.g., common CORS headers, API key validation)

2. Responses inherit automatically

All Responses in that Folder receive the Folder's settings without needing to redefine them

3. Override when needed

If a Response defines its own Headers or Rules, those take priority over the Folder settings

Inheritance Example

📁 Folder: Admin API

Headers: Content-Type: application/json

Headers: X-Admin-Access: required

Rules: Authorization header must exist

📄 Response: POST /admin/users

(Uses inheritance, no explicit configuration)

→ Headers: (inherited) Content-Type: application/json

→ Headers: (inherited) X-Admin-Access: required

→ Rules: (inherited) Authorization required

📄 Response: GET /admin/export

(Overrides Content-Type for CSV export)

Headers: Content-Type: text/csv (override!)

→ Headers: Content-Type: text/csv (Response priority)

→ Headers: (inherited) X-Admin-Access: required

→ Rules: (inherited) Authorization required

Override Priority

Response settings have highest priority

When you define Headers or Rules in a Response, they completely replace the Folder's settings (no merging). The more specific configuration always wins.

Folder settings serve as defaults

If a Response doesn't define any Headers or Rules, it automatically uses the Folder's configuration. This eliminates redundant definitions.

Best Practices

• Define common settings in Folders

Put shared Headers and Rules in the parent Folder to avoid duplication across multiple Responses

• Override only when necessary

Let Responses inherit by default, and only define Response-level settings for special cases

• Update Folder settings for bulk changes

When you modify Folder Headers or Rules, all child Responses automatically receive the updates (unless overridden)

• Use for consistent behavior

Ensure all endpoints in a Folder share common authentication, CORS, or content-type settings

⚠️ Override Behavior

When a Response defines Headers or Rules, it completely replaces the Folder's settings for that component (no merging). If you need both inherited and custom settings, you must explicitly define all of them in the Response.

Learn more about Folder organization and configuration in Folder Documentation

Path Configuration

Each Response can define a path pattern that determines which requests it matches. Paths can be static routes or regular expressions with capture groups.

Static Paths

Use static paths for exact route matching. Paths must start with a forward slash /.

Examplestext

/users
/api/v1/products
/admin/settings
/orders/123

Regular Expression Paths

Use regular expression paths for dynamic route matching. Regex paths must start with regex:/ and can capture groups for use in response templates.

Examplestext

regex:/users/(\d+)
regex:/api/v(\d+)/products/([a-z]+)
regex:/orders/(\d+)/items/(\d+)
regex:/posts/(\d+)/comments/(\d+)

💡 Capturing Groups

Use parentheses () to create capture groups. Captured values can be accessed in response templates using {{path.regex $1}}, {{path.regex $2}}, etc.

Learn more about using path values in templates in Template Syntax Reference.

⚠️ Path Format Rules

• Static paths must start with /
• Regex paths must start with regex:/
• Path segments are indexed starting from 1 (not 0)
• Regex capture groups are indexed starting from 1
• Use parentheses () to create capture groups in regex

Response Components

Each Response is configured using four main components that work together:

1. Status & Body

Configure HTTP status code and response body

Set the HTTP status code (200, 404, 500, etc.) and write the response body content. Use static JSON for simple responses or template syntax for dynamic data generation.

Example: Success Responsejson

Status: 200 OK

{
  "message": "User retrieved successfully",
  "user": {
    "id": "{{faker 'string.uuid'}}",
    "name": "{{faker 'person.fullName'}}",
    "email": "{{faker 'internet.email'}}"
  }
}

Learn more about Status & Body →

2. Templates

Generate dynamic response bodies with template syntax

Templates let you create realistic mock data using faker functions, repeat blocks, and template variables. Perfect for generating user lists, product catalogs, and complex nested data.

Example: Dynamic User Datajson

{
  "users": {{#repeat 5}}{
    "id": "{{faker 'string.uuid'}}",
    "name": "{{faker 'person.fullName'}}",
    "email": "{{faker 'internet.email'}}",
    "avatar": "{{faker 'image.avatar'}}",
    "role": "{{faker 'helpers.arrayElement' '["admin", "user", "guest"]'}}"
  }{{/repeat}}
}

Learn more about Templates →

3. Rules

Add conditional logic to return different responses

Rules let you return different responses based on request data. Check query parameters, headers, body content, cookies, and form data to simulate various scenarios without modifying your code.

Example: User Role Based Responsetext

Response 1 (Admin Users):
  Rule: Query Parameter | role | = Match | admin
  Status: 200
  Body: { "admin": true, "permissions": ["read", "write", "delete"] }

Response 2 (Regular Users):
  Rule: Query Parameter | role | = Match | user
  Status: 200
  Body: { "admin": false, "permissions": ["read"] }

Response 3 (Unauthorized):
  Rule: HTTP Header | Authorization | ✗ No value
  Status: 401
  Body: { "error": "Unauthorized" }

Learn more about Rules →

4. Headers

Configure HTTP response headers

Headers control how clients handle your response. Set content type, enable CORS, configure caching, add authentication tokens, and include custom headers for your specific needs.

Example: API Response Headerstext

Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Cache-Control: no-cache
X-API-Version: 2.0
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 750

Learn more about Headers →

Multiple Responses per Endpoint

You can create multiple Responses for a single endpoint. Each Response can have different Rules to match specific request conditions.

Example: GET /api/users/:id

Response 1: Success (Status 200)

Rule: Query Parameter | id | regex:^\d+$

Returns user data with faker-generated content

Response 2: Not Found (Status 404)

Rule: Query Parameter | id | = Match | 999

Returns: { "error": "User not found" }

Response 3: Unauthorized (Status 401)

Rule: HTTP Header | Authorization | ✗ No value

Returns: { "error": "Unauthorized" }

Response 4: Server Error (Status 500)

Rule: Query Parameter | error | = Match | true

Returns: { "error": "Internal server error" }

💡 Response Priority

Responses are evaluated in order. The first Response with matching Rules will be returned. Place more specific Rules before general ones.

HTTP Status Codes

Each Response can return a different HTTP status code to simulate various scenarios:

2xx Success

• 200 OK - Request succeeded
• 201 Created - Resource created
• 204 No Content - Success, no body

3xx Redirection

• 301 Moved Permanently
• 302 Found - Temporary redirect
• 304 Not Modified - Use cached

4xx Client Errors

• 400 Bad Request - Invalid input
• 401 Unauthorized - No auth
• 403 Forbidden - No permission
• 404 Not Found - Resource missing

5xx Server Errors

• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable

Best Practices

🎯 Start with Success Cases

Begin by configuring the happy path (200 OK) responses. Add error scenarios and edge cases incrementally as needed.

✅ Test All Scenarios

Create separate Responses for success, validation errors, authentication failures, and server errors. Comprehensive mocks help catch edge cases early.

⚡ Use Realistic Data

Leverage faker functions to generate realistic mock data. Real-looking data helps identify UI issues and validation bugs during development.

🔄 Match Real API Behavior

Configure your mock responses to match your actual API specification. This ensures smooth transition from development to production.

Next Steps

Dive deeper into each Response component:

→ Status & Body - Configure HTTP status codes and response bodies
→ Templates - Learn template syntax and faker functions
→ Rules - Master conditional response logic
→ Headers - Configure HTTP response headers