How to generate JSON test data from an OpenAPI schema

Choose a request model, not just any schema

A reusable OpenAPI component may describe a request, a response, or an internal object. For a create-customer test, use the request model referenced by that operation’s request body. A response model may contain server-generated IDs or timestamps that clients must not send.

The example below is a schema-only OpenAPI 3.0.3 document with an empty paths object. It describes fixtures; it does not claim to provide a callable endpoint. Its CustomerCreate schema requires an email, an age from 18 to 75, an allowed status, one or two tags, and a nested address.

openapi: 3.0.3
info:
  title: Customer fixture example
  version: 1.0.0
paths: {}
components:
  schemas:
    CustomerCreate:
      type: object
      required: [email, age, status, tags, address]
      properties:
        email:
          type: string
          format: email
          example: maya.chen@example.com
        age:
          type: integer
          minimum: 18
          maximum: 75
        status:
          type: string
          enum: [active, pending]
        tags:
          type: array
          minItems: 1
          maxItems: 2
          items:
            type: string
            enum: [trial, newsletter]
        address:
          $ref: '#/components/schemas/Address'
    Address:
      type: object
      required: [city, countryCode]
      properties:
        city:
          type: string
          example: Bristol
        countryCode:
          type: string
          enum: [GB, IN, US]

The address references a second component in the same document. The quoted $ref value starts with #/; quoting is important in YAML because an unquoted hash can start a comment. All names and contact values are synthetic.

Generate your first payload

1. Open the generator and choose OpenAPI.
2. Replace the sample with the full YAML above. Equivalent JSON works too.
3. Choose CustomerCreate in the Schema selector. Choosing Address would generate only the address object.
4. Set Records to 1, then select Generate JSON.
5. Inspect the result before selecting Copy or Download.

One possible result is shown below. The age, status, tags, and country vary between runs. The explicit email and city examples remain fixed. The tool has no random seed setting; save a generated fixture when you need a reproducible test.

{
  "email": "maya.chen@example.com",
  "age": 28,
  "status": "active",
  "tags": [
    "trial"
  ],
  "address": {
    "city": "Bristol",
    "countryCode": "GB"
  }
}

Check the structure, not an exact random value: age is a JSON number, tags is an array of one or two allowed strings, and address is an object rather than a literal reference path. A schema can allow combinations that your business rules reject; this example does not model whether a particular city belongs to a country.

Records set to 1 returns the schema’s value directly. A higher count wraps those values in an array. If your endpoint expects a single object, send one record at a time; a batch fixture is not proof that the endpoint accepts a batch request.

Convert one fixture into a test matrix

Generating twenty ordinary customers does not guarantee boundary coverage. Keep a copy of one valid fixture and change exactly one condition per test. For this fictional contract, use these cases:

A rejected request should not create a partial customer. Check both the response and the resulting state. The status might be 400 or 422 depending on your documented API contract; the generator does not choose that policy.

{
  "email": "maya.chen@example.com",
  "age": 17,
  "status": "active",
  "tags": [
    "trial"
  ],
  "address": {
    "city": "Bristol",
    "countryCode": "GB"
  }
}

This is an intentionally invalid age fixture, not a payload the generator should produce from the original schema. Start each negative test from a fresh valid copy so several defects do not hide which rule is being tested. See API error response design for useful validation messages.

Use field definitions when you do not have OpenAPI

email: email
age: integer(18, 75)
status: enum(active, pending)
isActive: boolean
createdAt: datetime
roles: array<string>

Select Field definitions and enter one field per line. Enums in this mode contain strings; use an OpenAPI schema for numeric or boolean enums. Array fields contain one to three generated values. The object and address types generate a sample address; they do not infer your domain model.

For names and common values, supported labels include firstName, lastName, name, phone, city, country, company, role, status, title, and description. Core types include string, uuid, email, date, datetime, uri, ipv4, integer, number, boolean, null, object, and array<type>. Unknown types, duplicate names, and reversed numeric ranges are errors. Comments can occupy a line starting with #.

Supported features and explicit limits

This is a fixture generator for common schema shapes, not a complete OpenAPI or JSON Schema validator. It does not call an API or prove a payload will be accepted.

Input is limited to 200,000 characters, with a traversal limit for deeply nested output. These bounds keep generation usable in a browser. Reduce a large specification to the relevant components while retaining referenced schemas.

Fix common generation errors

“Could not parse the specification”: check indentation and duplicate keys in YAML, or missing commas and quotes in JSON. Broken JSON is not reinterpreted as a different YAML document.

“No schema found”: an operation’s request body wrapper is not itself a schema. Paste its schema object or a document with components.schemas.

“Reference not found”: include the referenced component and match its spelling and case. External files are not fetched.

“Cannot enforce”: review the named constraint. Use a validated example at that schema node, or simplify a copy of the schema specifically for fixture generation. Keep your original production contract unchanged.

After any input change or generation error, the previous output is cleared and export controls are disabled until a new run succeeds. This avoids accidentally copying an old payload for a new schema.

Use the fixture safely and keep the test repeatable

Download the chosen JSON fixture and commit it with your test code, using your normal repository review process. Record the schema revision and expected response beside it. Random generation is useful for variety; a saved fixture is what makes a regression reproducible.

Use a test environment with disposable records. A POST can create data; sending the same fixture to two environments can create two records. Compare status, body, and documented side effects, and clean up test data afterward. The API comparison walkthrough explains how to interpret differences without treating every timestamp as a regression.

Generation happens locally in your browser. Examples in this guide use reserved example.com addresses; generated identifiers are synthetic and do not grant access to real accounts. Do not paste credentials or customer data into a specification.

For the meaning of schema keywords and local references, consult the official OpenAPI 3.0.3 Schema Object documentation. The customer schema, payload, and test matrix here are original examples.