How to Mock API Data With JSON Before the Backend Exists
The design is approved, the front-end team is ready and the API is still weeks away. Waiting is not an option, so you mock the data. Done well, JSON fixtures let you build screens, write tests and demo features long before a real endpoint exists. Done badly, they hide bugs that explode on launch day. This guide shows a practical workflow for mocking API data and the details that make fake data genuinely useful.
Agree on the shape first
Mock data is only valuable if it matches what the API will really return. Before writing any fixtures, agree with the backend team on:
- Field names and casing โ
firstNameorfirst_name? - Types โ is a price a number or a string? Is an id numeric or a UUID?
- Nullability โ which fields can be missing or
null? - Envelope โ is the list returned directly, or wrapped in an object with pagination info?
Writing this down as a small schema or an example response turns the mock into a contract both sides can test against.
Three ways to serve mock JSON
- Static files. Put
users.jsonin your project and load it in place of the real endpoint. Simple and perfect for prototypes. - A mock layer in code. Wrap your API calls in a small module that returns fixtures in development and real responses in production. Add an artificial delay to see loading states.
- A local mock server. A tiny server that answers real HTTP requests lets you test headers, status codes and errors, and keeps your front-end code identical to production.
Whichever you choose, keep the switch between mock and real data in one place so it is easy to remove later.
How to generate fixtures with the JSON tool
The generator above outputs a valid, pretty-printed JSON array you can paste straight into a file:
- Choose a Record type: Users (UUID id, firstName, lastName, email, phone), Customers with address, Products or Orders.
- Pick a Country to localize names and details, or choose โRandom countryโ to test how your layout handles an international mix.
- Generate up to 50 records per batch, then copy or download the JSON.
- Save it next to your code, for example as
fixtures/customers.json, and point your mock layer at it.
Emails use reserved test domains such as example.org, so a stray notification can never reach a real inbox.
Make the fake data uncomfortable
Perfectly tidy fixtures make every screen look great โ and that is the problem. Edit a few records by hand to cover what real users will do:
- Very long names and addresses that overflow cards and table cells.
- Accented and non-Latin characters, which reveal encoding bugs.
- Empty arrays and missing optional fields.
- Zero, negative and very large numbers in prices or quantities.
- Lists long enough to need pagination or scrolling.
Keep these โnastyโ records in a separate fixture so you can switch between a clean demo and a stress test.
JSON rules that trip people up
Hand-edited fixtures often break on small syntax rules. Standard JSON requires double quotes around keys and strings, does not allow trailing commas, and has no comments. Numbers cannot start with a leading zero, and dates have no native type, so agree on a format such as ISO 8601 strings. Run fixtures through a JSON validator or your test suite whenever you change them by hand.
From mock to real API
The handover is where mocks pay off or cause pain. When the real endpoint arrives, compare one real response with your fixture field by field and fix any differences in the fixture first, so your tests describe reality. Then switch the data source in one place and run the full test suite. Keep a small set of fixtures afterwards for unit tests, since they are faster and more predictable than live calls, and refresh them whenever the API contract changes.
Pro tips
- Keep fixture files in version control so tests are reproducible.
- Add an artificial delay to mocked calls so loading spinners get tested too.
- Mock error responses, such as 404 and 500, not just successful ones.
- Delete the mock layer once the real API is stable, or it will drift out of date.
Frequently asked questions
Should I commit mock data to the repository?
Yes, as long as it contains no real personal data. Committed fixtures make tests repeatable for everyone on the team.
Can I use real customer data as fixtures?
It is best avoided. Real data brings privacy obligations and risk, while generated data is safe to share, screenshot and commit.
How much mock data do I need?
Enough to fill each screen and trigger pagination, plus a handful of edge-case records. A few dozen records usually cover a prototype.