Status & Body

Configure the HTTP status code and response body for your mock API endpoints. Control what data your endpoints return and how clients should interpret the response.

HTTP Status Code

Every response must have an HTTP status code that tells the client whether the request was successful or not. Choose the appropriate status code based on the scenario you want to simulate.

2xx Success

200 OK

Standard success response. Request completed successfully.

201 Created

Resource successfully created (POST/PUT requests).

204 No Content

Success with no response body (DELETE requests).

3xx Redirection

301 Moved Permanently

Resource permanently moved to a new URL.

302 Found

Temporary redirect to another URL.

304 Not Modified

Cached version is still valid (no body needed).

4xx Client Errors

400 Bad Request

Invalid request format or validation failed.

401 Unauthorized

Authentication required or failed.

403 Forbidden

Authenticated but no permission to access.

404 Not Found

Resource does not exist.

429 Too Many Requests

Rate limit exceeded.

5xx Server Errors

500 Internal Server Error

Generic server error.

502 Bad Gateway

Invalid response from upstream server.

503 Service Unavailable

Server temporarily unavailable (maintenance).

504 Gateway Timeout

Upstream server timeout.

Response Body

The response body contains the actual data returned to the client. You can write static JSON or use template syntax for dynamic data generation.

Static JSON

Write plain JSON that returns the same data every time. Perfect for simple mocks or when you don't need randomization.

Example: Static User Responsejson

{
  "id": "12345",
  "name": "John Doe",
  "email": "john@example.com",
  "status": "active",
  "createdAt": "2024-01-15T10:30:00Z"
}

Dynamic Data with Templates

Use template syntax to generate realistic, randomized data on each request. Templates support faker functions, repeat blocks, and request data variables.

Example: Dynamic User Responsejson

{
  "id": "{{faker 'string.uuid'}}",
  "name": "{{faker 'person.fullName'}}",
  "email": "{{faker 'internet.email'}}",
  "status": "{{faker 'helpers.arrayElement' '["active", "inactive", "pending"]'}}",
  "createdAt": "{{faker 'date.recent'}}"
}

💡 Each request generates different data

Template functions run on every request, creating unique realistic data each time. This helps test your UI with varied data patterns.

Learn more about Templates →

Body Content Types

While JSON is the most common format, you can return different content types based on your needs. Set the appropriate Content-Type header to match your body format.

JSON (application/json)

Most common format for REST APIs. Structured data that's easy to parse.

Default

Required Header:Content-Type: application/json

Optional:Content-Type: application/json; charset=utf-8

json

{
  "message": "Success",
  "data": {
    "userId": "123",
    "username": "john_doe"
  }
}

Plain Text (text/plain)

Simple text responses without structure. Good for logs, CSV, or simple messages.

Required Header:Content-Type: text/plain

With Charset:Content-Type: text/plain; charset=utf-8

text

Request processed successfully

HTML (text/html)

HTML pages for server-rendered responses or email templates.

Required Header:Content-Type: text/html

With Charset:Content-Type: text/html; charset=utf-8

html

<!DOCTYPE html>
<html>
<head><title>Success</title></head>
<body><h1>Request Completed</h1></body>
</html>

XML (application/xml)

Legacy APIs or systems requiring XML format (SOAP, RSS feeds).

Required Header:Content-Type: application/xml

Alternative:Content-Type: text/xml

With Charset:Content-Type: application/xml; charset=utf-8

xml

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>success</status>
  <userId>123</userId>
</response>

CSV (text/csv)

Comma-separated values for spreadsheet data or bulk exports.

Required Header:Content-Type: text/csv

With Charset:Content-Type: text/csv; charset=utf-8

text

id,name,email,status
1,John Doe,john@example.com,active
2,Jane Smith,jane@example.com,inactive

Error Response Patterns

Consistent error responses help clients handle failures gracefully. Here are common patterns for different error scenarios.

400 Bad Request- Validation Error

json

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed",
    "details": [
      {
        "field": "email",
        "message": "Invalid email format"
      },
      {
        "field": "age",
        "message": "Must be at least 18"
      }
    ]
  }
}

401 Unauthorized- Authentication Required

json

{
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Authentication required",
    "details": "Please provide a valid access token"
  }
}

404 Not Found- Resource Not Found

json

{
  "error": {
    "code": "NOT_FOUND",
    "message": "Resource not found",
    "details": "User with ID '12345' does not exist"
  }
}

500 Internal Server Error- Server Error

json

{
  "error": {
    "code": "INTERNAL_ERROR",
    "message": "An unexpected error occurred",
    "requestId": "req-{{faker 'string.uuid'}}"
  }
}

Best Practices

🎯 Use Correct Status Codes

Choose status codes that accurately represent the response. Don't return 200 OK for errors or 500 for validation failures.

✅ Consistent Error Format

Use the same error response structure across all endpoints. This makes error handling predictable for clients.

⚡ Match Content-Type Header

Always set the Content-Type header to match your body format. JSON bodies should have Content-Type: application/json.

🔄 Use Templates for Realism

Leverage template functions to generate varied, realistic data. This helps catch UI bugs that only appear with certain data patterns.

Next Steps

Learn how to make your response bodies dynamic:

→ Templates - Learn template syntax for dynamic data generation
→ Rules - Add conditional logic to return different responses
→ Headers - Configure Content-Type and other HTTP headers