MOCK SERVERS

Routes & Responses

Define mock routes with path matching, response bodies, headers, status codes, file-based responses, snapshot responses, and dynamic variable interpolation.

Route editor with method, path, status, and body configuration

Adding Routes

Click + Add Route on a mock server to create a new route. Each route defines how the server responds to a specific request pattern.

Configure for each route:

Method — GET, POST, PUT, PATCH, DELETE, or ANY

Path — e.g. /users, /users/:id

Status code — HTTP status to return (200, 404, etc.)

Response headers — custom key-value headers

Response body — static content, file, or snapshot

Note: Routes are matched in order — the first matching route wins. Drag to reorder routes for priority control.

Path Matching

Routes support several matching patterns to handle different request paths:

Pattern	Example	Matches
Exact	/users	Only `/users`
Path params	/users/:id	`/users/123`, `/users/abc` (param value in logs)
Wildcard	/api/*	Any path under `/api/`

Method matching:

Specific method — only matches that exact HTTP method (GET, POST, etc.)

ANY — matches all HTTP methods on the given path

First matching route wins — place more specific routes above generic ones.

Response Body

Three modes for configuring response content:

Static Body

Type JSON, text, XML, or HTML directly in the body editor. Ideal for small, predictable responses.

File Response

Serve a file from disk with auto-detected Content-Type. See File Responses below.

Snapshot Response

Use a saved snapshot variant as the response body. See Snapshot Responses below.

Tip: The body editor supports {{variable}} interpolation from the active environment — making mock responses dynamic.

Response Headers

Add custom response headers via a key-value table in the route editor. Headers are sent with every response from that route.

Common headers:

Content-Type Cache-Control X-Custom-Header Access-Control-Allow-Origin

Content-Type is auto-set based on body type, but can be overridden

Headers support {{variable}} interpolation from the active environment

Status Code

Set any valid HTTP status code for the route response. Defaults to 200.

200 201

Success responses

400 404

Client errors — test error handling

500 503

Server errors — test resilience

301 302

Redirects — test redirect handling

Use 4xx and 5xx status codes to simulate error conditions and test how your application handles failures.

File Responses

Serve files directly from disk as mock responses. Select the File tab in the route editor and pick a file.

File response tab for serving files from disk

How it works:

File served with appropriate Content-Type based on file extension

File path is stored with the route configuration

File is read fresh on each request (changes to the file are reflected immediately)

Useful for:

Static JSON fixtures Images & PDFs Large response payloads Binary files

Snapshot Responses

Use a previously saved snapshot variant as the mock response. Select the Snapshot tab in the route editor and pick a saved snapshot.

The recorded response body from the snapshot is served as the mock response

Useful for replaying real API responses captured during development

Combine with the Snapshot feature to capture realistic responses and serve them from mocks

Workflow: Send a real request → save the response as a snapshot → create a mock route using that snapshot → your tests hit the mock with a realistic response.

Variables in Responses

Response bodies and headers support {{variable}} interpolation. Variables are resolved from the active environment at request time.

Example dynamic mock response:

{
  "user": "{{current_user}}",
  "env": "{{env_name}}",
  "token": "{{api_token}}"
}

Switch environments to return different mock data without changing routes

Variables work in both body content and header values

Unresolved variables are left as-is (not stripped)

Request Log → Swagger / OpenAPI →