Professional Validation with Zod

Welcome back! At this stage of your backend journey, your API already handles creation, retrieval, and updating of tasks. But there’s still a critical piece missing — robust, reusable validation.

Data validation ensures that:

• Required fields are present
• Values are the correct type and format
• Your app doesn’t crash or store invalid data

To accomplish this at a professional level, we’ll now use a TypeScript-first schema validation library called Zod.

In earlier lessons, you wrote custom validation logic using plain TypeScript and conditional checks. While this works for simple use cases, it can quickly become:

• Verbose and repetitive
• Error-prone as requirements evolve
• Difficult to maintain or reuse across endpoints

To solve this, most production backends use schema validation libraries like Zod. These libraries allow you to define strict rules for your data in a concise, declarative way — and Zod integrates seamlessly with TypeScript.

Zod lets you define "schemas" that describe exactly what a valid object looks like. It supports: Required fields, Optional fields, Default values, Nested objects, Preprocessing and transformation and Type inference (automatically generating TypeScript types from schemas)

💡 Note that Zod is pure TypeScript, and it doesn’t rely on decorators or any runtime framework, making it ideal for stateless APIs like ours.

In this lesson, you’ll replace your custom validation logic with Zod-based schemas, resulting in cleaner, safer, and more scalable backend code.

Zod is a TypeScript-first schema validation library. It helps you define what valid data should look like and checks incoming data against these rules.

Why use Zod?

• It is simple and easy to use.
• It works well with TypeScript and JavaScript.
• It gives clear error messages when data is invalid.

Here is a basic example of a Zod schema:

import { z } from 'zod';

const userSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});

const result = userSchema.safeParse({ name: "Alice", age: 25 });
console.log(result.success); // true

• z.object({...}) defines an object schema.
• z.string() and z.number() set the types for each field.
• safeParse checks whether the data matches the schema and returns an object with a success property. Calling .safeParse() on a value will return:
• { success: true, data } if valid
• { success: false, error } if invalid

Let’s define three task schemas: one for creation, one for full replacement (PUT), and one for partial updates (PATCH).

// src/lib/validation/taskSchemas.ts
import { z } from 'zod';

export const createTaskSchema = z.object({
  title: z.string().min(1, "'title' must be a non-empty string."),
  content: z.string().min(1, "'content' must be a non-empty string."),
  completed: z.boolean().default(false),
  dueDate: z.string().optional().refine(
    (val) => val === undefined || !Number.isNaN(Date.parse(val)),
    { message: "'dueDate' must be a valid date string." }
  ),
});

// PUT: all fields required
export const putTaskSchema = createTaskSchema;

// PATCH: all fields optional
export const patchTaskSchema = createTaskSchema.partial();

Let’s break this down:

• title and content must be non-empty strings (min(1) means at least 1 character).
• completed is a boolean and defaults to false if not provided.
• dueDate is optional, but if provided, it must be a valid date string.
• putTaskSchema: used in PUT routes, where all fields are required (full task replacement)
• patchTaskSchema: used in PATCH routes, where all fields are optional (partial update)

Example usage:

const result = createTaskSchema.safeParse({
  title: "Buy groceries",
  content: "Milk, eggs, bread",
  completed: false,
  dueDate: "2024-07-01"
});
console.log(result.success); // true

If you try to parse invalid data:

const result = createTaskSchema.safeParse({
  title: "",
  content: "",
  dueDate: "not-a-date"
});
console.log(result.success); // false
console.log(result.error.format());

Output:

false
{
  "title": { "_errors": ["'title' must be a non-empty string."] },
  "content": { "_errors": ["'content' must be a non-empty string."] },
  "dueDate": { "_errors": ["'dueDate' must be a valid date string."] }
}

Now, let’s see how to use these schemas in your API routes to check incoming data and respond properly.

Here’s how you can use the schema in your POST endpoint:

// src/app/api/tasks/route.ts
import { createTaskSchema } from '@/lib/validation/taskSchemas';
import { createErrorResponse, createSuccessResponse } from '@/lib/responses';

export async function POST(req: NextRequest) {
  const body = await req.json();
  const parsed = createTaskSchema.safeParse(body);

  if (!parsed.success) {
    return createErrorResponse(parsed.error.format(), 400);
  }

  const newTask = await createTask(parsed.data);
  return createSuccessResponse(newTask, 201);
}

Explanation:

• We use safeParse to check whether the request body matches the schema.
• If validation fails, we return an error response with details and a 400 status code.
• If validation passes, we create the task and return a success response.

This pattern helps ensure your API only accepts valid data and gives clear feedback when something is wrong.

Just like you did in the POST route, you can use Zod to validate the body of PUT and PATCH requests — but this time with different rules for each method.

Let’s take a look at the logic inside src/app/api/tasks/[id]/route.ts:

import { putTaskSchema, patchTaskSchema } from '@/lib/validation/taskSchemas';

PUT Endpoint: All Fields Required: The PUT handler replaces the entire task, so we expect all task fields to be provided:

export async function PUT(req: NextRequest, { params }: { params: { id: string } }) {
  const id = parseInt(params.id);
  const body = await req.json();

  const parsed = putTaskSchema.safeParse(body);
  if (!parsed.success) return createErrorResponse(parsed.error.format(), 400);

  const updated = await updateTask(id, parsed.data);
  if (!updated) return createErrorResponse('Task not found', 404);

  return createSuccessResponse(updated);
}

• putTaskSchema validates the body and expects all fields.
• If the input is valid and the task exists, it’s updated.
• If the task doesn’t exist or validation fails, the API returns an error.

PATCH Endpoint: Partial Updates Allowed The PATCH handler only updates fields that the client provides:

export async function PATCH(req: NextRequest, { params }: { params: { id: string } }) {
  const id = parseInt(params.id);
  const body = await req.json();

  const parsed = patchTaskSchema.safeParse(body);
  if (!parsed.success) return createErrorResponse(parsed.error.format(), 400);

  const updated = await updateTask(id, parsed.data);
  if (!updated) return createErrorResponse('Task not found', 404);

  return createSuccessResponse(updated);
}

• patchTaskSchema uses .partial(), so it accepts any subset of task fields. This allows clients to send just what they want to change — e.g. { completed: true }.

--

In this lesson, you learned:

• Why data validation is important for production-ready APIs
• How to use Zod to define and check schemas for your data
• How to handle validation results in your Next.js API endpoints

With these skills, you are ready to practice adding and using validation in your own API routes. In the next exercises, you will get hands-on experience with Zod and see how it helps keep your application safe and reliable.