Home Random user API alternative
A random user API alternative that needs no API
A random user API gives you profiles over HTTP. This gives you the same kind of records as a file, generated on your machine — which changes what can go wrong.
What a runtime fetch costs you
Fetching random users at runtime is the fastest way to fill a demo, and it quietly adds a third-party service to the list of things that can break your build. Four failure modes that a generated file does not have:
- The network. A test that fetches its own fixtures fails on a train, in a locked-down CI runner, and on the day the service has an outage.
- Rate limits. Fine for a demo, less fine when a suite runs a thousand times a day from one egress IP.
- Non-determinism. Random data fetched fresh each run means a failing test may not reproduce — the worst kind of flake, because it looks like a real bug.
- Drift. The response shape is the service's to change, and it does not change on your schedule.
A generated file has none of those. It is bytes in your repository: the same on the train, in CI, and in two years. And because generation is seeded, you can regenerate exactly the same set instead of storing it, if you would rather keep the seed than the file.
You choose the fields
A user API returns the profile it was designed to return. Here you decide what a "user" has: name, email, phone, address, avatar URL, job title, signup timestamp, an active boolean, an account balance, a UUID — plus anything else your schema needs, named the way your database already names it. The output is a users table for your schema rather than a generic profile you then have to map.
Side by side
| Fun Data Playground | a random user API | |
|---|---|---|
| How you get records | Generated on your machine, then downloaded | Fetched over HTTP when your code runs |
| Network needed | Only to load the page once | On every call |
| Rate limits | None | Whatever the service sets |
| Repeating a run exactly | Same seed, same rows | Fresh random data each request |
| Which fields you get | The ones your schema declares | The profile the service returns |
| Photographs | Avatar URLs pointing at a placeholder service, not photographs | Some services serve a photo set |
| Who can change the response shape | Nobody — the file is yours | The service, on its own schedule |
Structural differences only — how each tool is used, not what it currently offers. Check the other tool's own documentation before deciding.
Where an API is the better answer
- A live demo that should look different on every load, with no fixture to bundle.
- Portrait photographs. Some user APIs serve a photo set; the avatar field here is a URL to a placeholder-style service, not a photograph.
- You are already offline-tolerant and the convenience of a one-line fetch outweighs the dependency.
- Server-side generation on demand, which a static page cannot do.
Tools change. This page sticks to structural differences — how each one is used rather than what it currently offers — but check the current documentation of whichever you are comparing rather than trusting any comparison page, including this one.
Replacing a fetch with a fixture
The usual migration is three steps. Build a schema whose field names match the response
shape you are already consuming — dots make it nested, so name.first and
name.last reproduce a nested name object. Export as JSON and save it in your
test fixtures. Then replace the fetch with an import, or keep the fetch and intercept it:
Playwright and
Cypress both cover serving a fixture in place of a real
request, which is usually the smaller change.
The data is safe to publish
Every value is synthetic. Email addresses use domains reserved by RFC 2606 and RFC 6761 that cannot receive mail, so a fixture that leaks into a mailing list sends nothing to anybody; IP addresses come from documentation ranges. That is worth more than it sounds for demo data, which has a habit of ending up in screenshots and public repositories. The methodology page documents each choice.
Common questions
Why generate locally instead of calling an API?
Because a runtime fetch adds a third-party service to the things that can break your build: the network, rate limits, non-reproducible random data and a response shape that is not yours to control. A generated file has none of those.
Can I get the same users again?
Yes. Enter a seed and the same schema produces byte-identical output every time, so you can either commit the file or keep the seed and regenerate it.
Does it include profile photos?
Not photographs. There is an avatar URL field pointing at a placeholder-style image service. If you need portraits specifically, that is a reason to use a photo-serving API.
Can I match the response shape I already consume?
Yes. Name the fields to match, and use dots for nesting — name.first and name.last produce a nested name object — so the fixture drops into code written against the API shape.
Are the email addresses safe to use?
Yes. They use reserved documentation domains that cannot receive mail, so a fixture that escapes into a real mailing list sends nothing to anyone.
Related
- /api-mock-data — using the generated records as mock API responses.
- /random-name-generator — the name fields on their own, with a live example.
- /playwright-test-data — intercepting a request and serving a fixture instead.
- /methodology — what the values are made of and what they are not safe for.
- /faker-js-alternative — the same trade against a library rather than an endpoint.
- /mockaroo-alternative — and against a hosted generator.
- /json-generator-alternative — and against a template-based JSON generator.
Last updated