How to Mock an Unfinished API in Postman Before Backend Delivery

Waiting for the backend is the most common cause of a slipped frontend schedule. A mock server unblocks it in about ten minutes, provided the mock is close enough to the real thing that replacing it is a config change rather than a rewrite.

Direct answer: to mock an API in Postman, create a collection, save at least one example response per request, then click “Mock” on the collection to generate a mock URL. Point your app’s base URL at that mock server and Postman returns your saved examples. The free plan includes 1,000 mock calls per month.

What does an example response actually mean?

An example is a saved response attached to a request: status code, headers, body. The mock server matches the incoming request to a request in the collection and returns one of its examples.

Without an example, the mock returns nothing useful. This trips people up constantly — they create requests, generate the mock URL, call it, and get a 404 or empty body because no example was saved.

Save two examples per request where it matters: a success case and a failure case. Postman picks by matching the x-mock-response-name header, or falls back to the first example.

How does request matching work?

Three modes, set at mock creation:

Mode	Matches on	Use when
Exact	path + query + headers	strict contract testing
Path (default)	path only	normal development
Query params	path + declared params	filtering screens

Path matching is the right default. Exact matching breaks the moment the frontend adds a cache-buster query param, and you spend twenty minutes confused.

For requests with path variables like /users/:id, declare the variable in the URL as {{userId}} rather than :id. Postman treats {{x}} as a wildcard in mock matching; :id is not.

How do you configure the client?

One place, an environment variable:

const BASE = import.meta.env.VITE_API_BASE;
// .env.local  -> https://abc123.mock.pstmn.io
// .env.prod   -> https://api.yourapp.com

Never edit fetch calls to point at the mock. Switching back is then a diff across 40 files, and someone ships the mock URL to production. I have seen that exact bug reach a demo.

Also point your type definitions at the mock contract, not the eventual API. Since the mock is derived from examples you wrote, generating types with openapi-typescript from a spec keeps them honest. Writing types by hand from the mock guarantees drift.

What breaks with mocks?

Both of these bite on day one.

CORS. Mock servers return permissive CORS headers on paid plans; free-plan behaviour is inconsistent for browser requests. If you see an opaque CORS error, that is the cause, not your code.

Auth. A mock cannot validate a JWT. It returns your example response for any Authorization header, so a broken login flow passes every frontend test and fails in staging. Put a real auth check behind a separate flag and test it against staging.

A third: mock latency is zero. Loading states, skeletons, and spinners never render, so nobody notices that the UI has no loading state at all until a real 800 ms response arrives.

Add a deliberate delay. Postman’s mock settings support a response delay; set it to 400-800 ms and you will immediately discover which components lack a loading state.

When does the mock cost more than it saves?

Mocks encode your assumptions. If the backend team has not agreed to the shape, you build a frontend against a contract that will change, and the integration work is larger than if you had waited.

So: write the examples from an OpenAPI spec, or at minimum get the response shape reviewed before building screens against it. A mock built from guesses is a week of rework with extra confidence.

It also stops being useful once the real endpoint exists. Delete the mock collection at that point, or you will have two sources of truth and a team that debugs the wrong one.

What is the alternative?

A static JSON file served from the same dev server. Zero setup, works offline, no quota — but no request matching, no team sharing, and no way to simulate a 500.

If you need per-request control and your team already uses Postman, the mock server is the right call. If you need a single fixture for a design prototype, public/api/users.json is faster and you should not add a dependency for it.

Key Takeaways

• Every mocked request needs a saved example response or the mock returns nothing.
• Path matching is the sane default; exact matching breaks on added query params.
• Use an environment variable for the base URL — never edit fetch calls to point at a mock.
• Mocks cannot validate auth and add zero latency; enable a 400-800 ms delay to expose missing loading states.
• Build mocks from an agreed spec, and delete them once the real endpoint ships.