Generate Mock JSON for API Development and Prototyping

With Sequential IDs on, json-server's path routing works immediately because ids are integers.

// Generated: count 25, seed 42, Sequential IDs ON → paste under 'users'
// db.json
{
  "users": [
    { "id": 1, "index": 1, "name": "Grace Davis", "email": "grace.davis@mock.dev", "status": "pending", ... },
    { "id": 2, "index": 2, "name": "Frank Wilson", "email": "frank.wilson@sample.io", "status": "suspended", ... }
  ]
}

// $ npx json-server db.json
//   GET /users        → the full array
//   GET /users/1      → Grace's record (path routing by integer id)

The seed keeps the mocked response identical across reloads, so component tests against MSW do not flake on data order.

import { http, HttpResponse } from 'msw';
import users from './users.json'; // count 20, seed 42

export const handlers = [
  http.get('/api/users', () => HttpResponse.json(users)),
  http.get('/api/users/:id', ({ params }) =>
    HttpResponse.json(users.find(u => String(u.id) === params.id))
  ),
];

The generator gives the records; the envelope is yours. Build the contract shape around the array by hand.

import users from './users.json'; // count 50, seed 42

const page1 = {
  data: users.slice(0, 10),
  pagination: { page: 1, perPage: 10, total: users.length }
};

// http.get('/api/users', () => HttpResponse.json(page1))

If the real API uses snake_case, align the mock now so the swap-over needs no front-end changes.

Step 1 — generate count 30, seed 42 here.
Step 2 — json-key-renamer:
  name      → full_name
  createdAt → created_at
  active    → is_active

Result per record:
{ "id": 1, "full_name": "Grace Davis", "created_at": "2024-01-17", "is_active": false, ... }

For GET /users/:id mocks, generate one record (or slice the first from a larger array).

// Generated: count 1, seed 99
const user = {
  id: 1, name: "Alice Smith", email: "alice.smith@mock.dev",
  status: "active", score: 97.8, address: { city: "Capitol City" }
};
// http.get('/api/users/1', () => HttpResponse.json(user))

The generator does not read OpenAPI, JSON Schema, or an example object. It emits the fixed person shape and ignores any input. Generate the base array and reshape it to your contract with json-key-renamer and json-key-filter.

The generator emits a bare array, not a paginated envelope. Wrap it yourself: { data: users.slice(0, 10), total: users.length, page: 1 }. The generator's job is the record list; the response shape is yours.

json-server path routing keys on the id field. If you generated UUID ids but request an integer path (or vice versa), the lookup misses. Match the id mode to your routing: Sequential IDs on for integer paths, off for UUID paths.

The generator only emits success records. Author error bodies by hand in your MSW handler or json-server middleware — e.g. HttpResponse.json({ error: 'Not found' }, { status: 404 }). There is no error-shape mode.

Decide the casing once and align the mock to the real contract before you build against it. Run the generated array through json-key-renamer so the field names match — then swapping in the real API needs no front-end changes.

Emails derive from a 100-combination name pool plus 5 domains, so collections over ~100 records will contain duplicate emails. If your mocked endpoint enforces unique emails, keep the count small or de-duplicate the array before serving.

The id mode shifts the random stream, so the non-id fields change too at the same seed. Lock your id mode before committing to a seed, otherwise a teammate who flips it gets different mock data.

Free caps at 500 records. For prototyping you rarely need more — paginate the array client-side instead. Pro raises the cap to 10,000 if you genuinely need a large mock collection.

The only nesting the generator produces is the built-in address object. It cannot generate related collections (a user's orders, a post's comments). Generate each resource separately and stitch the relations by hand or in json-server's relationship config.