Mock API Tools Compared: APIGhost vs Prism vs WireMock vs Mockoon

The Mock API Problem

Frontend developers can't wait for backend APIs to be ready. Integration tests need deterministic responses. QA teams need to test error scenarios without breaking production. The solution: mock API servers that return realistic data without hitting real services.

But the mock API landscape is fragmented. Some tools require hand-coding every response. Others need a GUI. A few read your OpenAPI spec and generate mocks automatically. And only one — APIGhost — adds VCR recording for deterministic replay.

Here are the four most popular approaches:

1. APIGhost — CLI-first, OpenAPI spec → mock server with VCR record/replay and scenario switching.
2. Prism — StopLight's spec-driven mock proxy. Reads OpenAPI specs, generates example responses.
3. WireMock — JVM-based HTTP stub server. Define request→response mappings via JSON or Java API.
4. Mockoon — Desktop GUI app for building mock APIs. Also has a CLI mode.

At a Glance

Capability	APIGhost	Prism	WireMock	Mockoon
OpenAPI spec → mock	✓ Zero-config	✓ Zero-config	✗ Manual stubs	~ Import only
VCR record/replay	✓ Built-in	✗	✗	✗
Scenario switching	✓ Named presets	~ Dynamic	~ Via stubs	✓ Environments
Realistic fake data	✓ Faker-powered	✓ Examples	✗ Manual	✗ Manual
CLI-first (no GUI)	✓	✓	✓	~ CLI mode
Spec change auto-sync	✓ Reload spec	✓ Hot reload	✗ Manual	✗ Manual
Language	Python	TypeScript/Node	JVM (Java/Kotlin)	TypeScript/Electron
CI/CD integration	✓ Native	✓ Native	✓ Native	~ CLI mode
Free tier	100 req/session	Full (OSS)	Full (OSS)	Full (OSS)

Tool 1: APIGhost

How it works

# Install
pip install apighost

# Start mock from spec — zero config
apighost serve petstore.yaml
# ✓ Mock server running on http://localhost:8080
# 3 endpoints, 5 schemas detected

# Use error scenario for testing
apighost serve petstore.yaml --scenario error

# Record real interactions
apighost record petstore.yaml
# Make requests to the mock...
# ✓ Cassette saved: ~/.apighost/cassettes/my-recording.json

# Replay deterministically — same responses every time
apighost replay my-recording -p 8080

What APIGhost gets right

• Zero config from spec. Pass an OpenAPI file, get a working server. No stubs to write, no response templates to define.
• VCR record/replay. The only tool that records real API interactions and replays them deterministically. This eliminates flaky tests caused by changing mock data.
• Scenario switching. Named response presets (--scenario error, --scenario empty) make edge-case testing trivial.
• Realistic fake data. Faker integration uses property names to generate contextually appropriate data. An email field gets a realistic email, not a random string.
• Spec change auto-sync. When your OpenAPI spec changes, the mock server reflects the changes on restart. No manual stub updates.

Where APIGhost is limited

• Python-only runtime. If your stack is JVM or Go-only, adding Python may be an extra dependency.
• No GUI. No desktop app for visual request inspection. Dashboard is on the roadmap.
• Free tier limits. 100 requests per session on the free tier. Pro ($12/mo) removes the limit.

Tool 2: Prism (StopLight)

How it works

# Install
npm install -g @stoplight/prism-cli

# Start mock from spec
prism mock petstore.yaml
# ✓ Prism mock server running on http://localhost:4010

# Proxy mode — validate real API against spec
prism proxy petstore.yaml https://api.example.com

What Prism gets right

• Mature and widely adopted. Part of the StopLight ecosystem. Used by thousands of teams.
• Request validation. Validates incoming requests against the spec. Catches malformed payloads before they reach your backend.
• Proxy mode. Sits between client and real API, validating requests and responses against the spec. Useful for API governance.
• OpenAPI 2.0 + 3.0. Supports older Swagger specs too.
• Fully open source. No paid tier, no rate limits. Apache 2.0 license.

Where Prism falls short

• No VCR recording. Can't record real interactions for deterministic replay. Each mock run generates different random data, which can cause test flakiness.
• No scenario switching. Can't switch between "happy path" and "error" response sets with a flag. You'd need to maintain multiple spec files or override examples manually.
• Example-dependent mocking. If your spec doesn't define examples, Prism generates minimal data from schema constraints. Results are often less realistic than APIGhost's Faker-powered output.
• Node.js dependency. Requires Node.js runtime. Adding it to a Python-only CI pipeline is friction.
• StopLight ecosystem lock-in. Tighter integration with StopLight Studio. Using Prism outside the StopLight ecosystem works but feels like you're missing features.

Tool 3: WireMock

How it works

# Standalone server
java -jar wiremock-standalone.jar --port 8080

# Define a stub (JSON)
curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/api/pets/1"
    },
    "response": {
      "status": 200,
      "jsonBody": {
        "id": 1,
        "name": "Fido",
        "status": "available"
      },
      "headers": {
        "Content-Type": "application/json"
      }
    }
  }'

# Request it
curl http://localhost:8080/api/pets/1
# {"id": 1, "name": "Fido", "status": "available"}

What WireMock gets right

• Maximum flexibility. Define any request→response mapping. Fault injection, delays, malformed responses, stateful behavior — WireMock handles every edge case.
• JVM-native. Embed directly in Java/Kotlin tests. No subprocess, no separate server. JUnit 5 extension available.
• Record/replay proxy. Unlike Prism, WireMock can proxy real traffic and record it as stubs. Similar to APIGhost's VCR but generates stub files instead of cassettes.
• Response templating. Use Handlebars templates for dynamic responses. Generate IDs, timestamps, and conditional responses.
• Mature ecosystem. 10+ years of development. Extensive documentation. Large community.

Where WireMock falls short for API mocking

• No OpenAPI support. WireMock doesn't read specs. Every stub must be hand-coded. For a 50-endpoint API, that's 50 JSON stubs to write and maintain.
• Manual maintenance. When your API changes, you update each stub individually. No auto-sync from spec.
• Java dependency. Requires JVM. Heavy dependency for non-Java projects. The standalone JAR is 15MB+.
• No realistic data generation. Stubs return whatever you hardcode. No Faker integration. "Fido" is forever.
• Stub sprawl. Large projects accumulate hundreds of stub files. Organizing and debugging them becomes a maintenance burden.

Tool 4: Mockoon

How it works

# Desktop: open Mockoon app, create routes visually
# (GUI — not CLI)

# CLI mode for CI
npm install -g @mockoon/cli
mockoon start --data ./my-api.json
# ✓ Mock server running on http://localhost:3000

What Mockoon gets right

• Visual API design. Build routes, define responses, and set headers in a desktop app. No JSON editing. Great for non-technical team members.
• Environment switching. Define multiple environments (development, staging, error) and switch between them. Similar to APIGhost's scenarios but GUI-driven.
• OpenAPI import. Import OpenAPI specs to pre-populate routes. Reduces manual setup for existing APIs.
• No coding required. QA teams and product managers can build mock APIs without writing code or CLI commands.
• Fully open source. No paid tier. No rate limits. MIT license.

Where Mockoon falls short

• GUI-first, CLI-second. The primary workflow is the desktop app. The CLI is a separate package (@mockoon/cli) with limited feature parity.
• No VCR recording. Can't record real interactions. All responses must be manually defined.
• No realistic data generation. Like WireMock, responses are hardcoded. No Faker or dynamic data.
• Manual sync with spec changes. If your OpenAPI spec changes, you must re-import or manually update routes. No auto-sync.
• Electron dependency. Desktop app requires Electron. Heavy for CI environments.
• CLI mode limitations. Not all GUI features are available in CLI mode. Some advanced configurations require the desktop app.

Feature-by-Feature Comparison

OpenAPI Spec Support

Feature	APIGhost	Prism	WireMock	Mockoon
Read OpenAPI 3.0	✓	✓	✗	~ Import
Read OpenAPI 3.1	✓	~	✗	✗
Read Swagger 2.0	✗	✓	✗	~ Import
Auto-generate from spec	✓	✓	✗	✗
Spec hot reload	✓ Restart	✓ Watch	✗	✗

Mock Data Quality

Data Feature	APIGhost	Prism	WireMock	Mockoon
Realistic fake data	✓ Faker	~ From examples	✗ Manual	✗ Manual
Property-name-aware	✓	✗	✗	✗
Consistent across runs	✓ VCR	✗ Random	✓ Manual	✓ Manual
Dynamic templating	✗	~	✓ Handlebars	~ Templating

Testing Workflows

Workflow	APIGhost	Prism	WireMock	Mockoon
VCR record/replay	✓ Built-in	✗	~ Proxy record	✗
Scenario presets	✓ --scenario	✗	~ Stateful	✓ Environments
Fault injection	✗	✗	✓	~
Request validation	✗	✓	✗	✗
Deterministic tests	✓ Replay	✗ Random	✓ Stubs	✓ Manual

The VCR Advantage: Why Record/Replay Matters

Test flakiness from mock data is a real problem. Consider a typical test suite:

# With Prism: different data every run
prism mock petstore.yaml
# GET /pets/1 → {"name": "mollis", "status": "available"}  (random)
# Next run: GET /pets/1 → {"name": "dignissim", "status": "sold"}  (different!)

# Your test:
response = client.get("/pets/1")
assert response.name == "mollis"  # FAILS on second run

Every mock run generates different random data. Tests that assert on specific values break intermittently.

# With APIGhost VCR: same data every run
apighost record petstore.yaml
# Make real requests, capture responses
apighost replay my-recording -p 8080
# GET /pets/1 → {"name": "Buddy", "status": "available"}  (from cassette)
# Next run: GET /pets/1 → {"name": "Buddy", "status": "available"}  (identical!)

# Your test:
response = client.get("/pets/1")
assert response.name == "Buddy"  # PASSES every time

VCR recording eliminates this class of flakiness entirely. Record once, replay forever. When the real API changes, re-record to update the cassette.

CI/CD Integration Showdown

APIGhost

# GitHub Actions
- name: Start mock API
  run: |
    pip install apighost
    apighost serve api-spec.yaml -p 8080 &
    sleep 2

- name: Run integration tests
  run: pytest tests/integration/

# Deterministic replay
- name: Replay recorded interactions
  run: |
    apighost replay integration-cassette -p 8080 &
    sleep 2
    pytest tests/integration/

Prism

# GitHub Actions
- name: Start Prism mock
  run: |
    npx @stoplight/prism-cli mock api-spec.yaml &
    sleep 3

- name: Run integration tests
  run: npm test

WireMock

# GitHub Actions
- name: Start WireMock
  run: |
    java -jar wiremock-standalone.jar --port 8080 &
    sleep 2

- name: Load stubs
  run: |
    for f in stubs/*.json; do
      curl -X POST http://localhost:8080/__admin/mappings -d @$f
    done

- name: Run integration tests
  run: mvn test

Mockoon

# GitHub Actions
- name: Start Mockoon CLI
  run: |
    npx @mockoon/cli start --data ./my-api.json &
    sleep 3

- name: Run integration tests
  run: npm test

All four tools work in CI. The difference is setup effort: APIGhost and Prism need one command (spec file → running server). WireMock needs stubs loaded. Mockoon needs a JSON config exported from the desktop app.

When to Use Which

The Hybrid Approach

Many teams combine tools based on the task:

• APIGhost for integration tests — VCR record/replay eliminates flakiness. Scenario switching covers edge cases.
• WireMock for unit tests — Fine-grained stubs for testing specific HTTP error codes, timeouts, and malformed responses.
• Prism for API validation — Proxy mode validates real API responses against the spec during staging.
• Mockoon for prototyping — GUI mock building for early design exploration before the spec is finalized.

# Typical workflow:
# 1. Design: Mockoon (visual prototyping)
# 2. Spec: Write OpenAPI spec from prototype
# 3. Develop: APIGhost serve (spec → mock server for frontend team)
# 4. Test: APIGhost record + replay (deterministic integration tests)
# 5. Validate: Prism proxy (validate staging API against spec)
# 6. Edge cases: WireMock (fault injection, specific error scenarios)

Cost Comparison

Factor	APIGhost	Prism	WireMock	Mockoon
License	MIT (Free tier)	Apache 2.0	Apache 2.0	MIT
Free tier limits	100 req/session	None	None	None
Pro/paid tier	$12/mo	N/A	N/A (Cloud: $)	N/A (Cloud: $)
Runtime dep size	~15MB (Python)	~50MB (Node)	~15MB (JAR)	~200MB (Electron)
Setup time	30 seconds	1 minute	15 minutes	10 minutes

Install APIGhost

# pip
pip install apighost

# Start a mock server from your OpenAPI spec
apighost serve your-api-spec.yaml

# Record real interactions
apighost record your-api-spec.yaml

# Replay them deterministically
apighost replay your-recording

Star APIGhost on GitHub

Related Reading

• OpenAPI Spec to Mock Server in 60 Seconds — quickstart guide
• APIGhost Advanced Patterns — scenarios, VCR, and edge cases
• Turn Any OpenAPI Spec into a Running Mock Server — full tutorial
• API Key Management Compared — secrets management comparison