Skip to content
R3XTools

API Mock Serverserver-backed

Define endpoints, get a real URL, and have your client call it before the backend exists.

Checking for an existing mock…

Reference

Routing

Endpoints are matched top to bottom, by method and then path. The first enabled match answers; nothing else is consulted. There is no specificity scoring, which means a route above can shadow one below it — and you can see that in the list rather than having to deduce it.

PatternMatches
/usersExactly /users. A trailing slash is normalised away, so /users/ is the same route.
/users/:idOne segment, captured. /users/42 matches; /users/42/posts does not.
/files/*Everything from that point on, including nothing — /files and /files/a/b both match.

Dynamic values

Three tokens are substituted in a response body each time it is served: {{uuid}}, {{timestamp}} (Unix seconds) and {{randomNumber}}. Each occurrence gets its own value.

There is deliberately no expression syntax. A template language here would be code execution driven by a public URL, and the point of a mock is a predictable canned response — not a program.

CORS and preflight

With CORS enabled the mock reflects the calling origin, allows the five methods and echoes the requested headers, so a browser front-end can call it without a proxy. A preflight OPTIONS is answered before routing, since the browser is asking whether it may send the real request rather than asking for the endpoint's response.

Turn it off to test how your client behaves against an API that does not allow it.

Lifetime and limits

LimitValue
Mock lifetime24 hours from creation, then the definition and log are deleted.
Endpoints20 per mock.
Response body32 KB per endpoint.
DelayUp to 3000 ms, for testing spinners and timeouts.
Request logThe last 50 requests, with bodies kept up to 8 KB.
Rate240 requests per minute per calling IP address.

Content types other than JSON

A mock returns whatever you set a Content-Type for, and your application will receive it exactly as written. Two things are added to every response and cannot be overridden: Content-Security-Policy: sandbox, and — for types a browser renders as a live document, such as text/html and image/svg+xml Content-Disposition: attachment.

Neither is visible to fetch or XMLHttpRequest, so mocking an HTML or SVG endpoint your app requests works unchanged. What changes is opening such a mock directly in a browser tab: it downloads instead of rendering.

The reason is that a mock's body is written by whoever holds the URL and served from the same origin as this site. Without those two headers, a mock returning a script would run with R3X's privileges — including access to the tokens that read your webhook captures. Mocking an API is the job; hosting a page from one was never part of it.

Who can call it

Anyone with the base URL. Editing the definition needs the manage token held in this browser, but the endpoints themselves are open — they have to be, or your application could not call them. Put nothing in a response body that you would mind a stranger reading.

Changes are not live until you save. The running mock keeps answering with the last saved definition, which is why the button says so rather than saving on every keystroke.

Questions

How do I fake an API before the backend exists?
Create a mock, define the paths, status codes and JSON bodies you expect, and point your client at the base URL. It is a real HTTP endpoint, so your app's actual network layer is exercised rather than a stub inside your test process.
Can I simulate a slow or failing endpoint?
Yes. Every endpoint takes a delay of up to 3000 ms and any status code from 100 to 599, so you can test loading states, timeout handling and error paths without changing your client.
Does it support CORS?
Yes, and it is on by default: the mock reflects the calling origin and answers preflight requests, so a browser front-end can call it with no proxy. Turn it off to check how your client behaves against an API that does not allow it.