How to Generate Mock API Response Data for Frontend Development

Mock API response data is a realistic, fake JSON payload — a user object, a list of orders, a paginated search result — that a frontend can call against before the real backend endpoint exists or is reachable. It's served by a mock server or request interceptor sitting in place of the real API, not stored in a database, which is what separates mocking an API response from seeding a database with test data for an app to query directly.

Frontend work stalling on a backend endpoint that isn't built yet is one of the most common reasons teams reach for mocking in the first place. The gap between "mock returns a user" and "mock returns data that actually exercises pagination, empty states, and cross-endpoint consistency" is where most hand-written fixtures fall short — and it's the gap this post is about closing.

What is mock API response data?

It's a JSON (or other format) payload shaped exactly like what a real endpoint would return, used as a stand-in during development so a frontend doesn't need a live, fully-built backend to render against. A GET /api/users/123 mock returns something shaped like a user record; a GET /api/orders?page=2 mock returns something shaped like a page of orders, with the same field names, types, and nesting the real endpoint would use. The point isn't just "valid JSON" — it's JSON that looks enough like production data that UI bugs (a name too long for its container, a null field the component doesn't guard against, a date formatted wrong) show up in development instead of after launch.

Mocking vs. stubbing — what's the difference?

The terms get used interchangeably, but there's a useful distinction. A stub is usually a single hardcoded response wired to one specific scenario — "when this test calls this endpoint, return exactly this object." A mock, in the looser sense frontend teams use it, is closer to standing in for the whole endpoint during day-to-day development: varied data, multiple records, pagination that actually works across pages. Static stubs are fine for a unit test asserting on one known shape; they get thin fast the moment you need to mock REST API responses for an entire screen with a list, a search, and an empty state, all backed by data that doesn't repeat the same three fake names.

Why generate mock API data instead of hand-writing fixtures?

Hand-writing a JSON fixture works for the first request. It gets expensive in ways that show up gradually:

• Volume. A hand-typed fixture gives you the handful of records someone had patience to type — usually 3 to 5. That's enough to check a component renders, and not enough to catch a pagination bug, a virtualized list that breaks past 50 rows, or an infinite-scroll trigger that never fires because there's nothing left to load. A single JsonFabrica template can generate 1 record or 10,000 from the same definition, so mocking realistic list volumes is a count parameter, not a re-typing exercise.
• Cross-endpoint consistency. A frontend rarely calls one endpoint in isolation — a user detail page also calls that user's orders, that user's activity feed, and so on. Hand-written stubs for each endpoint drift apart: the user in users.json doesn't have the same name as the user referenced in orders.json, because a person typed both files separately. Generating the linked records in one relational batch keeps ids and names actually consistent across every endpoint that references them.
• Realistic values. Placeholder values like "Test User 1" or "[email protected]" don't stress a UI the way a genuinely long name, an address with a unicode character, or a date near a month boundary does. Generated fields — names, addresses, emails, dates — read like real data because they're drawn from real-shaped corpora, not typed by a developer in a hurry.
• One definition, many consumers. The same payload definition can feed MSW handlers, Playwright fixtures, Storybook stories, and a CI smoke test, instead of the same JSON blob getting copy-pasted (and slowly diverging) across all four.

How do I generate mock REST API responses?

JsonFabrica isn't a mock server — it doesn't intercept requests or run alongside your frontend. It's the data source you point a mock server at. You describe a response shape once as a JsonFabrica template, then call the generation API to produce payloads you drop into whatever's already intercepting your requests: MSW, json-server, Stoplight Prism, WireMock, or Beeceptor.

For a single response — say, the payload behind GET /api/users/123 — call the template's generate endpoint and hand the result straight to an MSW handler or a static fixture file:

curl -s -X POST https://api.jsonfabrica.com/v1/templates/tpl_user/generate \
  -H 'Authorization: Bearer sk_...' \
  -H 'content-type: application/json' \
  -d '{"seed": 42}'

That returns one record shaped like a user. Fix the seed value and the same call returns the identical record every time — useful for a snapshot or visual-regression test that needs stable output — or drop seed to get fresh values on every call.

How do I keep mock API data consistent across endpoints?

The screen that actually exposes hand-written mocks is the one where a user detail page and that same user's orders list both need to agree on who the user is. If users.json and orders.json were typed separately, they'll drift: different names, different ids, an order pointing at a userId that doesn't exist in the user mock at all.

A relational batch generation API call solves this by generating both sets of records together, with one document's field wired to another document's output through a relations map:

{
  "documents": [
    { "templateId": "tpl_user", "alias": "user", "count": 20 },
    {
      "templateId": "tpl_order",
      "alias": "order",
      "count": 80,
      "relations": { "userId": { "from": "user.id", "strategy": "round-robin" } }
    }
  ]
}

The response is 20 users and 80 orders where every order.userId is actually one of the 20 generated user ids — so mocking GET /api/users/:id and GET /api/users/:id/orders from the same batch means the two responses agree, instead of a frontend engineer having to notice and fix the mismatch by hand.

Can I generate mock data from an OpenAPI spec?

Not by pointing JsonFabrica at the spec file and having it build the template automatically — that's not a feature it has today. What you do is translate the responses schema already documented in your OpenAPI spec into a JsonFabrica template by hand: for each field, pick the matching generation function (a string with format: email becomes getRandomEmail, a date-time field becomes getRandomDate formatted with formatDate, and so on). It's a one-time mapping exercise per endpoint, not zero effort — but once the template exists, it generates conforming payloads at any volume from then on, which a hand-written OpenAPI example object never does.

Do I still have to update mock data when the schema changes?

Yes, and it's worth being direct about this rather than overselling it: JsonFabrica doesn't watch your API schema and regenerate mock data automatically when a field changes. Add a field to the real endpoint, rename one, or change a type, and you edit the JsonFabrica template by hand — exactly the same action as editing a static fixture file. On pure maintenance effort, this is a wash, not a win.

The actual advantage is narrower and more honest: it's one template to edit instead of N hand-written JSON blobs scattered across MSW handlers, Storybook stories, and Playwright fixtures. If three consumers all pull from the same generated payload, one template edit fixes all three; if they were three separate hardcoded fixtures, that's three edits, and it's easy to miss one. That's a real convenience win on collaboration and drift — it's just not "stays in sync automatically," and it isn't sold as such here.

FAQ

What is mock API response data? Mock API response data is a fake but realistic JSON payload shaped like a real endpoint's response, used to develop and test a frontend before or without a live backend. It's typically served through a mock server or interceptor such as MSW, json-server, Prism, or WireMock, which returns the mock payload instead of forwarding the request to a real API.

What's the difference between mocking and stubbing an API? Stubbing usually means a single hardcoded response wired to one specific test case, while mocking means standing in for an endpoint more generally, often with varied or larger datasets, across many calls during development. In practice the terms overlap a lot, and the tools mentioned here work for both.

How do I keep mock API data consistent across endpoints? Generate the records for related endpoints in one batch call with relations between them, so a GET /users/123 response and a GET /users/123/orders response reference the same underlying id and name instead of being typed separately by hand. A relational batch generation API can produce that linked set directly.

Can I generate mock data from an OpenAPI spec? Not automatically by pointing a tool at the spec file. You still translate the response schema in your OpenAPI document into a JsonFabrica template by hand, field by field, but once that template exists you can generate any number of conforming records or a full relational batch from it with a single API call.

Do I still have to update mock data when the API schema changes? Yes. JsonFabrica doesn't watch your schema and regenerate mocks automatically — when a field is added, renamed, or removed you edit the template the same way you'd edit a static fixture file. The advantage is narrower than "stays in sync": you're editing one template instead of patching the same field across every hand-written JSON blob scattered through your mocks.

What tools can I use to serve mock API responses to a frontend? MSW (Mock Service Worker), json-server, Stoplight Prism, WireMock, and Beeceptor are common choices for actually intercepting or serving requests. JsonFabrica isn't one of these — it generates the response payloads you feed into whichever of these tools your team already uses.

JsonFabrica doesn't replace your mock server — it's the payload generator that feeds it, producing realistic single records or relationally-consistent batches through the template generation API so your MSW handlers, Storybook stories, and Playwright fixtures pull from data that actually holds together across endpoints.