Dev

Mock HTTP Response Body Generator

Crafting realistic mock HTTP response bodies by hand is tedious, error-prone, and slows down development. This mock HTTP response body generator produces well-structured JSON for the most common REST API patterns: success responses with data, paginated list results, error payloads, created-resource confirmations, and authentication token responses. Just set your resource name and pick a pattern, and you get a copy-ready JSON body in seconds. Front-end developers benefit most when building against an API that doesn't exist yet. Instead of guessing the shape of the response or waiting on a backend team, you get a realistic fixture you can drop straight into your mock server. Tools like MSW, json-server, and Mirage JS all accept raw JSON bodies, so the output slots in with no transformation needed. API documentation writers and technical authors also get a lot of mileage here. Showing a concrete response example alongside an endpoint description makes docs far more useful than a dry schema table. The generated bodies follow widely-recognised REST conventions, so readers immediately understand the structure without additional explanation. For testing, a consistent set of fixtures prevents flaky tests caused by live API calls and keeps your test suite fast. Feeding generated response bodies into unit tests, integration tests, or contract tests with tools like Pact gives you stable, readable test data that is easy to update as your API evolves.

How to Use

  1. Select your desired response pattern from the dropdown: success with data, paginated list, error, created resource, or auth token.
  2. Type your resource name into the Resource Name field using a singular noun that matches your API domain (e.g. 'order', 'product').
  3. Click Generate to produce a valid JSON response body shaped to your chosen pattern and resource.
  4. Copy the output and paste it into your mock server config, test fixture file, or API documentation example.

Use Cases

  • •Mocking a REST endpoint in MSW or Mirage JS before the backend exists
  • •Generating paginated list fixtures for infinite-scroll UI components
  • •Creating error payload examples for 404, 422, and 500 documentation
  • •Seeding Postman mock servers with realistic resource responses
  • •Building auth flow prototypes using generated token response bodies
  • •Writing stable JSON fixtures for Jest or Vitest unit tests
  • •Demonstrating REST response structures in API design workshops
  • •Populating Storybook component stories with realistic API data shapes

Tips

  • →Use snake_case resource names like 'blog_post' or 'line_item' if your API follows Rails or Python conventions — the output keys will match.
  • →Generate one of each pattern for the same resource and save them as a fixture set; this covers the main response states a component needs to handle.
  • →For pagination testing, generate the paginated pattern twice with different page values and wire them to sequential requests in your mock server.
  • →The auth token response works well as a localStorage seed in Cypress or Playwright tests — set it before the test runs to skip the login flow entirely.
  • →When writing API docs in OpenAPI, paste the generated body into the `example` field of your response schema for instant, realistic documentation.
  • →Combine the error pattern with a specific HTTP status code (422 for validation, 404 for not found) in your mock config to test how your UI handles each failure type distinctly.

FAQ

How do I use a generated response body in MSW?

Copy the generated JSON, then return it inside an MSW handler using `HttpResponse.json(yourObject)`. Because the generator produces a plain JavaScript-compatible object structure, you can paste it directly as the response body without any transformation. Match the resource name to whatever your real endpoint will return to keep your mock consistent with the eventual API.

What does a paginated API response body look like?

A paginated response wraps the data array in a metadata envelope containing fields like `total`, `page`, `per_page`, `total_pages`, and sometimes `links.next` and `links.prev`. Choosing the paginated pattern in this generator produces exactly that structure, pre-filled with your chosen resource name so you can see how the envelope relates to the items inside.

What should an API error response JSON body include?

A well-structured error body should contain an `error` or `errors` key, a machine-readable `code` (e.g. `resource_not_found`), a human-readable `message`, the HTTP `status` number, and a `request_id` for server-side tracing. The error pattern in this generator follows that convention so you can copy it directly into your docs or test fixtures.

How do I mock a 201 Created response for a POST endpoint?

Select the 'created resource' pattern, set the resource name to match your endpoint (e.g. 'order' or 'invoice'), and generate. The output includes an `id`, timestamps, and a `status: created` field — the typical shape returned after a successful POST. Pair it with a 201 status code in your mock server configuration.

What is an auth token response body and when do I need one?

An auth token response is returned after a successful login or OAuth exchange. It typically contains `access_token`, `token_type: bearer`, `expires_in` (seconds), and often a `refresh_token`. Use the auth token pattern when mocking login endpoints so your front-end auth logic can consume a realistic payload without hitting a real identity provider.

Can I use these JSON fixtures for contract testing with Pact?

Yes. Copy the generated body into your consumer test as the expected response, then define it as the provider state in your Pact contract. Because the structure follows standard REST conventions, it maps cleanly to Pact's JSON matching rules. You can use exact matching or replace specific values with Pact matchers like `like()` or `eachLike()`.

How do I customise the resource name for my specific API?

Type your resource name into the Resource Name field — use singular nouns like 'product', 'invoice', or 'subscription'. The generator uses this value to name the top-level key and populate `id` fields, making the output feel specific to your domain rather than generic. Avoid spaces; use underscores if your API uses snake_case keys.

Are the generated response bodies valid JSON?

Yes. Every output is syntactically valid JSON with proper quoting, comma placement, and bracket closure. You can paste it directly into a JSON validator, a Postman example, or a `.json` fixture file. If you need JavaScript object syntax instead of strict JSON, remove the quotes from keys after pasting.