Mock API Responses for Frontend Dev

Frontend teams rarely have the luxury of waiting for the backend to be finished. Features need to be built, reviewed, and demoed while the API is still a work in progress. That means you need mock API responses -- realistic enough to surface real UI edge cases, structured enough to match the contracts you will eventually consume.

Mock APIs are not just a convenience; they are a critical part of a healthy development workflow. They enable parallel development so frontend and backend teams can work simultaneously without blocking each other. They support offline development when you are on a plane, in a coffee shop with spotty Wi-Fi, or simply don't want to spin up six microservices to test a dropdown. They make demos predictable because live APIs return different data every time, but mocks give you the exact payload you rehearsed with. And they are essential for automated testing -- you cannot write deterministic tests against an API that changes state between runs.

Below you will find ready-to-use API response payloads for the most common REST endpoint shapes, all generated from real schemas using the Mock Data Generator. Every value is realistic: properly formatted UUIDs, valid-looking emails, and plausible timestamps. Click Regenerate for fresh data, Copy to grab it, or Download to save the file.

Common API Response Shapes

Before diving into the data, it helps to understand the envelope patterns that most REST APIs follow. The actual records are only part of the response -- they are wrapped in metadata that tells the client about pagination, status, and errors.

List Endpoints with Pagination

Most list endpoints return an array of records inside a data key, plus a pagination object. This shape works whether the API uses page-based, cursor-based, or offset-based pagination:

{
  "data": [
    { "id": "...", "name": "..." },
    { "id": "...", "name": "..." }
  ],
  "pagination": {
    "page": 1,
    "per_page": 10,
    "total": 47,
    "total_pages": 5
  }
}

Single Resource Endpoints

Endpoints that return a single record (e.g. GET /api/users/123) typically wrap the object in a data key for consistency, though some APIs return the object directly at the top level:

{
  "data": {
    "id": "a1b2c3d4-...",
    "name": "Jordan Rivera",
    "email": "jordan@example.com",
    "created_at": "2026-01-15T09:32:00Z"
  }
}

Error Responses

Consistent error envelopes are just as important as success responses. A well-designed API returns structured errors that frontends can parse programmatically:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request body contains invalid fields.",
    "fields": {
      "email": "Must be a valid email address",
      "name": "Required field is missing"
    }
  }
}

Common HTTP status codes to mock: 400 for validation errors, 404 for missing resources, 422 for unprocessable entities with field-level details, and 429 for rate limiting. Your frontend should handle all of these gracefully -- mock responses are the easiest way to verify that it does.

User List Endpoint

The user list is the most commonly needed mock endpoint. Whether you are building an admin dashboard, a team members page, or a CRM interface, you need records with names, emails, avatars, and roles. This schema simulates GET /api/users and produces the data array that you would wrap in the pagination envelope above.

To simulate a full paginated response, wrap the generated array in the envelope pattern from above. Add pagination.total set to a large number (e.g. 247) so your frontend's pagination controls have something to work with.

Product Search Results

E-commerce and marketplace UIs need product data for search results, category pages, and recommendation carousels. This schema simulates GET /api/products?q=... with realistic product names, prices, categories, and image URLs.

For a complete e-commerce dataset that includes products, orders, customers, and line items connected by foreign keys, see our E-Commerce Test Data guide.

Activity Feed

Activity feeds, audit logs, and notification streams all follow a similar shape: a chronologically ordered list of events with a user reference, action type, timestamp, and optional metadata. This schema simulates GET /api/activity.

Activity feeds are a great place to test edge cases: what happens when a user has no recent activity? What does your UI look like with 500 events? You can adjust the row count above to stress-test your virtualized list or infinite scroll implementation.

Address Book

Contact management UIs, shipping forms, and directory pages all need address data. This schema simulates GET /api/contacts with realistic names, emails, phone numbers, and US addresses.

Address data is particularly tricky to mock well. Real addresses have variable-length street names, states can be abbreviated or spelled out, and zip codes have different formats per country. The generator produces values that follow US address conventions. If you need international addresses, switch the locale in the Mock Data Generator.

Tools for Serving Mock Data

Once you have generated your mock payloads, you need a way to serve them to your frontend. Here are the three most popular approaches, each suited to different workflows.

MSW (Mock Service Worker)

MSW intercepts fetch and XMLHttpRequest calls at the network level, so your frontend code makes real API calls that MSW intercepts and responds to with mock data. No server needed, no code changes to your API client. This is the gold standard for frontend testing and development.

import { http, HttpResponse } from 'msw';
import { setupWorker } from 'msw/browser';

// Paste your generated data here
const mockUsers = [ /* ... */ ];

const handlers = [
  http.get('/api/users', () => {
    return HttpResponse.json({
      data: mockUsers,
      pagination: { page: 1, per_page: 10, total: 47 }
    });
  }),
];

const worker = setupWorker(...handlers);
worker.start();

json-server

json-server gives you a full REST API from a single JSON file, with zero configuration. Save your generated data to db.json, run npx json-server db.json, and you get GET, POST, PUT, PATCH, and DELETE endpoints with filtering, sorting, and pagination built in. It is ideal for rapid prototyping when you need a real HTTP server.

Next.js Route Handlers

If your frontend is already a Next.js application, you can create Route Handlers that return mock data directly. This keeps everything in one project and eliminates the need for a separate mock server. Drop your generated JSON into a route handler and you have an instant API endpoint:

// app/api/users/route.ts
import { NextResponse } from 'next/server';

const mockUsers = [ /* paste generated data */ ];

export async function GET() {
  return NextResponse.json({
    data: mockUsers,
    pagination: { page: 1, per_page: 10, total: mockUsers.length }
  });
}

Best Practices for Mock API Data

Match Your Real API Shape

The single most important rule: your mock responses should use exactly the same envelope, field names, and data types as your real API. If the real API wraps data in { "data": [...] }, your mocks should too. If it uses snake_case field names, so should your mocks. Mismatched shapes are the number one cause of "it works with mocks but breaks with the real API" bugs.

Include Edge Cases

Happy-path data is easy. The valuable mocks are the ones that break your UI: empty arrays ({ "data": [] }), null fields, extremely long strings, special characters in names, and payloads with hundreds of items. Use the generator's nullable percentage feature to introduce null values at realistic rates -- most production databases have 5-20% null values in optional fields.

Test Error States

Don't just mock success responses. Create mocks for 400, 404, 422, and 500 errors. Your frontend should show meaningful error messages, retry where appropriate, and never crash on an unexpected status code. MSW makes this especially easy since you can return different status codes from the same handler based on request parameters.

Use Deterministic Seeds

When mock data appears in tests, use a fixed seed so the output is reproducible across machines and CI runs. Two developers running the same seed get identical data, making test failures easier to debug. Every SampleDataBlock on this page uses a fixed seed for exactly this reason.

Type-Safe Mocks with TypeScript

Hard-coded mock objects drift from your real types over time. The Mock Data Generator can export TypeScript interfaces alongside your data, so your mocks are always type-checked against the same schema that generates them. This catches breaking changes at compile time rather than in production.

The generator exports to seven formats -- JSON, JSONL, CSV, SQL, TypeScript, XML, and YAML -- so you can pick whatever your project needs. The TypeScript export includes both the interface definition and a typed constant with sample data, ready to import in your test files. You can also paste the generated JSON into your JSON Formatter to validate structure, or decode any JWT tokens that appear in your test fixtures.