Mock HTTP Response Body Generator

How to use

1. 1️⃣
   Choose your options above
2. 2️⃣
   Click Generate
3. 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