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

Throughout the documentation, examples use localhost:5770 as the Mockarty address. This is the default for local development. Replace it with your actual Mockarty address when running on a remote server:

For server-side features (Recorder, Fuzzer, Performance Testing), see the detailed explanation in Quick Start.

Keyboard Shortcuts

Mockarty supports global keyboard shortcuts that work on every page:

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 the Quick Search modal. It lets you instantly find and navigate to:

• Mocks by name or route
• API Tester collections
• Documentation pages

Type at least 2 characters to see results. Use Arrow Up/Down to navigate results and Enter to open the selected item.

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. and see the full catalog with 50+ functions organized by category (Address, DateTime, Internet, Person, Payment, ID & Hashes, Common). Each function shows an example value.
• Math functions — $.increment(...), $.sum(a, b), $.multiply(a, b), $.subtract(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.

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 (read-only 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.

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).

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