In-Browser Mock Server
Prototype client frontends, simulate multi-status responses, and test network latency before backend APIs exist. No Prism, no Docker, zero external CLI processes — built directly into your single RapiDoc bundle.
Test In-Page Fetch Interception Live
The <rapi-doc> element below is mounted with mock-server="true". Use the live test controls to trigger actual window.fetch() requests from this page, and see them intercepted and resolved with mock data in real time!
fetch() TesterINTERCEPTOR READY// Click "Execute In-Page fetch()" above to test interception...The Problem with Traditional API Mocking
The Cross-Origin CORS Trap
External mock servers like Prism or WireMock listen on separate ports (e.g. localhost:4010). Frontend developers spend hours debugging Preflight OPTIONS requests and CORS header misconfigurations instead of shipping features.
Heavy Containers & Node Services
Running Docker or dedicated CLI processes requires team-wide environment setup, npm package management, and port allocation across multiple repositories.
Zero-Dependency Native Interception
RapiDoc intercepts window.fetch and XMLHttpRequest directly inside the browser runtime. There is nothing to install, compile, or boot.
Unified Source of Truth
Mock data is generated on the fly from the exact same OpenAPI specification that powers your documentation. When the spec evolves, the mock responses update instantly.
RapiDoc vs Dedicated Mock Solutions
| Feature | RapiDoc Built-In | Prism (Stoplight) | MSW (Mock Service Worker) | WireMock / Docker |
|---|---|---|---|---|
| Setup Complexity | ✓ 1 HTML attribute | Node CLI / Docker container | Requires service worker script asset | Heavy JVM / Docker container |
| Single Bundle Distribution | ✓ Included in rapidoc-min.js | ✕ Separate CLI | ✕ Separate SW worker file | ✕ Standalone container |
| CORS Issues | ✓ Zero (In-browser intercept) | ✕ Cross-origin port headaches | ✓ Handled by worker | ✕ Manual CORS headers required |
| Works via CDN Script | ✓ Yes (unpkg / jsdelivr) | ✕ No | ✕ No (SW domain restriction) | ✕ No |
| Interactive API Docs Included | ✓ Full RapiDoc UI | ✕ Mock only | ✕ Mock only | ✕ Mock only |
| Multi-Status & Chaos (Cycle/Random) | ✓ Built-in strategies | Limited | Manual handler coding | Requires scenario rules |
How to Use in Your Application
1. Standard HTML & Documentation Portals
Drop the script tag onto your page and turn on mocking with mock-server="true":
<script type="module" src="https://unpkg.com/rapidoc/dist/rapidoc-min.js"></script>
<!-- Enable the built-in mock server with a single attribute -->
<rapi-doc
spec-url="https://petstore.swagger.io/v2/swagger.json"
mock-server="true"
mock-server-delay="300"
mock-server-log="true"
theme="dark"
> </rapi-doc>2. Testing Resilience & Retry Logic with Multi-Status Codes
Simulate intermittent failures or verify error notifications by cycling through multiple HTTP status codes:
<!-- Cycle through 200, 429, and 500 to test retry logic and banners -->
<rapi-doc
spec-url="/specs/reqres.yaml"
mock-server="true"
mock-server-status-code="200, 429, 500"
mock-server-status-strategy="cycle"
mock-server-delay="400"
> </rapi-doc>3. React, Vite, or Vue Frontend Prototyping
Mount RapiDoc in your development environment to unblock UI components before backend development finishes:
// src/App.jsx - Seamless frontend prototyping without waiting for backend
import React, { useEffect, useState } from 'react';
export default function App() {
const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
useEffect(() => {
// Intercepted in-page by RapiDoc! Resolves instantly from OpenAPI spec
fetch('/api/users')
.then((res) => res.json())
.then((data) => {
setUsers(data.data || []);
setLoading(false);
});
}, []);
if (loading) return <div className="spinner">Simulating network latency...</div>;
return (
<div>
<h2>User Directory (Mocked from OpenAPI)</h2>
<ul>
{users.map(u => <li key={u.id}>{u.first_name} {u.last_name} ({u.email})</li>)}
</ul>
</div>
);
}Mock Server Attributes
| Attribute | Type / Allowed | Default | Description |
|---|---|---|---|
mock-server | true | false | false | Activates the in-browser mock server interceptor. Transparently intercepts outgoing network requests (both in-doc TRY console and host application fetch/XHR calls) and synthesizes realistic mock responses directly from your OpenAPI specification. |
mock-server-status-code | String | (auto) | Target HTTP status code or comma-separated list of codes (e.g. "200, 404, 500") to simulate. If omitted, the mock server automatically picks the first available 2xx response in the spec. |
mock-server-status-strategy | first | cycle | random | first | Selection strategy when multiple status codes are provided in mock-server-status-code. 'first' always returns the first code; 'cycle' round-robins sequentially per endpoint (ideal for testing retry and backoff algorithms); 'random' selects a code randomly for chaos and resilience testing. |
mock-server-delay | Number (ms) | 0 | Simulated network latency in milliseconds before resolving mock responses. Perfect for testing loading skeletons, button disabled states, and race conditions. |
mock-server-log | true | false | true | Logs intercepted requests, matched OpenAPI routes, and synthesized status codes directly to the browser DevTools console. |
Ready for In-Depth Technical Details?
Read our complete Starlight guide on mock response resolution hierarchies, write-only attribute omission, and programmatic control.
