Do I need an account to create a mock REST API endpoint?

No. There is no signup, no email and no API key — you POST the mock definition and get a live URL back. Each mock returns a one-time admin token that you keep if you want to edit or delete it later.

How long does the endpoint stay up?

Seven days by default, thirty at the outside. That covers the usual gap between "the frontend is ready" and "the backend is ready", and the expiry keeps stale fixtures from leaking into production.

Can the response change between calls?

Yes. Use faker tokens for a fresh body each call, a response sequence to return different statuses in order, or a delay to simulate a slow endpoint. A fixed body is only the simplest case.

Mock a REST API endpoint

Get a public JSON endpoint to unblock your frontend before the backend exists.

A mock REST API endpoint is a public URL that returns JSON you defined, with no server of your own behind it. You describe the method, status code and response body once, and the mock answers every call with exactly that. It is the fastest way to unblock frontend work while the real backend is still being written: creating a mock and calling it took a median of 0.73 seconds across 20 runs from a European client, measured on 2026-09-08.

What JSON should the mock return?

Return the response your interface actually expects, not a simplified stand-in. The whole value of the mock is that you write real parsing code against it, so the shape has to match the contract you agreed with the backend team.

Keep the envelope. If the real API wraps results as {"data": [...], "total": 42}, mock the wrapper too. Code written against a bare array breaks the day the real endpoint arrives.
Keep the types. An id that is a string in production must be a string here. Silent number-to-string drift is the single most common cause of a mock that works and a real call that does not.
Include the awkward fields. Nulls, empty arrays and optional keys are exactly what your rendering code gets wrong, so put at least one of each in the fixture.

How do you mock error responses and CORS?

A mock that only ever returns 200 tests half your code. Set response_status to 404, 422 or 500 and point a second mock at it, so your error branches get exercised as deliberately as the happy path. The MDN status code reference is the quickest way to pick the honest one.

If you are calling the mock from a browser rather than from curl, set cors_enabled to true. Without it the browser blocks the response before your code ever sees it, and the console error rarely names the real cause — see MDN on CORS. For error bodies worth standardising, RFC 9457 Problem Details gives you a format the rest of the industry already parses.

How do you swap the mock for the real API later?

Put the base URL in configuration on day one, never inline in a component. Point it at the mock URL now and at the real host later, and the swap is a one-line change instead of a search across the codebase.

Mocks here last seven days by default and up to thirty at most, which is usually longer than the gap you are bridging. That expiry is a feature: a mock that quietly outlives the real endpoint is how a fixture ends up in production. If a teammate needs the same fixture, share the create command rather than the URL, so everyone can regenerate it.

What usually goes wrong?

Mocking the response you wish you had. Design the fixture from the backend's actual contract, not from what would be convenient to render.
Forgetting the content type. Without "content_type": "application/json" many clients hand you a string and your parser fails on valid JSON.
Testing only the happy path. If no test ever sees a 500, your error handling is unproven, not correct.
Leaving the mock URL in a merged branch. Configuration, not source, and the seven-day expiry stops it becoming permanent.

When to use this

When the backend isn't ready, the frontend stalls. Stand up a mock that returns the exact JSON your UI expects, get a public URL, and build against it now — swap in the real API later.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"users\":[{\"id\":1,\"name\":\"Ada\"}]}"
}'

Call it

curl https://quickmock.dev/m/<slug>

What you get

{"users":[{"id":1,"name":"Ada"}]}

FAQ

Do I need an account to create a mock REST API endpoint?: No. There is no signup, no email and no API key — you POST the mock definition and get a live URL back. Each mock returns a one-time admin token that you keep if you want to edit or delete it later.
How long does the endpoint stay up?: Seven days by default, thirty at the outside. That covers the usual gap between "the frontend is ready" and "the backend is ready", and the expiry keeps stale fixtures from leaking into production.
Can the response change between calls?: Yes. Use faker tokens for a fresh body each call, a response sequence to return different statuses in order, or a delay to simulate a slow endpoint. A fixed body is only the simplest case.

Build your own

Create a mock

Ready-made templates for this: Mock an OAuth2 token response, Mock an OpenID Connect discovery document, Mock a JWKS endpoint for JWT verification

Related guides

← All guides

Last updated: 2026-09-08