Gera Tools

Random API Response Generator

Fake REST API JSON responses for frontend mocking

Free random API response generator. Produce plausible JSON for common REST resources — user, product, order and event — with realistic ids, names, prices and timestamps. Mock backend responses for frontend development without a live server, all in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What resource types can I generate?

Four common REST resources: user (id, name, email, role, timestamps), product (sku, name, category, price, rating, stock), order (order number, status, line items, total) and event (analytics-style type, ids and properties). Each field uses a realistic value and the correct JSON type.

Mock a backend before it exists

The Random API Response Generator produces plausible JSON for the resources a typical REST API returns — users, products, orders and analytics events. It lets frontend work continue before the real endpoint is built: paste the output into a mock server, a fixture file, or a fetch stub and develop against a realistic response shape.

How it works

Each resource type has a template describing its fields and the JSON type of each one. For every requested record the generator fills that template from curated value pools — names, product titles, categories, currencies — and from small helpers that emit a UUID-style id, an ISO 8601 timestamp, or a two-decimal price. Orders additionally build a nested items array and sum the line totals so the total field is internally consistent. The whole structure is serialized with JSON.stringify and indented, which guarantees the result is valid, parseable JSON.

A seeded pseudo-random source keeps a given configuration stable between renders; pressing Regenerate advances the seed for a fresh set. Turning on the envelope option wraps a multi-record array as { data, meta } to match the pagination shape many APIs use.

Example output

A single generated user record looks like:

{
  "id": "a3f2c7d1-8b4e-4f3a-9c12-2e5a6b8d0f44",
  "name": "Jordan Mercer",
  "email": "[email protected]",
  "role": "member",
  "created_at": "2024-11-03T14:22:07Z",
  "updated_at": "2025-01-18T09:41:33Z"
}

A product record includes a SKU, category, a two-decimal price, and a rating:

{
  "id": "b91d3e72-4a0c-47f8-b52e-1c3d9f8a2b55",
  "sku": "PRD-00472",
  "name": "Ceramic Pour-Over Set",
  "category": "Kitchen",
  "price": 44.99,
  "rating": 4.3,
  "stock": 128
}

An order record builds a nested line-items array and a summed total, so it is safe to test cart logic against.

Where to use the output

Fixture files. Drop the JSON into a __fixtures__ directory and import it in Jest or Vitest tests. This decouples tests from live API calls and makes the test suite deterministic.

MSW (Mock Service Worker) handlers. Paste the output into a handler function so browser fetch calls during development hit a realistic response shape rather than a 404 or empty object.

Storybook stories. Component stories that depend on API data can use generated records to populate all states without spinning up a backend.

Postman / Insomnia mock servers. Most API clients support importing JSON directly as example responses. Generated records fill that role immediately.

Tips and example

  • For a single-object endpoint such as GET /users/:id, set the count to one and leave the envelope off to get a bare object.
  • For a list endpoint such as GET /products, raise the count and enable the envelope so your mock includes meta.total for pagination logic.
  • A generated order keeps its total equal to the sum of its line items, so it is safe to test cart and checkout rendering against it.
  • Treat every value as placeholder data — the names and emails are synthetic and must never stand in for real records.