Real-World Scenarios

API Mocking for Every Workflow

From frontend development to enterprise integration, discover how teams use Mockd to accelerate development, improve testing, and ship with confidence.

Frontend Development

Build UIs without waiting for backend

Integration Testing

Deterministic, reliable test suites

Microservices Development

Mock dependent services locally

IoT & Real-time Applications

Simulate devices and streams

Enterprise & Legacy Integration

SOAP, gRPC, and secure mocking

Webhook Development

Build and test webhook handlers locally

API Design & Prototyping

Design-first API development

Frontend Development

Build UIs without waiting for backend

Frontend teams often face a common bottleneck: waiting for backend APIs to be ready before they can build and test their user interfaces. This dependency creates delays, blocks parallel development, and makes it difficult to iterate quickly on designs.

With Mockd, frontend developers can start building immediately by creating mock endpoints that mirror the expected API contracts. Define the response shapes, error states, and edge cases you need to test, then build your UI against these mocks. When the real backend is ready, simply switch the endpoint URL.

Beyond basic development, mocking enables comprehensive testing of error handling, loading states, and edge cases that would be difficult or impossible to trigger with real backends. Need to test what happens when the API returns a 503? Or when a field is unexpectedly null? Mocks make these scenarios trivial to reproduce.

Learn about HTTP mocking

Example

# Mock a user API for frontend development
mockd add http --path "/api/users/{id}" \
  --body '{"id": "{{request.pathParam.id}}", "name": "Jane Doe", "email": "jane@example.com"}'

# Test error state
mockd add http --path "/api/users/404" \
  --status 404 \
  --body '{"error": "User not found"}'

Integration Testing

Deterministic, reliable test suites

Integration tests that depend on external APIs are inherently flaky. Third-party services go down, rate limits get hit, test data gets corrupted, and network latency varies. These issues lead to intermittent test failures that erode confidence in your test suite.

Mockd solves this by providing deterministic mock responses for every external dependency. Record real API responses once, then replay them consistently in every test run. Your tests become fast, reliable, and completely isolated from external factors.

The CI/CD integration is seamless: spin up Mockd as part of your pipeline, load your mock configurations, run your tests, and tear down. Since Mockd starts in under 10ms and requires no external dependencies, it adds virtually no overhead to your build times.

Learn about HTTP mocking

Example

# Record real API traffic through the proxy
mockd proxy start --mode record --port 8888
# Then point your app at the proxy:
# http_proxy=http://localhost:8888 your-app

# Convert recordings to mock config
mockd convert --session default --output ./fixtures/mocks.yaml

# Run tests against recorded mocks
mockd serve --config ./fixtures/mocks.yaml &
PAYMENT_API=http://localhost:4280 npm test

# In CI pipeline (GitHub Actions)
jobs:
  test:
    steps:
      - uses: getmockd/setup-mockd@v1
        with:
          config: ./fixtures/mocks.yaml
      - run: npm test

Microservices Development

Mock dependent services locally

Developing in a microservices architecture presents unique challenges. Your service might depend on five, ten, or even dozens of other services. Running all of them locally is impractical - it consumes resources, requires complex setup, and creates a maintenance burden.

Mockd enables service isolation by mocking all dependencies. Define the contracts your service expects, create mocks that fulfill those contracts, and develop in isolation. Test how your service behaves when dependencies are slow, unavailable, or return unexpected data.

For chaos engineering, Mockd's fault injection capabilities let you simulate realistic failure scenarios. Add random latency, inject errors at specific rates, or simulate partial outages. Build confidence that your service handles failures gracefully before they happen in production.

Learn about gRPC mocking

Example

# Mock multiple dependent services in one config
# mockd.yaml — mocks section
mocks:
  - id: user-service
    type: http
    http:
      matcher: { method: GET, path: /api/users/{id} }
      response:
        statusCode: 200
        body: '{"id": "1", "name": "Alice"}'

  - id: inventory-check
    type: http
    http:
      matcher: { method: GET, path: /api/inventory/{sku} }
      response:
        statusCode: 200
        body: '{"available": true}'
        delayMs: 250

  - id: payment-charge
    type: http
    http:
      matcher: { method: POST, path: /api/payment/charge }
      response:
        statusCode: 200
        body: '{"status": "ok"}'

# Start all mocks
mockd serve --config mockd.yaml

IoT & Real-time Applications

Simulate devices and streams

IoT applications face unique testing challenges. You can't always have physical devices available, device behavior is hard to reproduce consistently, and testing at scale requires hardware you might not have. Real-time applications using WebSockets or SSE have similar challenges with testing bidirectional communication.

Mockd's protocol support extends beyond HTTP to MQTT, WebSocket, and SSE - the protocols that power IoT and real-time systems. Simulate hundreds of virtual devices publishing sensor data, test how your application handles connection drops and reconnections, and verify message ordering and delivery guarantees.

For real-time web applications, mock WebSocket servers that push updates on demand, simulate SSE streams for live dashboards, and test how your frontend handles connection state changes. Build robust real-time features without complex infrastructure.

Learn about MQTT mocking

Example

# Add MQTT device mock (sensor data)
mockd add mqtt \
  --topic "sensors/temperature" \
  --payload '{"temp": 22, "unit": "celsius"}'

# Add WebSocket mock (real-time feed)
mockd add websocket \
  --path "/ws/live-feed" --echo

# Add SSE mock (notification stream)
mockd add http --path "/events/notifications" --sse \
  --sse-event 'notification:{"message": "New update"}'

# Or define all protocols in one config
# mockd.yaml — mocks section
mocks:
  - id: mqtt-sensor
    type: mqtt
    mqtt:
      port: 1883
      topics:
        - topic: sensors/temperature
          messages:
            - payload: '{"temp": 22, "unit": "celsius"}'
              interval: "5s"
              repeat: true

  - id: ws-feed
    type: websocket
    websocket:
      path: /ws/live-feed
      echoMode: true

  - id: sse-notifications
    type: http
    http:
      matcher: { method: GET, path: /events/notifications }
      sse:
        events:
          - type: notification
            data: '{"message": "New update"}'
        timing: { fixedDelay: 3000 }

Enterprise & Legacy Integration

SOAP, gRPC, and secure mocking

Enterprise environments often involve legacy systems that are difficult to replicate in development. SOAP/XML services from decades-old systems, mainframe integrations, and partner APIs with strict security requirements create barriers to effective testing.

Mockd supports enterprise protocols including SOAP/XML web services and gRPC microservices. Mock legacy SOAP endpoints complete with WSDL validation, or create gRPC mocks directly from your .proto files. No need to maintain separate tooling for each protocol.

For security-sensitive scenarios, Mockd provides mTLS (mutual TLS) authentication. Configure client certificate requirements, match requests based on certificate fields, and ensure your security testing is comprehensive. Meet compliance requirements with detailed audit logging to file, stdout, or external systems like Splunk.

Learn about SOAP mocking

Example

# Mock a SOAP web service
mockd add soap \
  --operation "GetCustomerDetails" \
  --response '<GetCustomerDetailsResponse>
    <Name>Alice Smith</Name>
  </GetCustomerDetailsResponse>'

# gRPC mock from proto file
mockd add grpc \
  --proto ./service.proto \
  --service "myapp.UserService" \
  --rpc-method "GetUser" \
  --response '{"id": 1, "name": "Test User"}'

# Enable mTLS authentication
mockd serve --config mockd.yaml \
  --tls-cert ./server.crt \
  --tls-key ./server.key \
  --mtls-enabled \
  --mtls-ca ./client-ca.crt

Webhook Development

Build and test webhook handlers locally

Webhook integrations are notoriously difficult to develop and test. Providers like Stripe, GitHub, and Twilio deliver events as POST requests, and iterating on your handler logic usually means waiting on real events or piecing together test payloads by hand.

With Mockd, you can model webhook traffic directly on your local machine. Define mock endpoints that mirror provider payloads, then drive requests at them to exercise your handlers exactly the way a provider would.

Create mock endpoints that simulate webhook payloads, test your handler logic against realistic event data, and verify your error handling for malformed or unexpected events. Reproduce signature checks, retries, and edge cases deterministically without depending on any third-party delivery.

Learn about HTTP mocking

Example

# Start your mock server with webhook handlers
mockd add http --path "/webhooks/stripe" \
  --method POST \
  --body '{"received": true, "event": "{{request.body.type}}"}'

# Drive a sample webhook payload at your handler
curl -X POST http://localhost:4280/webhooks/stripe \
  -H "Content-Type: application/json" \
  -d '{"type": "payment_intent.succeeded"}'

API Design & Prototyping

Design-first API development

The best APIs are designed before they're built. But traditional development often inverts this - backends are built first, and frontends adapt to whatever API emerges. This leads to awkward interfaces, unnecessary round trips, and poor developer experience.

Mockd enables true design-first development. Define your API contract as mock configurations, share them with consumers for feedback, iterate on the design, and validate that the interface meets everyone's needs before writing a line of backend code.

For API consumers, early access to mocks means they can start integration work immediately. Share mock configurations via your repository, publish mock servers for partners to test against, and catch contract mismatches before they become production incidents.

Learn about GraphQL mocking

Example

# Define API contract as mock configuration
# api-v2-design.yaml
mocks:
  - id: list-products
    type: http
    http:
      matcher: { method: GET, path: /api/v2/products }
      response:
        statusCode: 200
        headers:
          Content-Type: application/json
        body: '{"products": [], "pagination": {"page": 1, "totalPages": 10}}'

  - id: get-product
    type: http
    http:
      matcher: { method: GET, path: /api/v2/products/{id} }
      response:
        statusCode: 200
        body: '{"id": "{{request.pathParam.id}}", "name": "Sample Product", "price": 29.99}'

# Share with consumers — start mock server
mockd serve --config api-v2-design.yaml

Protocols Supported

<10ms

Startup Time

Dependencies Required

100%

Local & Offline

Ready to Transform Your Workflow?

Ship faster with Mockd. Get started in under a minute.

Get Started Free View All Features

# Quick install
curl -sSL https://get.mockd.io | sh