Every API endpoint makes an implicit promise to the code behind it: by the time this handler's business logic runs, the request has the shape the logic expects. A `quantity` field is a positive integer, not a string, not negative, not a number so large it overflows a downstream calculation. An `email` field is a plausible email address, not an object, not an array with a thousand entries. That promise is never automatically true — it's true only if something checks it before business logic runs, and input validation is the discipline of making that check explicit, structural, and impossible to bypass rather than an assumption every handler quietly relies on.
The next few lessons in this course cover specific failures that happen when that promise is broken — injection, server-side request forgery, mass assignment — and every one of them is, at its root, a validation gap: data the application should never have accepted reached code that trusted it anyway. This lesson is the general discipline those specific lessons all build on: define what a valid request looks like, enforce that definition before any handler logic runs, and reject anything that doesn't match rather than trying to sanitise or work around whatever arrived.
Schema enforcement is validation made systematic rather than ad hoc: instead of scattering individual `if` checks for each field across each handler — a pattern that's easy to get partially right and just as easy to forget entirely on a new endpoint — a schema declares the complete, exact shape of a valid request once, and a validation library rejects anything that doesn't conform before the handler ever sees it.
The two ideas that make input validation actually effective, rather than a box-ticking exercise, are allowlisting over blocklisting — define what's permitted, not what's forbidden — and validating at the boundary, as early as possible in the request lifecycle, so nothing downstream ever has to guess whether the data reaching it was checked.