Front-end work, integration testing, and demos all share a problem: they need an API that does not exist yet, is still changing, or is too slow, flaky, or restricted to use for every test. Building a fake API by hand is slow and drifts out of date the moment the real API changes. An OpenAPI specification offers a better starting point, because it already describes every endpoint, every request shape, and every response shape in a structured form. Generating mock data from that specification turns the description into usable data automatically — and regenerating it after a specification change keeps the mock in step with the design.

The OpenAPI Mock Data Generator does that generation in your browser. You provide an OpenAPI specification, and it produces sample responses that follow the schemas defined in it. The output is not production data, and it must never be mistaken for it. It is realistic-shaped data for development and testing: the right fields, the right types, and plausible values, without any real records behind them.

How the tool works

An OpenAPI specification describes an API as a set of paths, each with operations, parameters, request bodies, and responses, and each response body is described by a schema — the same schema language used by JSON Schema, with types, properties, required fields, formats, and enumerations. The mock generator reads those schemas and produces a sample document for each one, following the same logic as a schema sample generator: a string field gets a sample string, an integer with a minimum gets a number at or above it, an enum gets one of its values, an array gets at least its minimum number of items, and a nested object is filled in level by level.

Where the specification gives examples, a good generator uses them, because an example written by the API designer is more realistic than a generic sample. Where it gives formats — email, date-time, uuid — the generator produces values shaped accordingly, so a mock email looks like an email and a mock timestamp looks like a timestamp. Where a response is paginated, the generator can produce a page of items with the pagination fields — total count, page number, page size — filled in consistently. The result is data that a front-end application can render and a test can consume without modification, which is the whole point: the mock should be usable immediately, not require hand-editing before every run.

Generation runs in your browser, so the specification stays on your device. That matters because specifications sometimes describe internal systems, unpublished endpoints, or business rules that should not be sent to a remote service just to produce test data.

A worked example

Consider an API with a GET /users endpoint whose response schema describes a paginated list: a total count, a page number, a pageSize, and an array of user objects, each with an id, a name, and an email. Mock data generated from that schema might look like this:

{
  "total": 47,
  "page": 1,
  "pageSize": 10,
  "users": [
    { "id": 1, "name": "Alex Morgan", "email": "alex@example.com" },
    { "id": 2, "name": "Samira Khan", "email": "samira@example.com" }
  ]
}

Check the pagination arithmetic: with 47 records in total and a page size of 10, the number of pages is 47 divided by 10, which is 4.7, rounded up to 5 pages. The mock shows page 1 of 5, which is consistent. A front-end developer can now build a pagination control against this mock and verify that it handles a five-page result, including the last page holding only 7 records — 47 minus 40 on the first four pages — without waiting for the real API to contain 47 users.

The mock is also useful for testing edge cases deliberately. Generate a mock for an empty list response and confirm that the front end shows an empty state rather than crashing. Generate a mock where an optional field is absent and confirm that the display handles the gap gracefully. Generate a mock with the maximum page size and check that the layout holds. Each of these tests uses data shaped exactly as the specification promises, which is what makes them meaningful: they test the application against the contract, not against one developer's guess at the data.

For demos, mock data has a different virtue: it is safe to show. A demo running against mock data cannot leak a real customer's name, email, or order history, because no real records are involved. Label the demo as using sample data, so the audience understands what they are seeing, and the demo becomes both convincing and harmless.

Common mistakes

The most common mistake is treating mock data as real data. Mock names, emails, and identifiers look realistic, and that realism is a trap: loading mock data into a production database, sending a mock email address a real message, or quoting mock figures in a report are all errors with real consequences. Keep mock data in development and test environments, clearly labelled, and never let it cross into production systems.

The second mistake is generating mocks once and never regenerating them. A specification changes — a field is added, a type changes, an endpoint is removed — and a stale mock no longer matches the contract. The front end then gets built against data the real API will never return, and the mismatch surfaces late, during integration, when it is expensive to fix. Regenerate mocks whenever the specification changes, and treat a mock that is older than the specification as suspect.

The third mistake is testing only with the happy-path mock. A generator produces valid data by default, but real APIs also return errors, empty lists, and partially filled records. Generate mocks for the error responses described in the specification — a 404 with an error body, a 400 with validation details — and test those paths too. An application that only works when the API succeeds is only half tested.

The fourth mistake is assuming the mock proves the API is correct. Mock data follows the specification, including the specification's mistakes. If the specification says a field is a string when the implementation returns a number, the mock will show a string, and a front end built against it will break against the real API. Mocks test the consumer against the contract; only testing against the real implementation tests the contract against reality.

Honest limitations

A mock generator produces sample data; it does not run an API, enforce business rules, or maintain state. It cannot tell you that creating a user and then fetching it returns the same user, because each generated response is independent. It cannot model relationships between records — a mock order may reference a customer identifier that no mock customer carries — and it cannot generate realistic distributions at scale, such as a thousand users with plausible name frequencies. Specifications with vague schemas — a field typed simply as object with no properties, or a free-form string with no format — produce vague mocks, because the generator has nothing specific to follow. In those cases the mock reveals a specification problem worth fixing, rather than papering over it. Finally, mock data is not a substitute for contract testing against the real API: it shows what the specification promises, not what the implementation delivers.

Closing

Generate the mock from the specification, check its pagination and edge cases by hand, regenerate it whenever the specification changes, and keep it firmly in development and test environments. That discipline turns a specification from a document into a working stand-in for the API it describes. To generate a sample from a single schema, use the JSON Schema Sample Generator, and to work with JSON data generally, use JSON Studio. For building paginated test data well, see API Pagination Test Data: Build It the Easy Way.