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
Receive webhooks locally via tunnel
Remote Team Collaboration
Share mock APIs without deploying
Client Demos
Demo API mocks with a public URL
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.
# 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.
# 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 testMicroservices 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.
# 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.yamlIoT & 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.
# 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.
# 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.crtWebhook Development
Receive webhooks locally via tunnel
Webhook integrations are notoriously difficult to develop and test locally. Providers like Stripe, GitHub, and Twilio need a publicly accessible URL to deliver events, forcing developers to deploy to staging environments or use third-party tunneling tools just to iterate on webhook handlers.
With Mockd's built-in cloud tunnel, you can receive webhooks on your local machine with a single command. Run mockd tunnel --port 4280 and you get a public URL that routes traffic directly to your local mock server. No signup required for anonymous tunnels, and no third-party tools to install.
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. The tunnel supports all 7 protocols through a single secure connection on port 443, so it works through firewalls and NAT without any port forwarding.
# Start your mock server with webhook handlers
mockd add http --path "/webhooks/stripe" \
--method POST \
--body '{"received": true, "event": "{{request.body.type}}"}'
# Expose it via cloud tunnel
mockd tunnel --port 4280
# => https://abc123.tunnel.mockd.io
# Point Stripe to your tunnel URL
# Stripe Dashboard → Webhooks → Add endpoint
# URL: https://abc123.tunnel.mockd.io/webhooks/stripeRemote Team Collaboration
Share mock APIs without deploying
Sharing mock APIs with remote teammates typically requires deploying to a staging server, setting up cloud infrastructure, or maintaining a shared development environment. This adds friction to the development process and creates delays when iterating on API designs.
Mockd's cloud tunnel eliminates this overhead. Any team member can share their local mock server with a public URL by running a single command. Remote teammates, QA engineers, and stakeholders can access the mocks immediately without any deployment step.
For paid tiers, tunnel authentication (token, basic auth, or IP allowlisting) ensures that only authorized users can access your shared mocks. Custom subdomains on Team and Enterprise plans provide stable, memorable URLs for ongoing collaboration.
# Developer A: Share mock API with the team
mockd start --config api-mocks.yaml
mockd tunnel --port 4280
# => https://abc123.tunnel.mockd.io
# Developer B: Point frontend to shared mocks
VITE_API_URL=https://abc123.tunnel.mockd.io npm run dev
# With auth (Pro+ tiers)
mockd tunnel --port 4280 \
--auth-token "team-secret-123"
# With custom subdomain (Team+ tiers)
mockd tunnel --port 4280 \
--subdomain my-projectClient Demos
Demo API mocks with a public URL
Demonstrating API mocks to clients and stakeholders shouldn't require deploying to a server. Whether you're presenting an API design proposal, showcasing a prototype, or walking through integration documentation, you need a quick way to make your mocks accessible.
With Mockd's built-in tunnel, you can share a live mock server during a call or meeting with zero setup. Your client sees real responses from your mock API, can test endpoints in their browser or API client, and can provide immediate feedback on the API design.
This is especially powerful for API design and prototyping workflows. Define your API contract as mock configurations, share a tunnel URL with consumers, and iterate on the design in real time. Catch contract mismatches and usability issues before writing any backend code.
# Prepare demo mocks
mockd start --config client-api-v2.yaml
# Share with client via tunnel
mockd tunnel --port 4280
# => https://xyz789.tunnel.mockd.io
# Client can test immediately:
# curl https://xyz789.tunnel.mockd.io/api/v2/products
# curl https://xyz789.tunnel.mockd.io/api/v2/orders
# Anonymous tunnels last 2 hours — perfect
# for a demo session. No signup required.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.
# 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.yaml7
Protocols Supported
<10ms
Startup Time
0
Dependencies Required
100%
Local & Offline
Ready to Transform Your Workflow?
Ship faster with Mockd. Get started in under a minute.
curl -sSL https://get.mockd.io | sh