AI assisted · Free
API response mock generator
Define an entity name and its fields to generate realistic mock API responses — single object, five-item array, paginated response, and a TypeScript type — all with real-looking data.
Fields
Frequently asked questions
What field types can I define for my mock data?
The generator supports string, number, boolean, email, UUID, date, URL, and name field types. Each type generates realistic values — emails look like real email addresses, dates are formatted as ISO 8601 strings, UUIDs follow the correct format, and names are realistic full names rather than placeholder values.
Why does realistic mock data matter for testing?
Placeholder values like test, 0, and null-user often mask bugs that only appear with real-world data. A UI component might display correctly with a 4-character username but overflow or truncate with a 40-character name. An email field that always contains test does not test your validation or display logic. Realistic mock data with actual lengths, formats, and edge cases catches these issues before they reach production.
What is included in the paginated response format?
The paginated response includes the data array (5 mock items), a page field showing the current page number, a perPage field for items per page, a total field for the total number of items across all pages, and a totalPages field calculated from total divided by perPage. This mirrors the most common pagination shape used by REST APIs and is compatible with most frontend pagination libraries.
Can I use the TypeScript type output directly in my project?
Yes. The generated TypeScript type reflects the exact fields and types you defined, plus any additional fields the mock data generator added. Copy it directly into your types file or use it as a starting point. If your API response has more fields than you defined in the generator, add them to the interface manually. The generated type gives you the correct base structure to work from.
When to use mock API data
Mock API responses are useful for frontend development before the backend is ready, writing unit tests, documenting APIs with realistic examples, and generating seed data for local databases during development.
Frontend development: build UI components against realistic data structures without waiting for a backend. When the real API ships, swapping in the real endpoint should require only a URL change if the mock was designed to match the real schema.
Testing: realistic mock data (real names, valid UUIDs, ISO timestamps) catches more bugs than placeholder values. If your test mock uses “test” as a name and “0” as a price, you may miss display bugs that only appear with realistic string lengths.
Paginated responses typically include the data array plus metadata: current page, items per page, total item count, and total pages. Standardise this structure early — changing it after multiple consumers are built is painful.
Need a well-designed REST or GraphQL API built for your product?
Talk to Codalyst about API development