DummyJSON: a hosted REST API for placeholder JSON, and when to self-host it

The problem DummyJSON removes: a frontend blocked on a backend

The README states the motivation plainly: skip building a backend just to test UI, and avoid unreliable or rate-limited public APIs. That is the whole pitch. A developer who wants to render a product grid, a user table or a comment thread normally has to either wait for a real API, mock one by hand, or point at a public API that may throttle or disappear. DummyJSON offers a third option: a hosted set of REST endpoints already filled with JSON.

The intended audience is narrow and clear. Frontend developers working in React, Angular, Vue or plain JavaScript, people writing tutorials, and anyone who needs consistent fixture data for a demo. The README lists resources with rough counts: products (190+), users (200+), carts (200+), posts (250+), comments (340+), quotes (1400+), recipes (50+) and todos (250+). Those counts come from the README, not from an audit, and they are the kind of thing that drifts as the dataset changes.

The service also covers ground beyond plain resources. There is an auth section in the docs, a custom HTTP response endpoint, a dummy image generator and an identicon generator. That breadth is unusual for a placeholder API and is the main reason to consider this one over a hand-written mock.

How the hosted API answers a request

The mechanism is ordinary HTTP. A client sends a GET to a path such as /products, the server returns a JSON body, and the client parses it. The README shows the same call through fetch and through Axios, which is a useful signal that nothing about the protocol is unusual.

Query parameters carry the behaviour. Search is a query string on a resource: /products/search?q=phone. Pagination uses limit and skip: /products?limit=10&skip=10. Nested resources are expressed as paths: /users/1/posts returns the posts belonging to user 1. There is also a delay parameter, /products?delay=1000, which the README lists under features. That one is more interesting than it looks, because it lets you exercise loading states and skeleton screens without writing a fake timer in the client.

The README claims support for all HTTP methods. What that means in practice is not spelled out per resource, and the README does not document which endpoints accept writes or what happens to written data afterwards. Treat the write side as something to verify against the docs pages rather than assume.

On the server side, the repository is a Node application: Express for routing, EJS for views, Mongoose and the MongoDB driver for persistence, sharp and jdenticon for the image and identicon endpoints, jsonwebtoken and otplib for auth, node-cache for caching, and express-rate-limit for throttling. The Dockerfile installs fontconfig, copies the fonts directory into /usr/share/fonts and runs fc-cache, which is what makes the text rendering on generated images work inside the container.

Installing DummyJSON locally and making a first request

If you only want data, you do not install anything. The README points at https://dummyjson.com and the docs at https://dummyjson.com/docs, and the example is a single fetch call. The code below is the README's own example; run it in a browser console or a Node script and you should see a JSON object with a products array and pagination metadata.

const res = await fetch('https://dummyjson.com/products');
const json = await res.json();
console.log(json);

The same call through Axios, also from the README:

const response = await axios.get('https://dummyjson.com/products');
console.log(response.data);

Self-hosting is a different job. The package.json declares "type": "module" and an engines field of node >=24, so the runtime is not optional. The repository ships a Dockerfile based on node:24.14.1-alpine3.23, and .env.example lists the variables the application expects.

npm install
npm start

The start script runs node index.js. For development, the dev script uses env-cmd with a .env file and nodemon. Before either works, copy .env.example to .env and fill in the values it marks as required: MONGODB_URI, MONGODB_DB_NAME and JWT_SECRET. The file also carries optional blocks for AWS S3 credentials, Cloudflare, Pushover and Google tags, all commented out, plus STATS and SPONSORS_CONTENT strings that feed the site's own pages.

docker build -t dummyjson .
docker run -p 80:80 dummyjson

The image sets NODE_ENV to production and PORT to 80, and exposes port 80. If you run it that way, the API answers on localhost port 80, not on the hosted domain.

Where DummyJSON is the wrong tool

The first limitation is the most obvious and the easiest to forget: the hosted service is a remote dependency. Every fetch in your test suite, your CI job or your offline laptop goes out over the network. The README itself frames the project as an alternative to unreliable or rate-limited public APIs, which is a fair description of the problem, but it does not promise that DummyJSON is immune to the same conditions. The README does not document an uptime guarantee, a rate limit policy or a deprecation policy for the hosted endpoints.

The second is persistence. Nothing in the README describes how long a created, updated or deleted record survives, and the README does not document rollback. If your feature depends on data you wrote earlier in the session, a placeholder API is the wrong foundation. Use a local server you control, or a fixture file committed next to the tests.

The third is schema fidelity. DummyJSON gives you a product object with fields its authors chose. Your real product object will have different fields, different nullability and different nesting. The gap between the two is exactly where integration bugs hide, and a placeholder API can make that gap feel smaller than it is.

Finally, self-hosting has real weight. The dependency list includes MongoDB, sharp, the AWS SDK, jsonwebtoken, otplib and multer. That is a production application, not a fixture server. Running it locally to avoid a network call is a large amount of infrastructure for a small amount of test isolation.

DummyJSON against JSONPlaceholder and a local mock

The comparison people reach for is JSONPlaceholder, and the difference is scope rather than quality. JSONPlaceholder is a small, fixed set of resources: posts, comments, albums, photos, todos and users. DummyJSON covers more ground, adding products, carts, recipes and quotes, and it adds behaviour JSONPlaceholder does not offer, such as the delay parameter, nested resource paths like /users/1/posts, and image and identicon generation. If you are building a storefront demo, DummyJSON has products and carts and JSONPlaceholder does not.

The other alternative is not a service at all: a local mock. A JSON file in the repository, or a small Express or json-server process started by the test runner, removes the network entirely and lets you shape the schema to match your real API. That is more work up front and it is the right answer when the schema, not the data volume, is what you are testing against.

A reasonable split: use the hosted DummyJSON for visual work, demos and tutorials where realistic-looking data matters and the schema can be approximate. Use a local mock for unit and integration tests where determinism and offline execution matter. The two do not conflict.

Licence, maintenance and the cost of keeping a fork current

The repository's LICENSE file and the README both state MIT, while the package.json license field also says MIT. The repository metadata carries a NOASSERTION licence classification, which is a mismatch worth noting if your organisation scans licences automatically; the file in the repository is the one to read. MIT is permissive, and using the hosted API does not involve the licence at all. Self-hosting and redistributing the code is where the terms apply, and this is not legal advice, so read the LICENSE file yourself.

The last push to the default branch was on 2026-09-10, and the repository is not archived. That is recent enough that the codebase is moving. There are no retrieved releases, so the version in package.json, 0.2.0, is the only version signal available, and upgrades should be tracked through commits rather than release notes.

Upgrade cost depends on which side you are on. Consuming the hosted API costs nothing to upgrade and nothing to maintain, but it also means the response shape can change without your involvement. Self-hosting means owning a Node 24 runtime, a MongoDB instance, the sharp native build and the font cache step in the Dockerfile. The engines field pins the major Node version, so a runtime upgrade is a deliberate act rather than something that happens quietly.

Editorial conclusion

Adopt the hosted DummyJSON API when you need structured JSON for a prototype, a component demo or a teaching exercise, and you accept that the data lives on someone else's server. Do not adopt it when the data must persist, when you need write operations that survive a restart, or when a test suite must run without network access; for those, a local JSON server or a fixture file in the repository is the honest choice. Before building on it, verify the response shape for the resource you actually need, confirm whether the endpoint you picked supports the HTTP methods your client will send, and read the docs page for that resource rather than assuming every resource behaves like products.

Frequently asked questions

Official sources

1. Issues
2. Ovi/DummyJSON on GitHub
3. Project website
4. README