OpenAPI testing guide

How to generate JSON test data from an OpenAPI schema

Turn the schema you already maintain into realistic request bodies for manual testing, Postman collections, automated tests, and API migration checks.

9 minute readUpdated September 3, 2026

Generate a payload now

Paste an OpenAPI JSON or YAML specification and create up to 20 JSON records in your browser.

Open JSON test data generator

What OpenAPI test data generation does

An OpenAPI schema describes the shape of an API request or response: property names, data types, formats, allowed enum values, nested objects, arrays, examples, and numeric limits. A generator converts those rules into synthetic JSON records that match the documented contract.

This is useful when an endpoint is still being built, when you need several valid payloads quickly, or when you are comparing behavior between an old API and a migrated service.

1. Choose the schema you want to test

In a full OpenAPI 3 specification, reusable models normally appear under components.schemas. Choose the request model used by your endpoint rather than an unrelated response wrapper.

components:
  schemas:
    Customer:
      type: object
      required: [id, email]
      properties:
        id:
          type: string
          format: uuid
        email:
          type: string
          format: email
        status:
          type: string
          enum: [active, pending]

2. Keep constraints meaningful

Useful schemas create useful test data. Add formats for emails, UUIDs, dates, and date-times. Add minimum and maximum for bounded numbers, and use enum when only specific values are valid.

Examples and defaultsUse known representative values when a particular business format matters.

Required fieldsDocument the minimum valid payload separately from optional variations.

Nested objectsDefine address, account, or metadata objects with their own properties.

Local referencesReuse component schemas with local $ref links to keep models consistent.

3. Generate more than one record

One valid object proves very little. Generate several records so enums, booleans, arrays, identifiers, and realistic text vary between requests. Then add deliberate boundary and invalid cases yourself.

A normal valid payload
Minimum and maximum numeric values
Empty and populated arrays
Each allowed enum value
Missing, null, and malformed fields when the API should reject them

4. Review generated JSON before sending it

Generated data is synthetic and schema-shaped, but it does not know every business rule. Check cross-field rules such as start dates before end dates, currency-country combinations, or identifiers that must exist in another system.

Use safe environments and data.

Do not send generated records to production unless the endpoint is specifically designed for test data. Remove any real customer or credential information from schemas and examples.

5. Validate the API response

After sending the generated request, verify the status code, response schema, required fields, values, types, headers, and response time. When testing a migration, run equivalent requests against both implementations and compare the results.

Generate, send, and compare

Create realistic JSON from your schema, use it in your API client or automated test, and compare old and new endpoint responses for regressions.

Generate JSON test data