Server Generator Guide

Contents

1. Overview
2. Installation
3. Architecture
4. Operating Modes
5. Common CLI Flags
6. OpenAPI Generator
7. gRPC Generator
8. MCP Generator
9. GraphQL Generator
10. SOAP Generator
11. Kafka Generator
12. RabbitMQ Generator
13. SSE Generator
14. Socket Generator
15. HAR Import
16. Smart Merge Strategy
17. Orchestrator Mode
18. Experimental UI
19. Generated Server Environment Variables
20. Output Structure & Offline Build
21. Mock Examples
22. Limitations

Overview

Mockarty Server Generator is a unified code generation binary (mockarty-server-generator) that supports 9 protocol types. From a single binary you can generate standalone Go servers, create mocks via API, or manage multiple servers through an orchestrator UI.

Each generated server connects to the Mockarty HTTP node (admin or resolver) for mock resolution. The generated servers are fully autonomous Go programs with embedded UI, vendored dependencies, and optional high-performance caching.

Supported Protocols

Installation

Download the pre-built mockarty-server-generator binary for your platform from the Downloads page.

# Linux / macOS
chmod +x mockarty-server-generator

# Verify
./mockarty-server-generator --help

The binary is self-contained and requires no additional dependencies.

Architecture

All generated servers follow the same pattern: receive a protocol-specific request, translate it into a mock resolution call to the Mockarty HTTP node, and return the mock response back to the client.

+-----------------+
| Protocol Client |  (gRPC / MCP / GraphQL / SOAP / Kafka / etc.)
+--------+--------+
         |
         | Protocol request
         v
+-----------------+
| Generated Server|  (standalone Go binary with embedded UI)
+--------+--------+
         |
         | HTTP POST to /mock/find{Protocol}
         v
+-----------------+
|  Mockarty Node  |  (admin or resolver node, port 5770)
+--------+--------+
         |
         | Match mock by route, conditions, priority
         v
+-----------------+
|  Mock Storage   |  (PostgreSQL / SQLite)
+-----------------+

Mock Resolution Endpoints

Proxying

When a mock has proxy.target configured, proxying is always performed on the Mockarty HTTP node side, not in the generated server. The flow:

1. Generated server sends request to HTTP node
2. HTTP node finds the mock with proxy.target
3. HTTP node creates a client (MCP, gRPC, etc.) and calls the real service
4. HTTP node logs and returns the response to the generated server

Operating Modes

The server generator binary has three operating modes:

Mode 1: Generate Server Code

Generates a standalone Go server file with all dependencies vendored for offline build.

mockarty-server-generator openapi \
  -input swagger.json \
  -output server.go \
  -package main

Mode 2: Generate Server + Create Mocks

Generates the server and simultaneously creates mocks on the Mockarty HTTP node via API.

mockarty-server-generator openapi \
  -input swagger.json \
  -output server.go \
  -package main \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox

Mode 3: Create Mocks Only (API-First)

Creates mocks on the HTTP node without generating any server code. Useful for populating mocks from a spec when you don’t need a standalone server.

mockarty-server-generator openapi \
  -input swagger.json \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox \
  -tags "petstore,v2"

Note: The -create-mocks mode requires a valid license with the api-first-generator feature enabled on the Mockarty HTTP node.

Common CLI Flags

Usage: mockarty-server-generator <generator-type> [flags]

Input/Output Flags

Mock Creation Flags

Update Strategy Flags

Default behavior: When neither -force-update nor -merge-update is specified, smart merge is used — preserves user customizations while updating schema from the spec.

Performance Flags

OpenAPI Generator

Generates HTTP REST mock servers from OpenAPI 2.0 (Swagger) or OpenAPI 3.x specifications.

Input Sources

• Local JSON or YAML file
• URL to a Swagger/OpenAPI spec (JSON or YAML)

Usage

# From local file
mockarty-server-generator openapi \
  -input ./petstore.yaml \
  -output server.go \
  -package main \
  -http-admin-base-url http://localhost:5770 \
  -namespace sandbox

# From URL
mockarty-server-generator openapi \
  -input https://petstore3.swagger.io/api/v3/openapi.json \
  -output server.go \
  -package main

# Create mocks only (no server code)
mockarty-server-generator openapi \
  -input ./petstore.yaml \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox \
  -tags "petstore,v3"

# Generate server + create mocks with smart merge
mockarty-server-generator openapi \
  -input ./petstore.yaml \
  -output server.go \
  -package main \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox

# Force overwrite existing mocks
mockarty-server-generator openapi \
  -input ./petstore.yaml \
  -create-mocks \
  -api-token mk_your_token \
  -force-update

# With request body decomposition and header conditions
mockarty-server-generator openapi \
  -input ./petstore.yaml \
  -create-mocks \
  -api-token mk_your_token \
  -decompose-request-body \
  -use-headers-as-conditions

Advanced Options

• -decompose-request-body — when the spec has oneOf/anyOf request bodies, creates a separate mock per variant with appropriate conditions
• -use-headers-as-conditions — generates conditions from header parameters (e.g., Authorization, X-Request-ID)
• -path-prefix — adds a prefix to all routes: namespace/path-prefix/original-route

Generated Server Features

• Embedded Swagger UI at /swagger/ with the original OpenAPI spec
• Admin UI at /ui with service overview
• Health endpoint at /health
• All API paths mapped to mock resolution

gRPC Generator

Generates gRPC mock servers from .proto files. Uses protoreflect for parsing — no protoc installation required.

Proto File Requirements

Proto files must include a go_package option starting with /:

syntax = "proto3";
option go_package = "/your_company/service_name";

Mockarty automatically replaces the prefix to mockarty/your_company/service_name during code generation.

Input Sources

• Directory containing .proto files
• gRPC reflection URL (grpc:// or grpc+reflection://)

Usage

# From local proto directory
mockarty-server-generator grpc \
  -input ./proto/ \
  -output server.go \
  -package main \
  -http-admin-base-url http://localhost:5770 \
  -namespace sandbox

# With server name (important for mock matching in multi-instance setups)
mockarty-server-generator grpc \
  -input ./proto/ \
  -output server.go \
  -package main \
  -server-name my-grpc-service

# From gRPC reflection
mockarty-server-generator grpc \
  -input grpc+reflection://localhost:50051 \
  -output server.go \
  -package main

# Create mocks only
mockarty-server-generator grpc \
  -input ./proto/ \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox \
  -server-name my-grpc-service

Features

• Parses .proto files directly (no protoc dependency)
• Generates Go types inline from proto messages
• Handles Google well-known types: Timestamp, Duration, Empty, Struct, Value, wrapper types
• Handles validate proto imports
• Finds proto dependencies via GOMODCACHE
• Admin UI at /ui with gRPC Playground (interactive tester)

Generated Server Ports

Limitations

• Full support for unary methods only
• Stream methods have basic support (no proxy/delay/error features)
• Proxying is performed on the HTTP node side, not in the generated server

MCP Generator

Generates Model Context Protocol servers from multiple input sources.

Input Sources

1. MCP server URL — connects to a running MCP server via introspection to discover tools
2. MCP schema JSON — direct schema file with tools definition
3. Swagger/OpenAPI — converts REST endpoints to MCP tools
4. JSON/YAML config — manual tool definitions

Usage

# From running MCP server (introspection)
mockarty-server-generator mcp \
  -input http://localhost:8910/sse \
  -output server.go \
  -package main

# From JSON config
mockarty-server-generator mcp \
  -input mcp-server.json \
  -output server.go \
  -package main \
  -http-admin-base-url http://localhost:5770

# From Swagger spec (convert REST to MCP tools)
mockarty-server-generator mcp \
  -input http://localhost:5770/swagger/doc.json \
  -output server.go \
  -package main

# Create mocks only
mockarty-server-generator mcp \
  -input mcp-server.json \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox

Configuration Format

{
  "server": {
    "name": "example-mcp-server",
    "version": "1.0.0",
    "description": "Server description"
  },
  "tools": [
    {
      "name": "tool_name",
      "description": "Tool description",
      "inputSchema": {
        "type": "object",
        "properties": {
          "param1": {
            "type": "string",
            "description": "Parameter description"
          }
        },
        "required": ["param1"]
      }
    }
  ],
  "config": {
    "httpAdminBaseUrl": "http://localhost:5770",
    "namespace": "sandbox",
    "transport": "sse"
  },
  "proxy": {
    "target": "http://localhost:5772/mcp"
  }
}

Transports

Generated Server Endpoints

• SSE stream: http://localhost:8910/sse
• Message endpoint: http://localhost:8910/message
• Admin UI: http://localhost:8080/ui (MCP Tester)
• Health: http://localhost:8080/health

GraphQL Generator

Generates GraphQL mock servers from schema files, URLs (introspection), or JSON/YAML configs.

Input Sources

1. .graphql / .gql files — local GraphQL schema files (SDL)
2. URL — connects to a running GraphQL endpoint and performs introspection
3. Directory — scans for all .graphql/.gql files and combines them
4. JSON/YAML config — configuration with schema definition

Usage

# From GraphQL schema file
mockarty-server-generator graphql \
  -input ./schema.graphql \
  -output server.go \
  -package main \
  -http-admin-base-url http://localhost:5770 \
  -namespace sandbox

# From running GraphQL endpoint (introspection)
mockarty-server-generator graphql \
  -input http://localhost:4000/graphql \
  -output server.go \
  -package main

# From directory with multiple schema files
mockarty-server-generator graphql \
  -input ./schemas/ \
  -output server.go \
  -package main

# Create mocks only
mockarty-server-generator graphql \
  -input ./schema.graphql \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox \
  -tags "graphql,v1"

Features

• Batch mock creation with concurrent update optimization
• Smart merge, force update modes
• Supports queries and mutations
• Admin UI at /ui with GraphiQL interactive explorer
• Schema introspection at /graphql

Generated Server Ports

SOAP Generator

Generates SOAP mock servers from WSDL definitions with optional XSD enrichment.

Input Sources

• WSDL file (local)
• WSDL URL
• Directory with WSDL/XSD files (auto-discovers XSD imports)

Usage

# From WSDL file
mockarty-server-generator soap \
  -input ./service.wsdl \
  -output server.go \
  -package main

# From WSDL URL
mockarty-server-generator soap \
  -input http://example.com/service?wsdl \
  -output server.go \
  -package main

# Create mocks only
mockarty-server-generator soap \
  -input ./service.wsdl \
  -create-mocks \
  -api-token mk_your_token \
  -namespace sandbox

Important: Dual-Port Architecture

SOAP generated servers use two separate HTTP ports because the SOAP endpoint uses a wildcard route (/*path) that conflicts with static routes:

Running

HTTP_PORT=8080 ADMIN_PORT=8081 ./soap_server

Features

• Parses WSDL 1.1 with XSD import resolution
• Embedded SOAP Tester UI at /ui (on admin port)
• Matches requests by SOAPAction header and path
• Health endpoint at /health (on admin port)

Kafka Generator

Generates a mock Apache Kafka broker server using the Sarama library.

Configuration

{
  "server": {
    "name": "my-kafka-server",
    "version": "1.0.0"
  },
  "config": {
    "namespace": "sandbox",
    "brokers": ["localhost:9092"],
    "consumerGroup": "mockarty-consumer",
    "autoCommit": true,
    "commitInterval": 5,
    "cacheEnabled": false,
    "serverName": "my-kafka-server"
  },
  "topics": [
    {
      "name": "orders",
      "eventName": "order-created",
      "outputTopic": "order-results"
    },
    {
      "name": "payments",
      "eventName": "payment-processed"
    }
  ]
}

Configuration fields:

Usage

# Generate server
mockarty-server-generator kafka \
  -input kafka-server.json \
  -output kafka_server.go \
  -package main

# Generate server + create mocks
mockarty-server-generator kafka \
  -input kafka-server.json \
  -output kafka_server.go \
  -package main \
  -create-mocks \
  -api-token mk_your_token \
  -server-name my-kafka-server

# Create mocks only
mockarty-server-generator kafka \
  -input kafka-server.json \
  -create-mocks \
  -api-token mk_your_token \
  -server-name my-kafka-server

Build and Run

# Build (offline, vendored)
go build -mod=vendor -o kafka_server .

# Run
HTTP_PORT=8080 \
HTTP_ADMIN_BASE_URL=http://localhost:5770 \
NAMESPACE=sandbox \
./kafka_server

Features

• Full Kafka broker implementation via Sarama library
• Admin UI at /ui with 4 tabs: Dashboard, Broker Topics, Producer, Messages
• Create/delete topics via API
• Built-in producer for sending test messages
• Real-time message viewer
• Mock resolution via POST /mock/findKafka on the HTTP node

Mock Resolution

Kafka mocks use KafkaRequestContext with fields:

• topic — Kafka topic name
• serverName — server identifier (use -server-name flag or config.serverName in JSON)
• outputTopic — topic for response messages

RabbitMQ Generator

Generates a mock RabbitMQ AMQP broker server.

Configuration

{
  "server": {
    "name": "my-rabbitmq-server",
    "version": "1.0.0"
  },
  "config": {
    "namespace": "sandbox",
    "url": "amqp://guest:guest@localhost:5672/",
    "prefetchCount": 1,
    "cacheEnabled": false,
    "serverName": "my-rabbitmq-server"
  },
  "queues": [
    {
      "name": "orders-queue",
      "eventName": "order-received",
      "exchange": "orders",
      "routingKey": "orders.#"
    },
    {
      "name": "notifications-queue",
      "eventName": "notification-received"
    }
  ]
}

Configuration fields:

The RABBITMQ_URL environment variable can override config.url at runtime. The management API URL is auto-derived (port 15672).

Usage

# Generate server
mockarty-server-generator rabbitmq \
  -input rabbitmq-server.json \
  -output rabbitmq_server.go \
  -package main

# Generate server + create mocks
mockarty-server-generator rabbitmq \
  -input rabbitmq-server.json \
  -output rabbitmq_server.go \
  -package main \
  -create-mocks \
  -api-token mk_your_token \
  -server-name my-rabbitmq-server

# Create mocks only
mockarty-server-generator rabbitmq \
  -input rabbitmq-server.json \
  -create-mocks \
  -api-token mk_your_token \
  -server-name my-rabbitmq-server

Build and Run

# Build (offline, vendored)
go build -mod=vendor -o rabbitmq_server .

# Run
HTTP_PORT=8080 \
HTTP_ADMIN_BASE_URL=http://localhost:5770 \
NAMESPACE=sandbox \
RABBITMQ_URL=amqp://guest:guest@localhost:5672/ \
./rabbitmq_server

Features

• AMQP 0.9.1 compatible broker
• Admin UI at /ui with 4 tabs: Dashboard, Broker, Publisher, Messages
• Create exchange/queue via API
• Built-in publisher for sending test messages
• Real-time message viewer
• Mock resolution via POST /mock/findRabbitMQ on the HTTP node

Mock Resolution

RabbitMQ mocks use RabbitMQRequestContext with fields:

• queue — queue name
• exchange — exchange name
• routingKey — routing key
• serverName — server identifier (use -server-name flag or config.serverName in JSON)
• outputQueue — queue for response messages

SSE Generator

Generates Server-Sent Events mock servers.

Configuration

{
  "server": {
    "name": "my-sse-server",
    "version": "1.0.0"
  },
  "config": {
    "namespace": "sandbox",
    "sseEndpoint": "/sse",
    "port": 8090,
    "cacheEnabled": false
  },
  "events": [
    {
      "name": "notifications",
      "path": "/events/notifications",
      "description": "User notification events"
    },
    {
      "name": "heartbeat",
      "path": "/events/heartbeat",
      "description": "Keepalive heartbeat"
    }
  ]
}

Usage

# Generate server
mockarty-server-generator sse \
  -input sse-server.json \
  -output sse_server.go \
  -package main

# With path prefix
mockarty-server-generator sse \
  -input sse-server.json \
  -output sse_server.go \
  -package main \
  -path-prefix "v1/streams"

# Create mocks only
mockarty-server-generator sse \
  -input sse-server.json \
  -create-mocks \
  -api-token mk_your_token

Running

HTTP_PORT=8080 ./sse_server

Features

• SSE streams with text/event-stream content type
• Admin UI at /ui with SSE Monitor
• Path prefix support for route organization
• Mock resolution via SSERequestContext (event path + event name)

Socket Generator

Generates WebSocket, TCP, and UDP mock servers. Each socket type uses a different Go template for the generated code.

WebSocket Configuration

{
  "server": {
    "name": "my-ws-server",
    "version": "1.0.0"
  },
  "config": {
    "httpAdminHost": "localhost",
    "httpAdminPort": "5770",
    "namespace": "sandbox",
    "socketType": "websocket",
    "socketPort": 8081,
    "messageFormat": "json",
    "readTimeout": 30,
    "writeTimeout": 30
  }
}

TCP / UDP Configuration

{
  "server": {
    "name": "my-tcp-server",
    "version": "1.0.0"
  },
  "config": {
    "httpAdminHost": "localhost",
    "httpAdminPort": "5770",
    "namespace": "sandbox",
    "socketType": "tcp",
    "socketPort": 8080,
    "messageFormat": "json",
    "readTimeout": 30,
    "writeTimeout": 30
  },
  "messageHandlers": [
    {
      "pattern": ".*",
      "handler": "generic"
    }
  ]
}

Replace "socketType": "tcp" with "socketType": "udp" for UDP servers.

Usage

# Generate WebSocket server
mockarty-server-generator socket \
  -input ws-server.json \
  -output socket_server.go \
  -package main \
  -server-name my-ws-server

# Generate TCP server
mockarty-server-generator socket \
  -input tcp-server.json \
  -output socket_server.go \
  -package main

# Create mocks only
mockarty-server-generator socket \
  -input ws-server.json \
  -create-mocks \
  -api-token mk_your_token \
  -server-name my-ws-server

Running

HTTP_PORT=8080 ./socket_server

Features

• WebSocket: Bidirectional communication with embedded WebSocket Tester UI at /ui
• TCP: Raw TCP socket server
• UDP: Raw UDP socket server
• Mock resolution via SocketRequestContext with serverName and eventName

HAR Import

HAR (HTTP Archive) files can be imported to create mocks and API test collections. This feature is available through the Mockarty Web UI, not the server generator CLI.

Import via Web UI

1. Open the API Tester page in Mockarty
2. Click Import and select HAR
3. Upload a HAR file or provide a URL
4. Mockarty parses the HAR entries and creates:
   • An API Tester collection with all requests
   • Auto-generated test scripts for each request (status checks, content-type, headers, JSON structure validation)
5. Static assets (CSS, JS, images, fonts) are automatically filtered out

Features

• URL replacement system rewrites base URLs to /stubs/{namespace}/path format
• Handles protocol-relative URLs, host-only URLs, query params, and fragments
• Replaces URLs in JSON values, HTML content, and headers

Smart Merge Strategy

The server generator implements intelligent mock update logic that is used by default when mocks already exist.

Default Behavior: Smart Merge

When you run the generator against a spec that already has mocks in Mockarty:

• Preserves user customizations (manually added response payloads, conditions, priorities)
• Updates the schema (adds new required fields, removes fields deleted from the spec)
• Supports rollback — if the spec reverts a change, the generator removes previously added fields

Force Update (-force-update)

Replaces everything from the spec. Use with caution — this discards all manual customizations.

How Merge Works

Payload merge — recursively merges response objects and arrays:

• Adds new required fields from the spec
• Removes fields that are no longer in the spec
• Preserves user values for existing fields

Condition merge — intelligently merges request conditions:

• Preserves user-configured assertions
• Adds new fields from the spec as any conditions (allows any value)
• Removes conditions for deleted fields

Example

Imagine you have an OpenAPI spec with a /users endpoint, and you’ve manually added a condition $.body.role == "admin" to the mock. When you re-run the generator with an updated spec:

• Smart merge (default): Your role == "admin" condition is preserved. New fields from the spec are added as any conditions.
• Force update: Your condition is replaced with auto-generated ones from the spec.

Orchestrator Mode

The server generator includes an orchestrator mode — a web server with REST API for managing multiple generated servers. The orchestrator handles server generation, lifecycle management, health monitoring, and state persistence.

mockarty-server-generator orchestrator [flags]

Orchestrator Flags

Coordinator Integration Flags

For distributed deployments, the orchestrator can register with a Mockarty coordinator:

Usage

# Basic orchestrator
mockarty-server-generator orchestrator \
  -api-token mk_your_token \
  -http-admin-base-url http://localhost:5770

# With custom port range and data directory
mockarty-server-generator orchestrator \
  -api-token mk_your_token \
  -port 7770 \
  -data-dir /var/lib/mockarty-orchestrator \
  -port-min 9000 \
  -port-max 9500

# With coordinator integration
mockarty-server-generator orchestrator \
  -api-token mk_your_token \
  -coordinator-addr coordinator.example.com:5773 \
  -integration-token mki_your_integration_token \
  -coordinator-tls

REST API

Server management:

Batch operations:

Cache management:

Other:

Generation Request Example

curl -X POST http://localhost:8888/api/servers/generate \
  -H "Content-Type: application/json" \
  -d '{
    "type": "openapi",
    "name": "petstore-api",
    "input": "/path/to/petstore.yaml",
    "namespace": "sandbox",
    "group": "development",
    "createMocks": true,
    "apiToken": "mk_your_token",
    "tags": ["v3", "test"]
  }'

Response:

{
  "jobId": "abc123",
  "status": "pending"
}

Poll job status:

curl http://localhost:8888/api/jobs/abc123

{
  "jobId": "abc123",
  "status": "completed",
  "progress": 100,
  "serverId": "petstore-api-xyz"
}

Key Features

• Async generation — long-running builds don’t block; track progress via job ID
• Health monitoring — background health checks every 30 seconds
• Port management — auto-allocates ports from configurable range
• State persistence — saves/restores via JSON files in data directory
• Event bus — decoupled SSE broadcasts for real-time UI updates
• Server groups — organize servers by environment or purpose
• Cleanup — auto-removes orphaned binaries and stale servers

Experimental UI

The experimental UI mode wraps the orchestrator with a web-based management interface that includes session authentication.

mockarty-server-generator experimental-ui [flags]

Flags

Inherits all orchestrator flags, plus:

Usage

mockarty-server-generator experimental-ui \
  -api-token mk_your_token \
  -port 8888 \
  -username admin \
  -password my_secure_password \
  -http-admin-base-url http://localhost:5770

The web UI will be available at http://localhost:8888. After login, you can:

• Generate new servers from specs (file upload or URL)
• Start, stop, restart, and monitor servers
• View server logs and metrics
• Manage server groups
• Monitor real-time events

Note: The orchestrator and experimental-ui commands are functionally equivalent. The experimental-ui mode adds session-based authentication (login/logout) while the orchestrator mode exposes the API without authentication (designed for programmatic access or integration with an external auth layer).

Generated Server Environment Variables

Common to All Generated Servers

Protocol-Specific Variables

Output Structure & Offline Build

What Gets Generated

When you run the generator with -output and -package, it creates a complete Go project:

petstore-server/
├── server.go              # Generated server code
├── go.mod                 # Go module definition
├── go.sum                 # Dependency checksums
├── vendor/                # ALL dependencies vendored (no internet needed!)
├── assets/                # Swagger UI / GraphQL Playground JS, CSS
└── webfonts/              # Font Awesome icons

Building & Running

Generated servers include vendored dependencies, so they can be built completely offline:

cd petstore-server

# Build (no internet required!)
go build -mod=vendor -o server .

# Run
HTTP_PORT=8080 \
HTTP_ADMIN_BASE_URL=http://localhost:5770 \
NAMESPACE=sandbox \
./server

Vendored Dependencies

The server generator binary includes an embedded vendorfs bundle containing all Go dependencies, UI assets (Swagger UI, GraphQL Playground, Font Awesome), and module files. This means:

• No go mod download needed after generation
• Works in air-gapped environments
• Consistent builds regardless of network access

Mock Examples

MCP Mock

{
  "id": "mcp-tool-mock",
  "namespace": "sandbox",
  "mcp": {
    "serverName": "example-mcp-server",
    "method": "tool_name",
    "conditions": [
      {
        "path": "$.param1",
        "assertAction": "equals",
        "value": "test"
      }
    ]
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "result": "success"
    }
  }
}

gRPC Mock

{
  "id": "grpc-method-mock",
  "namespace": "sandbox",
  "grpc": {
    "grpcServiceName": "UserService",
    "grpcMethod": "GetUser",
    "conditions": [
      {
        "path": "$.id",
        "assertAction": "equals",
        "value": "123"
      }
    ]
  },
  "response": {
    "statusCode": 0,
    "payload": {
      "id": "123",
      "name": "John Doe"
    }
  }
}

GraphQL Mock

{
  "id": "graphql-query-mock",
  "namespace": "sandbox",
  "graphql": {
    "operationType": "query",
    "operationName": "GetUser"
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "data": {
        "user": {
          "id": "1",
          "name": "$.fake.Name",
          "email": "$.fake.Email"
        }
      }
    }
  }
}

Kafka Mock

{
  "id": "kafka-orders-mock",
  "namespace": "sandbox",
  "kafka": {
    "topic": "orders",
    "serverName": "my-kafka-server"
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "orderId": "$.fake.UUID",
      "status": "processed"
    }
  }
}

SOAP Mock

{
  "id": "soap-getuser-mock",
  "namespace": "sandbox",
  "soap": {
    "soapAction": "GetUser",
    "path": "/ws/users"
  },
  "response": {
    "statusCode": 200,
    "payload": "<GetUserResponse><Name>John</Name></GetUserResponse>"
  }
}

RabbitMQ Mock

{
  "id": "rabbitmq-orders-mock",
  "namespace": "sandbox",
  "rabbitmq": {
    "queue": "orders.queue",
    "exchange": "orders.exchange",
    "serverName": "my-rabbitmq-server"
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "orderId": "$.fake.UUID",
      "status": "received"
    }
  }
}

SSE Mock

{
  "id": "sse-events-mock",
  "namespace": "sandbox",
  "sse": {
    "path": "/events",
    "eventName": "notification"
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "type": "alert",
      "message": "$.fake.Sentence"
    }
  }
}

Socket (WebSocket) Mock

{
  "id": "ws-message-mock",
  "namespace": "sandbox",
  "socket": {
    "serverName": "my-ws-server",
    "eventName": "message"
  },
  "response": {
    "statusCode": 200,
    "payload": {
      "echo": "$.req.data",
      "timestamp": "$.fake.UnixTimestamp"
    }
  }
}

Limitations

General

1. Mockarty HTTP node required — generated servers cannot work without a running Mockarty instance (admin or resolver node)
2. Namespace isolation — all mocks must be in the specified namespace
3. Network accessibility — Mockarty HTTP node must be reachable from the machine running the generated server
4. License validation — -create-mocks mode and orchestrator/experimental-ui require a valid license with api-first-generator feature

Protocol-Specific

Mockarty Server Generator — unified code generation for 9 protocols from a single binary.

See Also

• Integrations Guide — Set up resolver nodes, runner agents, and the API-first workflow
• Installation & Deployment — Docker Compose examples with generated servers
• Faker Reference — All Faker functions available in mock responses
• JsonPath Guide — Request data extraction and response interpolation
• API Reference — REST API for programmatic mock management