Generate a Zod Schema for API Request Body Validation

Generate the body schema, then validate inside middleware. safeParse keeps you in control of the error response shape.

Input body sample:
{ "email": "a@b.com", "name": "Sam", "plan": "pro" }

Generated:
import { z } from "zod";
export const createUserBody = z.object({
  email: z.string(),
  name: z.string(),
  plan: z.string()
});
export type CreateUserBody = z.infer<typeof createUserBody>;

Middleware (you add .email()):
app.post('/users', (req, res, next) => {
  const r = createUserBody.safeParse(req.body);
  if (!r.success) return res.status(400).json(r.error.flatten());
  req.body = r.data; next();
});

In a Route Handler the body is parsed from the request stream. Use the generated schema to validate and narrow in one step.

Generated schema: createUserBody (as above)

export async function POST(req: Request) {
  const body = await req.json();
  const parsed = createUserBody.safeParse(body);
  if (!parsed.success) {
    return Response.json(parsed.error.flatten(), { status: 400 });
  }
  // parsed.data is typed CreateUserBody
  return Response.json({ ok: true });
}

Inference handles arbitrarily nested objects and typed arrays. An array of identically-shaped objects collapses to a single element schema.

Input:
{ "order": { "id": 9, "items": [ { "sku": "A", "qty": 2 } ] } }

Generated:
export const schema = z.object({
  order: z.object({
    id: z.number().int(),
    items: z.array(z.object({
      sku: z.string(),
      qty: z.number().int()
    }))
  })
});

Query strings are always strings, so a sample like { page: 2 } would mislead you. Generate the body schema for the type names, then coerce for query params.

URL: /search?page=2&active=true
req.query is { page: '2', active: 'true' } — all strings.

Generated from sample gives z.number()/z.boolean(),
but for query params switch to coercion by hand:
const Query = z.object({
  page: z.coerce.number().int().min(1),
  active: z.coerce.boolean()
});

Turn on Strict objects to reject any field outside the documented contract — a defensive default for inputs you do not control.

Strict objects: ON

export const schema = z.strictObject({
  email: z.string(),
  plan: z.string()
});

schema.parse({ email, plan, isAdmin: true })
// throws: Unrecognized key(s) in object: 'isAdmin'
// (a privilege-escalation field never reaches your handler)

The generator reads runtime types, so any string value is z.string(). UUIDs, emails, URLs, and ISO timestamps all come out as z.string(). Add .uuid(), .email(), .url(), or .datetime() at the validation boundary yourself.

If your sample shows { "page": 2 } the schema gets z.number().int(), but real query strings deliver '2'. Switch those fields to z.coerce.number() for any data sourced from URL query strings or form-encoded bodies.

Inference only includes keys present in the sample. An optional field omitted from your example will not appear in the schema. Include it in the sample, or add it as .optional() afterwards. For nullable-or-absent, combine .nullable().optional().

A null in the sample produces z.null(), which accepts only null. For a field that is sometimes a real value, rewrite to e.g. z.string().nullable(). The generator cannot infer the non-null type from a single null.

If an array holds different types, e.g. [1, "a"], the element becomes a union: z.array(z.union([z.number().int(), z.string()])). This is faithful to the sample but often a sign your payload is loosely typed — tighten it if the API contract should be homogeneous.

The generator does not merge differing object shapes into one schema with optionals. Two array elements with different keys produce z.array(z.union([z.object({...}), z.object({...})])). If you want a single object schema, give a sample where the array elements share one shape.

An empty array ([]) becomes z.array(z.unknown()) because the element type cannot be determined. Provide a sample with at least one element, or replace z.unknown() with the real element schema.

Free tier accepts JSON up to 2 MB; Pro up to 100 MB. A request-body sample is tiny, so this rarely bites — but if you feed a giant fixture dump, trim it to one representative record first. The schema does not get richer from more rows.