Skip to content
Generate now

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.

Options

Tip: press Enter or Space to generate again.

Ready

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 โ€” firstName or first_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

  1. Static files. Put users.json in your project and load it in place of the real endpoint. Simple and perfect for prototypes.
  2. 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.
  3. 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:

  1. Choose a Record type: Users (UUID id, firstName, lastName, email, phone), Customers with address, Products or Orders.
  2. Pick a Country to localize names and details, or choose โ€œRandom countryโ€ to test how your layout handles an international mix.
  3. Generate up to 50 records per batch, then copy or download the JSON.
  4. 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.

Try a generator

Random Address Generator

Realistic street addresses with valid-format postal codes and phone numbers for 40 countries.

Fake Identity Generator

Complete fictional person profiles: name, birthday, address, phone, email, job and more.

Need random data? Get it now.

Pick any of 144 generators, hit Generate and copy or export the results as CSV, JSON or TXT. No account, no limits, nothing stored.

Start generating โ€” free