How to Generate Mock Data for Swagger and OpenAPI Specs

June 13, 2026

You've written your OpenAPI spec. Now you need realistic example responses — for Swagger UI, for client SDK generation, for contract testing, or just to show stakeholders what the API will return. This guide covers every approach to generating mock data that matches your OpenAPI schema.

Option 1: Add Examples Directly to Your OpenAPI Spec

OpenAPI 3.0 supports inline examples in your spec. This is the cleanest approach — Swagger UI renders them automatically, and tools like Postman import them as test data.

# openapi.yaml
paths:
  /users:
    get:
      summary: List users
      responses:
        '200':
          description: Successful response
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
              examples:
                default:
                  value:
                    - id: "a3f8b2c1-4e5d-6f7a-8b9c-0d1e2f3a4b5c"
                      fullName: "Ayesha Rahman"
                      email: "ayesha.rahman@example.com"
                      city: "Lahore"
                      status: "active"
                      createdAt: "2024-08-14T09:33:21.000Z"
                    - id: "b7c3d4e5-5f6a-7b8c-9d0e-1f2a3b4c5d6e"
                      fullName: "James O'Brien"
                      email: "james.obrien@example.com"
                      city: "Dublin"
                      status: "inactive"
                      createdAt: "2025-01-02T16:47:05.000Z"

components:
  schemas:
    User:
      type: object
      required: [id, fullName, email, status]
      properties:
        id:
          type: string
          format: uuid
        fullName:
          type: string
          example: "Ayesha Rahman"
        email:
          type: string
          format: email
          example: "ayesha@example.com"
        city:
          type: string
          example: "Lahore"
        status:
          type: string
          enum: [active, inactive, pending]
        createdAt:
          type: string
          format: date-time

Generate the example values with Dummy JSON Generator — configure a schema that matches your OpenAPI model, generate 2–5 records, and paste them as the examples values in your spec.

Option 2: Prism — Auto Mock Server from OpenAPI

Stoplight Prism reads your OpenAPI spec and spins up a mock HTTP server that returns example responses automatically. It uses the example values you've defined, or generates random values based on your schema types. 

npm install -g @stoplight/prism-cli

# Start mock server from your spec
prism mock openapi.yaml

# Or from a URL
prism mock https://your-api.com/openapi.yaml

Your mock server is now running at http://localhost:4010. Hit any endpoint defined in your spec and get back the example response:

curl http://localhost:4010/users
# Returns your example data from the spec

Prism also validates incoming request bodies against your schema and returns 422 errors for invalid payloads — making it useful for contract testing.

Option 3: Postman Mock Server from OpenAPI Import

  1. In Postman → Import → upload your openapi.yaml
  2. Postman creates a Collection with all your endpoints
  3. Add example responses to each request (paste your generated JSON here)
  4. Collections → ··· → Mock Collection → Create Mock Server
  5. Postman gives you a public URL like https://abc123.mock.pstmn.io

Anyone on your team can now call your mock API without running anything locally. Useful for frontend developers who need a stable API URL before the real backend is deployed.

Option 4: json-server — REST API from a JSON File

json-server turns a JSON file into a full REST API in one command. Combined with data generated from Dummy JSON Generator, you have a working fake backend in under 2 minutes.

npm install -g json-server

Create a db.json file by generating data with Dummy JSON Generator and wrapping it in a top-level key:

{
  "users": [
    { "id": 1, "fullName": "Ayesha Rahman", "email": "ayesha@example.com", "status": "active" },
    { "id": 2, "fullName": "James O'Brien", "email": "james@example.com", "status": "inactive" }
  ],
  "products": [
    { "id": 1, "name": "Wireless Keyboard", "price": 49.99, "category": "electronics" },
    { "id": 2, "name": "Standing Desk", "price": 399.00, "category": "furniture" }
  ]
}
json-server --watch db.json --port 3001

You now have a REST API with these endpoints — all working out of the box:

GET    /users         → returns all users
GET    /users/1       → returns user with id 1
POST   /users         → creates a new user
PUT    /users/1       → replaces user 1
PATCH  /users/1       → updates user 1
DELETE /users/1       → deletes user 1
GET    /users?status=active  → filter by field
GET    /users?_page=1&_limit=10  → pagination

Option 5: OpenAPI Generator for Typed Mock Clients

If you're generating a client SDK from your OpenAPI spec and want typed mock data for TypeScript tests: 

npx @openapitools/openapi-generator-cli generate \
  -i openapi.yaml \
  -g typescript-fetch \
  -o src/api/generated

This generates TypeScript types that match your OpenAPI schema exactly. You can then cast your generated JSON to these types in tests:

import type { User } from '@/api/generated';
import rawUsers from '@/data/users.json';

// Cast generated JSON to your API types
const users = rawUsers as User[];

// Now fully typed in your tests
const activeUsers = users.filter(u => u.status === 'active');

Recommended Workflow

  1. Write your OpenAPI schema (components/schemas)
  2. Generate matching fake JSON with Dummy JSON Generator — field names and types matching your schema
  3. Add 2–3 of the generated records as inline examples in your spec
  4. Use Prism or json-server for a local mock API during development
  5. Use Postman Mock Server for a shared URL accessible to the whole team
  6. Use MSW in your test suite for component and integration tests

This gives you realistic, consistent mock data flowing through every tool in your API development workflow — from spec writing through frontend development to automated testing.