Tips & Useful Features

Mockarty’s UI includes many productivity features that are not immediately obvious. This page describes them so you can work faster and get more out of the tool.

Table of Contents

1. Understanding URLs in Examples
2. Keyboard Shortcuts
3. Quick Search
4. Constructor: Smart Autocomplete
5. Constructor: Request-Based Suggestions
6. Constructor: Info Tooltips
7. Constructor: URL Preview
8. Constructor: Auto-Generated Mock ID
9. Constructor: Form Validation
10. API Tester: Environments and Variables
11. API Tester: Pre-Request and Test Scripts
12. API Tester: Import and Export
13. API Tester: Collection Sharing
14. Recorder: Saved Configurations
15. Recorder: Map Local
16. Recorder: AI Analysis
17. Templates: Reusable Response Bodies

Understanding URLs in Examples

Examples use localhost:5770 for a local Mockarty installation. Replace it with your instance’s address when you use a remote server. Quick Start explains the URLs, including the separate address used by server-side features such as Recorder.

Keyboard Shortcuts

Mockarty provides these keyboard shortcuts in the admin interface:

Note: Ctrl/Cmd shortcuts work even when your cursor is in a text input. Non-modifier shortcuts are disabled while typing so they don’t interfere with your text.

Quick Search

Press Ctrl+K (Cmd+K) to open Quick Search. It finds:

• Mocks by name or route in the current namespace
• Test cases and test plans in the current namespace
• Admin pages and available plugin commands

Type at least 2 characters to see results. Use Arrow Up/Down to navigate results and Enter to open the selected item.
Recently opened items appear while the search box is empty and remain available only in the current tab and namespace. They are cleared when you switch namespaces or reload or close the tab.

Constructor: Smart Autocomplete

The Mock Constructor has a smart autocomplete system that suggests interpolation expressions, Faker functions, headers, and store references. It works in several contexts:

Response Body Fields

When editing response body values, the autocomplete suggests:

• JsonPath prefixes — $.req, $.reqHeader, $.queryParams, $.pathParam, $.fake, $.gS, $.cS, $.mS. The available prefixes depend on the mock protocol (e.g., HTTP mocks have $.queryParams and $.pathParam, but gRPC mocks do not).
• Faker functions — type $.fake. to browse 74 built-in functions by category (Address, DateTime, Internet, Person, Payment, ID & Hashes, Text, Business, Phone, Russian, Common). Each function shows an example value. Plugins may add more functions.
• Math functions — $.increment(...), $.sum(a, b), $.multiply(a, b), $.subtract(a, b), $.divide(a, b), $.modulo(a, b).
• Store references — $.gS.key (Global Store), $.cS.key (Chain Store), $.mS.key (Mock Store) with suggestions for common key names (counter, token, sessionId, userId, orderId, status).

How to Activate

• Click or focus on a response body value field — autocomplete appears automatically.
• Start typing $. — see prefix suggestions.
• In the CodeMirror editor (full JSON response body mode), press Ctrl+Space to trigger autocomplete.
• Use Arrow Up/Down to navigate suggestions, Enter to select, Escape to dismiss.

Condition Fields

When editing condition body fields, the autocomplete suggests request body field paths. When editing condition header fields, it suggests common HTTP header names (Content-Type, Authorization, Accept, X-Request-Id, and more).

Webhook Fields

When editing webhook body templates, the autocomplete suggests $.response.* paths to reference the mock’s own response data.

Constructor: Request-Based Suggestions

The autocomplete system becomes smarter when you provide an Example Request in the constructor:

1. In the Constructor, fill in the Example Request field with a sample JSON body that your mock expects to receive.
2. After that, when you edit response body values or condition body fields, the autocomplete will suggest field names extracted from your example request — with hierarchical dot-navigation for nested objects.

For instance, if your example request is:

{
  "user": {
    "name": "John",
    "email": "john@example.com"
  },
  "orderId": 123
}

The autocomplete will suggest $.req.user, $.req.user.name, $.req.user.email, $.req.orderId — so you can build dynamic responses that reference the incoming request without memorizing the field paths.

Tip: If no example request is provided, the autocomplete falls back to suggesting common field names (id, name, email, status, etc.).

Constructor: Info Tooltips

Throughout the constructor form, you will see small info buttons (ⓘ) next to field labels. Click or hover on them to see a tooltip explaining what the field does, what format it expects, and practical examples.

These tooltips are available for: Protocol, Mock ID, Route, Path Prefix, gRPC Service/Method, Response Status Code, Delay, Headers, Conditions, Extractors, Webhooks, and more.

Constructor: URL Preview

When you fill in the Route and Path Prefix fields in the constructor, a live URL preview updates automatically below the route input. It shows the full URL that clients will use to call the mock, including the namespace prefix /stubs/{namespace}/....

Constructor: Auto-Generated Mock ID

If you leave the Mock ID field empty, Mockarty generates a unique ID automatically when you save the mock. You can also click the sparkle button (✦) next to the Mock ID field to auto-generate a readable ID based on the route and method.

Constructor: Form Validation

The constructor validates your inputs in real time:

• Route must start with / and must not contain spaces.
• Status Code must be between 100 and 599.
• Delay must be non-negative and at most 300,000 ms (5 minutes).

Validation errors appear as red borders and error messages directly below the field. Errors clear automatically when you correct the value.

API Tester: Environments and Variables

The API Tester has a full environment variable system, similar to Postman:

Creating Environments

1. Open the API Tester from the sidebar.
2. Click the Environment dropdown in the top toolbar.
3. Click the gear icon to open the Environment Manager.
4. Create a new environment (e.g., “Development”, “Staging”, “Production”).
5. Add key-value pairs (e.g., base_url = http://localhost:5770, api_token = mk_your_token).

Using Variables in Requests

Reference environment variables in any field using double curly braces:

{{base_url}}/api/v1/mocks

Variables are interpolated in: URL, headers, query parameters, request body, and authentication fields. This works across all protocols (HTTP, gRPC, GraphQL, SOAP, Kafka, RabbitMQ, WebSocket, SSE, MCP, SMTP).

Switching Environments

Select a different environment from the dropdown — all {{variable}} references in your requests will instantly use the new environment’s values. This lets you quickly switch between dev/staging/production without editing each request.

Values keep their leading and trailing spaces. A shared environment owned by another user is read-only in the manager. Choose Create personal copy to edit a separate environment; script changes to the shared environment apply only to the current execution. Saving script variables in your own environment preserves its name and sharing settings.

API Tester: Pre-Request and Test Scripts

Each request in the API Tester can have two scripts:

Pre-Request Script

JavaScript code that runs before the request is sent. Use it to set dynamic headers, compute signatures, or prepare test data.

Test Script (Post-Response)

JavaScript code that runs after the response is received. Use it to assert response status, validate body fields, or extract values for subsequent requests.

Postman-Compatible API

The script editor supports a Postman-compatible pm.* API:

// Environment variables
pm.environment.get("key")       // Read variable
pm.environment.set("key", "v")  // Write variable
pm.environment.has("key")       // Check existence

// Collection variables
pm.collectionVariables.get("key")
pm.collectionVariables.set("key", "value")

// Request info; headers can be changed in pre-request scripts
pm.request.url       // Request URL
pm.request.method    // HTTP method
pm.request.headers   // Headers object
pm.request.body      // Request body

// Response assertions (only in test scripts)
pm.response.code                    // Status code (number)
pm.response.json()                  // Parse response as JSON
pm.response.text()                  // Response as text
pm.response.to.have.status(200)     // Assert status
pm.response.to.have.header("name")  // Assert header exists

// Test assertions
pm.test("Status is 200", function() {
    pm.expect(pm.response.code).to.equal(200);
});

The script editor has syntax highlighting, auto-completion for pm.* methods (press Ctrl+Space), bracket matching, and code folding.

Use Snippets for a ready example or open the visual Builder to compose requests, variables and assertions. Selected snippets stay selected while you search. The builder keeps hand-written conditions and, for load scripts, setup, teardown and options. A manual module appears as a code block so editing the surrounding blocks does not discard it. Invalid variable names or stage lines are reported before replacing your editor text.

Run a test stored in a collection to use that collection’s variables. Read the assertion results: a script that executes without an exception can still fail a test. Skipped assertions are listed separately. pm.execution.skipRequest() skips the current request and its response scripts; it does not stop the collection. Use pm.execution.setNextRequest(null) to stop the sequence.

API Tester: Import and Export

The API Tester supports importing and exporting collections in multiple formats:

Import

Export

API Tester: Collection Sharing

Collections can be shared with other users:

Within shared collections, users can have roles: Viewer (read-only), Editor (can modify requests), or Owner (full control including sharing settings and deletion).

To open a collection shared from another namespace, select the receiving namespace in the API Tester. Viewers can inspect, run and export its requests; editors can also change the collection and its requests. The collection remains owned by its original namespace.

Recorder: Saved Configurations

If you frequently record traffic from the same upstream service, save the session configuration for quick reuse:

1. After configuring a recording session (target URL, filters, toxics, modifications), click Save Config instead of starting immediately.
2. Name the config (e.g., “Stripe Dev”, “Internal API Staging”).
3. Next time, click New Session and select a saved config from the list — all fields are pre-filled.

You can also export configs as JSON files and import them on another Mockarty instance. This is useful for sharing standard recording setups across the team.

Limit: 10 saved configurations per user.

Recorder: Map Local

Map Local lets you mix real upstream responses with Mockarty mock responses in a single recording session:

1. When starting a recording session, enable Map Local and specify the namespace.
2. The recorder checks if a matching Mockarty mock exists before forwarding to the upstream.
3. If a mock matches (by route and HTTP method), the mock response is served locally — no network call.
4. If no mock matches, the request goes to the real upstream as usual.
5. Both types of entries appear in the recording (mock-served entries are flagged as mapLocal: true).

Use cases:

• Stub out a flaky upstream endpoint while testing the rest of the integration.
• Inject specific error responses for edge-case testing.
• Gradually replace real upstream calls with mocks.

Recorder: AI Analysis

If you have an LLM provider configured (Settings > AI), the recorder offers AI-powered analysis:

• Traffic Analysis — summarize traffic patterns, identify anomalies, and suggest optimizations.
• Security Analysis — scan recorded traffic for potential security issues (sensitive data in URLs, missing auth headers, etc.).
• Test Scenario Generation — generate test scenarios based on recorded traffic patterns.

These features are available via the AI buttons in the recording session view.

Templates: Reusable Response Bodies

The Templates page (sidebar) lets you save, search, and reuse common response body templates:

• Upload templates in JSON, YAML, XML, or HTML format.
• Search across templates with instant filtering.
• Filter by type (JSON, YAML, XML, HTML).
• Download templates as files.
• Templates are namespace-scoped — each namespace has its own template library.

When creating a mock in the Constructor, you can reference a saved template instead of writing the response body from scratch.

See Also

• Quick Start — Get Mockarty running in minutes
• Web UI Guide — Full interface walkthrough
• Faker Functions — All available Faker functions
• JsonPath Guide — Dynamic response interpolation
• Store Systems — State management across mocks
• API Reference — REST API documentation