Response Rules

Control when mock responses are returned based on request conditions. Response Rules let you create dynamic mock APIs that behave differently based on request parameters, headers, form data, and more.

What are Response Rules?

Response Rules allow you to conditionally return different mock responses based on the incoming request. You can check values from various sources (URL parameters, form data, JSON body, headers, cookies) and apply comparison logic to determine which response should be returned.

Use Cases:

• Return different user data based on user ID parameter
• Simulate authentication failures for specific API keys
• Return paginated data based on page query parameters
• Validate request headers and return appropriate errors
• Test edge cases with specific input patterns

Rules Table

The Rules Table is where you define conditions for your mock responses. Each row represents a rule that can be enabled/disabled, combined with AND/OR operators, and reordered via drag-and-drop.

Table Columns

Drag Handle (⋮⋮)- Drag to reorder rules. Rule order affects evaluation sequence.

Use- Toggle to enable/disable the rule. Disabled rules skip validation and won't be evaluated.

Operator- AND/OR logic operator (not shown for the first rule)

Source- Where to look for the value: Query Parameter, Form Data, JSON Body, HTTP Header, or Cookie

Key- The name of the parameter/field/header/cookie to check. Supports dot notation for JSON Body (e.g., user.profile.role)

Comparison- Comparison operator: = Match, ≠ Not match, > Greater, < Less, >= Greater or equal, <= Less or equal, ✓ Has key, ✗ No key, ✓ Has value, ✗ No value

Value- The value to compare against. For = Match and ≠ Not match operators, you can use regex by clicking the "Regex" button or prefixing with regex:

Description- Optional description to document what the rule checks

Actions- Plus icon adds new rows, minus icon removes rows

Default Configuration

New responses include one pre-configured rule:

text

Use: OFF | Source: Query Parameter | Comparison: = Match | Key: (empty) | Value: (empty)

New rows added via the + button default to disabled (Use: OFF) with Query Parameter source and = Match comparison.

Validation Rules

When a rule is enabled (Use: ON), both Key and Value are required and cannot be empty (except for existence checks: ✓ Has key, ✗ No key, ✓ Has value, ✗ No value)
When a rule is disabled (Use: OFF), validation is skipped and fields can be left empty
Empty or whitespace-only values are invalid for enabled rules
For regex patterns, the value must start with regex: prefix or use the Regex button

Source Types

Response Rules can check values from five different sources in the incoming request:

Query Parameter

Check values from URL query parameters (?key=value format).

Example Query Parameterstext

GET /api/users?page=1&limit=10

Rule: Query Parameter | page | = Match | 1
Rule: Query Parameter | limit | <= Less or equal | 50

Form Data

Check values from POST request body form data (multipart/form-data, application/x-www-form-urlencoded).

Example Form Datatext

POST /api/login
Content-Type: application/x-www-form-urlencoded

username=admin&password=secret123

Rule: Form Data | username | = Match | admin

JSON Body

Check values from JSON request body (application/json). Use dot notation for nested properties.

Example JSON Bodyjson

POST /api/users
Content-Type: application/json

{
  "user": {
    "email": "test@example.com",
    "profile": {
      "role": "admin"
    }
  }
}

Rule: JSON Body | user.profile.role | = Match | admin

HTTP Header

Check values from HTTP request headers. Header names are case-insensitive.

Example Headerstext

GET /api/data
Authorization: Bearer abc123xyz
X-API-Version: v2

Rule: HTTP Header | Authorization | regex:^Bearer\s+[A-Za-z0-9]+$
Rule: HTTP Header | X-API-Version | = Match | v2

Cookie

Check values from browser cookies.

Example Cookiestext

GET /api/profile
Cookie: sessionId=abc123; theme=dark

Rule: Cookie | sessionId | ✓ Has value
Rule: Cookie | theme | = Match | dark

Comparison Operators

Use these operators to compare values from request sources:

Value Comparison

= Match- Exact match (case-sensitive)

≠ Not match- Does not match

text

Query Parameter | status | = Match | active
Query Parameter | userId | ≠ Not match | guest

Numeric Comparison

> Greater- Value is greater than specified

< Less- Value is less than specified

>= Greater or equal- Greater than or equal to

<= Less or equal- Less than or equal to

text

Query Parameter | page | > Greater | 0
Query Parameter | limit | <= Less or equal | 100
JSON Body | user.age | >= Greater or equal | 18

Existence Checks

✓ Has key- Key exists (any value, even null)

✗ No key- Key does not exist

✓ Has value- Key exists with non-empty value

✗ No value- Key missing or has empty value

text

HTTP Header | Authorization | ✓ Has value
Cookie | sessionId | ✓ Has key
Query Parameter | debug | ✗ No key
JSON Body | user.email | ✓ Has value

Regex Pattern Matching

For = Match and ≠ Not match operators, you can use regular expressions by prefixing the value with regex:

Common Patterns

UUID v4

text

regex:^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Matches: 550e8400-e29b-41d4-a716-446655440000

Email Address

text

regex:^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Matches: user@example.com, test.user+tag@domain.co.uk

URL/Domain

text

regex:^https?:\/\/[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}(\/.*)?$

Matches: https://example.com, http://api.example.com/v1/users

IPv4 Address

text

regex:^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$

Matches: 192.168.1.1, 10.0.0.255, 8.8.8.8

Phone Number (International)

text

regex:^\+[1-9]\d{1,14}$

Matches: +12125551234, +821012345678, +442071234567

Numeric ID

text

regex:^[0-9]+$

Matches: 123, 456789, 1

Alphanumeric Token

text

regex:^[A-Za-z0-9_-]{20,}$

Matches tokens with letters, numbers, underscores, hyphens (minimum 20 chars)

Starts With Pattern

text

regex:^test.*$

Matches: test, testing, test123, test-data

User ID Pattern

text

regex:^user-\d+$

Matches: user-123, user-456789

Multiple Choice

text

regex:^(active|pending|inactive)$

Matches exactly: active, pending, or inactive

Usage Examples

Validate Request Parameterstext

# Ensure userId is a valid UUID
Query Parameter | userId | = Match | regex:^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

# Check if email format is valid
JSON Body | user.email | = Match | regex:^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

# Validate API key format
HTTP Header | X-API-Key | = Match | regex:^[A-Za-z0-9_-]{32,64}$

Combining Rules with AND/OR

Create complex conditions by combining multiple rules with AND/OR operators.

AND Operator

All rules must match for the response to be returned.

Example: Admin User with Valid Sessiontext

AND [
  JSON Body | user.role | = Match | admin
  Cookie | sessionId | ✓ Has value
  HTTP Header | Authorization | = Match | regex:^Bearer\s+[A-Za-z0-9]+$
]

→ Response returned only if all three conditions are true

OR Operator

At least one rule must match for the response to be returned.

Example: Multiple Valid User Rolestext

OR [
  JSON Body | user.role | = Match | admin
  JSON Body | user.role | = Match | moderator
  JSON Body | user.role | = Match | superuser
]

→ Response returned if role is admin, moderator, or superuser

Nested Logic

Combine AND/OR operators for complex conditions.

Example: Authorized Admin or Premium Usertext

AND [
  HTTP Header | Authorization | ✓ Has value
  OR [
    JSON Body | user.role | = Match | admin
    AND [
      JSON Body | user.plan | = Match | premium
      JSON Body | user.verified | = Match | true
    ]
  ]
]

→ Must have auth header AND (be admin OR be premium+verified user)

Real-World Examples

1. User Authentication

Return different responses based on authentication status and user role

Success Response Rulestext

AND [
  HTTP Header | Authorization | = Match | regex:^Bearer\s+[A-Za-z0-9_-]{20,}$
  JSON Body | user.email | = Match | regex:^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
  JSON Body | user.password | ✓ Has value
]

Response Bodyjson

{
  "success": true,
  "user": {
    "id": "{{faker 'string.uuid'}}",
    "email": "{{json 'user.email'}}",
    "token": "{{jwt 'HS256' '600' 'your-secret-key'}}"
  }
}

2. Paginated API

Return data only when page and limit parameters are valid

Valid Pagination Rulestext

AND [
  Query Parameter | page | > Greater | 0
  Query Parameter | page | <= Less or equal | 100
  Query Parameter | limit | > Greater | 0
  Query Parameter | limit | <= Less or equal | 50
]

Response Bodyjson

{
  "data": {{#repeat 10}}{
    "id": "{{faker 'string.uuid'}}",
    "name": "{{faker 'person.firstName'}} {{faker 'person.lastName'}}"
  }{{/repeat}},
  "pagination": {
    "page": {{get 'page'}},
    "limit": {{get 'limit'}},
    "total": 1000
  }
}

3. API Version Control

Return different responses based on API version header

Version 2 API Rulestext

OR [
  HTTP Header | X-API-Version | = Match | v2
  HTTP Header | X-API-Version | = Match | 2.0
  HTTP Header | Accept | = Match | regex:.*application/vnd\.api\+json;\s*version=2.*
]

V2 Response Bodyjson

{
  "apiVersion": "2.0",
  "data": {
    "type": "user",
    "id": "{{faker 'string.uuid'}}",
    "attributes": {
      "email": "{{faker 'internet.email'}}",
      "displayName": "{{faker 'person.firstName'}}"
    }
  }
}

4. Feature Flag Testing

Enable new features for specific users or test groups

Beta Feature Rulestext

OR [
  Cookie | betaTester | = Match | true
  JSON Body | user.id | = Match | regex:^user-(100|101|102|103|104)$
  HTTP Header | X-Feature-Flag | = Match | new-dashboard
]

Response with New Featurejson

{
  "features": {
    "newDashboard": true,
    "enhancedAnalytics": true
  },
  "message": "Welcome to the beta!"
}

5. Error Simulation

Test error handling by returning errors for specific conditions

Invalid Request Rulestext

OR [
  JSON Body | user.email | ≠ Not match | regex:^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
  JSON Body | user.age | < Less | 18
  HTTP Header | Authorization | ✗ No value
]

Error Response (400)json

{
  "error": {
    "code": "INVALID_REQUEST",
    "message": "Request validation failed",
    "details": [
      "Invalid email format",
      "User must be at least 18 years old",
      "Authorization header is required"
    ]
  }
}

Tips and Best Practices

💡 Start Simple

Begin with simple single-rule conditions before building complex AND/OR logic. Test each rule individually to ensure it works as expected.

✅ Test Regex Patterns

Always test your regex patterns with multiple inputs. Use tools like regex101.com to validate patterns before adding them to rules.

⚡ Performance Considerations

Complex regex patterns and deeply nested AND/OR logic can impact performance. Keep rules as simple as possible while meeting your requirements.

🎯 Order Matters

Rules are evaluated in the order they appear. Place more specific rules before general ones to ensure the correct response is returned.

Next Steps

Explore more features of DoMock:

→ Learn about Template Syntax - Use dynamic data in your responses
→ Browse Template Examples - Get inspired by real-world use cases