# How I build mock API responses that look real enough for frontend work

A beginner-friendly guide to creating realistic mock JSON responses, field types, arrays, IDs, dates, and using an API Mock Response Builder.

- Date: 2026-09-27
- URL: https://ilham.dev/posts/how-to-build-mock-api-responses-that-look-real-enough/
- Markdown: https://ilham.dev/posts/how-to-build-mock-api-responses-that-look-real-enough/index.md
- Tags: api, mock-data, json, tools
- Reading time: 2 min


Mock responses help frontend and integration work move before the real backend endpoint is finished.

The [API Mock Response Builder](/tools/api-mock-response-builder/) tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.

## The simple mental model

Mock responses help frontend and integration work move before the real backend endpoint is finished.

I try to reduce the tool to one question: what input do I have, what output do I expect, and what would make the result unsafe or misleading?

## Step 1: List the fields the UI needs

List the fields the UI needs.

Start with a small example first. A small example is easier to inspect than a real production-sized case.

## Step 2: Choose realistic data types for each field

Choose realistic data types for each field.

## Step 3: Generate arrays when the UI needs lists

Generate arrays when the UI needs lists.

## Step 4: Include IDs, dates, status values, and empty states

Include IDs, dates, status values, and empty states.

## Step 5: Keep mock data fake, not copied from real users

Keep mock data fake, not copied from real users.

## Step 6: Export JSON and wire it into tests or local fixtures

Export JSON and wire it into tests or local fixtures.

## Step 7: Update mocks when the real API contract changes

Update mocks when the real API contract changes.

## My checklist

Before I trust the result, I check:

- List the fields the UI needs.
- Choose realistic data types for each field.
- Generate arrays when the UI needs lists.
- Include IDs, dates, status values, and empty states.
- Keep mock data fake, not copied from real users.
- Export JSON and wire it into tests or local fixtures.
- Update mocks when the real API contract changes.

The tool saves time, but the important part is still understanding the input and reviewing the output before using it somewhere important.