Mockarty Web UI Guide

New to Mockarty? Start with the guided tour for your first HTTP mock, then return here when you need a particular screen.

Welcome to the Mockarty Web UI Guide. Whether you are a QA engineer creating your first mock, a developer integrating Mockarty into a CI/CD pipeline, or an architect designing multi-protocol test environments, this guide walks you through every page and feature of the web interface step by step.

This document introduces the main navigation pages, Agent Chat, API tokens, and access roles. The pages you see depend on your role and enabled features.

Key Terms

Before diving in, here are a few terms used throughout this guide:

• Mock – A simulated API endpoint that returns predefined responses instead of calling a real service. Mocks let you test your application without depending on external systems.
• Stub – In Mockarty, “stub” and “mock” are used interchangeably. Both refer to a configured endpoint that returns a controlled response.
• Condition – A rule that determines when a mock should match an incoming request. For example, “match only when the request body contains status: active.”
• Namespace – An isolated workspace that keeps mocks, stores, and test collections separate between teams or projects.
• Store – A key-value storage mechanism that lets mocks remember state across requests. Mockarty provides three store types: Global, Chain, and Mock.
• Faker – A built-in library of functions that generate realistic random data (names, emails, UUIDs, etc.) for mock responses.

Table of Contents

• Getting Started
  • Accessing the UI
  • Authentication
  • First Login and Initial Setup
• Interface Overview
  • Sidebar Navigation
  • Top Bar
  • User Menu
  • Theme Toggle
  • Language Switcher
• Dashboards
• Mocks
• Constructor
• Undefined Requests
• Stores
• Generator
• API Tester
• Test Runs
• Test Cases
• Test Plans
• Recorder
• Page Analyzer
• Security: fuzzing
• Contract Testing
• Chaos Engineering
• Utils
• Templates
• Settings
• Admin Panel
• Support Panel
• AI Features
• Agent Chat
• API Tokens
• Roles and Permissions
• Tips and Best Practices

Getting Started

Accessing the UI

After starting your Mockarty instance, open a web browser and navigate to:

http://localhost:5770/ui/

Replace localhost:5770 with your actual host and port if you have configured a custom HTTP port via the HTTP_PORT environment variable or are accessing a remote deployment. For installation and deployment instructions, see the Deployment Guide. For a full table of deployment scenarios and URL patterns, see Tips & Useful Features.

The UI works across modern desktop browsers (Chrome, Firefox, Safari, Edge). Main application pages also fit narrow phone-sized screens; complex editing is more comfortable on a tablet or desktop.

Use Tab and Shift+Tab to move between controls. Keyboard-focused buttons have
a visible outline in both the light and dark themes; press Enter or Space to
activate a focused button.

In a dialog, Tab and Shift+Tab stay within the top dialog. Escape closes that
dialog and returns focus to its opening control when it is still on the page.
Leaving a page dismisses its dialogs; a dismissed confirmation does not approve
the action, and a dismissed input dialog does not submit a value.

Authentication

Use the sign-in method shown on your instance’s login page. Your administrator chooses which methods are available.

Local Authentication

Sign in with your username or email and password. If your administrator has enabled email notifications, you can use password reset when you forget it.

If your account is locked after failed attempts, contact your administrator.

OAuth 2.0

If your administrator enabled Google, Yandex, VK, or another OAuth/OIDC provider, choose its Sign in with… button. Your first successful sign-in may create your Mockarty account automatically. Ask your administrator which provider to use if several appear.

LDAP / Active Directory

In organizations using LDAP or Active Directory, sign in with your work account. Your administrator manages directory access and role assignment.

SAML SSO

If your organization uses SAML single sign-on, Mockarty sends you to your organization’s sign-in page and returns you after authentication.

Two-Factor Authentication (2FA)

Regardless of the primary authentication method, users can enable two-factor authentication for additional security. Mockarty supports:

• Time-based One-Time Passwords (TOTP) via authenticator apps (Google Authenticator, Authy, etc.).
• Email-based one-time codes (when email notifications are enabled).

2FA can be enforced by the administrator for all users or specific roles.

First Login and Initial Setup

When you log in to Mockarty for the first time:

1. Default credentials: If using local authentication, the default administrator account is typically admin / admin. Change this password immediately after your first login.

2. Namespace selection: Mockarty organizes all resources (mocks, stores, test collections) into namespaces. After login, you will be placed into the default namespace. You can create additional namespaces from the Settings page.

3. Create your first mock: Navigate to the Constructor page to create your first mock, or use the Generator page to import mocks from an existing OpenAPI specification, WSDL file, or other supported format. See the Quick Start guide for a step-by-step walkthrough.

4. Explore the dashboard: The Dashboards page provides an overview of your Mockarty instance, including mock resolution statistics and system health metrics.

Interface Overview

The Mockarty Web UI follows a consistent layout across all pages, with a collapsible sidebar on the left, a top bar with global controls, and a main content area.

Sidebar Navigation

The sidebar groups pages by task. This table highlights common entries; your role and enabled features determine which ones you see. Page Analyzer is inside UI Testing → Page audit, and Templates is a tab in Stores.

Preview badges: Pages marked with “Preview” display a Preview badge in the sidebar. These features are fully functional but are in preview/beta state and may receive significant changes in future releases.

Feature visibility: Security, Contracts, Chaos, and other entries appear when your account has access to the corresponding feature. The Scanners tab in Security can also be available with API Tester access.

Docs link: The Docs link (/ui/docs) is located in a separate section at the very bottom of the sidebar, below the main navigation list. It provides access to the built-in documentation browser.

The sidebar can be collapsed to icons-only mode by clicking the toggle button at the bottom, giving more screen space to the main content area.

The active page is highlighted in the sidebar with a distinct accent color. The sidebar footer displays the current Mockarty version number.

Top Bar

The top bar appears on every page and contains:

• Namespace selector: A dropdown menu showing the currently active namespace. Switch between namespaces to view and manage resources scoped to each one. All mock creation, store operations, and test collections are namespace-scoped.

• Page title and Docs link: The current page title is shown in the header; pages with a guide can show a Docs link next to it when documentation links are enabled.

• Theme and account controls: Switch between light and dark themes, or open the account menu. Mockarty Desktop also shows refresh, zoom, and usage-limit controls here.

User Menu

Clicking your username or avatar in the top-right corner opens a dropdown menu with:

• Language: Switch the UI language. Mockarty ships with English and Russian translations.
• Settings: Open the user settings modal (profile, 2FA, API tokens, theme).
• API Tokens: Manage your personal API tokens for programmatic access to the Mockarty REST API. Not shown for auditor role.
• Profile: View and edit your user profile.
• Logout: End your current session.

Profile Picture (Avatar)

Every user can set a profile picture. It is shown next to your name across the product — in the header, user pickers, namespace member lists, and comment author rows — so teammates see a real person instead of just a login.

To upload an avatar:

1. Open the user menu (top-right) and choose Settings.
2. Switch to the Profile tab.
3. Click Upload avatar and pick a PNG, JPEG, or WebP file up to 5 MB.

The server automatically resizes the image to 256×256 pixels, so no cropping tool is needed. Click Remove to delete the picture — the UI falls back to your initials on a color generated from your login.

If you sign in through an OAuth provider or a corporate directory (LDAP/Active Directory), Mockarty automatically picks up the profile picture published by the provider (the OAuth picture claim or the LDAP jpegPhoto/thumbnailPhoto attribute). A picture you upload manually always takes priority and is never overwritten by the provider.

Theme Toggle

Mockarty supports two visual themes:

• Light theme: Clean, bright interface optimized for well-lit environments.
• Dark theme: Reduced brightness with dark backgrounds, optimized for low-light environments and reduced eye strain.

The theme applies to the entire UI, including the sidebar, content area, modals, and embedded code editors. Your theme choice is saved in this browser and synchronized with your Mockarty account when the server is available. An explicit theme or language choice is preserved while startup preferences are loading.

Language Switcher

The language switcher (accessible from the user menu) allows you to change the UI language. All labels, buttons, tooltips, error messages, and help text are translated. Currently supported languages:

• English (en) – default
• Russian (ru)

The language preference is saved for your Mockarty account and in this browser. Confirmed preferences can be restored in another browser when you sign in to the same account.

If you change the language again while translations are loading, the latest choice takes priority. An earlier response does not replace the newer translations.

Saving Changes Safely

Editors with an unsaved-changes warning keep that warning until their current
work is saved. Editing again after saving makes the new changes unsaved, even
when you stay on the same screen. If an editor cannot check its current state,
it keeps the protection rather than assuming your work was saved. Keep the
editor open and retry saving before closing Desktop or installing an update.

Dashboards

Path: /ui/dashboards

The Dashboards page is your home screen in Mockarty. It gives you a bird’s-eye view of how your mocks are being used: which protocols get the most traffic, how many requests matched (or missed) a mock, and overall system health. The page provides real-time analytics cards, charts, and summary tables so you can understand what is happening in your testing environment at a glance.

System Analytics Cards

At the top of the dashboard, a row of summary cards shows key metrics at a glance:

• Total Mocks: The number of active mocks in the current namespace.
• Total Requests: The cumulative number of requests resolved by mocks since the last reset.
• Active Namespaces: The number of namespaces with at least one mock.
• Active Users: The number of users who have logged in within the last 30 days.
• Undefined Requests: The number of recent requests that did not match any mock (404s).
• Store Entries: The total number of key-value entries across all stores in the namespace.

Each card shows the current value and a trend indicator (up/down arrow with percentage change compared to the previous period).

Mock Resolution Statistics Chart

A time-series chart shows mock resolution activity over the selected time range (last hour, 24 hours, 7 days, or 30 days). The chart displays:

• Resolved requests (matched a mock and returned a response).
• Unresolved requests (no matching mock found, returned 404).
• Proxy requests (forwarded to a real backend service).
• Error responses (mocks that returned error status codes by design).

You can hover over any point on the chart to see the exact count and timestamp. Click on a series in the legend to toggle its visibility.

Request Volume Trends

A bar chart or line chart (configurable) showing request volume aggregated by hour or day. This helps identify traffic patterns, peak usage times, and anomalies.

Protocol Distribution

A donut chart breaks down mock resolution by protocol type:

• HTTP / REST
• gRPC
• MCP
• GraphQL
• SOAP
• SSE
• WebSocket
• Kafka
• RabbitMQ
• SMTP

This visualization helps understand which protocols are most heavily used in your testing environment.

Top Mocks by Usage

A table listing the most frequently resolved mocks, sorted by request count. Each row shows:

• Mock name and ID.
• Protocol type.
• Route or method.
• Total request count.
• Last resolved timestamp.

Click any row to navigate to the mock detail page.

Mocks

Path: /ui/mocks

The Mocks page is the central hub for browsing, searching, filtering, and managing all mocks in the current namespace.

Browse All Mocks

The main view displays mocks in a list (or card) layout. Each mock entry shows:

• Name: The human-readable mock name.
• ID: The unique mock identifier.
• Protocol: The protocol type (HTTP, gRPC, MCP, etc.) indicated by an icon and label.
• Route / Method: The matched route pattern (e.g., /api/users/list) and HTTP method (GET, POST, etc.) or equivalent for other protocols.
• Status: Active, disabled, or expired (TTL exceeded or usage limit reached).
• Tags: Color-coded tags for categorization.
• Created / Updated: Timestamps showing when the mock was created and last modified.
• Request Count: The number of times this mock has been resolved.

Search and Filtering

The Mocks page provides powerful search and filtering capabilities:

• Text search: Type in the search box to filter mocks by ID, route, protocol address (such as a topic or bucket), or tag. Search is case-insensitive and matches partial strings.
• Protocol filter: Filter by one or more protocol types using the protocol dropdown or filter chips.
• Status filter: Show only active, disabled, or expired mocks.
• Tag filter: Filter by one or more tags. Tags can be combined with AND or OR logic.
• Sort options: Sort by name, creation date, last updated, or request count (ascending or descending).

Folder Organization

Mocks can be organized into folders for better structure:

• Create folder: Click the “New Folder” button to create a folder. Folders can be nested to any depth.
• Move mocks: Drag and drop mocks into folders, or use the context menu to move mocks between folders.
• Rename folder: Double-click a folder name or use the context menu to rename it.
• Delete folder: Deleting a folder moves its contents to the parent folder (mocks are not deleted).

Folders are namespace-scoped and visible to all users in the namespace.

Mock Workbench

Create, edit, or clone a mock without leaving the Mocks tree. Use New Mock,
Create Mock in a folder, or the edit and clone actions on a mock row. Mockarty
opens the same Constructor form in a large workspace over the tree, so the
current search, expanded folders, selection, and scroll position stay in place.

• Use Previous and Next to move through the mocks currently visible in
  the filtered tree.
• Use Test to open the Constructor’s request preview for the current form.
• Unsaved forms are stored as local drafts for that namespace and mock. Closing
  the workspace or moving to another mock asks for confirmation without
  discarding the draft.
• If another session updates the same mock while its draft is dirty, the
  workspace keeps the local draft and reports that a newer server version is
  waiting. A clean form is refreshed automatically.
• After saving, only the affected tree row is refreshed. Focus returns to the
  saved mock while the rest of the tree remains mounted.

On small screens the Workbench fills the viewport. Keyboard users can move
through its controls with Tab; Escape or the backdrop invokes the same unsaved
changes guard. Open full page remains available, and direct links such as
/ui/constructor?edit=MOCK_ID continue to work.

Mock Detail View

Click on any mock to open its detail page. The detail view shows the complete mock configuration organized into tabs:

• Config tab: Protocol-specific settings (route, method, service name, etc.), priority, TTL, usage limits, and proxy configuration.
• Conditions tab: All matching conditions (body, header, query parameter conditions with assert actions).
• Response tab: The response payload, status code, headers, and any OneOf response configurations.
• Extractors tab: Store extractors that capture data from requests into Global, Chain, or Mock stores.
• Logs tab: Recent request logs showing timestamps, request details, and matched conditions.
• History tab: Version history with diff view and rollback capability.

From the detail page you can:

• Edit: Opens the mock in the Constructor for editing.
• Clone: Creates a copy of the mock with a new ID.
• Disable / Enable: Temporarily disable the mock without deleting it.
• Delete: Soft-deletes the mock (can be restored).
• Export: Download the mock configuration as JSON.

Version History and Rollback

Every change to a mock creates a new version. The History tab shows:

• Version number and timestamp.
• The user who made the change.
• A diff view highlighting what changed between versions.
• A “Rollback” button to restore the mock to any previous version.

Rollback creates a new version (it does not delete intermediate versions), so you can always undo a rollback.

Request Logs Per Mock

The Logs tab on the mock detail page shows recent requests that were resolved by this mock:

• Timestamp and duration.
• Request method, path, headers, and body.
• Matched conditions and their evaluation results.
• The response that was returned.
• Store values that were read or written during resolution.

Logs can be filtered by time range and exported as JSON or CSV.

Batch Operations

Select multiple mocks using the checkboxes to perform batch operations:

• Delete: Soft-delete all selected mocks.
• Restore: Restore previously deleted mocks.
• Tag: Add or remove tags from all selected mocks.
• Move: Move selected mocks to a folder.
• Disable / Enable: Toggle the active status of selected mocks.

Constructor

The detailed field and protocol guide is now in Mock Constructor. For a first exercise, open the guided tour.

Undefined Requests

Path: /ui/undefined

The Undefined Requests page shows all incoming requests that did not match any mock and received a 404 response. This is invaluable for discovering missing mocks and understanding what your consumers expect.

Request List

The main view shows undefined requests in a table with:

• Timestamp: When the request was received.
• Method: The HTTP method (or protocol-specific equivalent).
• Path / Route: The requested URL path.
• Source IP: The client’s IP address.
• Headers: Key request headers (Content-Type, Authorization, etc.).
• Count: How many times this exact request pattern has been seen.

Requests are grouped by method + path to reduce noise. The count shows how frequently each pattern occurs.

Request Details

Click on any undefined request to see the full details:

• Complete request headers.
• Full request body (formatted for JSON/XML).
• Query parameters.
• Path parameters (if the URL matches a known pattern).
• Metadata (for gRPC/MCP requests).

Create Mock from Undefined Request

The most powerful feature of the Undefined Requests page: click the “Create Mock” button on any undefined request to open the Constructor pre-populated with:

• The request’s route pattern (with detected path parameters).
• The HTTP method.
• A suggested response payload based on the request structure.
• Any detected conditions from the request body.

This workflow dramatically speeds up the process of closing coverage gaps.

Ignore Requests

For requests you do not want to mock (health checks from load balancers, monitoring probes, etc.), click “Ignore” to suppress them from the list. Ignored patterns can be managed in the Settings page.

Bulk Clear

Use the “Clear All” button to remove all undefined requests from the list. This is useful after a bulk import or when you have addressed all coverage gaps. Clearing is permanent and cannot be undone.

Stores

Path: /ui/stores

Stores let your mocks remember data between requests. For example, a “create order” mock can save the new order ID, and a “get order” mock can return it later. This is what makes Mockarty capable of simulating realistic, multi-step workflows rather than just returning static responses.

The Stores page has tabs for all three types. You can manage Global and Chain entries there. The Mock Store tab is read-only and shows values configured on a selected mock, rather than a live snapshot of a request. For more examples, see Store Systems.

Global Store (gS)

The Global Store provides namespace-scoped persistent key-value storage:

• Scope: Values are shared across all mocks in the namespace.
• Persistence: Values persist until explicitly deleted or the namespace is cleaned up.
• Use cases: Counters (e.g., order sequence numbers), feature flags, shared configuration, cross-mock state.

From the UI, you can:

• View all entries: See all key-value pairs in the Global Store for the current namespace.
• Create entry: Add a new key-value pair manually.
• Edit entry: Modify the value of an existing key.
• Delete entry: Remove a key-value pair.
• Search: Filter entries by key name.

Referencing in mocks: Use $.gS.keyName in response payloads to insert the value of a Global Store key.

Chain Store (cS)

The Chain Store provides request-chain scoped state for multi-step workflows:

• Scope: Values are shared across mocks that belong to the same chain (linked by a chain ID passed in request headers or body).
• Persistence: Values persist for the duration of the chain.
• Use cases: Multi-step workflows (create order -> get order -> update order -> delete order), session state, conversation context.

The UI shows chain entries grouped by chain ID. You can inspect, edit, and delete individual entries or entire chains.

Referencing in mocks: Use $.cS.keyName in response payloads to insert the value of a Chain Store key for the current chain.

Mock Store (mS)

The Mock Store provides ephemeral per-request state:

• Scope: Values exist only during the processing of a single mock resolution.
• Persistence: Values are discarded after the response is sent.
• Use cases: Intermediate calculations, temporary variables for complex response generation.

Open Stores → Mock Store, select Choose a mock, and then Load to inspect its configured entries. This tab is read-only. Runtime values from a completed request are temporary and are not shown as a history here.

Referencing in mocks: Use $.mS.keyName in response payloads to insert values set by extractors during the current request processing.

Store Usage in Mock Responses

All three store types can be referenced in mock response payloads using the $.gS.*, $.cS.*, and $.mS.* syntax. For example:

{
  "orderId": "$.gS.lastOrderId",
  "status": "$.cS.orderStatus",
  "processedBy": "$.mS.handlerName",
  "sequenceNumber": "$.increment($.gS.orderCounter || 0)"
}

Stores can also be used in conditions to create stateful matching logic.

See also: Store Systems | JsonPath Guide

Generator

Path: /ui/generator

The Generator page allows you to bulk-create mocks by importing from various specification formats. Instead of creating mocks one by one in the Constructor, import an existing API specification to generate dozens or hundreds of mocks in seconds.

Import Source Selection

The Generator provides tabbed navigation for different import sources:

OpenAPI / Swagger

Import mocks from OpenAPI 2.0 (Swagger) or OpenAPI 3.0/3.1 specifications:

• File upload: Upload a JSON or YAML specification file from your local machine.
• URL import: Provide a URL to fetch the specification (e.g., https://api.example.com/swagger.json).
• Features: Automatically generates mocks for all defined endpoints with:
  • Route patterns with path parameters.
  • HTTP method matching.
  • Response payloads based on schema definitions (with Faker values for realistic data).
  • Status code mapping from defined responses.
  • Request body validation conditions.

WSDL

Import SOAP mocks from WSDL (Web Services Description Language) files:

• Upload a WSDL file or provide a URL.
• Generates mocks for all defined operations.
• Creates XML response templates matching the schema.
• Sets SOAPAction header conditions.

Proto (gRPC)

Import gRPC mocks from Protocol Buffer definition files:

• Upload one or more .proto files.
• Generates mocks for all defined services and methods.
• Creates JSON response payloads matching message definitions.
• Handles nested messages, enums, and repeated fields.
• Upload proto files as-is — option go_package is optional, any format is accepted, and language-specific options are stripped automatically. See the Server Generator documentation for details.

GraphQL

Import GraphQL mocks from schema definitions:

• File upload: Upload a .graphql or .gql schema file.
• URL introspection: Provide a GraphQL endpoint URL and Mockarty will run an introspection query to discover the schema.
• Generates mocks for queries and mutations.
• Creates response payloads matching type definitions.

HAR (HTTP Archive)

Import mocks from HAR files captured by browser developer tools or proxy software:

• Upload a .har file exported from Chrome DevTools, Firefox, Charles Proxy, Fiddler, or any HAR-compatible tool.
• Each recorded request/response pair becomes a mock.
• Preserves original headers, status codes, and response bodies.
• De-duplicates identical requests automatically.

MCP

Import MCP mocks from JSON configuration files:

• Upload a JSON file describing MCP tools, resources, and prompts.
• Generates mocks with input schemas and response templates.

Socket

Import WebSocket or raw socket mocks from configuration files:

• Upload a JSON configuration describing events and message formats.
• Generates event-based mocks with response payloads.

Preview Before Generation

After selecting a source and uploading/providing the specification, the Generator shows a preview of all mocks that will be created:

• HTTP method (or operation type) and route for every mock, with its status code and ID.
• Endpoints grouped by OpenAPI tag/controller (services for gRPC and SOAP, operation types for GraphQL, first path segment when the spec has no tags).
• Compact totals for endpoints and mocks at the top of the panel.

You can:

• Select/deselect individual mocks to include or exclude them from generation.
• Select/deselect a whole group with the group checkbox (partially selected groups show an indeterminate state).
• Collapse/expand groups by clicking the group header.

See also: Server Generator | API Reference

Merge Strategy

When generating mocks that may conflict with existing ones (same route and method), choose a merge strategy:

• Skip existing: Do not create mocks that would conflict with existing ones. Existing mocks remain unchanged.
• Force overwrite: Replace existing mocks with the newly generated ones. The old mocks are soft-deleted.

Namespace and Tag Assignment

Before generating, you can:

• Select namespace: Choose which namespace to create the mocks in (defaults to the current namespace).
• Assign tags: Add one or more tags to all generated mocks for easy identification (e.g., “imported”, “openapi”, “v2.1”).

API Tester

For HTML responses, the response body offers Source and HTML preview.
The preview is a static, isolated view: scripts, navigation and external resources
are disabled. Applications that require JavaScript may appear empty. Large HTML
responses remain available as source without preview. Copying the body preserves
the HTML source, not the preview’s visible text.

Response headers and gRPC metadata are displayed as a name/value table.
Copy as JSON preserves the structured data, including repeated values.

Path: /ui/api-tester

The API Tester is Mockarty’s built-in alternative to tools like Postman. You can send requests to any endpoint (your mocks or real services), organize them into collections, write automated test scripts, and switch between environments – all without leaving Mockarty.

AI Feature: Click the AI buttons to generate test scripts, create entire collections from API specs, or generate performance test scripts automatically. See AI Features for details.

Three-Panel Layout

The API Tester uses a three-panel layout:

1. Left panel (Collections sidebar): Hierarchical tree of collections and requests. Create folders within collections to organize requests logically.

2. Center panel (Request editor): Configure and send individual requests. Contains tabs for different request aspects.

3. Response panel: View the response after sending a request, including body, headers, timing, and test results.

The response panel sits on the right by default. Click the panel button in the request name bar to move it below the request — the status, time and size then share one row with the response tabs. The choice applies to every protocol (for Kafka, RabbitMQ and SMTP it moves their log console) and follows you to other browsers after you sign in. Drag the panel’s edge to resize it.

Tabs and Unsaved Work

Every request you open appears as a tab above the request editor. Switch between tabs freely: a request from a collection is saved as you leave it, and a request that is not in a collection yet keeps its edits and shows a dot on its tab until you save it. Each tab shows its own last response.

While you have not typed a name yourself, the request is named from what it does — the gRPC method, the URL path, the GraphQL operation — and Save stores it under that name. Clear the name field to hand naming back to Mockarty.

The last response stays with its request even when you switch tabs or return later without pressing Save. For a saved request, Mockarty restores your latest execution from its history; a new draft keeps a local copy in this browser. The Last response label shows when it was received. Large responses are shortened in the local copy and marked accordingly. Saving a request also stores a response example with the collection.

The compact copy button beside the response tabs copies the whole exchange — request parameters, response and script output — for a chat or bug report. Body and headers have their own copy buttons in their existing toolbar. SMTP shows Response and Console as tabs in the same panel; broker consoles use the same controls. Additional tools are grouped in the Actions menu.

Use Actions → Create checks from this response to add status and JSON structure checks to the test script. Create an exact response check also compares the captured JSON values. Structure checks suit responses with changing IDs or timestamps; exact checks suit stable fixtures. Repeat the request to run the checks, then save it to use the same script when running its collection. Your own script is preserved; using the action again updates only the generated checks.

The Faker action (dice icon) sits beside the body editor’s existing tools. For HTTP, select JSON. It is unavailable for None, XML, plain text and form bodies, and does not convert those formats to JSON. Without a contract, enter a JSON example first: generation preserves its structure and value types, including scalar values such as false, 0 and null. An empty body without a contract stays empty; malformed JSON disables the action until you correct it.

With a bound OpenAPI contract, Faker generates from the schema even if the JSON editor is empty, using valid enum values and supported array bounds. If automatic generation cannot satisfy the contract, your body is preserved and the editor explains the problem. GraphQL variables use the loaded schema and variable declarations. If an input type is unknown or includes a custom scalar whose JSON representation is unspecified, Faker uses your existing JSON example instead; it keeps an empty editor empty. MCP parameters use the selected tool’s contract. JSON payloads for Kafka, RabbitMQ, NATS and WebSocket support the same action. gRPC uses its existing example-message dice button after a method schema has been loaded.

Collections

Collections are containers for organizing related requests:

• Create: Click “New Collection” to create a new collection. Give it a descriptive name (e.g., “User Service”, “Payment Flow”).
• Rename: Double-click the collection name to edit it.
• Delete: Right-click and select “Delete”. Collections can be recovered from trash.
• Duplicate: Create a copy of an entire collection with all its requests.
• Share: Choose current members of the collection’s Space or a Space you can access. Invite a colleague to the Space or Team first: sharing a collection does not add membership or a Team Seat. Recipients open the collection while their receiving Space is selected; their current membership and role control access and editing. Removal from the Space closes old grants too. Sharing settings cannot be changed while the collection is in trash; restore it first.
• Folders: Create folders within collections to group related requests (e.g., “Auth”, “CRUD Operations”, “Error Cases”).

Requests

The API Tester supports all protocols that Mockarty can mock:

HTTP Requests

• URL: Enter the full URL or a path (relative to the environment base URL).
• Method: Select the HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS).
• Headers: Add request headers as key-value pairs. Common headers can be selected from a dropdown.
• Body: Enter the request body in JSON, XML, form-data, or raw text format. A syntax-highlighted code editor is provided.
• Auth: Configure authentication (None, Bearer Token, Basic Auth, API Key, OAuth 2.0).
• Query Params: Add query parameters as key-value pairs. Parameters can include environment variables.

gRPC Requests

• Enter the server address and click Discover (server reflection), or upload .proto files. The first service and method are selected for you, and the body is filled with an example that matches the message: repeated fields as arrays, enums with a real value.
• Click the dice button above the body to generate a new example with fake data that is valid for the message — each click gives different values and array sizes.
• While typing the body, the editor suggests the message’s field names and, inside an enum field, its allowed values (press Ctrl+Space to open the list). You can also select the enum value in the dropdown shown for the field under your cursor. A value that is not part of the enum is flagged above the editor before you send. JSON bodies imported from OpenAPI offer the same field hints and enum selection.
• Add metadata key-value pairs.
• Under Advanced, set a different target address when the request must go to another server than the one the schema came from.
• View the response as formatted JSON.

GraphQL Requests

• Enter the GraphQL endpoint URL.
• Write the query or mutation in the GraphQL editor (with syntax highlighting and auto-completion).
• Add variables as JSON.
• View the response with data and errors sections.

SOAP Requests

• Enter the SOAP endpoint URL.
• Write the SOAP envelope in the XML editor.
• Set the SOAPAction header.
• View the XML response.

WebSocket Requests

• Enter the WebSocket URL (ws:// or wss://).
• Connect to the server and send/receive messages interactively.
• View the message history with timestamps and direction indicators.

SSE Requests

• Enter the SSE endpoint URL.
• Connect and view incoming events in real time.
• Events are displayed with their type, data, and ID.

Kafka Requests

• Configure broker address and topic.
• Publish messages with key, value, and headers.
• Consume messages from a topic with offset control.
• View consumed messages in a scrollable list.

RabbitMQ Requests

• Configure connection URL, exchange, and routing key.
• Publish messages with headers and properties.
• Consume messages from a queue.
• View consumed messages with metadata.

MCP Requests

• Enter the MCP server URL.
• A URL containing user info, a query string, or a fragment works for the current connection but is not saved for later sessions. Enter it again after reopening Mockarty.
• Select the tool name and provide input parameters.
• View the tool response.

For API Tester connection failures (HTTP, SOAP, GraphQL, SSE, WebSocket, and MCP), the error shows a safe reason such as DNS lookup failure, timeout, or connection refusal. It does not repeat the complete target URL, which may contain a token.

Loading a Service Schema

You can use {{service_url}} in the gRPC reflection address, SOAP WSDL URL,
GraphQL endpoint, or the URL used to import an OpenAPI/WSDL specification or
gRPC services. Select the environment first. Imported Bruno request variables
take precedence over environment variables, which take precedence over collection
variables. An unresolved variable must be corrected before discovery or import.

When you change the schema source or environment, discover the methods again.
If discovery fails or finds no methods, the previous service’s choices are
cleared instead of being presented as results for the new service. Your edited
body, query, variable template and explicitly chosen execution target are kept.
Changing selection while loading prevents the old reply from selecting a
different collection. An import already completed on the server remains saved.

Environment Variables

Environments allow you to define variable sets that can be substituted into requests:

• Create environments: Define environments like “Local”, “Staging”, “Production” with different variable values.
• Variable syntax: Use {{variableName}} in URLs, headers, body, and query parameters. Variables are replaced with the active environment’s values at send time.
• Common variables: {{baseUrl}}, {{apiKey}}, {{authToken}}, {{userId}}.
• Secret variables: Values whose key looks like a secret (token, password, api_key, …) are masked in the editor; use the eye button to reveal them.
• Secret store references: A value can reference the namespace secret store: {{secret:storeName/keyName}}. The reference is resolved on the server at send time and the plaintext never appears in the UI. Secret references work only with server-side execution — client-side (browser) execution rejects them with a clear error.
• Active environment: Select the active environment from a dropdown in the top bar of the API Tester. Only one environment is active at a time (per user).
• Shared environments: Tick Share with namespace in the environment editor to make an environment visible to every member of the namespace. Teammates can view and activate a shared environment, but only the owner can edit, delete, or unshare it. Each user’s active-environment choice is independent — activating a shared environment never changes anyone else’s selection.

Where a Request Runs

Every request is sent either by the Mockarty server (the default) or directly by your browser. The dot next to the Send button shows which, before you click.

• Server-side — the server makes the request. Secret-store references, private networks the server can reach and every protocol work here.
• Client-side (browser) — used automatically when Mockarty is opened from another machine and the request targets localhost or a private address: the server cannot reach your machine, so the browser sends the request itself. Works for HTTP, SOAP, GraphQL, MCP, SSE and WebSocket. Your local service must answer with CORS headers, and secret-store references are refused because the plaintext would have to reach the browser.
• gRPC always runs server-side.

If the server is on the same machine as your local service, set ALLOW_PROXY_TO_PRIVATE_IPS=true on the server to let it reach localhost directly.
The same server-side network policy applies to mk.http.send in API Tester scripts and Tests collections. If an assertion sees status 0 with an empty response, check the step log for a blocked target or connection error before changing the assertion.

Pre-Request Scripts

Pre-request scripts execute before a request is sent, allowing you to:

• Dynamically set headers, query parameters, or body values.
• Generate authentication tokens or signatures.
• Set environment or collection variables programmatically.
• Chain requests by using data from previous responses.

Scripts use a JavaScript-like syntax with a built-in API for accessing request properties and environment variables.

Test Scripts

Test scripts execute after a response is received, allowing you to write assertions:

• Status code assertions: Verify the response status code.
• Body assertions: Check specific fields in the response body using JsonPath.
• Header assertions: Verify response headers.
• Timing assertions: Assert that the response time is within acceptable bounds.
• Variable extraction: Save response values to environment or collection variables for use in subsequent requests.

Test results are displayed in the response panel with pass/fail indicators and error details.

To run collections under load, open Run Tests, select the collections or individual requests, and choose Performance. Set the number of virtual users, duration and target requests per second (RPS); 0 RPS uses the virtual-user load without a fixed request rate. Choose the runner and environments for this run. When several environments contain the same variable, choose its value in the conflict dialog. Keep Create public test run selected to save the result in Test Runs history; clear it for a debug run without a saved history entry.

This collection mode generates load from HTTP, GraphQL and SOAP requests. For requests with enabled pre-request/test scripts, collection scripts, multipart or binary bodies, use a dedicated load script. An unhandled script exception marks the load run as failed; HTTP metrics reflect only actual requests.

Request History

The API Tester maintains a history of all sent requests:

• View previous requests with their responses.
• Re-send a historical request with one click.
• Compare responses across multiple executions.
• History is scoped to the current user and namespace.

Import

The API Tester supports importing from multiple formats:

• Postman: Import Postman collections (v2.0 and v2.1 JSON format) with requests, folders, environments, and pre-request/test scripts.
• SoapUI: Import SoapUI projects with SOAP and REST requests.
• OpenAPI: Import an OpenAPI specification to generate a collection with one request per endpoint.
• WSDL: Import a WSDL file to generate SOAP requests.
• gRPC: Import .proto files to generate gRPC requests.
• GraphQL: Import a GraphQL schema or introspect an endpoint.
• MCP: Import an MCP configuration file.
• HAR: Import a HAR file to recreate captured requests.
• JMeter: Import an Apache JMeter test plan (.jmx). Every HTTP sampler becomes an editable request; JSON/Regex/Boundary extractors and Response/Duration assertions become the request’s test script; ${var} references become {{var}} environment variables; User Defined Variables can be imported as a new environment; thread groups map to separate collections. Constructs that can’t be mapped (CSV Data Set, Cookie Manager, ${__function} calls) are listed as import notes.
• Mockarty format: Import collections exported from another Mockarty instance.

Native Mockarty collection JSON files can be up to 50 MiB. A larger file is rejected before import; split a large collection and import its parts separately.

If a request or folder cannot be saved, the import shows a partial result with the number saved and the number that failed. Items inside a failed folder are skipped to preserve their location. The successfully imported items remain in the new collection. Review that collection before retrying to avoid duplicates. SoapUI and JMeter imports return saved collections and requests together with a summary and a list of failed elements. An HTTP 200 response may still describe a partial import: check summary.failedCount and failures before running the imported tests. If the UI cannot verify the response, inspect your collections before manually trying again.

File and server imports accept one pending submission per format. A file read failure shows an error and sends no import request. Closing the form, changing its source, switching namespace, or leaving the page retires its UI result. An import already sent to the server can still finish; check your collections before submitting it again. Requests are not automatically repeated.

Export Collections

Export collections in Mockarty’s native JSON format for backup, sharing, or migration between environments.

Generate Mocks from Responses

After receiving a response in the API Tester, click “Create Mock” to generate a mock based on:

• The request’s route, method, and headers.
• The received response’s status code, headers, and body.
• Detected path parameters and query parameters.

This is useful when recording real API behavior and converting it to mocks.

Test Runs

Path: /ui/test-runs

The Test Runs page shows the results of all test executions, including collection runs, scheduled test runs, and performance tests.

AI Feature: Click the Analyze Report button on any test run to get AI-powered diagnostics of failures and performance issues. See AI Features for details.

Test Execution List

The main view displays all test runs in a table:

• Run ID: Unique identifier for the test run.
• Collection: The collection that was tested.
• Type: Collection run, scheduled run, or performance test.
• Status: Running, completed, failed, or cancelled.
• Started / Finished: Timestamps for the test run.
• Duration: Total execution time.
• Pass / Fail: Number of passed and failed assertions.
• Triggered by: The user or schedule that initiated the run.

Filter test runs by status, type, collection, or date range.

Test Report Detail

Click on any test run to see the detailed report:

• Summary: Overall pass/fail count, execution time, and status.
• Request-by-request results: Each request in the collection with:
  • Request details (method, URL, body).
  • Response details (status code, body, headers).
  • Assertion results (passed/failed with expected vs. actual values).
  • Execution time.
• Error details: For failed assertions, detailed error messages explaining what went wrong.
• Timeline view: Visual timeline showing request execution order and timing.

APDEX Scoring

For performance test runs (see Performance Testing), the report includes an APDEX (Application Performance Index) score:

• Score: A value between 0 and 1, where 1 is perfect satisfaction.
• Rating: Excellent (> 0.94), Good (> 0.85), Fair (> 0.70), Poor (> 0.50), Unacceptable (<= 0.50).
• Breakdown: Counts of satisfied, tolerating, and frustrated responses based on the configured threshold.
• Threshold (T): The target response time in milliseconds. Responses under T are “satisfied”, under 4T are “tolerating”, and above 4T are “frustrated”.

Latency Statistics

Performance test reports include detailed latency statistics:

• Mean: Average response time across all requests.
• Median (p50): The 50th percentile response time.
• p95: 95th percentile (95% of requests were faster than this).
• p99: 99th percentile (99% of requests were faster than this).
• Min / Max: Fastest and slowest response times.
• Standard Deviation (StdDev): Measure of response time variability.
• Coefficient of Variation (CV): StdDev as a percentage of the mean, indicating consistency.

Export Reports

Export test reports in JSON format:

• JSON: Machine-readable format for CI/CD integration and sharing with stakeholders.
  For API Tester Tests collections, the export includes each assertion and its skipped result; importing the report preserves them.

You can import a native Mockarty JSON report up to 50 MiB. Larger reports are rejected without creating a run.
If import capacity is busy, wait for the response’s Retry-After interval and retry the report.

Cancel Running Tests

For long-running tests, click the “Cancel” button to stop execution. Partial results are preserved and can be viewed in the report.

Test Cases

Path: /ui/test-cases

The Test Cases page is Mockarty’s built-in Test Management System (TMS). It lets you organise manual and automated test cases into a folder hierarchy, track their execution, and integrate with your team’s workflow.

Key capabilities

• Folder tree (up to 8 levels deep) — mirror your project or module structure. Drag to reorder, right-click for a context menu. Multi-select with Ctrl+Click for bulk operations.
• Case builder — write steps with Action + Expected Result, attach files, set dependencies between steps, pick execution mode (auto / manual / semi-automatic).
• Shared steps — reusable step fragments you can embed by reference across multiple cases. Changes propagate automatically.
• Version history — every save creates a versioned snapshot. Compare any two versions and roll back to any previous state.
• Review workflow — submit a case for review, leave comments, approve or reject. The review panel shows history and who acted.
• External tracker links — link cases to Jira, GitHub, Linear, or GitLab issues. Linked issue titles and statuses appear as live chips.

Running test cases

Test cases can be executed:

• One-off — from the builder via the Run button.
• As part of a Test Plan — add the test_case item type to a plan.
• Batched (synthetic plan) — select multiple cases and trigger a batch run.

Results feed into the same unified Test Run report as every other test type.

Full reference: Test Case Management · Test Case Steps · Runtime Flow View · Attachments

Test Plans

Path: /ui/test-plans

Test Plans orchestrate any combination of test types — functional (API Tester), load (k6), fuzz, chaos, and contract — into a single, repeatable workflow. Each plan gets a stable numeric ID (#42) so CI/CD pipelines can reference it by name or number.

What a plan contains

• Items — the individual test steps. Each item points to a resource (an API Tester collection, a load-test config, a fuzz config, etc.) and has an order and optional dependencies.
• Execution mode — fifo (sequential, default), parallel (all items at once), or dag (respects dependsOn and Gates).
• Gates — conditions that block the next item if the previous one fails (e.g., stop the load test if the smoke test failed).
• Schedules — attach one or more cron / one-shot / interval schedules to run the plan automatically.
• Override surfaces — per-run variable overrides and item subsets for targeted reruns.

Running a plan

Click Run in the plan detail view, or trigger via CLI (mockarty-cli testplan run) or API (POST /api/v1/test-plans/:id/run). The Run View shows live progress with per-item status and a unified log stream. The final report consolidates all item results into a single Allure-compatible export.

Full reference: Test Plans · Advanced Test Plans · Test Plans in CI/CD · Run View · Plan Report

Recorder

Path: /ui/recorder

The Recorder lets you capture real network traffic between your application and its backend services. Once captured, you can inspect every request and response, replay them, or convert them directly into mocks with a single click. It is the fastest way to create mocks that accurately reflect how a real service behaves.

AI Feature: Click the Analyze Traffic button on recorded sessions for AI-powered traffic analysis, security audit, or scenario discovery. See AI Features for details.

Session Management

Recording is organized into sessions:

• Start: Click “Start Recording” to begin a new session. Configure the recording mode and port.
• Stop: Click “Stop” to end the current recording session. Captured entries are preserved.
• Restart: Stop and immediately start a new session with the same configuration.
• Delete: Remove a session and all its captured entries.

Multiple sessions can exist simultaneously, but only one session per port can be actively recording.

Recording Modes

Reverse Proxy Mode

Mockarty acts as a reverse proxy in front of a target service:

• Configure the target URL (the real backend service).
• All requests sent to the recorder’s port are forwarded to the target.
• Both the request and response are captured.
• The target’s response is returned to the client unmodified (unless header modification rules are configured).

Forward Proxy Mode

Mockarty acts as an HTTP(S) forward proxy:

• Configure your client (browser, application, or test suite) to use Mockarty as its HTTP proxy.
• All HTTP traffic is captured as it passes through.
• For HTTPS traffic, Mockarty performs MITM (Man-in-the-Middle) interception using a generated certificate.

Captured Traffic Types

The Recorder captures:

• HTTP requests/responses: Method, URL, headers, body, status code, timing.
• WebSocket messages: Connection upgrade, individual messages (both directions), connection close.
• SSE events: Event type, data, ID, and retry values.

Entry List

Captured entries are displayed in a list with:

• Timestamp: When the entry was captured.
• Method: HTTP method or protocol indicator.
• URL: The full request URL.
• Status: Response status code (color-coded: green for 2xx, yellow for 3xx, red for 4xx/5xx).
• Duration: Response time in milliseconds.
• Size: Response body size.

Entries can be filtered by method, status code range, URL pattern, and content type.

Entry Detail

Click on any entry to see the full details:

• Request tab: Method, URL, headers (formatted table), query parameters, and body (syntax-highlighted).
• Response tab: Status code, headers, and body (syntax-highlighted for JSON/XML/HTML).
• Timing tab: DNS lookup, TCP connection, TLS handshake, time to first byte, and total duration.

Header/Metadata Modification Rules

Configure rules to modify headers as traffic passes through the recorder:

• Add header: Inject a new header into requests or responses.
• Remove header: Strip a header from requests or responses.
• Replace header: Change a header’s value using string replacement or regex.

Rules are applied in order and can target requests, responses, or both.

MITM Certificate Management

For HTTPS recording in forward proxy mode:

• Generate CA certificate: Mockarty generates a root CA certificate for MITM interception.
• Download CA certificate: Download the certificate to install in your browser or system trust store.
• Certificate status: View the current certificate’s validity period and fingerprint.

Port Pool Configuration

Configure the range of ports available for recorder sessions. Each session requires a dedicated port for proxying traffic.

Export Options

Captured traffic can be exported in multiple formats:

• HAR file: Standard HTTP Archive format compatible with browser dev tools, Charles Proxy, and other tools.
• Performance test script: Generate a performance test script from captured traffic for load testing.
• Test script with assertions: Generate API Tester test scripts with assertions based on the captured responses.
• API Tester collection: Create an API Tester collection with one request per captured entry.

Create Mocks from Entries

Select one or more captured entries and click “Create Mocks” to generate mocks based on:

• The captured request’s route, method, and headers.
• The captured response’s status code, headers, and body.
• Automatically detected path parameters.

This is the fastest way to create realistic mocks based on actual service behavior.

See also: Traffic Recorder

Live Updates

During an active recording session, new entries appear in the list in real time via WebSocket updates. No page refresh is needed. A live indicator shows the recording status and entry count.

Page Analyzer

Path: /ui/ui-testing?tab=page-audit (the Page audit tab of UI Testing; the old /ui/page-analyzer address redirects here)

Page Analyzer measures ONE page over plain HTTP and scores it out of 100. It does not open a browser, so it needs no runner and answers in seconds – and it is the surface that reports the page’s security and cache headers.

Analyzing a page

1. Open UI Testing → Page audit. The older /ui/page-analyzer bookmark redirects to this tab.
2. Enter the absolute URL of the page (https://example.com/checkout).
3. Adjust the options if you need to:
   • Timeout, s – how long to wait for the response (default 30, maximum 300).
   • Max resources – how many referenced scripts, styles and images to fetch and measure (default 100, maximum 500).
   • Measure referenced resources – turn off for a headers-and-timings-only pass.
   • Follow redirects – follow to the final page instead of measuring the redirect itself.
4. Press Analyze. The analysis runs in the background; the row appears in Analyses straight away and updates when it finishes.
5. Click a row to open its breakdown.

What the breakdown shows

Saved configurations

Save as config stores the current URL and options so you can re-run the same check later – press Load on a saved row to put it back in the form. Delete removes it.

Authentication values supplied through the API in authConfig are write-only: config responses keep the existing authConfig key but return an empty object. When updating a config, omit authConfig to keep the saved values, send an empty object to clear them, or send complete new values to replace them. If MOCKARTY_PII_ENCRYPTION_KEY is configured, fresh authentication values are encrypted at rest; without that opt-in key they remain readable in the database. Enable the existing key before saving credentials in a configuration. See Admin setup.

Do not put credentials or signed tokens in the target URL. Use authConfig instead. Analysis results, resource evidence, AI prompts, and config API responses keep only a secret-free URL projection without user-info, query values or fragments. Mockarty keeps the exact saved URL only for execution: with MOCKARTY_PII_ENCRYPTION_KEY, URLs with query values or fragments are stored in the existing encrypted envelope; without that key, saving or replacing such a URL is rejected instead of writing those values in plaintext. Existing query-free URLs remain byte-compatible. On update, omit targetUrl to preserve the exact stored execution URL.

API, CLI and SDK examples

Every client below starts the same POST /api/v1/page-analyzer/run operation. Config responses always contain authConfig: {} and only the secret-free targetUrl projection. The lifecycle also includes config list/save/update/delete and result list/get/delete/AI-analyze through the same client surfaces.

cURL:

curl -sS -X POST "http://localhost:5770/api/v1/page-analyzer/run" \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"targetUrl":"https://example.com","options":{"checkResources":true,"followRedirects":true}}'

CLI (put the JSON body from the cURL example in page-analysis.json):

mockarty-cli page-analyzer run --file page-analysis.json
mockarty-cli page-analyzer results get RESULT_ID
mockarty-cli page-analyzer configs list

Go:

run, err := client.PageAnalyzer().Run(ctx, mockarty.PageAnalyzerRunRequest{
    TargetURL: "https://example.com",
    Options: &mockarty.PageAnalyzerOptions{CheckResources: true, FollowRedirects: true},
})

Python:

run = client.page_analyzer.run({
    "targetUrl": "https://example.com",
    "options": {"checkResources": True, "followRedirects": True},
})

Java:

Map<String, Object> run = client.pageAnalyzer().run(Map.of(
    "targetUrl", "https://example.com",
    "options", Map.of("checkResources", true, "followRedirects", true)
));

All three SDKs expose all nine registered Page Analyzer operations. A run returns resultId; read that result until its status becomes completed or failed.

Page Analyzer or UI Testing?

Both measure a page, and they answer different questions:

• Page Analyzer works over HTTP. Use it for headers, response timings and page weight, and when no browser runner is available.
• UI Testing drives a real browser. Use it when you need what a browser sees – rendering, Web Vitals, or a page that only assembles itself after JavaScript runs.

Security (Fuzzing)

Path: Security → Scanners (/ui/security). The older /ui/fuzzing URL still opens the fuzzing view.

Fuzzing is an automated security testing technique. Instead of manually trying edge cases, Mockarty sends thousands of crafted or random inputs to your API endpoints and watches for unexpected behavior – crashes, error leaks, or security vulnerabilities. It is a quick way to find bugs that normal testing often misses.

AI Feature: Click the Analyze Finding button on any fuzzing finding for AI-powered root cause analysis and remediation suggestions. See AI Features for details.

Fuzzing Configurations

Create and manage fuzz test configurations:

• Target URL: The endpoint to fuzz.
• Method: The HTTP method (or protocol type for non-HTTP targets).
• Payload Positions: Mark positions in the request (URL, headers, body) where fuzz payloads will be injected. Positions are marked with placeholder syntax.
• Base request: The template request that fuzzing payloads will be injected into.
• Authentication: Configure authentication for the target (Bearer token, Basic Auth, API Key, etc.).
• Rate limiting: Control the request rate to avoid overwhelming the target.
• Timeout: Maximum response time before considering a request as timed out.

Payload Categories

Mockarty includes built-in payload dictionaries for common vulnerability categories:

• SQL Injection: SQL syntax fragments, UNION-based payloads, blind SQL injection patterns, time-based payloads.
• XSS (Cross-Site Scripting): Script tags, event handlers, encoded payloads, polyglot XSS strings.
• Buffer Overflow: Long strings, repeated characters, format string specifiers.
• Path Traversal: Directory traversal sequences (../, ..%2f), absolute paths, null byte injections.
• Command Injection: Shell metacharacters, command separators, backtick execution, pipe chains.
• Format Strings: Printf-style format specifiers, width/precision attacks.
• Header Injection: CRLF injection, header smuggling payloads.
• XXE (XML External Entity): Entity declarations, external references, parameter entities.
• SSRF (Server-Side Request Forgery): Internal IP addresses, cloud metadata URLs, DNS rebinding payloads.
• Authentication Bypass: Default credentials, JWT manipulation, session fixation tokens.

Custom payload lists can also be uploaded or created manually.

Import Targets

Quickly set up fuzzing targets by importing from existing sources:

• cURL commands: Paste a cURL command to extract the URL, method, headers, and body.
• OpenAPI specification: Import an API spec and select endpoints to fuzz.
• API Tester collections: Select requests from your API Tester collections as fuzzing targets.
• Recorder sessions: Use captured traffic as the basis for fuzzing.
• Existing mocks: Select mocks and fuzz their endpoints.

Protocol-Specific Discovery

• GraphQL introspection: Automatically discover queries, mutations, and types by running an introspection query against a GraphQL endpoint.
• gRPC reflection: Discover services and methods using gRPC server reflection.

Running Fuzz Tests

Start a fuzz test from a configuration:

• Progress monitoring: A real-time progress bar shows completion percentage, requests sent, and elapsed time.
• Live statistics: View the current request rate, response code distribution, and error count as the test runs.
• Stop: Stop the running fuzz test and preserve partial results.

Findings

After a fuzz test completes (or during execution), findings are listed with:

• Severity: Critical, High, Medium, Low, or Informational.
• Category: The type of vulnerability detected (SQL Injection, XSS, etc.).
• Payload: The exact payload that triggered the finding.
• Response: The response status code and body excerpt.
• Evidence: Specific patterns in the response that indicate a potential vulnerability (error messages, stack traces, reflected input).

Triage Findings

Review and classify each finding:

• Confirmed: Mark as a real vulnerability that needs to be addressed.
• False Positive: Mark as a false alarm (the behavior is expected or benign).
• Ignored: Dismiss the finding without classification.

Triage status is preserved across sessions and can be exported with the findings report.

Replay Findings

Click “Replay” on any finding to re-send the exact request that triggered it. This is useful for:

• Verifying the finding is reproducible.
• Testing after a fix has been applied.
• Investigating the behavior in more detail.

Export Findings Report

Export all findings (or filtered subsets) as:

• JSON: Machine-readable format for integration with security tools and CI/CD pipelines.
• CSV: Spreadsheet-compatible format for tracking and reporting.

Scheduled Fuzz Runs

Configure fuzzing to run on a schedule (daily, weekly, or custom cron expression). Scheduled runs:

• Execute automatically at the configured time.
• Send notification on completion (when email notifications are enabled).
• Results are available in the Fuzzing page and Test Runs page.
• Compare findings across runs to track security posture over time.

Quick Fuzz Mode

For rapid testing without detailed configuration:

• Enter a target URL and select payload categories.
• Mockarty automatically detects parameters and injection points.
• Results are available within minutes for a quick security assessment.

See also: API Fuzzing

Contract Testing

Path: /ui/contract-testing

Feature gate: This feature is hidden by default and shown when the contract-testing license feature is enabled.

Contract Testing validates that your mocks stay in sync with real API specifications, manages consumer contracts, and provides bidirectional deployment safety checks. Supports all protocols: OpenAPI, gRPC, GraphQL, MCP, AsyncAPI, WSDL.

Tabs

The Contract Testing page is organized into 6 tabs:

1. Validate Mocks

Upload or reference an API specification and validate that your existing mocks conform to it. Supports all spec types (OpenAPI, gRPC proto, GraphQL SDL, MCP JSON, AsyncAPI, WSDL). Select mocks by tags or browse folders. AI analysis available for findings.

2. Can I Deploy?

Bidirectional deployment readiness check with two perspectives:

• As Consumer: Select your consumer contract and verify all provider dependencies are still compatible. Answers: “will my dependencies break me?”
• As Provider: Select your API from the registry and optionally paste a new spec. Answers: “will my changes break consumers?” Useful for pre-deploy impact analysis.

3. Compatibility

Compare two versions of an API specification to detect breaking changes. Two modes:

• Paste: Paste old and new specs side-by-side.
• From Registry: Select an API from the registry and compare two versions from its version history.

Supports all spec types. Shows structural diff with added/removed/changed items and breaking change indicators.

4. Contracts

Manage consumer contracts in two formats:

• Mockarty Contracts (Dependency Bundles): Create via a 4-step visual wizard — select providers from registry, pick endpoints, configure required fields, review and save. One contract can cover multiple provider APIs.
• Pact v3: Standard Pact Broker compatible format for teams using pact-js, pact-jvm, pact-python. Publish via visual builder or raw JSON.

Both formats participate in the unified Can-I-Deploy matrix and health dashboard.

5. API Registry

Internal API marketplace where teams publish their API specifications. Features:

• Publish APIs with visibility control (public, internal, restricted).
• Protocol-specific UX — placeholders and hints adapt to the selected spec type.
• Auto-refresh for URL-based entries — Mockarty periodically fetches updated specs (configurable interval).
• Version history with diff visualization and rollback.
• Review workflow (draft → pending review → active/deprecated).
• Subscribe to API changes and get notified on breaking changes.

6. History & Health

• History: Timeline of all validation runs with expandable results, trend chart (60-day compliance).
• Health Dashboard: Traffic-light status (green/yellow/red) for each contract. Shows overall namespace health. Monitors provider availability and spec changes.
• Scheduled Monitors: Configure cron-based validation runs with notifications.

Consumer Contract Wizard

The wizard guides you through creating a contract in 4 steps:

1. Select Providers — search and pick APIs from the registry (any protocol).
2. Select Endpoints — browse parsed endpoints, check the ones your service depends on.
3. Configure Requirements — mark required response fields, expected status codes, type constraints. Fields from the spec are pre-populated.
4. Review & Save — name your contract, review the summary, save.

AI Features

• AI Analyze: Get LLM-powered analysis of validation findings with fix suggestions (rendered as markdown).
• Auto-Triage: Automatically classify findings by severity and priority.
• Available on all result panels (validation, drift detection, pact verification).

See also: Contract Testing Guide

Chaos Engineering

Path: /ui/chaos

Feature gate: This feature is hidden by default and shown when the chaos license feature is enabled. Requires a connected Kubernetes cluster.

Chaos Engineering lets you test system resilience by injecting controlled faults into your Kubernetes infrastructure. Instead of waiting for outages to discover weaknesses, you proactively run experiments that kill pods, inject network latency, disrupt DNS, or stress resources – and observe whether your system recovers gracefully.

Cluster Topology

The first tab shows a live visualization of your Kubernetes cluster using an interactive graph (powered by Cytoscape.js):

• Namespaces, Deployments, Pods: Displayed as nodes in a directed graph with automatic layout.
• Health indicators: Nodes are color-coded by health status (green = healthy, yellow = degraded, red = failing).
• Selection: Click any node to see its details (labels, resource usage, events) in a side panel.
• Zoom and pan: Use mouse wheel or on-screen controls to navigate large clusters.
• Refresh: Topology updates on demand or at a configurable interval.

Experiment Types

Mockarty supports these 12 fault types:

Creating an Experiment

To create a new chaos experiment:

1. Select fault type: Choose from the 12 supported fault types.
2. Define targets: Select target pods by namespace, label selector, or specific pod names. Set a blast radius limit (e.g., affect at most 50% of matching pods).
3. Configure parameters: Each fault type has specific parameters (e.g., latency duration in milliseconds, packet loss percentage, CPU cores to stress).
4. Set duration: How long the fault should be active before automatic rollback.
5. Add steady-state probes: Define health checks that validate your system during and after the experiment (HTTP endpoint probes, Prometheus metric queries, pod count assertions).
6. Safety guardrails: Configure namespace deny lists, maximum blast radius, and auto-rollback conditions.

Running Experiments

Start an experiment and monitor it in real time:

• Progress timeline: Visual timeline showing injection start, steady-state checks, and rollback.
• Live probe results: Steady-state probes run continuously and display pass/fail status as the experiment progresses.
• Emergency stop: A prominent red button immediately rolls back all active faults if something goes wrong.
• Auto-rollback: Experiments automatically rollback when duration expires or when a steady-state probe fails (configurable).

Experiment Results

After an experiment completes, the results include:

• Verdict: Pass (system remained healthy) or Fail (steady-state probes detected degradation).
• Timeline: Complete event log with timestamps for injection, probe checks, and rollback.
• Probe details: Each probe’s results with expected vs. actual values.
• Affected resources: List of pods/containers that were targeted.
• Recovery time: How long the system took to return to steady state after rollback.

Presets

Mockarty includes pre-built experiment presets for common scenarios:

• Chaos Monkey: Random pod kill in selected namespace.
• Network Partition: Isolate a service from its dependencies.
• Scale to Zero: Kill all pods of a deployment and measure recovery.
• Slow Network: Inject increasing latency to find timeout thresholds.
• Resource Starvation: Stress CPU and memory to test autoscaling.

Presets can be customized before running and saved as new templates.

Scheduling

Configure experiments to run on a recurring schedule:

• Cron expressions: Standard cron syntax for flexible scheduling.
• Notifications: Receive alerts via configured notification channels when experiments complete.
• Trend analysis: Compare results across scheduled runs to track resilience improvements.

Reports

Export experiment results in multiple formats:

• JSON: Machine-readable format for CI/CD integration.
• HTML: Human-readable report with charts and timeline visualization.
• JUnit XML: Compatible with CI/CD test result parsers (Jenkins, GitLab CI, etc.).

See also: Chaos Engineering Guide

Utils

Path: /ui/utils

The Utils page provides a collection of developer utilities for common data format conversions and generation tasks. These tools run entirely in the browser and do not send data to the server.

JSON Formatter and Validator

• Paste or type JSON in the input area.
• Click “Format” to pretty-print the JSON with proper indentation.
• Click “Minify” to compress the JSON to a single line.
• Validation errors are highlighted with line numbers and error descriptions.
• Copy the formatted output to clipboard with one click.

UUID Generator

• Generate random UUID v4 values.
• Generate multiple UUIDs at once (configurable count).
• Copy individual UUIDs or the entire list to clipboard.

Base64 Encoder/Decoder

• Encode: Paste plain text and encode it to Base64.
• Decode: Paste a Base64 string and decode it to plain text.
• Supports standard and URL-safe Base64 variants.
• Handles multi-line input.

URL Encoder/Decoder

• Encode: Encode special characters in a URL or URL component.
• Decode: Decode percent-encoded characters back to their original form.
• Encode/decode the full URL or individual components.

JWT Decoder

• Paste a JWT (JSON Web Token) to decode its header, payload, and signature.
• The header and payload are displayed as formatted JSON.
• Expiration time is shown in human-readable format with an indication of whether the token has expired.
• Signature verification is not performed (the decoder does not validate signatures).

Timestamp Converter

• Convert between Unix timestamps (seconds and milliseconds) and human-readable date/time formats.
• Display the current timestamp with a live-updating counter.
• Support for multiple date/time formats (ISO 8601, RFC 2822, custom).
• Timezone-aware conversion with timezone selector.

Hash Generators

Generate cryptographic hashes from input text:

• MD5: 128-bit hash (not recommended for security, useful for checksums).
• SHA-1: 160-bit hash.
• SHA-256: 256-bit hash (recommended for general use).

Input can be pasted or typed. The hash is computed in real time as you type.

Templates

Path: /ui/stores?tab=templates-store (formerly /ui/templates — the old URL still redirects here).

Templates are response-body files that mocks reference by name. They live as a tab inside the Stores page alongside Global / Chain / Mock / Prompts / Secrets / S3 stores.

Template File Management

• Upload: Click “Upload template” to push a file from your local machine. Any text or binary file is accepted (.json, .yaml, .xml, .html, .txt, images, etc.). The file is stored namespace-scoped on the server.
• Type filter: All / JSON / YAML / XML / HTML / Other pills above the list narrow the view by file extension.
• Search: Filter by file name.
• Preview (eye icon): Opens a modal showing the file content. Text files render inline; images preview as <img>; binary files prompt to download.
• Edit (pencil icon): Opens the same modal in editor mode. Make changes, then Save to persist them — or Cancel to discard. The Format button pretty-prints JSON / XML in place; Fullscreen expands the modal to fill the screen for large files.
• Download / Delete: Per-row, and also available in the modal footer when a file is open.

Template Reference

Templates use Go’s text/template syntax with Mockarty’s custom functions:

• Faker functions: All Faker functions available in inline payloads are also available in templates (e.g., {{fake "UUID"}}, {{fake "FirstName"}}).
• JsonPath interpolation: Access request data within templates (e.g., {{jsonpath "$.user.id"}}).
• Store references: Read and write store values in templates.
• Control structures: Use Go template conditionals ({{if}}, {{else}}), loops ({{range}}), and other constructs for complex response logic.
• Template composition: Include one template within another using {{template "name"}}.

Using Templates in Mocks

When creating or editing a mock in the Constructor, set payloadTemplatePath to the template file name instead of providing an inline response payload. The template is rendered at request time with access to the full request context.

Settings

Path: /ui/settings

Access restriction: The Settings page is only visible to users with the Admin or Support system role. Users with the standard “User” or “Auditor” role do not see the Settings item in the sidebar and cannot access this page.

The Settings page is where you configure how your namespace behaves: who has access, how long logs are retained, which webhooks fire on events, and how the AI assistant is configured. Namespace owners and administrators use this page frequently.

Settings are scoped to the currently selected namespace and affect all users within it.

Namespace Management

• View current namespace: See the namespace name, description, creation date, and member count.
• Create namespace: Click “New Namespace” to create a new namespace. Provide a name and optional description.
• Switch namespace: Select a different namespace from the namespace selector in the top bar.
• Namespace isolation: Each namespace has its own mocks, stores, test collections, and settings. Resources are not shared across namespaces unless explicitly configured.

User Management Within Namespace

Manage which users have access to the current namespace and their roles:

• View members: See all users assigned to the current namespace with their roles.
• Add user: Invite a user to the namespace by selecting their account and assigning a role.
• Change role: Update a user’s role within the namespace.
• Remove user: Revoke a user’s access to the namespace.

Namespace roles:

Cleanup Policies

Configure automatic cleanup of transient data:

• Request logs retention: How long to keep mock request logs (e.g., 7 days, 30 days, forever).
• Undefined requests retention: How long to keep unmatched request records.
• Test report retention: How long to keep test run results.
• Expired mock handling: Whether to automatically delete or archive mocks that have exceeded their TTL or usage limits.

Webhooks

Configure HTTP callbacks triggered by specific events (see Webhooks & Callbacks for details):

• Event types: Mock resolved, mock created, mock deleted, test run completed, undefined request received.
• Target URL: The URL to send the webhook POST request to.
• Headers: Custom headers to include in the webhook request (e.g., authentication tokens).
• Payload format: JSON payload with event details, timestamps, and relevant resource data.
• Retry policy: Number of retries and backoff strategy for failed webhook deliveries.

Notification Channels

Configure notification delivery channels for system events, alerts, and test run results:

• Telegram: Connect a Telegram bot to receive notifications in a chat or group.
• Email: Configure SMTP-based email notifications for users and teams.
• Webhooks: Send event payloads to external HTTP endpoints.
• Slack: Send notifications to Slack channels via incoming webhooks.
• Discord: Send notifications to Discord channels via webhooks.

Each channel can be enabled or disabled independently, and events can be routed to specific channels. For full details, see Notification Channels.

LLM Configuration

Configure the AI assistant (Agent Chat) settings:

• Model selection: Choose the LLM model to use (OpenAI, Claude, OpenRouter, or custom provider).
• API key: Provide the API key for the selected LLM provider.
• Temperature: Adjust the creativity/randomness of AI responses (0.0 for deterministic, 1.0 for creative).
• Context settings: Configure how much mock context the AI assistant receives.

Integrations

Manage integration tokens for runner agents and mock resolvers (see Integrations Guide and Scaling Architecture for multi-node setup):

• Create token: Generate a new integration token (mki_* format) for a runner agent or mock resolver.
• View tokens: See all active integration tokens with their type, scope, and last-used timestamp.
• Revoke token: Disable an integration token immediately.
• Token types: Test runner (for executing test runs on remote agents), Mock resolver (for distributed mock resolution), Orchestrator (for multi-node coordination).

Admin Panel

Path: /ui/admin

The Admin Panel provides system-wide administration capabilities. Access is restricted to users with the Admin system role. See the Administration Guide for detailed setup instructions.

User Management

Comprehensive user administration:

• Create user: Add new user accounts with username, email, and initial password.
• Edit user: Update user profile information, email, and display name.
• Set password: Reset a user’s password (generates a temporary password or sends a reset link).
• Disable / Enable: Temporarily disable a user account without deleting it. Disabled users cannot log in.
• Delete user: Permanently remove a user account and all associated data.
• System roles: Assign system-wide roles to users:

Namespace Management

System-wide namespace administration:

• View all namespaces: See all namespaces across the system with member counts and resource statistics.
• Create namespace: Create a new namespace and assign an initial owner.
• Delete namespace: Soft-delete a namespace and all its resources. Deleted namespaces can be restored within the retention period.
• Restore namespace: Recover a previously deleted namespace with all its resources.

Cleanup Settings

Configure global cleanup policies that apply to all namespaces:

• Log retention: Default retention period for mock request logs.
• Undefined request retention: Default retention period for unmatched requests.
• Test report retention: Default retention period for test run results.
• Cleanup schedule: Configure when cleanup jobs run (cron expression).

These settings serve as defaults; individual namespaces can override them with shorter retention periods.

Audit Logs

View and export the system audit trail:

• Event types: User logins, mock CRUD operations, namespace changes, admin actions, API token usage.
• Filters: Filter by user, event type, date range, and namespace.
• Export: Download audit logs as CSV or JSON for compliance and reporting.
• Retention: Audit logs are retained independently from other cleanup policies.

Job Executions

View the history of scheduled background jobs:

• Job types: Cleanup, backup, scheduled tests, health checks.
• Status: Completed, failed, running, or queued.
• Details: Execution time, duration, and any error messages.
• Manual trigger: Run a job manually outside its schedule.

Database Health

Monitor and maintain database health:

• Index status: View all database indexes with their size, usage statistics, and health.
• Table statistics: Row counts, table sizes, dead tuple counts, and last vacuum/analyze times.
• Maintenance recommendations: Suggestions for index optimization, vacuuming, and other maintenance tasks.
• Connection pool: Current connection pool usage and configuration.

Email Configuration

Configure email notifications (requires EMAIL_ENABLED=true):

• SMTP settings: Host, port, username, password, and TLS configuration.
• Sender address: The “From” address for all outgoing emails.
• Test email: Send a test email to verify the SMTP configuration.
• Email templates: Customize the HTML templates used for notification emails (password reset, 2FA codes, invitations, test run notifications).

LLM Profiles

Configure global AI model profiles:

• Provider settings: API endpoints, keys, and model identifiers for supported LLM providers.
• Default model: Set the default model used when namespaces do not specify their own.
• Usage tracking: View token usage and cost estimates per namespace.
• Rate limits: Configure per-namespace rate limits for LLM API calls.

Monitoring (OpenTelemetry)

Configure OpenTelemetry tracing for mock resolution and find operations:

• Enable OpenTelemetry Tracing: Turn tracing on or off. Changes apply on the fly — no restart required.
• Exporter Type: OTLP over gRPC or HTTP.
• OTLP Endpoint: The collector address, e.g. localhost:4317 (gRPC) or localhost:4318 (HTTP).
• Skip TLS Verification: Use a plaintext/insecure connection to the collector.
• Service Name / Service Version: Identify this Mockarty instance in your tracing backend.
• Additional Headers (JSON): Extra headers sent to the collector (e.g. an authorization token).

Integrations (Admin)

System-wide integration token management:

• View all integration tokens across all namespaces.
• Create tokens for system-level integrations (shared runners, orchestrators).
• Monitor token usage and last-active timestamps.
• Revoke tokens across the entire system.

Effects (Admin)

Some actions leave the platform and cannot be undone by it: a paid LLM call, a deployment, a message sent through a connector. When the outcome of such an action could not be observed (the provider timed out after the request was sent, a lease expired mid-flight, a cancel arrived after dispatch), the receipt stays unresolved and waits for a person.

The Effects tab lists these receipts per namespace, oldest first, with the reason and the mission/execution identifiers.

1. Pick the namespace and, optionally, a reason or effect family.
2. Claim an effect. The claim is a 10-minute lease, so exactly one operator decides it; another operator sees who holds it.
3. Confirm with the provider or the target system what actually happened.
4. If nothing happened, choose Mark: no effect happened — the receipt is settled and the paid reservation is released.
5. If the effect did apply, do nothing here: the producing module settles it from provider evidence. A person’s word never settles an applied effect.

Release gives a claim back without a decision. The same queue is available to agents through the effect_reconciliation_queue and effect_reconcile_no_effect MCP tools.

Delivery Policy (Admin)

Deployment environments and their approval posture (which deploys need a reviewed grant, what a grant may cover) live in the Delivery policy tab. Every save creates an immutable revision; existing revisions are never overwritten. The former standalone page /ui/admin/delivery-policy opens this tab.

Support Panel

Path: /ui/support

The Support Panel is available to users who have been assigned the Support system role. Support users have full read access and can manage users, namespaces, cleanup settings, LLM profiles, webhooks, and database health within their scope.

What is the Support Role?

The Support role is designed for team leads, QA leads, or designated support personnel who need visibility into the system to assist other users without having full administrator access. Support users can see more of the system than regular users but are restricted from making configuration changes that could affect the entire platform.

Support Capabilities

Users with the Support role can:

• View users and their profiles: Browse the list of all users in the system, see their assigned namespaces and roles. Useful for verifying account status when a user reports an issue.
• Reset user passwords: Help users who are locked out of their accounts by resetting their passwords.
• View all namespaces: See every namespace in the system with its member list and resource counts. This helps when troubleshooting namespace-scoped issues reported by users.
• View system status: Access system health information, including database connectivity, background job status, and resource utilization.
• View audit logs: Read the audit trail to investigate what happened when a user reports unexpected behavior (e.g., mocks disappearing, settings changing).
• View job executions: See the history of background jobs (cleanup, backups, scheduled tests) to diagnose issues like missing test reports or stale data.

What Support Users Cannot Do

The Support role intentionally does not grant:

• Changing system-wide settings (telemetry, email configuration).
• Performing destructive administrative operations on system resources.

How to Assign the Support Role

Only administrators can assign the Support role:

1. Navigate to Admin Panel (/ui/admin).
2. Open the User Management section.
3. Find the user you want to promote and click Edit.
4. In the System Role dropdown, select Support.
5. Save the changes. The user will see the Support navigation item in their sidebar on their next page load.

AI Features

Mockarty integrates AI across the platform with dedicated buttons on every major page. Each AI button follows a consistent pattern: click to run the operation, click the gear icon to customize settings.

AI Button Pattern

Every AI feature provides:

1. Action button — click to run the AI operation
2. Settings gear — select LLM profile, enter a custom prompt, and manage MCP tool integrations
3. Result display — AI responses rendered as formatted Markdown

Where to Find AI Buttons

• Constructor: Generate Mock, Improve Mock
• API Tester: Generate Script, Generate Perf Script, Diagnose Error, API Diff, Log Analysis, Generate Collection
• Test Runs: Analyze Report (in report modal)
• Fuzzing: Analyze Finding, Batch Analyze, Batch Auto-Triage
• Recorder: Analyze Traffic, Security Audit, Find Scenarios
• Performance: Analyze Results

Customizing AI Behavior

Click the gear icon on any AI button to:

• Select AI Profile: Choose which LLM to use (fast vs. powerful models)
• Add Custom Prompt: Provide additional instructions (e.g., “Focus on security”, “Respond in Russian”, “Compare against SLA: p95 < 200ms”)
• Select MCP Tools: Enable external tools for the AI to query live data

Settings are saved per feature — your “Generate Script” settings won’t affect “Diagnose Error”.

For the complete guide to all AI features, custom prompts, and tips, see the AI Features documentation.

Agent Chat

The Agent Chat is an AI-powered assistant available on every page via a floating chat button in the bottom-right corner of the screen.

Accessing the Chat

Click the floating chat button (a speech bubble icon) to open the chat panel. The panel slides in from the right side and can be resized by dragging its left edge.

Capabilities

The Agent Chat leverages a configured LLM (OpenAI, Claude, or OpenRouter) to assist with:

• Mock creation: Describe the mock you need in natural language (e.g., “Create a GET endpoint for /api/users that returns a list of 10 users with random names and emails”). The assistant creates and configures the mock automatically.
• Mock editing: Ask the assistant to modify existing mocks (e.g., “Add a condition to the /api/users mock to return a 404 when the user ID is 0”).
• Question answering: Ask questions about Mockarty features, JsonPath syntax, Faker functions, or store usage.
• Troubleshooting: Describe an issue (e.g., “My mock is not matching requests”) and the assistant will help diagnose the problem.
• Bulk operations: Ask the assistant to create multiple related mocks in one conversation.

Conversation History

The chat maintains a conversation history for the current session. You can:

• Scroll through previous messages.
• Reference earlier parts of the conversation.
• Start a new conversation by clicking “Clear Chat”.

Agent chat sessions are persisted to the database. When you reopen a session, up to 100 previous messages are loaded automatically.

Auto-Approve Mode

By default, each tool call made by the AI assistant requires manual approval — you see Accept and Decline buttons for each action. For faster workflows, switch to Auto Approve mode:

1. Open the Agent Chat panel.
2. Find the Auto Approve dropdown at the top.
3. Switch from Manual to Auto Approve.

In auto-approve mode, tool calls are executed immediately without waiting for confirmation. This setting is saved in your browser and persists across sessions.

Tip: Use auto-approve in sandbox/development namespaces for rapid prototyping. Keep manual mode in production namespaces for safety.

Server-Side vs. Client-Side LLM

The Agent Chat supports two modes of LLM operation:

Server-side (default):

• LLM API calls are routed through the Mockarty server
• Uses the LLM profile configured by the administrator
• No API key needed from the user

Client-side:

• LLM API calls are made directly from your browser to the LLM provider
• You provide your own API key and provider URL
• Tool execution still happens server-side
• Useful when you want to use your own OpenAI/Claude account

To use client-side mode, select a custom user profile in the chat settings and provide your API key.

Available Tools

The AI assistant has access to the following built-in tools:

The exact tools available depend on the current page context. For example, on the Constructor page, the assistant has access to form fields and mock configuration tools.

Context Awareness

The Agent Chat is aware of:

• The current page you are viewing.
• The selected namespace and its resources.
• Available Faker functions and template syntax.
• Mockarty’s API capabilities and limitations.

This context allows the assistant to provide relevant, actionable suggestions.

Tips for Effective Prompts

• Be specific: “Create a GET /api/users/list endpoint that returns user data with fake name and email” works better than “create a user mock”
• Describe the behavior: “Return 404 when the ID is ’not-found’, otherwise return 200 with user data”
• Reference existing mocks: “Modify the /api/orders mock to add a condition for canceled orders”
• Ask for explanations: “Explain how Chain Store works for a multi-step checkout flow”
• Request bulk operations: “Create CRUD endpoints for a products resource (GET list, GET by ID, POST, PUT, DELETE)”

API Tokens

API tokens provide programmatic access to the Mockarty REST API. They are used for automation, CI/CD integration, and external tool integration. See the API Reference for the full list of available endpoints.

Accessing Token Management

API token management is available from the user dropdown menu (click your username in the top-right corner and select “API Tokens”).

Generate New Token

Click “Generate Token” to create a new API token:

• Name: Give the token a descriptive name (e.g., “CI/CD Pipeline”, “Postman Collection”).
• Expiration: Optionally set an expiration date. Expired tokens are automatically revoked.
• Scope: Tokens inherit the permissions of the user who created them.

After generation, the token is displayed once. Copy it immediately, as it cannot be retrieved later.

Token Format

API tokens use the format mk_* (for example mk_7_<random-base64-string>). Include the token in API requests using the Authorization header:

Authorization: Bearer mk_<your-token-here>

The X-API-Key: mk_<token> header is also accepted.

View and Revoke Tokens

The token management page shows all your active tokens with:

• Token name and creation date.
• Last used timestamp.
• Expiration date (if set).

Click “Revoke” to immediately disable a token. Revoked tokens cannot be restored.

Roles and Permissions

Mockarty implements a comprehensive role-based access control (RBAC) system with two levels: system roles and namespace roles.

System Roles

System roles are assigned by administrators and determine global permissions:

For users with the “User” system role, permissions are determined by their namespace role assignments.

Namespace Roles

Namespace roles are assigned per namespace and determine what a user can do within that namespace:

Hidden Pages

Some pages require a particular role. If your role does not allow a page, Mockarty hides it from navigation and rejects direct access.

Blocked for Auditors (403 on page access):

• Constructor, Undefined Requests, Stores, Generator, and Templates pages return a 403 Forbidden response when an Auditor attempts to navigate to them.
• Settings page is hidden from the sidebar entirely.
• Auditors retain view-only access to Dashboards, Mocks, API Tester, Test Runs, Recorder, Fuzzing, Contract Testing, Chaos Engineering, Utils, and the Admin panel (audit logs only).

Hidden from Users (standard role):

• Settings is hidden. Access is reserved for Admin and Support roles only.
• Admin Panel is hidden.

Hidden by default (feature flags):

• Fuzzing, Contract Testing, and Chaos Engineering appear when the corresponding feature is available to your account.

Admin Panel: Hidden from all non-Admin users (shown via client-side role check).

Tips and Best Practices

Organization

• Use namespaces to organize mocks by project, team, or environment. Each microservice or API boundary can have its own namespace, keeping mocks isolated and manageable.
• Use tags for cross-cutting categorization that spans namespaces. Tags like “regression”, “smoke-test”, “v2”, or “deprecated” help find related mocks quickly.
• Use folders within the Mocks page to create a logical hierarchy. Mirror your API’s resource structure (e.g., /users, /orders, /payments).

Mock Design

• Leverage Faker for realistic test data instead of hardcoded values. Responses with $.fake.FirstName, $.fake.Email, and $.fake.UUID are more representative of real-world scenarios and help catch serialization/parsing bugs.
• Use Global Store for shared state like counters and feature flags. For example, use $.increment(gS.orderCounter) to generate sequential order IDs across multiple mocks.
• Use Chain Store for multi-step workflows. Design your mocks so that creating an order stores its ID in cS.orderId, and subsequent GET/UPDATE/DELETE mocks reference $.cS.orderId.
• Use conditions wisely. Start with broad mocks (no conditions) and add specific ones with higher priority as your test scenarios become more detailed.
• Use OneOf responses to simulate realistic behavior. Real services do not always return the same response; OneOf with random selection simulates this naturally.

Importing and Bootstrapping

• Import OpenAPI specs to quickly bootstrap mocks for an entire API. This saves significant time compared to creating mocks one by one.
• Use the Recorder to capture real traffic and convert it to mocks. This is the fastest way to create mocks that accurately represent actual service behavior.
• Import Postman collections if your team already has API testing collections. Mockarty’s API Tester is Postman-compatible and can import collections seamlessly.

Testing

• Schedule test runs for continuous validation. Run your test collections on a schedule (e.g., hourly or daily) to catch mock configuration drift.
• Use environments in the API Tester to switch between targets. Define “Local” (pointing to Mockarty), “Staging” (pointing to your staging environment), and “Production” environments with the same collection.
• Write test scripts to validate not just status codes but also response structure, data types, and business logic.

Security

• Use fuzzing regularly to test your APIs for common vulnerabilities. Even mock services can reveal input validation gaps.
• Enable 2FA for all users with write access to mocks. A compromised mock could serve malicious responses.
• Rotate API tokens periodically and revoke tokens that are no longer in use.
• Use namespace isolation to ensure teams cannot accidentally modify each other’s mocks.

Performance

• Monitor the dashboard regularly to understand traffic patterns and identify heavily-used mocks.
• Use proxy mode judiciously. While powerful, proxying adds latency. Use it for testing scenarios, not for permanent pass-through.
• Set TTL on temporary mocks to keep your namespace clean. Mocks created for one-off tests should expire automatically.
• Use cleanup policies to automatically remove old request logs, undefined requests, and test reports. This keeps the database lean and queries fast.

See Also

• Quick Start – Get up and running with Mockarty in minutes.
• API Reference – Complete REST API documentation for programmatic access.
• Faker Functions Reference – All available Faker functions for dynamic response data.
• JsonPath Guide – JsonPath syntax for request data extraction and conditions.
• Store Systems – Detailed guide to Global, Chain, and Mock stores.
• Server Generator – Generate standalone gRPC, Kafka, RabbitMQ, SMTP, and other protocol servers.
• Deployment Guide – Docker and bare-metal deployment instructions.
• Administration Guide – System administration and configuration.
• Integrations Guide – Runner agents, mock resolvers, and third-party integrations.
• Scaling Architecture – Multi-node deployment and distributed mock resolution.
• Test Case Management – Folder-based TMS with versioned steps, shared steps, and review workflows.
• Test Plans – Orchestrate multi-type test runs as a DAG workflow with CI/CD integration.
• API Fuzzing – Automated security testing with fuzz payloads.
• Contract Testing – Validate mocks against API specifications.
• Chaos Engineering – Kubernetes fault injection and resilience testing.
• Performance Testing – Load testing and APDEX scoring.
• Traffic Recorder – Capture and replay real API traffic.
• Notification Channels – Configure Telegram, email, Slack, Discord, and webhook notifications.