Skip to main content
Back to Dev generators

Dev

Mock HTTP Response Body Generator

Used by developers, writers, and creators worldwide.

A mock HTTP response body generator saves you from hand-writing JSON fixtures every time you stub a REST endpoint. Pick one of five response patterns — success with data, paginated list, error response, created resource, or auth token — set a resource name, and get a copy-ready JSON body in seconds. Front-end developers use it to unblock UI work before the backend exists. API authors drop the output straight into endpoint documentation. QA engineers feed it into Jest, Vitest, or Pact contract tests to keep fixtures stable. The output follows standard REST conventions, so it slots into MSW, json-server, and Postman mock servers with no transformation needed.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  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

  • •Dropping a paginated list fixture into an MSW handler to develop infinite-scroll UI before the backend is ready
  • •Pasting a generated error payload into Postman as a saved example for 404 and 422 endpoint documentation
  • •Seeding Pact consumer tests with a stable auth token response body to verify front-end login logic
  • •Populating Storybook stories with a realistic created-resource shape for a POST confirmation screen
  • •Replacing a flaky live API call in a Jest test with a controlled success-with-data fixture

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 JSON body in MSW

Copy the output and return it inside an MSW handler using `HttpResponse.json(yourObject)`. The generator produces valid JSON, so you can paste it directly without transformation. Set the resource name to match your real endpoint to keep the mock consistent with the eventual API.

what fields should an API error response body include

A solid error body needs 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 here follows that convention so you can paste it straight into docs or test fixtures without editing the structure.

what does a paginated API response look like vs a plain success response

A plain success response returns your resource directly under a `data` key. A paginated response wraps the item array in an envelope with fields like `total`, `page`, `per_page`, and `total_pages`. Select the paginated pattern and set your resource name to see both levels of the structure filled in.