Documentation

Mimicry is a Mock API Engine for frontend developers: it lets you create and manage mocks with dynamic data, without writing a backend. In this documentation you will find everything you need to integrate Mimicry into your apps.

You can use Mimicry in two modes: as a guest (no registration, instant access) or as a registered user (full console, higher limits, permanent projects). See the Guest vs Registered section for details.

Mimicry can be used without an account - in guest mode - or with a registered account. The two modes differ in quotas, features, and project duration.

What guests can do

Guests can immediately create a project and start consuming mocks without any registration. However, there are some important limitations:

• They can create only 1 CRUD project (with only 1 resource) and only 1 non-CRUD project. If they need more resources or want to relate them (1:N, M:N), they must register.
• Guest projects expire after 24 hours from creation and are automatically deleted.
• They do not have access to the management console: the project can only be configured from the dedicated page.
• They cannot protect mocks with a project API key.

What registered users can do

• Access the full console with all projects in a single dashboard.
• Up to 25 CRUD projects and 25 non-CRUD projects.
• Multiple CRUD resources per project, with 1:N and M:N relationships between resources.
• No expiration for projects (unlimited duration).
• Generate and manage project API keys.
• Significantly higher schema and response limits (see table below).

Comparison table

Warning: schema limits (depth, fields, EGV, response size) vary by role. See theComplexity and limits section.

Minimum flow to get to your first working integration in just a few steps.

As a guest (without registration)

1. From the homepage, enter the desired path (for example /users) and click Create mock. From the dropdown choose:
   • Quick Mock - creates a single endpoint with a Faker response (no persistence).
   • CRUD Resource - creates a project with a complete CRUD resource (GET, POST, PUT, PATCH, DELETE) with persisted data.
2. Configure the schema in the modal that opens.
3. Copy the displayed projectSlug and make your first call:

   GET https://mimicry.rest/m/{projectSlug}/users

Warning: guest projects expire after 24 hours. Register to make them permanent.

As a registered user (from the console)

1. Access the console, create a project, and copy its projectSlug.
2. Create a CRUD resource /users, a simple mock /users/profile, or import from OpenAPI.
3. Make your first call:

   GET https://mimicry.rest/m/{projectSlug}/users

If you configured an API key on the project, always add the x-api-key header as shown in the dedicated section.

All mock requests follow this format:

METHOD https://mimicry.rest/m/{projectSlug}/{path}

projectSlug is the project slug (for example from the console). Example: GET https://mimicry.rest/m/my-app/users.

Mimicry distinguishes between two types of mocks:

• Simple mocks (non-CRUD): a path + method (for example GET /users/profile). The response is generated on every request from a Faker schema. No data persistence.
• CRUD resources: a resource (for example /users) with full operations (GET list, GET single, POST, PUT, PATCH, DELETE), pagination, filters, relationships, nested routes, embedding. Data is persisted and remains between calls.

Note for guests: it is possible to create only one CRUD resource and only one non-CRUD project. To relate multiple resources together (for example /users to /orders) you need to register.

A mock can be created in two ways:

• With a Faker schema:define path, method, and schema (fields with Faker types). For simple mocks, the response is generated on every request; for CRUD resources you can enable "Configure Schema" and Mimicry generates the initial data (with optional seed).
• With POST (CRUD only): CRUD resources can be created without a schema and populated by sending POST requests to the resource path. Persistence depends on the account: for registered users, data is stored in the database (durable, survives server restarts) and is automatically removed after days of project inactivity; for guests, data is kept in memory (volatile) for the lifetime of the project and is lost if the server restarts.

Mimicry can import an OpenAPI or Swagger contract and convert JSON response schemas into mock endpoints with Faker-powered data. This is the fastest way to bootstrap a mock API when you already have an API definition from your backend team, a design tool, or an existing service.

Where to use it

• Homepage (guest): open the Create Mock dropdown and choose Import from OpenAPI.
• Console — new project: enable the OpenAPI toggle when creating a project.
• Console — existing project: use the project menu or empty state to import into an existing workspace.

Import workflow

1. Choose a source: upload a file, paste YAML/JSON content, or provide a public schema URL.
2. Click Preview to list every importable operation.
3. Select the endpoints you want and drag them into CRUD groups or keep them as standalone mocks.
4. Click Import — Mimicry creates the project and endpoints in one step.

Supported formats

OpenAPI 3.0.x and 3.1.x in YAML or JSON are supported, with response bodies under application/json or compatible JSON media types. Swagger 2.0 is partially accepted when it can be dereferenced and exposes response schemas.

What gets imported

• 2xx JSON response schemas are converted into Mimicry Faker schemas (standalone mocks or CRUD seed data).
• Enums become configurable enum types with all allowed values.
• Pattern constraints map to regex-based Faker helpers.
• Common formats (email, uuid, date-time, currency, phone, etc.) map to the closest Faker type.

Field type mapping and heuristics

During import, Mimicry tries to assign a Faker type that produces coherent data for each field. The mapper combines the OpenAPI type, format, and constraints with name-based heuristics on the field key. For example, a property named email or with format: email maps to an email generator; id or format: uuid to a UUID; field names containing phone, currency, country, city, zip, price, avatar, and similar tokens are matched to the closest Faker helper when no explicit format is present.

Heuristics are a best-effort shortcut — they cannot cover every domain-specific naming convention. If an imported field returns data that does not match what you expect, open the resource or mock in the Schema Editor, click the configuration icon next to the field, and adjust the assigned type and its type parameters in the dedicated modal (for example min/max, pattern, enum values, or a different Faker type). Changes apply to that field only and take effect on the next generated response.

Limitations

• Mimicry imports response body schemas, not request-only operations, parameters alone, or security definitions.
• If an operation has no importable JSON response schema, you can still create the endpoint and populate it later via POST.
• Imported schemas are subject to the same complexity limits as manually created schemas. See Schema Complexity and Limits.
• OpenAPI import does not create relationships for foreign keys inside nested objects or arrays (for example order.items[].productId). Root-level fields such as productId on a flat CRUD resource can be linked automatically when a matching resource is imported. See Nested Foreign Keys (Limitations).

Minimal example

A minimal OpenAPI fragment with an importable GET response:

openapi: 3.0.3
info:
  title: Users API
  version: 1.0.0
paths:
  /users:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  properties:
                    id:
                      type: string
                      format: uuid
                    email:
                      type: string
                      format: email
                    role:
                      type: string
                      enum: [admin, member, guest]

After import, GET /users returns Faker-generated JSON matching that shape. For the full feature overview, see the Features page.

You can associate an API key (private key) with a project. From the console, in the project / API Keys section, you can generate a key and set its status.

If the project has an API key configured and its status is active, every request to /m/{projectSlug}/... must include the header:

x-api-key: your-project-api-key

If the header is missing or the key is incorrect, the response is 401 (stable code MOCK_API_KEY_REQUIRED). The suspended status disables key usage.

Ready-to-copy snippets for frontend apps or end-to-end tests.

fetch (without API key)

const res = await fetch("https://mimicry.rest/m/my-app/users?page=1&limit=10");
const data = await res.json();

fetch (with API key)

const res = await fetch("https://mimicry.rest/m/my-app/users", {
  headers: { "x-api-key": "your-project-api-key" },
});

axios (with API key)

import axios from "axios";

const res = await axios.get("https://mimicry.rest/m/my-app/users", {
  headers: { "x-api-key": "your-project-api-key" },
});

When you create a CRUD resource you can configure:

With "Configure Schema" you define the structure and Mimicry generates data with Faker (optional seed). Without a schema you can populate it only via POST.

• GET list: GET https://mimicry.rest/m/{projectSlug}/users - returns the items (with pagination if wrapResponse is enabled)
• GET single: GET https://mimicry.rest/m/{projectSlug}/users/abc123
• POST: POST https://mimicry.rest/m/{projectSlug}/users + JSON body - creates an item (ID auto-generated if missing; if configured relationships exist, any missing foreign keys in the body will be auto-populated by associating them with existing parent entities).
• PUT: PUT https://mimicry.rest/m/{projectSlug}/users/abc123 - full replacement
• PATCH: PATCH https://mimicry.rest/m/{projectSlug}/users/abc123 - partial update
• DELETE: DELETE https://mimicry.rest/m/{projectSlug}/users/abc123 - 204 No Content

Faker schema and validation: if you configure a schema for the resource, Mimicry uses it to generate the initial seed and to regenerate sample data (reset, sync). Subsequent POST, PUT, and PATCH requests are not validated against the Faker schema shape, so records with different structures can coexist in the same CRUD resource. Mimicry still applies complexity checks (depth, fields, EGV) to every write payload (POST, PUT, PATCH) before persisting it. The only other active mechanisms are the automatic generation of the id when missing and the foreign key auto-population described above, if you have relationships configured.

Parameters: page (default 1), limit (default 10).

GET https://mimicry.rest/m/{projectSlug}/users?page=2&limit=25

With wrapResponse: true the response includes meta: { total, page, limit, totalPages }.

sort=field ascending

GET https://mimicry.rest/m/{projectSlug}/users?sort=name

sort=-field descending.

GET https://mimicry.rest/m/{projectSlug}/users?sort=-createdAt

Filters via query: ?field=value. Exact match (case-insensitive strings).

Multiple parameters = AND.

GET https://mimicry.rest/m/{projectSlug}/users?active=true&role=admin

Repeating the same parameter = OR.

GET https://mimicry.rest/m/{projectSlug}/users?status=pending&status=processing

You can define 1:N (One-to-Many) and M:N (Many-to-Many) relationships. The target resource receives a foreign key (userId or userIds). Configurable options: nullableRate; for M:N also minCount and maxCount. To apply FKs to existing data: resources with a Faker schema use "Sync data"; resources populated via POST use "Apply FK".

OpenAPI import: when you import multiple CRUD resources, Mimicry automatically creates relationships for recognizable root-level foreign keys (for example productId on /order-items pointing to an imported /products resource). Nested foreign keys are not supported yet — see Nested Foreign Keys (Limitations).

Auto-population on POST: If you create a new item via POST on a target resource and do not provide the foreign key in the payload (for example, omitting the userId field), Mimicry will search among existing parent records and randomly associate one. This guarantees mock integrity and speeds up inserts without requiring you to fetch parent IDs in advance.

Mimicry relationships work on root-level foreign keys between separate CRUD resources. This covers the common pattern where a child resource carries scalar fields such as orderId or productId at the top level of each record.

What is not supported today:

• Foreign keys inside nested objects or arrays, for example order.items[].productId embedded inside an /orders document
• _embed or automatic FK population on nested paths
• Creating a product via POST /products and having it appear automatically inside embedded order line items

This is a common REST pattern (line items embedded in an order response), but Mimicry's mock engine treats each CRUD resource as a flat document store. Nested references are planned for a future release.

Mimicry-friendly OpenAPI structure (e-commerce example)

To get linked CRUD resources from an OpenAPI import, model relationships as separate flat resources with root-level foreign keys. Import will create the CRUD groups and auto-wire relations when matching resources are present:

openapi: 3.0.3
info:
  title: E-commerce Mock (Mimicry-friendly)
  version: 1.0.0
paths:
  /products:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: array
                items: { $ref: "#/components/schemas/Product" }
    post:
      requestBody:
        content:
          application/json:
            schema: { $ref: "#/components/schemas/ProductPayload" }
      responses:
        "201":
          content:
            application/json:
              schema: { $ref: "#/components/schemas/Product" }

  /orders:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: array
                items: { $ref: "#/components/schemas/Order" }
    post:
      requestBody:
        content:
          application/json:
            schema: { $ref: "#/components/schemas/OrderPayload" }
      responses:
        "201":
          content:
            application/json:
              schema: { $ref: "#/components/schemas/Order" }

  /order-items:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: array
                items: { $ref: "#/components/schemas/OrderItem" }
    post:
      requestBody:
        content:
          application/json:
            schema: { $ref: "#/components/schemas/OrderItemPayload" }
      responses:
        "201":
          content:
            application/json:
              schema: { $ref: "#/components/schemas/OrderItem" }

components:
  schemas:
    Product:
      type: object
      properties:
        id:    { type: string, format: uuid }
        name:  { type: string }
        price: { type: number }
    ProductPayload:
      type: object
      required: [name, price]
      properties:
        name:  { type: string }
        price: { type: number }
    Order:
      type: object
      properties:
        id:          { type: string, format: uuid }
        status:      { type: string, enum: [pending, confirmed] }
        customerId:  { type: string, format: uuid }
        totalAmount: { type: number }
    OrderPayload:
      type: object
      required: [customerId]
      properties:
        customerId: { type: string, format: uuid }
    OrderItem:
      type: object
      properties:
        id:        { type: string, format: uuid }
        orderId:   { type: string, format: uuid }
        productId: { type: string, format: uuid }
        quantity:  { type: integer }
        unitPrice: { type: number }
    OrderItemPayload:
      type: object
      required: [orderId, productId, quantity]
      properties:
        orderId:   { type: string, format: uuid }
        productId: { type: string, format: uuid }
        quantity:  { type: integer }

What Mimicry creates automatically

• orders 1:N order-items via root field orderId
• products 1:N order-items via root field productId
• customerId on /orders is skipped because no /customers resource was imported

After import

You can immediately use nested routes and embedding:

GET https://mimicry.rest/m/{projectSlug}/orders/{orderId}/order-items
GET https://mimicry.rest/m/{projectSlug}/order-items?_embed=products,orders

If auto-inference misses a relation (unusual field naming or a missing parent resource), configure it manually in the console Relations panel and click "Sync data".

Use the pattern /{parentResource}/{parentId}/{childResource} to work with child resources in a relationship. It works when a relationship exists between the two CRUD resources, for example users 1:N tasks.

Concrete example with the To-Do List template: if the project contains the relationship users -> tasks, then /users/user-id-abc-def/tasksreturns only that user's tasks.

GET https://mimicry.rest/m/{projectSlug}/users/{userId}/tasks
POST https://mimicry.rest/m/{projectSlug}/users/{userId}/tasks
{ "title": "Buy milk", "completed": false }

In GET, Mimicry automatically applies the userId=u1 filter. In POST, it automatically sets userId to u1 even if you do not send it in the body.

Use the _embed parameter to include related resources in the response (the FK field is replaced by the objects).

GET https://mimicry.rest/m/{projectSlug}/users/u1?_embed=products
GET https://mimicry.rest/m{projectSlug}/products/p1?_embed=users

A simple mock has a path, method (GET, POST, etc.), and a Faker schema. The response is generated on every request. Configurable options: delayMs (latency), seed (deterministic response), statusCode. Root type can be object or array (with arrayRootTypeLength). Complexity limits (depth, EGV, response size) apply as described in the next section.

A mock can return different responses depending on the incoming request. You attach one or more conditional response rules to a simple mock or to a CRUD resource: each rule has a condition on the request and a response (status code + body) returned when that condition matches. This lets you simulate multiple states (empty result, auth error, different role) without duplicating endpoints.

On a CRUD resource a rule applies to the whole resource, on every enabled method (list, read, create, update, delete); conditions on body still match only on POST/PUT/PATCH. So GET /users?role=admin and GET /users/123?role=admin can both return a canned response when the rule matches.

How a rule is evaluated

A condition has a source, a key, an operator and an optional value:

• source: query (a query parameter), header (a request header, case-insensitive), or body (a top-level field of the JSON body, only for POST/PUT/PATCH).
• operator: eq (exact match), contains (substring), exists (present and non-null), not_exists (absent or null).

Rules are evaluated in priority order (configurable). The first rule that matches wins: its body and status code are returned and no further rule is evaluated. If no rule matches, the endpoint falls back to its default response (the Faker schema for a simple mock, the persisted data for a CRUD resource). A single mock or CRUD resource can have up to 20 conditional rules.

Interaction with Chaos Mode: chaos is evaluated before conditional responses, so on any request where Chaos triggers a failure the conditional rule is never evaluated. Disable Chaos (or send X-Mimicry-Chaos: off) when you need to read a conditional response cleanly.

Interaction with pagination, sorting and filtering

For array-root simple mocks and CRUD resources, query parameters such as page, limit, sort and field=value drive pagination, sorting and filtering of the default response. Conditional responses do not change this behavior:

• When a rule matches, the configured body is returned exactly as-is — it is not paginated, sorted or filtered, even if it is an array and the request carries page/sort/filter parameters. On a CRUD resource a matched rule also bypasses wrapResponse and the data store entirely: the canned body is returned verbatim, with no { data, meta } envelope.
• When no rule matches, the default response keeps its current behavior, so pagination, sorting and filtering work exactly as documented in the CRUD sections.
• Because a CRUD query parameter such as ?role=admin normally drives filtering, be deliberate: if you add a rule keyed on that same parameter, a matching request returns the canned response instead of the filtered list. Use header conditions if you want to avoid any overlap with filter parameters.

The response body can be inline JSON, a Faker schema, a reference to another mock in the project, or a Response Library template — the same options available in Chaos Mode.

To protect performance and stability, schemas are subject to limits at save time (EGV, number of fields, depth) and at runtime (maximum JSON response size). Limits apply to both simple mocks and CRUD resources, for both guests and registered users.

For CRUD resources, equivalent complexity checks are applied to every write operation (POST, PUT, PATCH) on the actual JSON payload before persistence.

403 errors: ENDPOINT_SCHEMA_TOO_MANY_FIELDS, ENDPOINT_SCHEMA_TOO_COMPLEX, ENDPOINT_SCHEMA_DEPTH_EXCEEDED, ENDPOINT_RESPONSE_TOO_LARGE. The table above shows the reference values; if you exceed them, you will receive a 403 error with one of the codes listed.

In case of an error, the JSON response includes a stable client code (errorCode), the category (code, for example UNAUTHORIZED) and the already translated message (error).

{
  "error": "API key required for this project",
  "errorCode": "MOCK_API_KEY_REQUIRED",
  "code": "UNAUTHORIZED"
}

Common examples (stable code in bold):

• 401 MOCK_API_KEY_REQUIRED: missing or invalid x-api-key header
• 403 ENDPOINT_SCHEMA_TOO_COMPLEX: schema exceeds allowed limits
• 404 MOCK_ENDPOINT_NOT_FOUND: path or resource not found

In addition to schema complexity limits, Mimicry applies operational quotas on the number of projects and mocks, differentiated by role.

• If a limit is exceeded, you receive an explicit error from the API or console.
• CRUD resource data is automatically deleted after a period of project inactivity.

• 401 Unauthorized: check the x-api-key header and the key status.
• 404 Not Found: check projectSlug, path, and HTTP method.
• 403 Forbidden: reduce schema complexity (fields, depth, EGV, payload).
• 405 Method Not Allowed: enable the method in the resource options.
• 503 Service Unavailable: check that the mock is not paused.

Mimicry includes a powerful Chaos Mode designed to help you test how your frontend handles network instability and server errors. Unlike static mocks, Chaos Mode introduces randomness and predictable failure patterns without changing your main mock configuration.

Simulating Random Failures

You can configure a failure rate (0-100%) and a specific HTTP status code (e.g., 500, 503, 404) to be returned randomly. You can also provide a custom response body to simulate specific error schemas used by your backend.

Random Latency and Spikes

Beyond simple delay, Chaos Mode supports:

• Fixed Latency: a constant delay added to every request.
• Range Latency: a random delay between a minimum and maximum value.
• Latency Spikes: occasional, severe slowdowns (e.g., 5 seconds) occurring at a low frequency to simulate high-load scenarios.

Granular Control

For CRUD resources, Chaos Mode can be configured per HTTP method. This allows you to simulate scenarios where, for example, reading data (GET) is stable, but creating or updating data (POST/PUT) is unreliable or slow.

You can also control Chaos Mode directly from the request that calls a mock. Header-based configuration is temporary and per-request: it does not save anything to the mock, does not change the UI configuration, and is ideal for automated tests, QA sessions, demos, or reproducing a single network scenario.

Header configuration works for both simple mocks and CRUD resources. For CRUD resources, Mimicry first resolves the effective saved configuration (method-specific config if present, otherwise resource-level config), then applies the request headers on top of it.

Header precedence

1. X-Mimicry-Chaos: off wins over everything and disables Chaos Mode for that request.
2. X-Mimicry-Chaos-Preset replaces the base chaos configuration for that request.
3. X-Mimicry-Chaos-Failure and X-Mimicry-Chaos-Latency override only the properties they specify.
4. If no chaos headers are sent, Mimicry uses the configuration saved from the UI.

Available Chaos headers

Preset reference

Random failure header

Use X-Mimicry-Chaos-Failure to configure random HTTP failures. Values are separated by semicolons.

curl "https://mimicry.rest/m/my-app/users" \
  -H 'X-Mimicry-Chaos-Failure: enabled=true;rate=100;status=429;body={"error":"rate limited"}'

Random latency header

Use X-Mimicry-Chaos-Latency to configure latency for the current request. With behavior=override, chaos latency replaces the mock base delay. With behavior=add, it is added on top of the mock base delay.

curl "https://mimicry.rest/m/my-app/users" \
  -H "X-Mimicry-Chaos-Latency: enabled=true;rate=100;mode=range;min=400;max=1800;behavior=override"

Common header combinations

# Disable persisted Chaos Mode for one request
curl "https://mimicry.rest/m/my-app/users" \
  -H "X-Mimicry-Chaos: off"

# Use a preset for one request
curl "https://mimicry.rest/m/my-app/users" \
  -H "X-Mimicry-Chaos-Preset: mobile"

# Start from a preset, then override failures
curl "https://mimicry.rest/m/my-app/users" \
  -H "X-Mimicry-Chaos-Preset: laggy" \
  -H 'X-Mimicry-Chaos-Failure: enabled=true;rate=25;status=503;body={"error":"laggy plus failures"}'

# Configure failure and latency without saving anything in the UI
curl "https://mimicry.rest/m/my-app/users" \
  -H 'X-Mimicry-Chaos-Failure: enabled=true;rate=15;status=500;body={"error":"random failure"}' \
  -H "X-Mimicry-Chaos-Latency: enabled=true;rate=100;mode=fixed;fixed=900;behavior=add"

# off wins over preset and granular overrides
curl "https://mimicry.rest/m/my-app/users" \
  -H "X-Mimicry-Chaos: off" \
  -H "X-Mimicry-Chaos-Preset: burning" \
  -H 'X-Mimicry-Chaos-Failure: enabled=true;rate=100;status=500;body={"error":"ignored"}' \
  -H "X-Mimicry-Chaos-Latency: enabled=true;rate=100;mode=fixed;fixed=5000"

Unlike endpoint-level chaos, Field Chaos acts directly on the generated Faker payloads.
Note: This feature is only available when the schema is generated via Faker. You can enable it by clicking the configuration icon next to a specific field in the Schema Editor. By setting a probability rate for each field, you can test how your frontend handles malformed or missing data.

• Null rate: The field will be returned as null.
• Omit rate: The field will be completely omitted from the JSON response.
• Invalid rate: The field will be replaced with an invalid value (e.g., returning a number instead of an email string, or a custom invalid value you provide).

The Response Library is a console page where you can save up to 20 reusable error-response templates. Each template stores a name, an HTTP error status code (4xx or 5xx), and an optional body — either a raw JSON string or a Faker-generated schema. Templates are scoped to your account and are available across all your projects.

Creating a template

1. Go to Console → Response Library and click New Template.
2. Enter a name and pick an HTTP error status code (4xx or 5xx).
3. Optionally add a body: paste a JSON object or array, or define a Faker schema to generate a realistic error payload.
4. Save — the template is immediately available in the Chaos Mode failure body selector.

Using templates (and project mocks) as Chaos failure bodies

When configuring a Random Failure in the Chaos Mode sheet, the Body field lets you choose where the injected response body comes from:

• Inline — type or paste a custom JSON string directly in the field.
• This Project — pick any standalone mock defined in the same project whose configured status code is a 4xx or 5xx. The source is project-specific: only mocks belonging to the current project appear here. Mimicry uses that endpoint's response body and suggests its status code for the failure.
• Library — pick one of your saved Response Library templates. Templates are reusable across all your projects: a template created once is available in the Chaos Mode sheet of every project in your account. Mimicry fills in the body and suggests the template's status code for the failure.

Selecting a source from This Project or Library auto-suggests the corresponding status code in the failure configuration, but you can still override it manually.

Limits

• Maximum 20 templates per account.
• Status code must be a client error (4xx) or server error (5xx).
• Templates are user-scoped — shared across all projects in your account.

Mimicry exposes a remote Model Context Protocol (MCP) server that AI clients can connect to directly. Once configured, assistants like Claude Code, Cursor, Windsurf, or Antigravity can query your projects, list endpoints, create new mocks, and read activity logs through natural language — no manual API calls required.

Prerequisites

• A registered Mimicry account.
• An MCP token with the required scopes — create one from the Integrations page.

Server URL

The MCP endpoint is available at the same origin as the mock engine, replacing the trailing /m path with /mcp:

https://mimicry.rest/mcp

The exact URL for your account is shown in the Integrations page after you create a token.

Authentication

Every MCP request must include a Bearer token in the Authorization header. Tokens are prefixed mc_pat_ and created from the Integrations page with the scopes you need:

Authorization: Bearer mc_pat_...

Tokens can have an expiry date and a set of scopes that limit which tools are available. A token with only projects:read will not see write tools even if the client requests them.

Client configuration

Copy the snippet from the Integrations page after creating a token — the MCP server URL and the token are pre-filled. Below are the formats for the most common clients.

Claude Code (CLI)

claude mcp add --transport http mimicry https://mimicry.rest/mcp \
    --header "Authorization: Bearer <MCP_SERVER_URL>"

Cursor / VS Code (JSON)

"mcpServers": {
    "mimicry": {
      "serverUrl": "https://mimicry.rest/mcp",
      "headers": {
        "Authorization": "Bearer <MCP_SERVER_URL>"
      }
    }
}

Windsurf / Antigravity (JSON)

These clients use serverUrl instead of url:

"mcpServers": {
    "mimicry": {
      "serverUrl": "https://mimicry.rest/mcp",
      "headers": {
        "Authorization": "Bearer <MCP_SERVER_URL>"
      }
    }
}

Available tools by scope

Tools not covered by the token's scopes are not registered — they will not appear in tools/list and calling them returns an error.

Notes

• The server is stateless: each request is fully self-contained. No session is maintained between calls, which means the server scales horizontally and requires no sticky sessions.
• The initialize handshake is optional — clients can call tools/call directly. Because the server is fully stateless (a fresh MCP server instance is created for every HTTP request), there is no connection state to establish: the Bearer token already carries the identity and scope information the server needs. Standard MCP clients still send the initialize /initialized lifecycle messages and that works fine, but a client that skips them and goes straight to tools/call will also get a correct response in a single round-trip.
• Responses are plain JSON (no SSE stream). Clients must still send Accept: application/json, text/event-stream per the MCP spec.
• The endpoint is rate-limited to 120 requests per minute per token.
• OAuth 2.1 (required for Claude.ai / Desktop Connectors) is not yet supported. Bearer PAT works with Claude Code CLI, Cursor, VS Code extensions, Windsurf, and Antigravity.

• Use plural names for CRUD resources: /users, /products.
• Enable only the methods you need to simulate realistic restrictions.
• Use wrapResponse: true if you need pagination metadata.
• Set a deterministic seed on Faker schemas for stable development data.
• Associate an API key with projects that expose sensitive mocks.

CRUD resource data persistence depends on the account: registered users get durable storage in the database (survives restarts, automatically deleted after a period of project inactivity), while guests get in-memory storage (volatile, lost on server restart). There is no fixed maximum number of records per resource; practical limits depend on schema or payload complexity checks and on the maximum response size.