Advanced

Condition types

Operators

Logical operators

You can combine multiple conditions.

Configuration example

To match only "search requests from premium users":

URL Pattern: /api/search*
Method: GET

Conditions (AND):
  - Query Parameter "q" exists
  - Header "X-User-Type" equals "premium"

Switching responses from the client side

When you want to prepare multiple response patterns for the same endpoint (success, error, empty data, and so on) and switch between them from the caller via test code or request headers, place several rules that use a dedicated header as their condition near the top of the list at a higher priority.

# Rule 1 (priority): error pattern
URL Pattern: /api/users/*
Conditions: Header "X-Mock-Response" equals "error"
Status: 500

# Rule 2 (priority): empty data pattern
URL Pattern: /api/users/*
Conditions: Header "X-Mock-Response" equals "empty"
Status: 200 / Body: []

# Rule 3 (default): no conditions
URL Pattern: /api/users/*
Status: 200 / Body: {normal response}

If the caller sends the X-Mock-Response: error header, Rule 1 matches; if it sends nothing, Rule 3 (the default) matches. Rules are evaluated from top to bottom, so place variants with more specific conditions higher up. The same mechanism works with both a local proxy and Cloud Publish.

Request pass-through

Forwards the request as-is to the real server. The response returned is what you configured in the mock rule.

Response pass-through

Returns the real server's response as-is. The mock rule is used only for condition matching.

Status code override

With response pass-through enabled, specifying a status code lets you override the real server's status code.

# Change to 500 even if the real server returns 200
Response pass-through: ON
Status code: 500

Handy for testing error handling.

Response body merge

For JSON responses, you can merge the real server's response with the mock response.

# Real server response
{
  "id": 1,
  "name": "John",
  "status": "active"
}

# Body configured in the mock (Merge Response Body: ON)
{
  "status": "inactive",
  "debug": true
}

# Final response
{
  "id": 1,
  "name": "John",
  "status": "inactive",
  "debug": true
}

Latency settings

Set the delay time in milliseconds in each rule's Delay (ms) field.

Use cases

• Loading state testing: Test whether the loading UI displays correctly

• Timeout handling testing: Test whether timeout handling works correctly

• Slow network simulation: Verify behavior on a slow network

• Race condition testing: Test order-dependency problems across multiple requests

Supported formats

Key features

Path conversion

OpenAPI path parameters are automatically converted to Mimicry wildcards.

# OpenAPI definition
/users/{userId}/posts/{postId}

# Converted to a Mimicry pattern
/users/*/posts/*

Response generation

Response bodies are auto-generated in the following order of priority.

How to use

1. 1

   Click the OpenAPI Import button in the sidebar

2. 2

   Select an OpenAPI definition file (YAML/JSON)

3. 3

   Review the folder and rule structure in the preview

4. 4

   Click the Import button to create all mock rules at once

Settings

Use cases

• Injecting a staging auth token: Authorization: Bearer xxx is always injected, saving you from setting it manually every time

• Injecting a debug header: X-Debug-Token and similar headers are always added to correlate with server-side logs

Configuration example

To add an auth token to every API in the staging environment:

Name: Staging auth token
Target domains:
  *.staging.example.com
Scope: (unselected → all projects)
Headers to add / override on the request:
  Authorization: Bearer eyJhbGciOi...
  X-Debug-Token: dev-local

Available placeholders

Example in a response body

An example of returning a unique ID and timestamp every time:

{
  "id": "{{uuid}}",
  "createdAt": "{{now}}",
  "expiresAt": "{{now+7d}}",
  "score": {{random_int(1,100)}},
  "status": "{{random_choice(active,pending,closed)}}"
}

Hooks

Define the following functions in your script and they are called at the corresponding times.

Request/response objects

The objects passed to the hooks have the following structure.

// request
{
  url: string,        // e.g. "https://api.example.com/items?id=1"
  method: string,     // "GET" / "POST" / ...
  headers: { [name: string]: string },
  body: string,       // text or base64 (when isBinary is true)
  isBinary: boolean,
}

// response
{
  statusCode: number, // e.g. 200
  headers: { [name: string]: string },
  body: string,
  isBinary: boolean,
}

Scope and activation

• Scope (URL pattern): Narrows down the target traffic using the same format as mock rules (e.g., api.example.com/*).
• Enabled/disabled: Toggle per script. A disabled script is not run even if it matches.
• console output: console.log/ warn/ error are shown in real time in the console at the bottom of the script window.
• Dry run: Test-run the script with a dummy request/response. You can check hook behavior and logs without sending real traffic.

Script example

An example that adds a signature to the request header and rewrites part of the response body:

// Scope: api.example.com/*

function onRequest(request) {
  // Add a signature to the request
  request.headers['X-Signature'] = 'sig-' + Date.now();
  console.log('signed:', request.url);
  return request;
}

function onResponse(request, response) {
  // Overwrite part of the JSON response
  if ((response.headers['content-type'] || '').includes('application/json')) {
    try {
      const json = JSON.parse(response.body);
      json.debug = { injectedBy: 'mimicry-script' };
      response.body = JSON.stringify(json);
    } catch (e) {
      console.warn('JSON parse failed:', e.message);
    }
  }
  return response;
}

Runtime environment

Scripts run in a sandbox and cannot directly access external resources (network or file system). Execution time and memory are capped, and each request is evaluated in an isolated context, so no state is shared between scripts or across calls.