OpenAPI to Zod Converter

OpenAPI to Zod: Validate API Responses at Runtime with Type Safety

OpenAPI specs describe what your API should return. Zod schemas validate what it actually returns — at runtime, in TypeScript, with full type inference. Converting OpenAPI to Zod closes the gap: once you have Zod schemas derived from your spec, you can validate every API response before it reaches your application logic, and TypeScript will know the exact shape of the validated data.

TypeMorph converts all components/schemas entries at once. Paste any OpenAPI 3.x YAML or JSON spec into the Zod tab — every named schema becomes a named Zod const with inferred TypeScript types, formats preserved.

Live Example: OpenAPI Spec to Zod Schemas

# Input: OpenAPI 3.0 spec (paste directly — no tab switching needed)
openapi: 3.0.0
info:
  title: User API
  version: 1.0.0
components:
  schemas:
    User:
      type: object
      required: [id, email]
      properties:
        id:         { type: string, format: uuid }
        email:      { type: string, format: email }
        role:       { type: string, enum: [admin, editor, viewer] }
        created_at: { type: string, format: date-time }
    Order:
      type: object
      required: [orderId, total]
      properties:
        orderId: { type: string, format: uuid }
        total:   { type: number }
        status:  { type: string, enum: [pending, shipped, delivered] }

// Generated Zod (all components, single output)
import { z } from 'zod';

export const userSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(['admin', 'editor', 'viewer']).optional(),
  created_at: z.string().datetime().optional(),
});
export type User = z.infer<typeof userSchema>;

export const orderSchema = z.object({
  orderId: z.string().uuid(),
  total: z.number(),
  status: z.enum(['pending', 'shipped', 'delivered']).optional(),
});
export type Order = z.infer<typeof orderSchema>;

Why Convert OpenAPI to Zod?

OpenAPI specs live in YAML files updated by backend teams. Your TypeScript frontend needs to trust the data before using it. Zod schemas let you validate at the fetch boundary:

import { userSchema } from './schemas';

async function getUser(id: string) {
  const res = await fetch(`/api/users/${id}`);
  const data = await res.json();
  // Throws if the API response doesn't match the spec
  return userSchema.parse(data);
  // TypeScript now knows: data.email exists and is a string
}

Without Zod, a backend change silently breaks your frontend — TypeScript types can't catch runtime mismatches. With Zod derived from your OpenAPI spec, mismatches become explicit errors at the API boundary.

OpenAPI Format Mapping

// OpenAPI type + format → Zod
{ type: string, format: uuid }      → z.string().uuid()
{ type: string, format: email }     → z.string().email()
{ type: string, format: date-time } → z.string().datetime()
{ type: string, format: uri }       → z.string().url()
{ type: integer }                   → z.number().int()
{ type: number }                    → z.number()
{ type: boolean }                   → z.boolean()
{ type: array, items: { ... } }     → z.array(...)
{ enum: ["a", "b"] }                → z.enum(["a", "b"])
{ nullable: true }                  → .nullable()
// required[] controls .optional() on each field

Using with tRPC and Next.js

// tRPC router: reuse OpenAPI-derived Zod schemas as input validators
import { userSchema } from './openapi-schemas';

const appRouter = router({
  createUser: procedure
    .input(userSchema.omit({ id: true, created_at: true }))
    .mutation(async ({ input }) => {
      // input is typed as { email: string; role?: "admin"|"editor"|"viewer" }
      return db.users.create(input);
    }),
});

// Next.js App Router: validate incoming webhook payloads
import { orderSchema } from './openapi-schemas';

export async function POST(req: Request) {
  const body = await req.json();
  const order = orderSchema.safeParse(body);
  if (!order.success) return Response.json({ error: order.error }, { status: 400 });
  // order.data is typed correctly
}

Handling $ref and Multi-File Specs

TypeMorph resolves $ref within the same document. Schemas that reference other named schemas emit separate Zod consts that reference each other — no z.any() fallback for resolvable refs:

// OpenAPI with $ref
components:
  schemas:
    Address:
      type: object
      properties:
        city: { type: string }
    User:
      type: object
      properties:
        address: { $ref: '#/components/schemas/Address' }

// Output — Address is emitted first, User references it
export const addressSchema = z.object({
  city: z.string().optional(),
});
export type Address = z.infer<typeof addressSchema>;

export const userSchema = z.object({
  address: addressSchema.optional(),
});
export type User = z.infer<typeof userSchema>;