Schema Validation

Your API accepts a JSON body to create a user. The frontend team sends { "name": "Roni", "email": "roni@example.com", "age": 28 }. Works perfectly. Then a mobile developer sends { "name": "", "email": "not-an-email", "age": "twenty-eight" }. Your API crashes because it tried to do math on the string "twenty-eight."

You could add individual checks: if (typeof age !== 'number') throw error. But with 50 API endpoints, each accepting 5 to 15 fields, that is hundreds of manual checks. Miss one, and bad data gets through. Worse, your TypeScript types say age: number but nothing at runtime enforces it. The types lie.

Schema validation replaces ad-hoc checks with a formal definition of what valid data looks like. You define the schema once: "name is a required non-empty string, email matches an email pattern, age is a number between 1 and 150." The validation library checks every request against it. One schema, total coverage, consistent error messages.

This is not a theoretical concern. In 2022, a fintech startup had a production incident where a partner API sent amounts as strings instead of numbers. Their TypeScript types said amount: number, but the runtime accepted whatever JSON.parse produced. The result: negative balances, incorrect transaction records, and a week of manual data cleanup. A single Zod schema would have caught it at the API boundary.

Schema validation in a typical request lifecycle:

1. Request arrives with JSON body
2. Schema validates structure, types, formats, ranges
3. If invalid: return 400 with specific error details ("age must be a number")
4. If valid: parsed and typed data flows into business logic
5. Business logic applies domain rules (separate from schema validation)

The schema handles "is this well-formed data?" Business logic handles "is this valid for our domain?"