What the OpenAPI Mock Data Generator does
This generator reads an OpenAPI document and writes example requests and responses for every operation - path and query parameters, request bodies and the bodies of each documented status - then checks each generated body against its own schema. The output is seeded, so the same document and seed always produce the same fixtures.
Mock data is only useful if it is valid. A fixture that breaks a pattern or skips a required property teaches a front end or a contract test the wrong thing. So every compromise the generator makes is listed in a constraint report, and any body that fails validation is marked as failing rather than handed over quietly.
How to use it
- Paste an OpenAPI 2.0, 3.0 or 3.1 document in JSON or YAML, or drop the file.
- Pick a seed. Keep it fixed in a test suite so fixtures do not change between runs; change it to get a different but equally valid set.
- Set how many items arrays get, whether optional properties are included, and whether to mock only success responses or every documented status.
- Choose Generate mocks and read each operation's request and responses. The badge beside each body says whether it passed validation.
- Open the Constraint report for anything the generator could not honour, then download the fixture JSON, keyed by method and path, for your tests or mock server.
Reading the results
A green badge means the body passed validation against the operation's schema, including $ref targets, required, enum, bounds, lengths, pattern and the common formats. It does not mean the data is realistic for your business - an order total of 897.29 is valid, not plausible.
Generator notes explain approximations: a recursive $ref stopped to avoid an infinite object, a pattern too complex to generate, a format the generator does not know, or bounds that leave no valid value. Each names the operation and the JSON path.
When a document supplies its own example or examples and the option is on, those are used instead of generated data and are validated too - which regularly catches examples that drifted away from their schemas.
Worked example: fixtures for a four-operation Orders API
Load the example Orders API (OpenAPI 3.0.3) with seed 42, two items per array and success responses only. It has four operations: list orders, create an order, get one order and cancel an order.
The generator produces four bodies: the POST /orders request and the 200, 201 and 200 responses of the other calls. The cancel operation returns 204 with no content, so it has none. All four pass self-validation.
The GET /orders/{orderId} fixture calls a URL ending in a version-4 UUID, because the parameter's format is uuid, and its 200 body has an id in UUID format, a status drawn from the four-value enum, a non-negative total, an RFC 3339 createdAt and two line items whose sku values, such as DIJ-6214, match the pattern ^[A-Z]{3}-\d{4}$. Run it again with seed 42 and you get exactly the same values.
How values are chosen
const wins, then an enum value picked by the seeded generator, then the type. Strings follow format (date-time, date, time, email, uuid, uri, hostname, ipv4, ipv6, duration, byte), then pattern, then minLength and maxLength; a few common property names such as email, city or currency get recognisable values. Numbers respect minimum, maximum, both exclusive forms and multipleOf. Arrays respect minItems, maxItems and uniqueItems.
allOf members are merged, oneOf and anyOf pick one branch with the seed (and fill a discriminator's property with the matching mapping value), and readOnly properties are left out of requests while writeOnly ones are left out of responses, as the OpenAPI specification describes.
Patterns the generator can and cannot satisfy
Simple regular expressions are generated directly: literals, character classes and ranges, \d, \w, \s, groups, alternation and quantifiers such as {3}, + and ?. Every generated string is then tested against the real regular expression.
Look-aheads, look-behinds, back-references and word boundaries are refused with a note instead of guessed, because a string that merely looks right would fail your server's validation.
Limitations: what the result does not prove
- Mocks show the shape the contract promises, not how the real service behaves: there is no state between calls, no business rule such as totals matching line items, and no realistic error content beyond the schema.
- Only local
$refpointers are followed. References to other files are reported as unresolved and those bodies are left empty. - Validation uses a draft-07 JSON Schema validator extended for the OpenAPI 3.0 dialect and common 2020-12 keywords. Keywords it does not implement, such as
unevaluatedProperties, are not checked. - The seeded generator is deterministic for this version of the tool. A future change to the generator can change the values produced for the same seed, so pin the downloaded fixture file rather than the seed if byte-for-byte stability matters.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- OpenAPI Specification 3.1.1 - checked 19 Sep 2026
- OpenAPI Specification 3.0.4 - Schema Object and nullable
- JSON Schema Validation 2020-12 - formats and constraints
- RFC 3339 - Date and time on the Internet
Frequently asked questions
Will the same seed always give the same mock responses?
Yes, for the same document, settings and tool version. Each operation gets its own stream derived from the seed and its method and path, so adding a new endpoint does not reshuffle the data of the existing ones.
What happens with recursive schemas such as a tree of categories?
The generator follows a reference into itself once, then stops and records a note. Optional recursive properties are simply left out; if a recursive property is required the body is marked as failing validation, so you can see the schema cannot be satisfied by a finite example.
Does it use the examples already in my OpenAPI file?
By default, yes: a media type example or the first entry of examples is used as the body. It is still validated, and a failing badge tells you the example no longer matches its schema. Untick the option to generate everything instead.
Can I use the output with a mock server or contract tests?
The fixture JSON maps each operation to its request URL, headers, body and one body per status code. It is plain JSON, so it can seed a stub server, a Postman collection or table-driven tests without any A2Z code.
Why did a string come out as a placeholder that fails validation?
Its pattern uses a feature the generator cannot produce reliably, such as a look-ahead, or the pattern cannot be met within the given length limits. The Constraint report names the pattern and the reason. Supplying an example for that property in the document is the simplest fix.
Are Swagger 2.0 form parameters supported?
Yes. formData parameters are combined into one object body for the operation's consumed media type, and body parameters become the request body, so a 2.0 document produces the same kind of fixtures as a 3.x one.
Last reviewed by the A2Z.Tools team against the sources listed above.
