Mock API

How it works

Every Mock API gets its own subdomain at *.rbmock.dev. Incoming requests are matched against your rules (by method + path) and the first active rule wins. Unmatched requests get a default 200 OK with an empty body. Either way, the request is captured so you can inspect exactly what the caller sent — headers, body, query string, the lot.

Create a Mock API

1. Go to Mock APIs from the sidebar, or pick Mock API inside the New Bin dialog on /bins.
2. A random slug is assigned (e.g. tlx8f.rbmock.dev). PRO users can set a custom slug.
3. Add one or more rules (method + path → status + headers + body).
4. Click Deploy to push the rules to the mock server. The version number bumps on each deploy.
5. Point your integration or test harness at the URL and hit it — captured requests stream into the Requests tab within ~5s.

Rules

A rule describes what a caller request should look like and what the mock should respond with. Rules are evaluated top-down by priority — the first active rule whose method and path match wins.

• Method — one of GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, or * for any method.
• Path — exact match on the request path (up to 2048 chars). Query string is ignored for matching; path starts with /.
• Status code — any HTTP code 100–599. There's a preset dropdown for the common ones.
• Headers — free-form Name: value pairs, one per line.
• Body — any text up to 100 KB. JSON bodies get a "Prettify" shortcut.
• Priority — lower numbers match first. Useful for mixing a generic * /* fallback with specific overrides above it.

Inspecting captured requests

Every request the mock serves is captured in the Requests tab. Filter by Important / Unread, search by method or path, and replay any request server-side via the Replay on server button — or forward it to a saved destination. The captured body view has a Raw / Pretty JSON toggle so JSON payloads are readable without leaving the page.

Auto-forward captured requests (PRO)

Open the Forwarding tab to add rules that auto-send matching captures to a saved destination — useful for piping webhook traffic into staging or replaying production hits into a local tunnel.

• Conditions are ANDed (method, path, header, body, content-type). An empty list means "match every request".
• Destinations are shared with the cloud-bin forwarding feature — manage them at /destinations.
• A saas-side cron evaluates new captures within ~30s of arrival. A per-rule trigger count and last-triggered timestamp show up on the row.
• Outgoing URLs are SSRF-filtered (private IP ranges rejected). In-flight jobs already queued in the runner are not cancelled when you delete or disable a rule.
• Plan: PRO allows 5 rules per mock endpoint; TEAM is unlimited; FREE is locked behind an upgrade teaser.

Sharing

Hit the Share button on the Mock API detail page to generate a public read-only link (/mock-share/<token>). Anyone with the link can see the mock URL, rules, and captured requests — no account needed. Rotate the link to invalidate the old one, or disable sharing to revoke access. Treat the token like a password.

Plan limits

• FREE — 1 Mock API, 1 rule per endpoint (preview). Custom subdomain is locked.
• PRO — 20 Mock APIs, 5 rules each. Custom subdomain.
• TEAM — unlimited Mock APIs, 20 rules each. Custom subdomain.

Limits & caveats

• Response body is capped at 100 KB per rule.
• Mock responses advertise Cache-Control: no-store so the Cloudflare edge doesn't cache them.
• CORS preflight (OPTIONS with Access-Control-Request-Method) is answered automatically — you don't need a rule for it.
• Deploying bumps the config version. The mock server picks up the new config within seconds via Redis.