Can I rely on the id being unique across many generated responses?

It's drawn fresh each time from 100 to 9,999, so a collision is possible but unlikely over a handful of generations — it isn't guaranteed unique the way a UUID is. For a test fixture that genuinely needs guaranteed-unique IDs, generate them separately and substitute them in.

Mock API Response Generator

Generates a sample successful JSON API response — a record with an id, name and status — for a mock server, client test, or documentation example.

Don't repeat what I've already seen

Your result will appear here.

What this generator does

Builds a JSON response with the fields an API usually returns. Only the numeric id is drawn afresh at the moment you generate; the name, status, timestamp and request ID are each picked from a short fixed list.

How to use this tool

Press generate for a response.
Copy it, or generate again for another one.

Worked examples

Shape: A JSON object with an id, a name, a status and a createdAt timestamp — or the same id, name and status nested under data, with a meta.requestId in place of the timestamp

Common use cases

Mock-server fixture data
API-client happy-path tests
Documentation response examples

How this generator works

Fills one of two response templates: a flat record with a name, status and creation timestamp, or a nested data/meta shape with a request ID instead of a timestamp. The numeric id is drawn fresh from the browser's cryptographic random generator on every call (100 to 9,999, not from a fixed list), while the name, status, timestamp and request ID each come from a small set of 4 or 5 illustrative values — so the id looks different almost every time, while the other fields repeat across enough generations to be recognisably sample data.

Limitations and good to know

Modelled on common conventions rather than any real provider's schema. Check the actual documentation before writing code against these field names.
Two shapes only — a flat record and a nested data/meta record — chosen to illustrate the common patterns rather than to match a specific API you're mocking.
The id is randomised but the name, status and timestamp values repeat from a small fixed set, so don't rely on the non-id fields for uniqueness across multiple generated responses.

Practical tips

Match the shape to your real API before relying on it — a mock that differs from production is worse than no mock, because it tests the wrong contract.
Include an error case as well as a success one; error paths are where mocks earn their keep.

Frequently asked questions

Can I rely on the id being unique across many generated responses?: It's drawn fresh each time from 100 to 9,999, so a collision is possible but unlikely over a handful of generations — it isn't guaranteed unique the way a UUID is. For a test fixture that genuinely needs guaranteed-unique IDs, generate them separately and substitute them in.