Zod runtime validation in Next.js API routes: what TypeScript alone can't catch

Oliver White

2 May 2026 · 6 min read

// ❌ TypeScript thinks this is fine — it will runtime-error in production
export async function POST(request: Request) {
  const body = await request.json();
  // TypeScript assumes body has the shape you expect — it doesn't verify it
  const { artwork_id, contest_id } = body as { artwork_id: string; contest_id: string };

  // What if artwork_id is undefined? Or a SQL injection string? Or 50,000 characters long?
  await supabase.rpc('submit_vote', { p_artwork_id: artwork_id, p_contest_id: contest_id });
}

// lib/validators.ts
import { z } from 'zod';

export const VoteSchema = z.object({
  artwork_id: z.string().uuid('Invalid artwork ID'),
  contest_id: z.string().uuid('Invalid contest ID'),
});

// app/api/v1/vote/route.ts
export async function POST(request: Request) {
  const requestId = generateRequestId();

  let body: unknown;
  try { body = await request.json(); }
  catch { return NextResponse.json({ error: 'Invalid JSON' }, { status: 400 }); }

  const parsed = VoteSchema.safeParse(body);
  if (!parsed.success) {
    logger.warn({ requestId, errors: parsed.error.flatten() }, 'validation failed');
    return NextResponse.json({ error: 'Invalid input', details: parsed.error.flatten() }, { status: 400 });
  }

  // parsed.data is now typed AND validated at runtime
  const { artwork_id, contest_id } = parsed.data;
  // ...
}

UUIDs have a strict format: 8-4-4-4-12 hexadecimal characters. z.string().uuid() rejects anything that doesn't match — including SQL injection attempts, oversized strings, and type confusions. This eliminates an entire class of injection risk before the query even forms.

Built with this methodology

TypeScript catches type errors at compile time. At the API boundary — HTTP request bodies, query parameters, webhook payloads — TypeScript has no power. Zod validates at runtime, before anything touches Redis or the database.