Table of Contents

1. Introduction
2. Optionality in TypeScript: A Quick Refresher
3. Introducing z.interface()
4. Recursive Types Made Simple With z.interface()
5. z.object() vs z.interface(): A Side-by-Side Comparison
6. Use Cases
7. Conclusion & Recommendations

Introduction

Zod has become the go-to schema validation library for TypeScript developers who want both runtime validation and static type safety — all from a single source of truth. With the release of Zod v4, the library introduces a new API that quietly solves some long-standing limitations around optional properties and recursive types: z.interface().

At first glance, this new API might seem redundant — after all, Zod already had z.object() for defining object schemas. But beneath the surface, z.interface() offers a more precise and predictable way to model optional keys and self-referential structures — problems that previously required workarounds like z.lazy() and redundant casting.

In this article, we’ll explore what makes z.interface() a significant step forward. We’ll break down its syntax, show how it handles optionality more accurately than z.object(), and demonstrate how it simplifies defining recursive types — all while maintaining full type inference.

Whether you're building complex APIs, recursive data models, or just want to mirror TypeScript types more faithfully, z.interface() is likely the better tool — and by the end of this article, you’ll understand why.

Optionality in TypeScript: A Quick Refresher

To fully appreciate what z.interface() brings to the table, it's important to first understand the two distinct forms of optionality in TypeScript:

1. Key Optionality

This means the key may be omitted entirely from the object.

type KeyOptional = {
  name?: string;
};

Here, the property name is optional — it may be omitted, and if present, must be a string.

2. Value Optionality

This means the key is required, but the value may be undefined.

type ValueOptional = {
  name: string | undefined;
};

In this case, the key name must be present, but it can be set to undefined.

🤯 Subtle But Significant

Although these two types look similar, they express very different intentions in type design and runtime behavior:

• name?: string allows the absence of the key
• name: string | undefined mandates the presence of the key, but allows an undefined value

TypeScript models both, but before Zod 4, Zod could not cleanly represent this distinction. The existing z.object() API would automatically interpret undefined in the value schema as implying optionality in the key — collapsing both cases into one.

That’s where z.interface() comes in.

Introducing z.interface()

Zod 4 introduces a new object schema API: z.interface(). While it behaves almost identically to z.object() under the hood, it provides two powerful advantages:

1. Precise control over key vs. value optionality
2. Native support for recursive types using getter syntax

Let’s break each of these down.

Differentiating Key and Value Optionality

The core improvement is how z.interface() makes optionality explicit by moving key optionality into the key name itself — using the ? suffix.

🔹 Key Optional (name?)

const keyOptional = z.interface({
  "name?": z.string(),
});

Inferred type:

type KeyOptional = {
  name?: string;
};

Here, the key is optional, but if present, the value must be a string.

🔸 Value Optional (string | undefined)

const valueOptional = z.interface({
  name: z.string().optional(),
});

Inferred type:

type ValueOptional = {
  name: string | undefined;
};

Here, the key is required, but the value may be undefined. This is a completely different contract than the previous example — and now Zod can express both precisely.

What This Solves

Zod 3 could not distinguish between these two cases — both ended up as { name?: string | undefined }. With z.interface(), you get full fidelity with how TypeScript models optional keys and values.

Under the Hood

Despite the API differences, z.object() and z.interface() share the same internal parsing engine. This means:

• Same runtime performance
• Same validation mechanics
• But z.interface() gives you more precision in schema design

Next, we’ll explore how z.interface() makes recursive types dead simple.

Recursive Types Made Simple With z.interface()

One of the standout features of z.interface() is how it dramatically simplifies recursive (cyclical) schema definitions — a task that was notoriously awkward in previous Zod versions.

The Problem in Zod v3

In Zod v3, defining a recursive schema required a multi-step workaround:

• Use z.lazy() to defer schema evaluation
• Create a separate TypeScript interface for the recursive structure
• Manually cast the schema to a z.ZodType<T> to satisfy TypeScript

Example (Zod v3)

interface Category {
  name: string;
  subcategories: Category[];
}
const Category: z.ZodType<Category> = z.object({
  name: z.string(),
  subcategories: z.lazy(() => Category.array()),
});

This pattern worked, but it was verbose, unintuitive, and repetitive.

🌟 The Zod 4 Solution: Getter Syntax

With z.interface(), you can define self-referential schemas natively using a getter. Zod will automatically evaluate the property lazily — no need for z.lazy() or type casting.

Example (Zod v4)

const Category = z.interface({
  name: z.string(),
  get subcategories() {
    return z.array(Category);
  },
});

• Clean
• No casting
• No z.lazy()
• Full type inference

Why It Matters

Recursive structures are common in:

• Nested UI components
• File/folder trees
• GraphQL schemas
• Database models (e.g., categories, comments, threads)

With z.interface(), you can now model these structures in a fully type-safe and intuitive way, with minimal boilerplate.

z.object() vs z.interface(): A Side-by-Side Comparison

Zod v4 maintains both z.object() and z.interface() for defining object schemas — but they serve different purposes when it comes to precision and clarity.

Here’s a direct comparison to help you decide when to use which:

Use Cases

Use z.object() when:

• You need simple, flat object schemas
• You don’t need fine-grained control over optionality
• You're working in legacy codebases or prefer its simpler syntax

Use z.interface() when:

You need precise modeling of optional keys vs optional values

• You're working with recursive types
• You want full parity with complex TypeScript shapes

Conclusion & Recommendations

Zod v4’s introduction of z.interface() marks a thoughtful evolution in schema design. It doesn't aim to replace z.object() — but rather to fill in the gaps where z.object() fell short, especially around optionality semantics and recursive types.

Key Takeaways

• Precise optionality: z.interface() distinguishes between key optional ("key?") and value optional (key: z.type().optional()) in a way that aligns perfectly with TypeScript's behavior.
• Simplified recursion: Recursive schemas are now first-class citizens, thanks to the get-based lazy evaluation model. No more z.lazy() or type casting.
• Non-breaking upgrade: You can adopt z.interface() incrementally. It coexists with z.object() and uses the same parser under the hood.